From benjaminrk at gmail.com  Fri Jun  1 00:51:46 2012
From: benjaminrk at gmail.com (MinRK)
Date: Thu, 31 May 2012 21:51:46 -0700
Subject: [IPython-dev] Bumping up priority of thinking about output
	scrolling/control
In-Reply-To: <CAHAreOrE4sMfPCMUfu8yJOwMB5gK9H2HD7Tf-vh+Ny701e6==g@mail.gmail.com>
References: <CAHAreOrsh7R5VrJy8NTdMOF0ZrmLfGfYxeT96HNZNa2ZwdYDKw@mail.gmail.com>
	<CAH4pYpRQbaJ0oAj0+4UoO_gidxzCnDEMiPc7XB9hPiwpGpXRHQ@mail.gmail.com>
	<CAHAreOrE4sMfPCMUfu8yJOwMB5gK9H2HD7Tf-vh+Ny701e6==g@mail.gmail.com>
Message-ID: <CAHNn8BVHPw29eN0_uf4hNzXuSzrTQa+wBa5reDpKcEF3OxGuAg@mail.gmail.com>

On Thu, May 31, 2012 at 8:30 PM, Fernando Perez <fperez.net at gmail.com>wrote:

> On Thu, May 31, 2012 at 8:22 PM, Brian Granger <ellisonbg at gmail.com>
> wrote:
> > i can look into this.  But the other option for the output of multiple
> > engines is to build a simple widget that has a slider and allows you
> > the slide through the output of the different engines.  But I agree
> > that we need a more general solution to this issue.
>
> I think it's worth thining about the clean solution for the long run:
> Titus had examples that were unmanageable even without any
> parallelism, simply because of very long running code that had super
> verbose stdout.  Without something to manage output size, his demos
> would have been simply impossible.  He actually did the public demos
> off Min's quick branch, but that's not a long-term solution :)
>
> So let's see what we can do for a clean solution we're happy with that
> applies even in the absence of multiple engines.  Obviously your idea
> could also be quite useful for that case, but let's first think about
> what to do with stdout of absurd lengths...
>

I peeked at my old branch, and did a cleaner version here:
https://github.com/ipython/ipython/pull/1825

It's simple CSS as suggested
here<https://github.com/ipython/ipython/issues/1553#issuecomment-4963443>,
but required a slightly ugly workaround for the fact that FF's box-model
doesn't properly measure the height of max-height limited children
(container height is calculated ignoring max-height truncation).  The hack
is to shrink-wrap the parent, which works on FF but breaks the display on
WebKit.

I wouldn't say it's particularly pretty (especially on FF, but little is),
but it solves a problem.

-MinRK


> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120531/e6042403/attachment.html>

From ellisonbg at gmail.com  Fri Jun  1 01:37:23 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Thu, 31 May 2012 22:37:23 -0700
Subject: [IPython-dev] Hard to keep up...
Message-ID: <CAH4pYpQhTTZzNq+V+HNeYhhZKpV_oufHi9KBwtMHRfr2dqXceA@mail.gmail.com>

Hi,

Fernando and I were talking today about the serious problem we have -
we can hardly keep up with all the code everyone is writing!  It is
truly spectacular all the work the everyone is doing: coding, helping
with code reviews, testing, discussing, etc.  I just looked on github
and we merged 14 pull requests in the last 24 hours, and there were
another 5 created today.  Amazing - great work everyone!

Cheers,

Brian

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


From bussonniermatthias at gmail.com  Fri Jun  1 02:32:12 2012
From: bussonniermatthias at gmail.com (Matthias BUSSONNIER)
Date: Fri, 1 Jun 2012 08:32:12 +0200
Subject: [IPython-dev] Hard to keep up...
In-Reply-To: <CAH4pYpQhTTZzNq+V+HNeYhhZKpV_oufHi9KBwtMHRfr2dqXceA@mail.gmail.com>
References: <CAH4pYpQhTTZzNq+V+HNeYhhZKpV_oufHi9KBwtMHRfr2dqXceA@mail.gmail.com>
Message-ID: <AD2327DA-673B-40FE-B6AB-8DD470D6A8F9@gmail.com>


Le 1 juin 2012 ? 07:37, Brian Granger a ?crit :

> Hi,
> 
> Fernando and I were talking today about the serious problem we have -
> we can hardly keep up with all the code everyone is writing!  It is
> truly spectacular all the work the everyone is doing: coding, helping
> with code reviews, testing, discussing, etc.  I just looked on github
> and we merged 14 pull requests in the last 24 hours, and there were
> another 5 created today.  Amazing - great work everyone!

An you are awake when most of this stuff appends. 
I just woke Up and have around 100 mails only from github...

Thanks to every one, and happy that 1711 is merged.  
-- 
Matthias

> 
> Cheers,
> 
> Brian
> 
> -- 
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu and ellisonbg at gmail.com
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



From fperez.net at gmail.com  Fri Jun  1 02:56:11 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 31 May 2012 23:56:11 -0700
Subject: [IPython-dev] Hard to keep up...
In-Reply-To: <AD2327DA-673B-40FE-B6AB-8DD470D6A8F9@gmail.com>
References: <CAH4pYpQhTTZzNq+V+HNeYhhZKpV_oufHi9KBwtMHRfr2dqXceA@mail.gmail.com>
	<AD2327DA-673B-40FE-B6AB-8DD470D6A8F9@gmail.com>
Message-ID: <CAHAreOrjUoZH0bghFJVEhML6fdoRbvvgNbNB9yMRmDpH96C3Uw@mail.gmail.com>

On Thu, May 31, 2012 at 11:32 PM, Matthias BUSSONNIER
<bussonniermatthias at gmail.com> wrote:
>
> An you are awake when most of this stuff appends.
> I just woke Up and have around 100 mails only from github...

Today I went for lunch with a clear lists inbox and came back to 25
messages.  It's crazy :)

Just to second Brian's comments, thanks to everyone for all the
awesome work!  It's great to see the project so active, and we can
only hope we'll be able to continue working this well; the really
interesting work is yet to come.  Much of what we've been doing
recently is laying down the infrastructure we'd had in mind for a very
long time but that took us a while to build.  The pieces are finally
falling in place, and the fun should really get going in earnest!

Cheers,

f


From johann.cohentanugi at gmail.com  Fri Jun  1 03:41:40 2012
From: johann.cohentanugi at gmail.com (Johann Cohen-Tanugi)
Date: Fri, 01 Jun 2012 09:41:40 +0200
Subject: [IPython-dev] local ipython install from github
In-Reply-To: <4FC7FDE3.7010509@gmail.com>
References: <4FC7FDE3.7010509@gmail.com>
Message-ID: <4FC87234.1000203@gmail.com>

Hi, there has been some blogs in the past helping peope use ipython with 
virtualenv : see for instance 
http://igotgenes.blogspot.fr/2010/01/interactive-sandboxes-using-ipython.html
Has this become obsolete with new ipython?

best,
Johann

On 06/01/2012 01:25 AM, Ralf Hemmecke wrote:
> Maybe this is interesting for someone or for the ipython documentation...
>
> https://sites.google.com/site/hemmecke/ipython-nb
>
> Ralf
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>


From benjaminrk at gmail.com  Fri Jun  1 04:18:58 2012
From: benjaminrk at gmail.com (MinRK)
Date: Fri, 1 Jun 2012 01:18:58 -0700
Subject: [IPython-dev] local ipython install from github
In-Reply-To: <4FC87234.1000203@gmail.com>
References: <4FC7FDE3.7010509@gmail.com> <4FC87234.1000203@gmail.com>
Message-ID: <CAHNn8BWFdsAi+Zf6_G-hPkjRnCgDzp9OdZQfagRJT4jj-0cuaA@mail.gmail.com>

On Fri, Jun 1, 2012 at 12:41 AM, Johann Cohen-Tanugi <
johann.cohentanugi at gmail.com> wrote:

> Hi, there has been some blogs in the past helping peope use ipython with
> virtualenv : see for instance
>
> http://igotgenes.blogspot.fr/2010/01/interactive-sandboxes-using-ipython.html
> Has this become obsolete with new ipython?
>

Many of these helpers seriously misunderstand virtualenv and Python
packages, specifically the fact that IPython is just a Python package.  To
get IPython to work perfectly in a virtualenv is a single step (as it has
always been, I think): install IPython in the virtualenv.  Most of the
tricks in these various guides are about unmangling paths that were only
problematic because the process started with the un-patched system Python,
rather than the one in the venv.

-MinRK


>
> best,
> Johann
>
> On 06/01/2012 01:25 AM, Ralf Hemmecke wrote:
> > Maybe this is interesting for someone or for the ipython documentation...
> >
> > https://sites.google.com/site/hemmecke/ipython-nb
> >
> > Ralf
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> >
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120601/d44b2c2e/attachment.html>

From hemmecke at gmail.com  Fri Jun  1 04:19:37 2012
From: hemmecke at gmail.com (Ralf Hemmecke)
Date: Fri, 01 Jun 2012 10:19:37 +0200
Subject: [IPython-dev] local ipython install from github
In-Reply-To: <4FC87234.1000203@gmail.com>
References: <4FC7FDE3.7010509@gmail.com> <4FC87234.1000203@gmail.com>
Message-ID: <4FC87B19.1020105@gmail.com>

On 06/01/2012 09:41 AM, Johann Cohen-Tanugi wrote:
> Hi, there has been some blogs in the past helping peope use ipython with
> virtualenv : see for instance
> http://igotgenes.blogspot.fr/2010/01/interactive-sandboxes-using-ipython.html

Since I am neither an expert with python nor with virtualenv, I had 
another approach than what seems to be written in the above cited blog.

There python is installed system wide and ipython is installed on top of 
that. Then virtualenv is installed to separate environments.

In my setup, I install virtualenv and let my PATH point to the programs 
installed in the respective directory. Only then I install IPython. So 
my believe is that I python actually never sees the system python since 
$HOME/software/python comes first in the PATH. It would surprise me if 
ipython and virtualenv would not work nicely together in such a setup. 
But, of course, I don't know for sure. So I'm quite interested how other 
people see this.

My setup is perhaps not appropriate for any python development, but 
would be good enough for me.
Any opinions welcome.

Ralf


From takowl at gmail.com  Fri Jun  1 06:21:32 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Fri, 1 Jun 2012 11:21:32 +0100
Subject: [IPython-dev] local ipython install from github
In-Reply-To: <4FC87234.1000203@gmail.com>
References: <4FC7FDE3.7010509@gmail.com> <4FC87234.1000203@gmail.com>
Message-ID: <CAOvn4qh9de4fzCkY_kpshMWTSoj-_SgkqH9eMWkNq-jkwghm0w@mail.gmail.com>

On 1 June 2012 08:41, Johann Cohen-Tanugi <johann.cohentanugi at gmail.com> wrote:
> Hi, there has been some blogs in the past helping peope use ipython with
> virtualenv : see for instance
> http://igotgenes.blogspot.fr/2010/01/interactive-sandboxes-using-ipython.html
> Has this become obsolete with new ipython?

We've integrated the trick those posts describe, so that if you have a
virtualenv active when you start ipython 0.13, the virtualenv's
package directories will be added to sys.path, and you can import
packages installed in the virtualenv. So yes, they are obsolete as of
the next release.

As Min says, though, we still recommend installing IPython inside the
virtualenv if you want everything to work properly. But we know that
many people use IPython as a quick and simple Python shell, so we
don't want to force everyone to install it in each virtualenv just to
get basic functionality.

Thomas


From jason-sage at creativetrax.com  Fri Jun  1 06:27:20 2012
From: jason-sage at creativetrax.com (Jason Grout)
Date: Fri, 01 Jun 2012 05:27:20 -0500
Subject: [IPython-dev] Bumping up priority of thinking about output
	scrolling/control
In-Reply-To: <CAHAreOrE4sMfPCMUfu8yJOwMB5gK9H2HD7Tf-vh+Ny701e6==g@mail.gmail.com>
References: <CAHAreOrsh7R5VrJy8NTdMOF0ZrmLfGfYxeT96HNZNa2ZwdYDKw@mail.gmail.com>
	<CAH4pYpRQbaJ0oAj0+4UoO_gidxzCnDEMiPc7XB9hPiwpGpXRHQ@mail.gmail.com>
	<CAHAreOrE4sMfPCMUfu8yJOwMB5gK9H2HD7Tf-vh+Ny701e6==g@mail.gmail.com>
Message-ID: <4FC89908.4020907@creativetrax.com>

On 5/31/12 10:30 PM, Fernando Perez wrote:
> On Thu, May 31, 2012 at 8:22 PM, Brian Granger<ellisonbg at gmail.com>  wrote:
>> i can look into this.  But the other option for the output of multiple
>> engines is to build a simple widget that has a slider and allows you
>> the slide through the output of the different engines.  But I agree
>> that we need a more general solution to this issue.
>
> I think it's worth thining about the clean solution for the long run:
> Titus had examples that were unmanageable even without any
> parallelism, simply because of very long running code that had super
> verbose stdout.  Without something to manage output size, his demos
> would have been simply impossible.  He actually did the public demos
> off Min's quick branch, but that's not a long-term solution :)
>
> So let's see what we can do for a clean solution we're happy with that
> applies even in the absence of multiple engines.  Obviously your idea
> could also be quite useful for that case, but let's first think about
> what to do with stdout of absurd lengths...

Just FYI, Sage takes a slightly different approach.  When output reaches 
a certain length, it is instead saved off to a file, and just the start 
and ending of the output is displayed, separated by a noticeable 
ellipsis.  At the end, there is a link to the output file, which, when 
clicks, opens up in the browser to display all of the output.  While 
output is being returned, this display (of the last bit of output) is 
continuously updated.  See http://sagenb.org/home/pub/4784/ for an example.

Mathematica 8 displays the first and last bit of output, but then 
there's a button which will show progressively more output.  See the 
last example at 
http://reference.wolfram.com/mathematica/tutorial/ShortAndShallowOutput.html.

Jason


From hemmecke at gmail.com  Fri Jun  1 10:12:41 2012
From: hemmecke at gmail.com (Ralf Hemmecke)
Date: Fri, 01 Jun 2012 16:12:41 +0200
Subject: [IPython-dev] doc error
Message-ID: <4FC8CDD9.2030007@gmail.com>

http://ipython.org/ipython-doc/dev/development/messaging.html#execution-semantics

Item 3 has "compute" two times.

==========
If #2 succeeds, compute user_variables and user_expressions are computed.
==========

Is this somewhere in the git repo? Maybe next time I could immediately 
provide a patch and pull request.

BTW, this sentence does not specify what happens, if #2 does not 
succeed. In fact, with that sentence it would be perfectly valid if 
user_variables is evaluated and user_expressions is not. Even if IPython 
produces a segfault in case "#2 does not succeed" would be a valid 
implementation of the "Execution semantics".

Ralf


From takowl at gmail.com  Fri Jun  1 11:03:01 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Fri, 1 Jun 2012 16:03:01 +0100
Subject: [IPython-dev] doc error
In-Reply-To: <4FC8CDD9.2030007@gmail.com>
References: <4FC8CDD9.2030007@gmail.com>
Message-ID: <CAOvn4qgfP=fM8_8oNW2nXCPttopQjkmeD6k4GfaVBOgvaFHrGw@mail.gmail.com>

On 1 June 2012 15:12, Ralf Hemmecke <hemmecke at gmail.com> wrote:
> Is this somewhere in the git repo?

It certainly is!

https://github.com/ipython/ipython/blob/master/docs/source/development/messaging.txt

Thanks for pointing it out.

Thomas


From ellisonbg at gmail.com  Fri Jun  1 12:31:30 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Fri, 1 Jun 2012 09:31:30 -0700
Subject: [IPython-dev] [IPython-User] Another monster landed: refactored
 JavaScript, new tooltips and interactive widgets in the notebook
In-Reply-To: <20120601083615.GB26696@starnesm-desktop>
References: <CAHAreOrCNMrnQSPW2se-9iJ6d7Xj7d+psHgO6a9LcV=iOmFGew@mail.gmail.com>
	<20120601083615.GB26696@starnesm-desktop>
Message-ID: <CAH4pYpTfj6jAwt_onww5z4YAsiyjrZjxuRqn6tSmCyHsFUZM4w@mail.gmail.com>

Mark,

On Fri, Jun 1, 2012 at 1:36 AM, Mark Starnes <mark.starnes at fttech.co.uk> wrote:
> This is my first post. ?I've been using IPython
> for years now and always appreciated it but the
> notebook and the work going into it has forced me
> into saying thanks.
>
> Thank you for all this work! The way I work has
> completely changed (for the better) due to you
> and your team's efforts.

Thanks for the feedback!

Cheers,

Brian

> Best regards,
>
> Mark Starnes.
>
>
> On Thu, May 31, 2012 at 05:30:05PM -0700, Fernando Perez wrote:
>> Hi folks,
>>
>> After the merge of the previous big two branches (the merging of the
>> interactive and parallel kernels into one object and the magics
>> refactoring/cell support), the third monster we had in flight has now
>> landed:
>>
>> https://github.com/ipython/ipython/pull/1711/
>>
>> For those of you not following the github hooks obsessively, here's
>> the high-level view of the goodies:
>>
>> - New graphical tooltip with keyboard control: successive presses of
>> the TAB key will expand it, pin it for 10 s (a clock icon is shown),
>> and send its content to the bottom help pager (which is now
>> resizable).
>>
>> - Completer has been refactored into a new class and now can analyze
>> the current cell to support completions on objects that don't exist in
>> the kernel yet (because the cell hasn't been executed).
>>
>> - All the client-side JavaScript has been decoupled to ease reuse of
>> parts of the machinery without having to build a full-blown notebook.
>> This will make it much easier to communicate with an IPython kernel
>> from existing web pages and to integrate single cells into other
>> sites, without loading the full notebook document-like UI.
>>
>> - This refactoring also enables the possibility of writing dynamic
>> javascript widgets that are returned from Python code and that present
>> an interactive view to the user, with callbacks in Javascript
>> executing calls to the Kernel. ?This will enable many interactive
>> elements to be added by users in notebooks.
>>
>> An example of this capability has been provided as a proof of concept
>> in `docs/examples/widgets` that lets you directly communicate with one
>> or more parallel engines, acting as a mini-console for parallel
>> debugging and introspection.
>>
>>
>> Kudos to Brian and Matthias for the excellent work they put into this,
>> it was over 84 commits and involved the merging of several
>> intermediate pull requests. ?But the goodies shipped therein should be
>> *very* ?useful.
>>
>> We've seen recently attempts at interactive plots with d3/flot and
>> other similar tools; now the machinery is ready to do that cleanly, so
>> by all means have fun!
>>
>> Cheers,
>>
>> f
>> _______________________________________________
>> IPython-User mailing list
>> IPython-User at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-user
>
> --
> Dr. Mark Starnes
> Principal Physicist
> FT Technologies
> Church Lane
> Teddington
> TW11 8PA
>
> web: ?www.fttech.co.uk
> DDI: ?0208 614 2730
> _______________________________________________
> IPython-User mailing list
> IPython-User at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-user



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


From ellisonbg at gmail.com  Fri Jun  1 12:35:29 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Fri, 1 Jun 2012 09:35:29 -0700
Subject: [IPython-dev] Bumping up priority of thinking about output
	scrolling/control
In-Reply-To: <4FC89908.4020907@creativetrax.com>
References: <CAHAreOrsh7R5VrJy8NTdMOF0ZrmLfGfYxeT96HNZNa2ZwdYDKw@mail.gmail.com>
	<CAH4pYpRQbaJ0oAj0+4UoO_gidxzCnDEMiPc7XB9hPiwpGpXRHQ@mail.gmail.com>
	<CAHAreOrE4sMfPCMUfu8yJOwMB5gK9H2HD7Tf-vh+Ny701e6==g@mail.gmail.com>
	<4FC89908.4020907@creativetrax.com>
Message-ID: <CAH4pYpT_sX1c=O9f8RPE65KPkk7m_asWM9fmUnd1fGLHcXLLKA@mail.gmail.com>

Let's continue this discussion on Min's PR...

Cheers,

Brian

On Fri, Jun 1, 2012 at 3:27 AM, Jason Grout <jason-sage at creativetrax.com> wrote:
> On 5/31/12 10:30 PM, Fernando Perez wrote:
>> On Thu, May 31, 2012 at 8:22 PM, Brian Granger<ellisonbg at gmail.com> ?wrote:
>>> i can look into this. ?But the other option for the output of multiple
>>> engines is to build a simple widget that has a slider and allows you
>>> the slide through the output of the different engines. ?But I agree
>>> that we need a more general solution to this issue.
>>
>> I think it's worth thining about the clean solution for the long run:
>> Titus had examples that were unmanageable even without any
>> parallelism, simply because of very long running code that had super
>> verbose stdout. ?Without something to manage output size, his demos
>> would have been simply impossible. ?He actually did the public demos
>> off Min's quick branch, but that's not a long-term solution :)
>>
>> So let's see what we can do for a clean solution we're happy with that
>> applies even in the absence of multiple engines. ?Obviously your idea
>> could also be quite useful for that case, but let's first think about
>> what to do with stdout of absurd lengths...
>
> Just FYI, Sage takes a slightly different approach. ?When output reaches
> a certain length, it is instead saved off to a file, and just the start
> and ending of the output is displayed, separated by a noticeable
> ellipsis. ?At the end, there is a link to the output file, which, when
> clicks, opens up in the browser to display all of the output. ?While
> output is being returned, this display (of the last bit of output) is
> continuously updated. ?See http://sagenb.org/home/pub/4784/ for an example.
>
> Mathematica 8 displays the first and last bit of output, but then
> there's a button which will show progressively more output. ?See the
> last example at
> http://reference.wolfram.com/mathematica/tutorial/ShortAndShallowOutput.html.
>
> Jason
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



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


From stefan at sun.ac.za  Fri Jun  1 16:31:35 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 1 Jun 2012 13:31:35 -0700
Subject: [IPython-dev] Octave magic
Message-ID: <CABDkGQnFtPrH2HYeJpjO_DZobNvBnE3a5mxuyDBTzkHknWy-gg@mail.gmail.com>

Hey, folks

Just a heads up that I have a working Octave magic here:

https://github.com/stefanv/ipython/tree/octavemagic

Example output:

http://mentat.za.net/refer/ipython_octave.pdf

There are still a few bugs remaining (like blank plots sometimes being
generated after executing a cell--as shown in the PDF), but I'll sort
that out on Monday when I get back to this.  Feel free to try it
out--you just need to install oct2py beforehand, using

easy_install oct2py

Regards
St?fan


From jason-sage at creativetrax.com  Fri Jun  1 17:07:37 2012
From: jason-sage at creativetrax.com (Jason Grout)
Date: Fri, 01 Jun 2012 16:07:37 -0500
Subject: [IPython-dev] MultiKernelManager vs. ipcluster
Message-ID: <4FC92F19.10308@creativetrax.com>

Hi everyone,

As mentioned yesterday, we've been exploring ways to implement the Sage 
cell server using the IPython capabilities better.  This message is a 
call for comments, as well as a few questions about the directions of 
things like ipcluster.

Our goals are to:

* start multiple kernels/engines very quickly (e.g., through forking a 
master kernel)
* connect single kernels to single web sessions
* be able to transfer files back and forth between the executing 
environment and the web browser
* do things as securely as is reasonable (e.g., workers are running on a 
firewalled virtual instance, etc.)
* be able to use an enterprise-level web server, such as Google App Engine.


We've explored two approaches, and have somewhat-barely-working partial 
proofs-of-concepts of each:

IPCLUSTER
---------

We implemented a forking engine factory which is run on the worker 
computer.  A cluster can start up new engines by sshing into the worker 
computer and sending a message to the forking engine factory.  A new 
engine starts and then registers with the controller.  We're thinking it 
might be best to implement a new scheduler that would take messages, 
check to see if the session id matches up with one of the 
currently-running engines, and send the message to the appropriate 
engine if so.  If the message id does not match up to a currently 
running engine, then the scheduler would start up a new engine (can the 
scheduler do this?)

The client would basically be the zmq/socket.io bridge, translating 
messages to/from the controller and the browser.  I guess we could 
implement one client per session, or we could implement one overall 
client that would route cluster output to the appropriate browser.


MULTI FORKING KERNEL MANAGER
----------------------------

This approach stays much closer to the current IPython notebook 
architecture.  A MultiKernelManager starts up kernels using a 
ForkingKernelManager (based on Min's gist the other day).  Each kernel 
sets up a connection to a specific set of websocket channels through a 
tornado-based bridge.  We still have to implement things like separation 
of the forked kernels (on a separate ssh account somewhere) and the 
tornado handler, and things like that.


THOUGHTS
--------
It seems that the multikernel manager is much lighter-weight, but we'd 
have to implement a lot of the enterprise-level functionality that the 
cluster already has.  On the other hand, the ipcluster approach really 
does more than we need, so, in a sense, we need to trim it back.  We're 
not asking you to make a decision for us, obviously, but it would be 
valuable to hear any comments or suggestions.

SPECIFIC QUESTIONS
------------------

1. Brian, why did you decide to make a new multikernel manager instead 
of trying to leverage the ipcluster functionality to execute multiple 
engines?

2. Some time ago, on this list or on a pull request, there was some 
discussion about the difference between kernels and engines (or the lack 
of difference).  Are there some plans to simplify the ipcluster 
architecture a bit to merge the concepts of engines and kernels?

3. Any idea about how much overhead the cluster introduces for lots of 
short computations involving lots of output?  We'll test this too, but 
I'm curious if there was thought towards this use-case in the design.

Thanks,

Jason


From fperez.net at gmail.com  Fri Jun  1 18:06:07 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 1 Jun 2012 15:06:07 -0700
Subject: [IPython-dev] Octave magic
In-Reply-To: <CABDkGQnFtPrH2HYeJpjO_DZobNvBnE3a5mxuyDBTzkHknWy-gg@mail.gmail.com>
References: <CABDkGQnFtPrH2HYeJpjO_DZobNvBnE3a5mxuyDBTzkHknWy-gg@mail.gmail.com>
Message-ID: <CAHAreOrk=ZOKPSKypzs6MEBjzAfMYoN6jVk5W=3bFajoPT=CpQ@mail.gmail.com>

On Fri, Jun 1, 2012 at 1:31 PM, St?fan van der Walt <stefan at sun.ac.za> wrote:
> Just a heads up that I have a working Octave magic here:
>
> https://github.com/stefanv/ipython/tree/octavemagic

Awesome!  0.13 will come out of the gate with Cython, R and Octave
integration, as well as shell magics (for more complex interaction
with a remote system than ! is comfortable for) and %%file (for
editing real files in remote systems you don't have SSH access to).

It's going to be fun :)

f


From fperez.net at gmail.com  Fri Jun  1 18:06:07 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 1 Jun 2012 15:06:07 -0700
Subject: [IPython-dev] Octave magic
In-Reply-To: <CABDkGQnFtPrH2HYeJpjO_DZobNvBnE3a5mxuyDBTzkHknWy-gg@mail.gmail.com>
References: <CABDkGQnFtPrH2HYeJpjO_DZobNvBnE3a5mxuyDBTzkHknWy-gg@mail.gmail.com>
Message-ID: <CAHAreOrk=ZOKPSKypzs6MEBjzAfMYoN6jVk5W=3bFajoPT=CpQ@mail.gmail.com>

On Fri, Jun 1, 2012 at 1:31 PM, St?fan van der Walt <stefan at sun.ac.za> wrote:
> Just a heads up that I have a working Octave magic here:
>
> https://github.com/stefanv/ipython/tree/octavemagic

Awesome!  0.13 will come out of the gate with Cython, R and Octave
integration, as well as shell magics (for more complex interaction
with a remote system than ! is comfortable for) and %%file (for
editing real files in remote systems you don't have SSH access to).

It's going to be fun :)

f


From benjaminrk at gmail.com  Fri Jun  1 18:11:48 2012
From: benjaminrk at gmail.com (MinRK)
Date: Fri, 1 Jun 2012 15:11:48 -0700
Subject: [IPython-dev] Octave magic
In-Reply-To: <CAHAreOrk=ZOKPSKypzs6MEBjzAfMYoN6jVk5W=3bFajoPT=CpQ@mail.gmail.com>
References: <CABDkGQnFtPrH2HYeJpjO_DZobNvBnE3a5mxuyDBTzkHknWy-gg@mail.gmail.com>
	<CAHAreOrk=ZOKPSKypzs6MEBjzAfMYoN6jVk5W=3bFajoPT=CpQ@mail.gmail.com>
Message-ID: <CAHNn8BVb5HdOD-5xhLqbdLkDWpU-by1XOh6WE+7-QEaHP0rySQ@mail.gmail.com>

On Fri, Jun 1, 2012 at 3:06 PM, Fernando Perez <fperez.net at gmail.com> wrote:

> On Fri, Jun 1, 2012 at 1:31 PM, St?fan van der Walt <stefan at sun.ac.za>
> wrote:
> > Just a heads up that I have a working Octave magic here:
> >
> > https://github.com/stefanv/ipython/tree/octavemagic
>
> Awesome!  0.13 will come out of the gate with Cython, R and Octave
> integration, as well as shell magics (for more complex interaction
> with a remote system than ! is comfortable for) and %%file (for
> editing real files in remote systems you don't have SSH access to).
>
> It's going to be fun :)
>

I get the feeling that cell magics are going propagate rapidly.  Perhaps
%load_ext should support git urls :)

-MinRK


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

From benjaminrk at gmail.com  Fri Jun  1 18:11:48 2012
From: benjaminrk at gmail.com (MinRK)
Date: Fri, 1 Jun 2012 15:11:48 -0700
Subject: [IPython-dev] Octave magic
In-Reply-To: <CAHAreOrk=ZOKPSKypzs6MEBjzAfMYoN6jVk5W=3bFajoPT=CpQ@mail.gmail.com>
References: <CABDkGQnFtPrH2HYeJpjO_DZobNvBnE3a5mxuyDBTzkHknWy-gg@mail.gmail.com>
	<CAHAreOrk=ZOKPSKypzs6MEBjzAfMYoN6jVk5W=3bFajoPT=CpQ@mail.gmail.com>
Message-ID: <CAHNn8BVb5HdOD-5xhLqbdLkDWpU-by1XOh6WE+7-QEaHP0rySQ@mail.gmail.com>

On Fri, Jun 1, 2012 at 3:06 PM, Fernando Perez <fperez.net at gmail.com> wrote:

> On Fri, Jun 1, 2012 at 1:31 PM, St?fan van der Walt <stefan at sun.ac.za>
> wrote:
> > Just a heads up that I have a working Octave magic here:
> >
> > https://github.com/stefanv/ipython/tree/octavemagic
>
> Awesome!  0.13 will come out of the gate with Cython, R and Octave
> integration, as well as shell magics (for more complex interaction
> with a remote system than ! is comfortable for) and %%file (for
> editing real files in remote systems you don't have SSH access to).
>
> It's going to be fun :)
>

I get the feeling that cell magics are going propagate rapidly.  Perhaps
%load_ext should support git urls :)

-MinRK


>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120601/7ef0bca6/attachment-0001.html>

From jason-sage at creativetrax.com  Fri Jun  1 18:16:18 2012
From: jason-sage at creativetrax.com (Jason Grout)
Date: Fri, 01 Jun 2012 17:16:18 -0500
Subject: [IPython-dev] Octave magic
In-Reply-To: <CAHAreOrk=ZOKPSKypzs6MEBjzAfMYoN6jVk5W=3bFajoPT=CpQ@mail.gmail.com>
References: <CABDkGQnFtPrH2HYeJpjO_DZobNvBnE3a5mxuyDBTzkHknWy-gg@mail.gmail.com>
	<CAHAreOrk=ZOKPSKypzs6MEBjzAfMYoN6jVk5W=3bFajoPT=CpQ@mail.gmail.com>
Message-ID: <4FC93F32.4040502@creativetrax.com>

On 6/1/12 5:06 PM, Fernando Perez wrote:
> %%file (for
> editing real files in remote systems you don't have SSH access to).

Can you give an example of %%file?  That sounds interesting.

Jason



From fperez.net at gmail.com  Fri Jun  1 18:37:05 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 1 Jun 2012 15:37:05 -0700
Subject: [IPython-dev] Octave magic
In-Reply-To: <CAHNn8BVb5HdOD-5xhLqbdLkDWpU-by1XOh6WE+7-QEaHP0rySQ@mail.gmail.com>
References: <CABDkGQnFtPrH2HYeJpjO_DZobNvBnE3a5mxuyDBTzkHknWy-gg@mail.gmail.com>
	<CAHAreOrk=ZOKPSKypzs6MEBjzAfMYoN6jVk5W=3bFajoPT=CpQ@mail.gmail.com>
	<CAHNn8BVb5HdOD-5xhLqbdLkDWpU-by1XOh6WE+7-QEaHP0rySQ@mail.gmail.com>
Message-ID: <CAHAreOqDmmckjRLEB=eAbGkcTsLHOY=vzDG9zzsu-SoRNGQwHA@mail.gmail.com>

On Fri, Jun 1, 2012 at 3:11 PM, MinRK <benjaminrk at gmail.com> wrote:
> I get the feeling that cell magics are going propagate rapidly. ?Perhaps
> %load_ext should support git urls :)

Not necessarily a bad idea :)


From fperez.net at gmail.com  Fri Jun  1 18:37:05 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 1 Jun 2012 15:37:05 -0700
Subject: [IPython-dev] Octave magic
In-Reply-To: <CAHNn8BVb5HdOD-5xhLqbdLkDWpU-by1XOh6WE+7-QEaHP0rySQ@mail.gmail.com>
References: <CABDkGQnFtPrH2HYeJpjO_DZobNvBnE3a5mxuyDBTzkHknWy-gg@mail.gmail.com>
	<CAHAreOrk=ZOKPSKypzs6MEBjzAfMYoN6jVk5W=3bFajoPT=CpQ@mail.gmail.com>
	<CAHNn8BVb5HdOD-5xhLqbdLkDWpU-by1XOh6WE+7-QEaHP0rySQ@mail.gmail.com>
Message-ID: <CAHAreOqDmmckjRLEB=eAbGkcTsLHOY=vzDG9zzsu-SoRNGQwHA@mail.gmail.com>

On Fri, Jun 1, 2012 at 3:11 PM, MinRK <benjaminrk at gmail.com> wrote:
> I get the feeling that cell magics are going propagate rapidly. ?Perhaps
> %load_ext should support git urls :)

Not necessarily a bad idea :)


From fperez.net at gmail.com  Fri Jun  1 18:40:27 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 1 Jun 2012 15:40:27 -0700
Subject: [IPython-dev] Octave magic
In-Reply-To: <4FC93F32.4040502@creativetrax.com>
References: <CABDkGQnFtPrH2HYeJpjO_DZobNvBnE3a5mxuyDBTzkHknWy-gg@mail.gmail.com>
	<CAHAreOrk=ZOKPSKypzs6MEBjzAfMYoN6jVk5W=3bFajoPT=CpQ@mail.gmail.com>
	<4FC93F32.4040502@creativetrax.com>
Message-ID: <CAHAreOq7wg_C7T2VpfcrqLu0uOx-nhhMMXamDS452AYeahiogA@mail.gmail.com>

On Fri, Jun 1, 2012 at 3:16 PM, Jason Grout <jason-sage at creativetrax.com> wrote:
> Can you give an example of %%file? ?That sounds interesting.

%%file foo.csv
1, 2,3
4,5,6

----

in another cell:

a = np.loadtxt('foo.csv')

etc.

The idea is that it lets you edit right in the notebook arbitrary
local files, which may be tricky to do otherwise if you're logged in a
remote notebook server to which you don't have SSH access.

Not something you're likely to use to write major library code, but
very useful for small edits.

It also means that if you have an analysis notebook that needs to run
say a few shell scripts that call out third-party tools, you can
essentially 'embed' those shell scripts in the notebook itself,
helping with portability, reusability and tracking of your tools.

It's something that is *trivial* for us to add right now, and that can
come in very handy in a multitude of scenarios.

Cheers,

f


From benjaminrk at gmail.com  Fri Jun  1 21:21:56 2012
From: benjaminrk at gmail.com (MinRK)
Date: Fri, 1 Jun 2012 18:21:56 -0700
Subject: [IPython-dev] MultiKernelManager vs. ipcluster
In-Reply-To: <4FC92F19.10308@creativetrax.com>
References: <4FC92F19.10308@creativetrax.com>
Message-ID: <CAHNn8BWVK-HDFnh2B+=3mQV6s=iBmt+5XrnPpczr89=Cq_+8xg@mail.gmail.com>

On Fri, Jun 1, 2012 at 2:07 PM, Jason Grout <jason-sage at creativetrax.com>wrote:

> Hi everyone,
>
> As mentioned yesterday, we've been exploring ways to implement the Sage
> cell server using the IPython capabilities better.  This message is a
> call for comments, as well as a few questions about the directions of
> things like ipcluster.
>
> Our goals are to:
>
> * start multiple kernels/engines very quickly (e.g., through forking a
> master kernel)
> * connect single kernels to single web sessions
> * be able to transfer files back and forth between the executing
> environment and the web browser
> * do things as securely as is reasonable (e.g., workers are running on a
> firewalled virtual instance, etc.)
> * be able to use an enterprise-level web server, such as Google App Engine.
>
>
> We've explored two approaches, and have somewhat-barely-working partial
> proofs-of-concepts of each:
>
> IPCLUSTER
> ---------
>
> We implemented a forking engine factory which is run on the worker
> computer.  A cluster can start up new engines by sshing into the worker
> computer and sending a message to the forking engine factory.  A new
> engine starts and then registers with the controller.  We're thinking it
> might be best to implement a new scheduler that would take messages,
> check to see if the session id matches up with one of the
> currently-running engines, and send the message to the appropriate
> engine if so.  If the message id does not match up to a currently
> running engine, then the scheduler would start up a new engine (can the
> scheduler do this?)
>

Very little of the current scheduler's code would be useful for this.  the
scheduler object is for load-balanced execution, and all of its logic is
involved in deciding what engines should get tasks.  You seem to be looking
for a pattern more like MUX (direct-routing).  For this pattern, IPython
just uses a pure-C MonitoredQueue function from pyzmq.  It sounds like you
want that is initially identical to the zmq_queue function, but on
unroutable requests, it starts a new engine and then routes the request
there.


>
> The client would basically be the zmq/socket.io bridge, translating
> messages to/from the controller and the browser.  I guess we could
> implement one client per session, or we could implement one overall
> client that would route cluster output to the appropriate browser.
>

Again, most of the Client code is involved in dealing with multiple
engines, and interleaving asynchronous requests.  So I would do one of:

* 1 Client per Server process, and 1 light View-like object per session
* build a much lighter Client that is more akin to the KernelManager, which
only talks to one engine.  It's possible this should just be a
KernelManager subclass.


>
> MULTI FORKING KERNEL MANAGER
> ----------------------------
>
> This approach stays much closer to the current IPython notebook
> architecture.  A MultiKernelManager starts up kernels using a
> ForkingKernelManager (based on Min's gist the other day).  Each kernel
> sets up a connection to a specific set of websocket channels through a
> tornado-based bridge.  We still have to implement things like separation
> of the forked kernels (on a separate ssh account somewhere) and the
> tornado handler, and things like that.
>
>
> THOUGHTS
> --------
> It seems that the multikernel manager is much lighter-weight, but we'd
> have to implement a lot of the enterprise-level functionality that the
> cluster already has.  On the other hand, the ipcluster approach really
> does more than we need, so, in a sense, we need to trim it back.  We're
> not asking you to make a decision for us, obviously, but it would be
> valuable to hear any comments or suggestions.
>
> SPECIFIC QUESTIONS
> ------------------
>
> 1. Brian, why did you decide to make a new multikernel manager instead
> of trying to leverage the ipcluster functionality to execute multiple
> engines?
>
> 2. Some time ago, on this list or on a pull request, there was some
> discussion about the difference between kernels and engines (or the lack
> of difference).  Are there some plans to simplify the ipcluster
> architecture a bit to merge the concepts of engines and kernels?
>

Engines and Kernels really are the exact same thing (as of a recent PR,
consolidating the two Kernel classes that had diverged during simultaneous
development).

The IPython Kernel is a single object defined in IPython.zmq.ipkernel

But there are two ways to start a Kernel:

1. IPKernelApp (used by KernelManagers, and `ipython kernel`).
2. IPEngineApp (used by `ipengine`)

At the simplest level, an Engine is a Kernel that connects instead of binds
(for consolidation of connection points at the Controller).

The Kernel object itself does not know whether it is binding or connecting
(in fact, it can already do both at the same time).

All of the practical differences at this point are due to the different
Application classes, which have a different set of command-line options
(IPKernelApp has all the expected shell options, like pylab, etc., while
the EngineApp has some options general to the IPython.parallel apps, like
forwarding logging over zmq).

The remaining differences are configuration details, and ultimately the two
entry points will probably be merged as well, and there will no longer be a
distinction beyond:

Binding Kernel: `ipython kernel `
Engine: `ipython kernel --connect`
Both: `ipython kernel --connect --bind`



> 3. Any idea about how much overhead the cluster introduces for lots of
> short computations involving lots of output?  We'll test this too, but
> I'm curious if there was thought towards this use-case in the design.
>

I haven't done performance tests with output before, but I would expect it
to do fairly well.  It's a  direct PUB-SUB channel up to the Clients (one
pure-C zmq_device hop at the Controller).


>
> Thanks,
>
> Jason
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120601/d3c8c06c/attachment.html>

From benjaminrk at gmail.com  Fri Jun  1 23:58:34 2012
From: benjaminrk at gmail.com (MinRK)
Date: Fri, 1 Jun 2012 20:58:34 -0700
Subject: [IPython-dev] Cell Magic names
Message-ID: <CAHNn8BWQduo4SUAhwzefVJu4BGSiy8WRv4oBCxxrGbrpzuAj6w@mail.gmail.com>

I was playing with my shebang magic, and I decided to test something evil:

    @cell_magic('#!')
    def shebang(self, line, cell):
        """Run a cell via a shell command

        The `%%shebang` line is like the #! line, specifying a program
(bash, perl, ruby, etc.)
        """
        p = Popen(line, stdout=PIPE, stderr=PIPE, stdin=PIPE)
        out,err = p.communicate(cell)
        print(out, end='')
        print(err, file=sys.stderr, end='')


Which actually lets me do:

%%#! bash
for i in 1 2 3; do
  echo $i
done

I presume we don't want that to actually work, right?  Kinda fun, though.

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

From ellisonbg at gmail.com  Sat Jun  2 00:07:32 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Fri, 1 Jun 2012 21:07:32 -0700
Subject: [IPython-dev] Cell Magic names
In-Reply-To: <CAHNn8BWQduo4SUAhwzefVJu4BGSiy8WRv4oBCxxrGbrpzuAj6w@mail.gmail.com>
References: <CAHNn8BWQduo4SUAhwzefVJu4BGSiy8WRv4oBCxxrGbrpzuAj6w@mail.gmail.com>
Message-ID: <CAH4pYpRtEkMUSn41FF+J+D95mQeAw5k6-SRFhPMs9pTkbXay-w@mail.gmail.com>

On Fri, Jun 1, 2012 at 8:58 PM, MinRK <benjaminrk at gmail.com> wrote:
> I was playing with my shebang magic, and I decided to test something evil:
>
> ? ? @cell_magic('#!')
> ? ? def shebang(self, line, cell):
> ? ? ? ? """Run a cell via a shell command

Oh, what fun, I love it!  Actually, this is not that crazy considering
that we already have the `!foo` syntax.  I guess the important
question is this: are the any constraints on the names of cell magics
at all?  Will this mess up things somehow?

> ? ? ? ? The `%%shebang` line is like the #! line, specifying a program
> (bash, perl, ruby, etc.)
> ? ? ? ??"""
> ? ? ? ? p = Popen(line, stdout=PIPE, stderr=PIPE, stdin=PIPE)
> ? ? ? ? out,err = p.communicate(cell)
> ? ? ? ? print(out, end='')
> ? ? ? ? print(err, file=sys.stderr, end='')
>
>
> Which actually lets me do:
>
> %%#! bash
> for i in 1 2 3; do
> ? echo $i
> done
>
> I presume we don't want that to actually work, right? ?Kinda fun, though.

I think there are two questions:

* Will this actually break something?
* Is another name for this magic clearer?

Cheers,

Brian

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



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


From benjaminrk at gmail.com  Sat Jun  2 00:52:46 2012
From: benjaminrk at gmail.com (MinRK)
Date: Fri, 1 Jun 2012 21:52:46 -0700
Subject: [IPython-dev] Cell Magic names
In-Reply-To: <CAH4pYpRtEkMUSn41FF+J+D95mQeAw5k6-SRFhPMs9pTkbXay-w@mail.gmail.com>
References: <CAHNn8BWQduo4SUAhwzefVJu4BGSiy8WRv4oBCxxrGbrpzuAj6w@mail.gmail.com>
	<CAH4pYpRtEkMUSn41FF+J+D95mQeAw5k6-SRFhPMs9pTkbXay-w@mail.gmail.com>
Message-ID: <CAHNn8BUWkxt0nh4S40qnRu5mfm6J0O+Q_8OpYOB-cLW6eWGe4w@mail.gmail.com>

On Fri, Jun 1, 2012 at 9:07 PM, Brian Granger <ellisonbg at gmail.com> wrote:

> On Fri, Jun 1, 2012 at 8:58 PM, MinRK <benjaminrk at gmail.com> wrote:
> > I was playing with my shebang magic, and I decided to test something
> evil:
> >
> >     @cell_magic('#!')
> >     def shebang(self, line, cell):
> >         """Run a cell via a shell command
>
> Oh, what fun, I love it!  Actually, this is not that crazy considering
> that we already have the `!foo` syntax.  I guess the important
> question is this: are the any constraints on the names of cell magics
> at all?  Will this mess up things somehow?
>
> >         The `%%shebang` line is like the #! line, specifying a program
> > (bash, perl, ruby, etc.)
> >         """
> >         p = Popen(line, stdout=PIPE, stderr=PIPE, stdin=PIPE)
> >         out,err = p.communicate(cell)
> >         print(out, end='')
> >         print(err, file=sys.stderr, end='')
> >
> >
> > Which actually lets me do:
> >
> > %%#! bash
> > for i in 1 2 3; do
> >   echo $i
> > done
> >
> > I presume we don't want that to actually work, right?  Kinda fun, though.
>
> I think there are two questions:
>
> * Will this actually break something?
>

I imagine we want magics to be identifiers, but I guess `%%...<space>` is
sufficiently well defined that there's no technical reason why any unicode
characters should be illegal.

* Is another name for this magic clearer?
>

I was just going to call it `%%shebang`, I think `%%#!` is a few too many
special characters in a row.


>
> Cheers,
>
> Brian
>
> > -MinRK
> >
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> >
>
>
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu and ellisonbg at gmail.com
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120601/16548ff6/attachment.html>

From fperez.net at gmail.com  Sat Jun  2 00:53:41 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 1 Jun 2012 21:53:41 -0700
Subject: [IPython-dev] Cell Magic names
In-Reply-To: <CAH4pYpRtEkMUSn41FF+J+D95mQeAw5k6-SRFhPMs9pTkbXay-w@mail.gmail.com>
References: <CAHNn8BWQduo4SUAhwzefVJu4BGSiy8WRv4oBCxxrGbrpzuAj6w@mail.gmail.com>
	<CAH4pYpRtEkMUSn41FF+J+D95mQeAw5k6-SRFhPMs9pTkbXay-w@mail.gmail.com>
Message-ID: <CAHAreOoBf1acsziBNtLf1qfGieNdC+TFY1b=d+pKKS3=Zc8HZA@mail.gmail.com>

On Fri, Jun 1, 2012 at 9:07 PM, Brian Granger <ellisonbg at gmail.com> wrote:
> I think there are two questions:
>
> * Will this actually break something?

Actually, no :)  It's kind of sick, but it's fine from an
implementation perspective...

The magic dispatch mechanism simply looks up the block of characters
between the %% marker and the first space as a key in a dict.  So
pretty much any non-whitespace string will do.  MMh, I guess you could
use the empty string too, probably.  Though that may be one loose
screw too many ;)

> * Is another name for this magic clearer?

I don't know, I kind of like it... But it may be too much cuteness in
the long run...

cheers,

f


From fperez.net at gmail.com  Sat Jun  2 00:56:52 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 1 Jun 2012 21:56:52 -0700
Subject: [IPython-dev] Cell Magic names
In-Reply-To: <CAHNn8BUWkxt0nh4S40qnRu5mfm6J0O+Q_8OpYOB-cLW6eWGe4w@mail.gmail.com>
References: <CAHNn8BWQduo4SUAhwzefVJu4BGSiy8WRv4oBCxxrGbrpzuAj6w@mail.gmail.com>
	<CAH4pYpRtEkMUSn41FF+J+D95mQeAw5k6-SRFhPMs9pTkbXay-w@mail.gmail.com>
	<CAHNn8BUWkxt0nh4S40qnRu5mfm6J0O+Q_8OpYOB-cLW6eWGe4w@mail.gmail.com>
Message-ID: <CAHAreOqomtjNb01PWwdNRAcxrpXG+t5EVb0NgJogOtoTq5Fkwg@mail.gmail.com>

On Fri, Jun 1, 2012 at 9:52 PM, MinRK <benjaminrk at gmail.com> wrote:
> I was just going to call it `%%shebang`, I think `%%#!` is a few too many
> special characters in a row.

I guess you could just call it '!', and it would then be

%%! bash
etc..

Though regarding the shell stuff, I think I'd prefer this to be a
*factory* that would return shell-like magics, so that we'd offer

%%shell  -> basically wrap around os.system()
%%bash or %%sh -> explicitly call bash (only available on POSIX)
%%cmd  -> explicitly call CMD.EXE (on windows)
%%powershell ? (don't know if it has a canonical shorthand).

That seems like a more natural usage pattern to me.

Cheers,

f


From benjaminrk at gmail.com  Sat Jun  2 01:25:03 2012
From: benjaminrk at gmail.com (MinRK)
Date: Fri, 1 Jun 2012 22:25:03 -0700
Subject: [IPython-dev] Cell Magic names
In-Reply-To: <CAHAreOqomtjNb01PWwdNRAcxrpXG+t5EVb0NgJogOtoTq5Fkwg@mail.gmail.com>
References: <CAHNn8BWQduo4SUAhwzefVJu4BGSiy8WRv4oBCxxrGbrpzuAj6w@mail.gmail.com>
	<CAH4pYpRtEkMUSn41FF+J+D95mQeAw5k6-SRFhPMs9pTkbXay-w@mail.gmail.com>
	<CAHNn8BUWkxt0nh4S40qnRu5mfm6J0O+Q_8OpYOB-cLW6eWGe4w@mail.gmail.com>
	<CAHAreOqomtjNb01PWwdNRAcxrpXG+t5EVb0NgJogOtoTq5Fkwg@mail.gmail.com>
Message-ID: <CAHNn8BWpQ3zz4ONXhpBf3vrzPu5BG3wqYoHzJAVi5WPZOHvTdQ@mail.gmail.com>

On Fri, Jun 1, 2012 at 9:56 PM, Fernando Perez <fperez.net at gmail.com> wrote:

> On Fri, Jun 1, 2012 at 9:52 PM, MinRK <benjaminrk at gmail.com> wrote:
> > I was just going to call it `%%shebang`, I think `%%#!` is a few too many
> > special characters in a row.
>
> I guess you could just call it '!', and it would then be
>
> %%! bash
> etc..
>
> Though regarding the shell stuff, I think I'd prefer this to be a
> *factory* that would return shell-like magics, so that we'd offer
>
> %%shell  -> basically wrap around os.system()
> %%bash or %%sh -> explicitly call bash (only available on POSIX)
> %%cmd  -> explicitly call CMD.EXE (on windows)
> %%powershell ? (don't know if it has a canonical shorthand).
>
> That seems like a more natural usage pattern to me.
>


I think there's space for both.  I think this factory idea makes sense
(probably similar to the aliases list),
but I don't think there's a reason to *exclude* the generic case.

-MinRK


>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120601/0e4a3aa1/attachment.html>

From fperez.net at gmail.com  Sat Jun  2 02:41:02 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 1 Jun 2012 23:41:02 -0700
Subject: [IPython-dev] Cell Magic names
In-Reply-To: <CAHNn8BWpQ3zz4ONXhpBf3vrzPu5BG3wqYoHzJAVi5WPZOHvTdQ@mail.gmail.com>
References: <CAHNn8BWQduo4SUAhwzefVJu4BGSiy8WRv4oBCxxrGbrpzuAj6w@mail.gmail.com>
	<CAH4pYpRtEkMUSn41FF+J+D95mQeAw5k6-SRFhPMs9pTkbXay-w@mail.gmail.com>
	<CAHNn8BUWkxt0nh4S40qnRu5mfm6J0O+Q_8OpYOB-cLW6eWGe4w@mail.gmail.com>
	<CAHAreOqomtjNb01PWwdNRAcxrpXG+t5EVb0NgJogOtoTq5Fkwg@mail.gmail.com>
	<CAHNn8BWpQ3zz4ONXhpBf3vrzPu5BG3wqYoHzJAVi5WPZOHvTdQ@mail.gmail.com>
Message-ID: <CAHAreOpVuR-GZovzVOmPkYA=8g8soCncdNMzN=frGJN2qLXRjA@mail.gmail.com>

On Fri, Jun 1, 2012 at 10:25 PM, MinRK <benjaminrk at gmail.com> wrote:
> I think there's space for both. ?I think this factory idea makes sense
> (probably similar to the aliases list),
> but I don't think there's a reason to *exclude* the generic case.

Agreed, I wasn't suggesting excluding it; sorry for the lack of
clarity.  The 'shebang' idea is actually great.  I just think that for
each OS having a direct version of the default system shell, plus one
that does more or less os.system(cell), would be a good complement of
system access tools.

Cheers,

f


From takowl at gmail.com  Sat Jun  2 06:25:42 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Sat, 2 Jun 2012 11:25:42 +0100
Subject: [IPython-dev] Octave magic
In-Reply-To: <CAHNn8BVb5HdOD-5xhLqbdLkDWpU-by1XOh6WE+7-QEaHP0rySQ@mail.gmail.com>
References: <CABDkGQnFtPrH2HYeJpjO_DZobNvBnE3a5mxuyDBTzkHknWy-gg@mail.gmail.com>
	<CAHAreOrk=ZOKPSKypzs6MEBjzAfMYoN6jVk5W=3bFajoPT=CpQ@mail.gmail.com>
	<CAHNn8BVb5HdOD-5xhLqbdLkDWpU-by1XOh6WE+7-QEaHP0rySQ@mail.gmail.com>
Message-ID: <CAOvn4qjaX0DXwCPMP-6aFxRrugWkKnB70KusASCp1Ru6TUNyXg@mail.gmail.com>

On 1 June 2012 23:11, MinRK <benjaminrk at gmail.com> wrote:
> I get the feeling that cell magics are going propagate rapidly. ?Perhaps
> %load_ext should support git urls :)

I did add an %install_ext magic which takes a URL. Not quite the same
mode of interaction, but it should make it easy to grab new
extensions.

Thomas


From takowl at gmail.com  Sat Jun  2 06:38:29 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Sat, 2 Jun 2012 11:38:29 +0100
Subject: [IPython-dev] Cell Magic names
In-Reply-To: <CAHAreOpVuR-GZovzVOmPkYA=8g8soCncdNMzN=frGJN2qLXRjA@mail.gmail.com>
References: <CAHNn8BWQduo4SUAhwzefVJu4BGSiy8WRv4oBCxxrGbrpzuAj6w@mail.gmail.com>
	<CAH4pYpRtEkMUSn41FF+J+D95mQeAw5k6-SRFhPMs9pTkbXay-w@mail.gmail.com>
	<CAHNn8BUWkxt0nh4S40qnRu5mfm6J0O+Q_8OpYOB-cLW6eWGe4w@mail.gmail.com>
	<CAHAreOqomtjNb01PWwdNRAcxrpXG+t5EVb0NgJogOtoTq5Fkwg@mail.gmail.com>
	<CAHNn8BWpQ3zz4ONXhpBf3vrzPu5BG3wqYoHzJAVi5WPZOHvTdQ@mail.gmail.com>
	<CAHAreOpVuR-GZovzVOmPkYA=8g8soCncdNMzN=frGJN2qLXRjA@mail.gmail.com>
Message-ID: <CAOvn4qhpiPrgmBF+F79rpr_H5Kz_ZY-0U2Mn-hzKnRp7nPKLOA@mail.gmail.com>

I'm not sold on %%shebang from a UI perspective. It reminds me of an
april fools joke in which Python & Perl combined forces to name
variables like DOLLAR_UNDERSCORE. Spelling out the name of punctuation
feels odd, and we shouldn't assume everyone knows what a shebang is.

%%#! is quite neat, but I think people will expect it to work exactly
like real shebangs - which, crucially, don't require a space. So I
think people would try to do:

  %%#!/bin/sh

So I'd prefer a more explicit name, less tied to Unix history. I
suggest something based on words like "run with" or "exec in", or
something like %%script.

Thomas


From carl.input at gmail.com  Sat Jun  2 13:46:03 2012
From: carl.input at gmail.com (Carl Smith)
Date: Sat, 2 Jun 2012 18:46:03 +0100
Subject: [IPython-dev] Cell Magic names
In-Reply-To: <CAOvn4qhpiPrgmBF+F79rpr_H5Kz_ZY-0U2Mn-hzKnRp7nPKLOA@mail.gmail.com>
References: <CAHNn8BWQduo4SUAhwzefVJu4BGSiy8WRv4oBCxxrGbrpzuAj6w@mail.gmail.com>
	<CAH4pYpRtEkMUSn41FF+J+D95mQeAw5k6-SRFhPMs9pTkbXay-w@mail.gmail.com>
	<CAHNn8BUWkxt0nh4S40qnRu5mfm6J0O+Q_8OpYOB-cLW6eWGe4w@mail.gmail.com>
	<CAHAreOqomtjNb01PWwdNRAcxrpXG+t5EVb0NgJogOtoTq5Fkwg@mail.gmail.com>
	<CAHNn8BWpQ3zz4ONXhpBf3vrzPu5BG3wqYoHzJAVi5WPZOHvTdQ@mail.gmail.com>
	<CAHAreOpVuR-GZovzVOmPkYA=8g8soCncdNMzN=frGJN2qLXRjA@mail.gmail.com>
	<CAOvn4qhpiPrgmBF+F79rpr_H5Kz_ZY-0U2Mn-hzKnRp7nPKLOA@mail.gmail.com>
Message-ID: <CAP-uhDeooCq08s5iTPEZR7kKb+Z7Oou9nj=YXhwwyiAktpxHYA@mail.gmail.com>

Just a thought: How about calling it lang?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120602/249deffd/attachment.html>

From carl.input at gmail.com  Sat Jun  2 14:00:19 2012
From: carl.input at gmail.com (Carl Smith)
Date: Sat, 2 Jun 2012 19:00:19 +0100
Subject: [IPython-dev] Cell Magic names
In-Reply-To: <CAP-uhDeooCq08s5iTPEZR7kKb+Z7Oou9nj=YXhwwyiAktpxHYA@mail.gmail.com>
References: <CAHNn8BWQduo4SUAhwzefVJu4BGSiy8WRv4oBCxxrGbrpzuAj6w@mail.gmail.com>
	<CAH4pYpRtEkMUSn41FF+J+D95mQeAw5k6-SRFhPMs9pTkbXay-w@mail.gmail.com>
	<CAHNn8BUWkxt0nh4S40qnRu5mfm6J0O+Q_8OpYOB-cLW6eWGe4w@mail.gmail.com>
	<CAHAreOqomtjNb01PWwdNRAcxrpXG+t5EVb0NgJogOtoTq5Fkwg@mail.gmail.com>
	<CAHNn8BWpQ3zz4ONXhpBf3vrzPu5BG3wqYoHzJAVi5WPZOHvTdQ@mail.gmail.com>
	<CAHAreOpVuR-GZovzVOmPkYA=8g8soCncdNMzN=frGJN2qLXRjA@mail.gmail.com>
	<CAOvn4qhpiPrgmBF+F79rpr_H5Kz_ZY-0U2Mn-hzKnRp7nPKLOA@mail.gmail.com>
	<CAP-uhDeooCq08s5iTPEZR7kKb+Z7Oou9nj=YXhwwyiAktpxHYA@mail.gmail.com>
Message-ID: <CAP-uhDfeKqRx8QXoua+EaXz_2PxCJOhDrnQHfShQ6BpHLk1hFA@mail.gmail.com>

A little while back I was playing with a magic called %from that imported
files from urls using Python syntax.

%from knownsource.dir.subdir import file as name

It worked fine, but I never took it anywhere. Just thought I'd mention it
while you're looking at wonky features.
On Jun 2, 2012 6:46 PM, "Carl Smith" <carl.input at gmail.com> wrote:

> Just a thought: How about calling it lang?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120602/bf81bc73/attachment.html>

From arnaud at oscopy.org  Sat Jun  2 14:45:44 2012
From: arnaud at oscopy.org (Arnaud Gardelein)
Date: Sat, 02 Jun 2012 20:45:44 +0200
Subject: [IPython-dev] Add new commandline option from profile
Message-ID: <1338662744.15011.12.camel@bomberx.somewhere-in-the-space.org>

Hi all,

The new ipython configuration system allows to customize for particular
application three classes, InteractiveShell, PrefilterManager and
AliasManager all subclasses of Configurable as described in the
documentation. Each option from those classes are settable from argument
of ipython command.
Assuming a new configurable object described in a ipython 'foo' profile:

from IPython.config.configurable import Configurable
from IPython.utils.traitlets import Int, Float, Unicode, Bool
class Foo(Configurable):
    name = Unicode(u'Foo')
    bar = Bool(False, config=True)

How to make the boolean 'bar' also an argument settable from ipython
command with a '--bar' or '--no-bar' when invoking ipython
--profile=foo?

Thanks,

Arnaud.



From fperez.net at gmail.com  Sat Jun  2 15:15:34 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 2 Jun 2012 12:15:34 -0700
Subject: [IPython-dev] Add new commandline option from profile
In-Reply-To: <1338662744.15011.12.camel@bomberx.somewhere-in-the-space.org>
References: <1338662744.15011.12.camel@bomberx.somewhere-in-the-space.org>
Message-ID: <CAHAreOoyRHo+22HJnRVMWKO-78W5+7ywfrXf9N6Zb=wgdxGQFw@mail.gmail.com>

On Sat, Jun 2, 2012 at 11:45 AM, Arnaud Gardelein <arnaud at oscopy.org> wrote:
> How to make the boolean 'bar' also an argument settable from ipython
> command with a '--bar' or '--no-bar' when invoking ipython
> --profile=foo?

I haven't tried myself to do precisely this, so I'm not 100% sure and
Min knows this code far better than I do.  But here's a quick pointer
to the code that creates the short aliases and flags that give more
convenient access to the fully qualified trait names:

https://github.com/ipython/ipython/blob/master/IPython/core/application.py#L55

That should give you an idea of how to start...

Cheers,

f


From fperez.net at gmail.com  Sat Jun  2 15:15:34 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 2 Jun 2012 12:15:34 -0700
Subject: [IPython-dev] Add new commandline option from profile
In-Reply-To: <1338662744.15011.12.camel@bomberx.somewhere-in-the-space.org>
References: <1338662744.15011.12.camel@bomberx.somewhere-in-the-space.org>
Message-ID: <CAHAreOoyRHo+22HJnRVMWKO-78W5+7ywfrXf9N6Zb=wgdxGQFw@mail.gmail.com>

On Sat, Jun 2, 2012 at 11:45 AM, Arnaud Gardelein <arnaud at oscopy.org> wrote:
> How to make the boolean 'bar' also an argument settable from ipython
> command with a '--bar' or '--no-bar' when invoking ipython
> --profile=foo?

I haven't tried myself to do precisely this, so I'm not 100% sure and
Min knows this code far better than I do.  But here's a quick pointer
to the code that creates the short aliases and flags that give more
convenient access to the fully qualified trait names:

https://github.com/ipython/ipython/blob/master/IPython/core/application.py#L55

That should give you an idea of how to start...

Cheers,

f


From fperez.net at gmail.com  Sat Jun  2 15:24:15 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 2 Jun 2012 12:24:15 -0700
Subject: [IPython-dev] Cell Magic names
In-Reply-To: <CAP-uhDeooCq08s5iTPEZR7kKb+Z7Oou9nj=YXhwwyiAktpxHYA@mail.gmail.com>
References: <CAHNn8BWQduo4SUAhwzefVJu4BGSiy8WRv4oBCxxrGbrpzuAj6w@mail.gmail.com>
	<CAH4pYpRtEkMUSn41FF+J+D95mQeAw5k6-SRFhPMs9pTkbXay-w@mail.gmail.com>
	<CAHNn8BUWkxt0nh4S40qnRu5mfm6J0O+Q_8OpYOB-cLW6eWGe4w@mail.gmail.com>
	<CAHAreOqomtjNb01PWwdNRAcxrpXG+t5EVb0NgJogOtoTq5Fkwg@mail.gmail.com>
	<CAHNn8BWpQ3zz4ONXhpBf3vrzPu5BG3wqYoHzJAVi5WPZOHvTdQ@mail.gmail.com>
	<CAHAreOpVuR-GZovzVOmPkYA=8g8soCncdNMzN=frGJN2qLXRjA@mail.gmail.com>
	<CAOvn4qhpiPrgmBF+F79rpr_H5Kz_ZY-0U2Mn-hzKnRp7nPKLOA@mail.gmail.com>
	<CAP-uhDeooCq08s5iTPEZR7kKb+Z7Oou9nj=YXhwwyiAktpxHYA@mail.gmail.com>
Message-ID: <CAHAreOrJgVnsjzGN4F2_36SMumjpsxchvu79azE4FfmtE21Hzg@mail.gmail.com>

On Sat, Jun 2, 2012 at 10:46 AM, Carl Smith <carl.input at gmail.com> wrote:
> Just a thought: How about calling it lang?

lang or script both sound OK to me, and indeed I prefer them to
shebang, I concur with Thomas on this one.

Cheers,

f


From carl.input at gmail.com  Sat Jun  2 15:26:00 2012
From: carl.input at gmail.com (Carl Smith)
Date: Sat, 2 Jun 2012 20:26:00 +0100
Subject: [IPython-dev] Notebook doesn't load profile when started on boot.
Message-ID: <CAP-uhDcJCaQ+QowKf8kAgC8RFt8parXDib0xqzCZBghAUubnDg@mail.gmail.com>

I've got a basic nb config that works fine if I do

ipython notebook --profile=nbserver

I'm using Ubuntu 12.04 on EC2. If a add the above cmd to an upstart config
it starts the nb server, but on localhost. I assume it's not loading the
profile and falling back to the generic temp one.

I've tried using init.d and even tried running a script that passes the cmd
via os.system, but I get the exact same problem.

I tested for network and filesystem access and I can open remote urls and
read and write to the fs prior to calling os.system, but it still seems to
ignore the profile.

I'm really stuck.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120602/db936e1b/attachment.html>

From carl.input at gmail.com  Sat Jun  2 15:30:32 2012
From: carl.input at gmail.com (Carl Smith)
Date: Sat, 2 Jun 2012 20:30:32 +0100
Subject: [IPython-dev] Cell Magic names
In-Reply-To: <CAHAreOrJgVnsjzGN4F2_36SMumjpsxchvu79azE4FfmtE21Hzg@mail.gmail.com>
References: <CAHNn8BWQduo4SUAhwzefVJu4BGSiy8WRv4oBCxxrGbrpzuAj6w@mail.gmail.com>
	<CAH4pYpRtEkMUSn41FF+J+D95mQeAw5k6-SRFhPMs9pTkbXay-w@mail.gmail.com>
	<CAHNn8BUWkxt0nh4S40qnRu5mfm6J0O+Q_8OpYOB-cLW6eWGe4w@mail.gmail.com>
	<CAHAreOqomtjNb01PWwdNRAcxrpXG+t5EVb0NgJogOtoTq5Fkwg@mail.gmail.com>
	<CAHNn8BWpQ3zz4ONXhpBf3vrzPu5BG3wqYoHzJAVi5WPZOHvTdQ@mail.gmail.com>
	<CAHAreOpVuR-GZovzVOmPkYA=8g8soCncdNMzN=frGJN2qLXRjA@mail.gmail.com>
	<CAOvn4qhpiPrgmBF+F79rpr_H5Kz_ZY-0U2Mn-hzKnRp7nPKLOA@mail.gmail.com>
	<CAP-uhDeooCq08s5iTPEZR7kKb+Z7Oou9nj=YXhwwyiAktpxHYA@mail.gmail.com>
	<CAHAreOrJgVnsjzGN4F2_36SMumjpsxchvu79azE4FfmtE21Hzg@mail.gmail.com>
Message-ID: <CAP-uhDcubXU4SO1SVxN5uHskSRR5jyb1sEZGMSCHwN4w6BXKmw@mail.gmail.com>

If the magic knows the installed interpreters and what not, couldn't you
just do...

%%lang bash
echo hello world

On Jun 2, 2012 8:24 PM, "Fernando Perez" <fperez.net at gmail.com> wrote:
>
> On Sat, Jun 2, 2012 at 10:46 AM, Carl Smith <carl.input at gmail.com> wrote:
> > Just a thought: How about calling it lang?
>
> lang or script both sound OK to me, and indeed I prefer them to
> shebang, I concur with Thomas on this one.
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120602/00527b22/attachment.html>

From fperez.net at gmail.com  Sat Jun  2 15:45:28 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 2 Jun 2012 12:45:28 -0700
Subject: [IPython-dev] Notebook doesn't load profile when started on
	boot.
In-Reply-To: <CAP-uhDcJCaQ+QowKf8kAgC8RFt8parXDib0xqzCZBghAUubnDg@mail.gmail.com>
References: <CAP-uhDcJCaQ+QowKf8kAgC8RFt8parXDib0xqzCZBghAUubnDg@mail.gmail.com>
Message-ID: <CAHAreOrFPnX7TCSQt_iBqcNqxx_bVF3DRchZs+8JS+JmFkBKZA@mail.gmail.com>

On Sat, Jun 2, 2012 at 12:26 PM, Carl Smith <carl.input at gmail.com> wrote:
> I'm using Ubuntu 12.04 on EC2. If a add the above cmd to an upstart config
> it starts the nb server, but on localhost. I assume it's not loading the
> profile and falling back to the generic temp one.
>
> I've tried using init.d and even tried running a script that passes the cmd
> via os.system, but I get the exact same problem.
>
> I tested for network and filesystem access and I can open remote urls and
> read and write to the fs prior to calling os.system, but it still seems to
> ignore the profile.
>
> I'm really stuck.

What user does the upstart command run as?  It's possible that it's
not looking at the same home directory... Just a thought.

f


From carl.input at gmail.com  Sat Jun  2 15:54:25 2012
From: carl.input at gmail.com (Carl Smith)
Date: Sat, 2 Jun 2012 20:54:25 +0100
Subject: [IPython-dev] Notebook doesn't load profile when started on
	boot.
In-Reply-To: <CAHAreOrFPnX7TCSQt_iBqcNqxx_bVF3DRchZs+8JS+JmFkBKZA@mail.gmail.com>
References: <CAP-uhDcJCaQ+QowKf8kAgC8RFt8parXDib0xqzCZBghAUubnDg@mail.gmail.com>
	<CAHAreOrFPnX7TCSQt_iBqcNqxx_bVF3DRchZs+8JS+JmFkBKZA@mail.gmail.com>
Message-ID: <CAP-uhDcea_T8ZMmmR1cJPXXAEeBzz7uF58swy=A7UPcmSw2zZw@mail.gmail.com>

Thank you. Any ideas are welcomed. I'll try looking at that.
On Jun 2, 2012 8:46 PM, "Fernando Perez" <fperez.net at gmail.com> wrote:

> On Sat, Jun 2, 2012 at 12:26 PM, Carl Smith <carl.input at gmail.com> wrote:
> > I'm using Ubuntu 12.04 on EC2. If a add the above cmd to an upstart
> config
> > it starts the nb server, but on localhost. I assume it's not loading the
> > profile and falling back to the generic temp one.
> >
> > I've tried using init.d and even tried running a script that passes the
> cmd
> > via os.system, but I get the exact same problem.
> >
> > I tested for network and filesystem access and I can open remote urls and
> > read and write to the fs prior to calling os.system, but it still seems
> to
> > ignore the profile.
> >
> > I'm really stuck.
>
> What user does the upstart command run as?  It's possible that it's
> not looking at the same home directory... Just a thought.
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120602/1a7f20fd/attachment.html>

From carl.input at gmail.com  Sat Jun  2 16:23:07 2012
From: carl.input at gmail.com (Carl Smith)
Date: Sat, 2 Jun 2012 21:23:07 +0100
Subject: [IPython-dev] Notebook doesn't load profile when started on
	boot.
In-Reply-To: <CAHAreOrFPnX7TCSQt_iBqcNqxx_bVF3DRchZs+8JS+JmFkBKZA@mail.gmail.com>
References: <CAP-uhDcJCaQ+QowKf8kAgC8RFt8parXDib0xqzCZBghAUubnDg@mail.gmail.com>
	<CAHAreOrFPnX7TCSQt_iBqcNqxx_bVF3DRchZs+8JS+JmFkBKZA@mail.gmail.com>
Message-ID: <CAP-uhDcADy1pCdu8-8GLcsyw1iHi1cKYpGvPjC_LTvx8uKYL9g@mail.gmail.com>

Thanks Fernando. That was it. Nice one.
On Jun 2, 2012 8:46 PM, "Fernando Perez" <fperez.net at gmail.com> wrote:

> On Sat, Jun 2, 2012 at 12:26 PM, Carl Smith <carl.input at gmail.com> wrote:
> > I'm using Ubuntu 12.04 on EC2. If a add the above cmd to an upstart
> config
> > it starts the nb server, but on localhost. I assume it's not loading the
> > profile and falling back to the generic temp one.
> >
> > I've tried using init.d and even tried running a script that passes the
> cmd
> > via os.system, but I get the exact same problem.
> >
> > I tested for network and filesystem access and I can open remote urls and
> > read and write to the fs prior to calling os.system, but it still seems
> to
> > ignore the profile.
> >
> > I'm really stuck.
>
> What user does the upstart command run as?  It's possible that it's
> not looking at the same home directory... Just a thought.
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120602/69368161/attachment.html>

From fperez.net at gmail.com  Sat Jun  2 16:32:51 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 2 Jun 2012 13:32:51 -0700
Subject: [IPython-dev] Notebook doesn't load profile when started on
	boot.
In-Reply-To: <CAP-uhDcADy1pCdu8-8GLcsyw1iHi1cKYpGvPjC_LTvx8uKYL9g@mail.gmail.com>
References: <CAP-uhDcJCaQ+QowKf8kAgC8RFt8parXDib0xqzCZBghAUubnDg@mail.gmail.com>
	<CAHAreOrFPnX7TCSQt_iBqcNqxx_bVF3DRchZs+8JS+JmFkBKZA@mail.gmail.com>
	<CAP-uhDcADy1pCdu8-8GLcsyw1iHi1cKYpGvPjC_LTvx8uKYL9g@mail.gmail.com>
Message-ID: <CAHAreOpE0L-J8bb-1=Xp_U9YMXc9XmifFes=KZ3zbJp8pUb2YQ@mail.gmail.com>

On Sat, Jun 2, 2012 at 1:23 PM, Carl Smith <carl.input at gmail.com> wrote:
> Thanks Fernando. That was it. Nice one.

Great, glad it worked.

Cheers,

f


From fperez.net at gmail.com  Sat Jun  2 16:51:05 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 2 Jun 2012 13:51:05 -0700
Subject: [IPython-dev] test_pr for 3.x picking up 2.x paths
Message-ID: <CAHAreOrdBRdCtASk=edd1KOTuW7ntGph=O6QArM3-LR5QtOzwA@mail.gmail.com>

Hey Thomas,

any idea why we're seeing this kind of failure with test_pr?

https://gist.github.com/2859912

I think I may have asked you already, sorry if this is a dupe.  But I
know you fixed the main PYTHONPATH issue already, so I'm puzzled as to
why the 3.x run is picking up 2.x paths (which are obviously bogus).

Cheers,

f


From fperez.net at gmail.com  Sat Jun  2 16:52:56 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 2 Jun 2012 13:52:56 -0700
Subject: [IPython-dev] Thanks for the kernel shutdown button!
Message-ID: <CAHAreOr5EOrKCun4CjJ4YHh2EvXWnrv4W35BV8U8NCP6FbPCDQ@mail.gmail.com>

To whomever was responsible for the per-kernel shutdown button in the
Dashboard: thank you!  I just noticed it recently and don't know as
part of which PR it landed (it's hard to keep track at this point :),
but it's great!  It was something that had bugged me since the start,
so I'm really happy to see a clean solution for it.

Cheers,

f


From bussonniermatthias at gmail.com  Sat Jun  2 17:06:25 2012
From: bussonniermatthias at gmail.com (Matthias BUSSONNIER)
Date: Sat, 2 Jun 2012 23:06:25 +0200
Subject: [IPython-dev] Thanks for the kernel shutdown button!
In-Reply-To: <CAHAreOr5EOrKCun4CjJ4YHh2EvXWnrv4W35BV8U8NCP6FbPCDQ@mail.gmail.com>
References: <CAHAreOr5EOrKCun4CjJ4YHh2EvXWnrv4W35BV8U8NCP6FbPCDQ@mail.gmail.com>
Message-ID: <00978665-E877-42F0-AD20-BB7064F1328B@gmail.com>


Le 2 juin 2012 ? 22:52, Fernando Perez a ?crit :

> To whomever was responsible for the per-kernel shutdown button in the
> Dashboard: thank you!  I just noticed it recently and don't know as
> part of which PR it landed (it's hard to keep track at this point :),

That's strange, it was part of a PR you gave feedback on :
https://github.com/ipython/ipython/pull/1739

But happy you're getting some surprise like that, hope it won't stop :-)
-- 
Matthias


> but it's great!  It was something that had bugged me since the start,
> so I'm really happy to see a clean solution for it.
> 
> Cheers,
> 
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



From fperez.net at gmail.com  Sat Jun  2 17:09:35 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 2 Jun 2012 14:09:35 -0700
Subject: [IPython-dev] Data viz in the notebook with JS
Message-ID: <CAHAreOoaQ2J1PaQBHxA9KxAM1ZyQi-V=hYK-PXYiy=rjPY8zMg@mail.gmail.com>

Hi folks

Here's a quick preview of what we can start having now:

http://imgur.com/vk2Q6

courtesy of Cameron Bates:

https://github.com/crbates/ipython-flot/blob/master/IPython/frontend/html/notebook/flot.py

I suggest simply to grab the single flot.py file and put it in your
working dir for testing.

We still have a ways to go with this kind of setup, because the user
experience upon saving is a bit awkward: these javascript objects are
only rendered when their code executes, so the saved page shows empty
placeholders.  We'll have to think more about all this, but it's great
to have a concrete point to start from.

Now that all the JavaScript refactoring has been merged, writing
dynamic code with JS in the notebook will be much cleaner.

If anyone is looking for toys of this nature to play with, here's a
great summary page of viz JS libraries that could all be very
elegantly plugged into the notebook:

http://selection.datavisualization.ch

Let us know what you come up with!

Cheers,

f


From fperez.net at gmail.com  Sat Jun  2 17:10:40 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 2 Jun 2012 14:10:40 -0700
Subject: [IPython-dev] Thanks for the kernel shutdown button!
In-Reply-To: <00978665-E877-42F0-AD20-BB7064F1328B@gmail.com>
References: <CAHAreOr5EOrKCun4CjJ4YHh2EvXWnrv4W35BV8U8NCP6FbPCDQ@mail.gmail.com>
	<00978665-E877-42F0-AD20-BB7064F1328B@gmail.com>
Message-ID: <CAHAreOpm0iHNp5_aBJiprMQyi9=3dv88Y+gV3-a+EQ57QKp6Sw@mail.gmail.com>

On Sat, Jun 2, 2012 at 2:06 PM, Matthias BUSSONNIER
<bussonniermatthias at gmail.com> wrote:
> That's strange, it was part of a PR you gave feedback on :
> https://github.com/ipython/ipython/pull/1739

I figured as much, as I said, at this point I can't keep track anymore
:)  We're processing so much code quickly that things aren't making it
to long term memory!

Cheers,

f


From benjaminrk at gmail.com  Sat Jun  2 20:54:19 2012
From: benjaminrk at gmail.com (Min RK)
Date: Sat, 2 Jun 2012 17:54:19 -0700
Subject: [IPython-dev] Cell Magic names
In-Reply-To: <CAP-uhDcubXU4SO1SVxN5uHskSRR5jyb1sEZGMSCHwN4w6BXKmw@mail.gmail.com>
References: <CAHNn8BWQduo4SUAhwzefVJu4BGSiy8WRv4oBCxxrGbrpzuAj6w@mail.gmail.com>
	<CAH4pYpRtEkMUSn41FF+J+D95mQeAw5k6-SRFhPMs9pTkbXay-w@mail.gmail.com>
	<CAHNn8BUWkxt0nh4S40qnRu5mfm6J0O+Q_8OpYOB-cLW6eWGe4w@mail.gmail.com>
	<CAHAreOqomtjNb01PWwdNRAcxrpXG+t5EVb0NgJogOtoTq5Fkwg@mail.gmail.com>
	<CAHNn8BWpQ3zz4ONXhpBf3vrzPu5BG3wqYoHzJAVi5WPZOHvTdQ@mail.gmail.com>
	<CAHAreOpVuR-GZovzVOmPkYA=8g8soCncdNMzN=frGJN2qLXRjA@mail.gmail.com>
	<CAOvn4qhpiPrgmBF+F79rpr_H5Kz_ZY-0U2Mn-hzKnRp7nPKLOA@mail.gmail.com>
	<CAP-uhDeooCq08s5iTPEZR7kKb+Z7Oou9nj=YXhwwyiAktpxHYA@mail.gmail.com>
	<CAHAreOrJgVnsjzGN4F2_36SMumjpsxchvu79azE4FfmtE21Hzg@mail.gmail.com>
	<CAP-uhDcubXU4SO1SVxN5uHskSRR5jyb1sEZGMSCHwN4w6BXKmw@mail.gmail.com>
Message-ID: <B497CED6-E119-436E-BBAC-5B8C5292AE7F@gmail.com>

I don't like lang, because it doesn't actually communicate what it does. For instance you could use it to select one of the half-dozen Pythons or venv-pythons, etc.

I agree that shebang is unclear to users who don't know what it means (and
is this probably a poor choice, but still my personal favorite, because I think it's fun), but it most accurately describes what the magic does (to the minority aware of the reference): run the rest of the cell with the *program* described on this line.

I think script is probably best, and should then have a default interpreter of 'sh' (or $SHELL?).

-MinRK

On Jun 2, 2012, at 12:30, Carl Smith <carl.input at gmail.com> wrote:

> If the magic knows the installed interpreters and what not, couldn't you just do...
> 
> %%lang bash
> echo hello world
> 
> On Jun 2, 2012 8:24 PM, "Fernando Perez" <fperez.net at gmail.com> wrote:
> >
> > On Sat, Jun 2, 2012 at 10:46 AM, Carl Smith <carl.input at gmail.com> wrote:
> > > Just a thought: How about calling it lang?
> >
> > lang or script both sound OK to me, and indeed I prefer them to
> > shebang, I concur with Thomas on this one.
> >
> > Cheers,
> >
> > f
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120602/19f349cc/attachment.html>

From jason-sage at creativetrax.com  Sat Jun  2 21:39:32 2012
From: jason-sage at creativetrax.com (Jason Grout)
Date: Sat, 02 Jun 2012 20:39:32 -0500
Subject: [IPython-dev] Cell Magic names
In-Reply-To: <B497CED6-E119-436E-BBAC-5B8C5292AE7F@gmail.com>
References: <CAHNn8BWQduo4SUAhwzefVJu4BGSiy8WRv4oBCxxrGbrpzuAj6w@mail.gmail.com>
	<CAH4pYpRtEkMUSn41FF+J+D95mQeAw5k6-SRFhPMs9pTkbXay-w@mail.gmail.com>
	<CAHNn8BUWkxt0nh4S40qnRu5mfm6J0O+Q_8OpYOB-cLW6eWGe4w@mail.gmail.com>
	<CAHAreOqomtjNb01PWwdNRAcxrpXG+t5EVb0NgJogOtoTq5Fkwg@mail.gmail.com>
	<CAHNn8BWpQ3zz4ONXhpBf3vrzPu5BG3wqYoHzJAVi5WPZOHvTdQ@mail.gmail.com>
	<CAHAreOpVuR-GZovzVOmPkYA=8g8soCncdNMzN=frGJN2qLXRjA@mail.gmail.com>
	<CAOvn4qhpiPrgmBF+F79rpr_H5Kz_ZY-0U2Mn-hzKnRp7nPKLOA@mail.gmail.com>
	<CAP-uhDeooCq08s5iTPEZR7kKb+Z7Oou9nj=YXhwwyiAktpxHYA@mail.gmail.com>
	<CAHAreOrJgVnsjzGN4F2_36SMumjpsxchvu79azE4FfmtE21Hzg@mail.gmail.com>
	<CAP-uhDcubXU4SO1SVxN5uHskSRR5jyb1sEZGMSCHwN4w6BXKmw@mail.gmail.com>
	<B497CED6-E119-436E-BBAC-5B8C5292AE7F@gmail.com>
Message-ID: <4FCAC054.4060305@creativetrax.com>

On 6/2/12 7:54 PM, Min RK wrote:
> I think script is probably best, and should then have a default
> interpreter of 'sh' (or $SHELL?).

+1 for %%script

as in the slightly silly, but still cool

%%script /usr/bin/env python
print 1+2

Jason


From fperez.net at gmail.com  Sat Jun  2 23:18:35 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 2 Jun 2012 20:18:35 -0700
Subject: [IPython-dev] Small config puzzle
Message-ID: <CAHAreOrR7-dtRwTD5ONbu7gtx-SzFzrZxbcn3TgjANvUgCHHFg@mail.gmail.com>

Howdy,

(this is likely for Min, but perhaps somebody else knows) I'm kind of
stumped trying to figure out why this works fine in my config file:

c.InlineBackend.figure_format = 'png'  (or 'svg')

but I can't seem to make this work:

c.InlineBackend.rc['savefig.dpi'] = 96

In fact, I get a traceback:

[IPKernelApp] Exception while loading config file
/home/fperez/.ipython/profile_default/ipython_notebook_config.py
Traceback (most recent call last):
  File "/home/fperez/usr/lib/python2.7/site-packages/IPython/config/application.py",
line 447, in load_config_file
    config = loader.load_config()
  File "/home/fperez/usr/lib/python2.7/site-packages/IPython/config/loader.py",
line 269, in load_config
    self._read_file_as_dict()
  File "/home/fperez/usr/lib/python2.7/site-packages/IPython/config/loader.py",
line 322, in _read_file_as_dict
    py3compat.execfile(conf_filename, namespace)
  File "/home/fperez/usr/lib/python2.7/site-packages/IPython/utils/py3compat.py",
line 178, in execfile
    __builtin__.execfile(filename, *where)
  File "/home/fperez/.ipython/profile_default/ipython_notebook_config.py",
line 7, in <module>
    c.InlineBackend.rc['savefig.dpi'] = 96
  File "/home/fperez/usr/lib/python2.7/site-packages/IPython/config/loader.py",
line 167, in __getattr__
    raise AttributeError(e)
AttributeError: 'rc'


If I make the same change inside the backend_inline file in IPython
itself it does have an effect, but not in the config file, and I'm
curious why...  The rc field is a traitlet Dict.

Puzzled...  Before I dig into the traitlets machinery to track this
down, I figured I'd ask...

f


From takowl at gmail.com  Sun Jun  3 09:29:38 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Sun, 3 Jun 2012 14:29:38 +0100
Subject: [IPython-dev] test_pr for 3.x picking up 2.x paths
In-Reply-To: <CAHAreOrdBRdCtASk=edd1KOTuW7ntGph=O6QArM3-LR5QtOzwA@mail.gmail.com>
References: <CAHAreOrdBRdCtASk=edd1KOTuW7ntGph=O6QArM3-LR5QtOzwA@mail.gmail.com>
Message-ID: <CAOvn4qjSigfoy8_SPC1USbg-TgSxceevxUhM7CW3FyJKYX0kYg@mail.gmail.com>

On 2 June 2012 21:51, Fernando Perez <fperez.net at gmail.com> wrote:
> I think I may have asked you already, sorry if this is a dupe. ?But I
> know you fixed the main PYTHONPATH issue already, so I'm puzzled as to
> why the 3.x run is picking up 2.x paths (which are obviously bogus).

No flash of inspiration, sorry. I haven't seen that myself. If you
check /home/fperez/.ipy_pr_tests/venv-python3.2/bin/iptest3 , does it
have the correct shebang (should be pointing to a python executable in
the same folder)?

I'll keep thinking about it.

Thomas


From takowl at gmail.com  Sun Jun  3 09:38:54 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Sun, 3 Jun 2012 14:38:54 +0100
Subject: [IPython-dev] Cell Magic names
In-Reply-To: <B497CED6-E119-436E-BBAC-5B8C5292AE7F@gmail.com>
References: <CAHNn8BWQduo4SUAhwzefVJu4BGSiy8WRv4oBCxxrGbrpzuAj6w@mail.gmail.com>
	<CAH4pYpRtEkMUSn41FF+J+D95mQeAw5k6-SRFhPMs9pTkbXay-w@mail.gmail.com>
	<CAHNn8BUWkxt0nh4S40qnRu5mfm6J0O+Q_8OpYOB-cLW6eWGe4w@mail.gmail.com>
	<CAHAreOqomtjNb01PWwdNRAcxrpXG+t5EVb0NgJogOtoTq5Fkwg@mail.gmail.com>
	<CAHNn8BWpQ3zz4ONXhpBf3vrzPu5BG3wqYoHzJAVi5WPZOHvTdQ@mail.gmail.com>
	<CAHAreOpVuR-GZovzVOmPkYA=8g8soCncdNMzN=frGJN2qLXRjA@mail.gmail.com>
	<CAOvn4qhpiPrgmBF+F79rpr_H5Kz_ZY-0U2Mn-hzKnRp7nPKLOA@mail.gmail.com>
	<CAP-uhDeooCq08s5iTPEZR7kKb+Z7Oou9nj=YXhwwyiAktpxHYA@mail.gmail.com>
	<CAHAreOrJgVnsjzGN4F2_36SMumjpsxchvu79azE4FfmtE21Hzg@mail.gmail.com>
	<CAP-uhDcubXU4SO1SVxN5uHskSRR5jyb1sEZGMSCHwN4w6BXKmw@mail.gmail.com>
	<B497CED6-E119-436E-BBAC-5B8C5292AE7F@gmail.com>
Message-ID: <CAOvn4qjWwTosKKdmbKC7zs68WjmutXb5v9RYOCP0G-7xd4zy9w@mail.gmail.com>

On 3 June 2012 01:54, Min RK <benjaminrk at gmail.com> wrote:
> I think script is probably best, and should then have a default interpreter
> of 'sh' (or $SHELL?).

I'd lean towards not having a default, so if you come across a script
cell, it's immediately clear what kind of script it is. Also, we aim
to be cross platform, so requiring 'sh' or 'bash' is a clear reminder
to the author that it won't work on Windows.

Thomas


From hans_meine at gmx.net  Sun Jun  3 14:56:59 2012
From: hans_meine at gmx.net (Hans Meine)
Date: Sun, 03 Jun 2012 20:56:59 +0200
Subject: [IPython-dev] Cell Magic names
In-Reply-To: <CAOvn4qjWwTosKKdmbKC7zs68WjmutXb5v9RYOCP0G-7xd4zy9w@mail.gmail.com>
References: <CAHNn8BWQduo4SUAhwzefVJu4BGSiy8WRv4oBCxxrGbrpzuAj6w@mail.gmail.com>
	<B497CED6-E119-436E-BBAC-5B8C5292AE7F@gmail.com>
	<CAOvn4qjWwTosKKdmbKC7zs68WjmutXb5v9RYOCP0G-7xd4zy9w@mail.gmail.com>
Message-ID: <7754652.tIHPHViiSg@hmeine-pc>

Am Sonntag, 3. Juni 2012, 14:38:54 schrieb Thomas Kluyver:
> On 3 June 2012 01:54, Min RK <benjaminrk at gmail.com> wrote:
> > I think script is probably best, and should then have a default
> > interpreter
> > of 'sh' (or $SHELL?).
> 
> I'd lean towards not having a default, so if you come across a script
> cell, it's immediately clear what kind of script it is. Also, we aim
> to be cross platform, so requiring 'sh' or 'bash' is a clear reminder
> to the author that it won't work on Windows.

Good point.

Interactively, I would rather like to have a default, but of course in a 
notebook (or similar) I would go with the Zen ("explicit is better?").  Maybe 
that explains the two opinions.

A solution could be to require a specification, but offer completion (e.g. 
from /etc/shells, with $SHELL being the default)?

Also note that %%script could remind of the 'script' program, whose main 
purpose is to copy(/tee) the fds 0,1,2 into a file.  That 'script' also has a 
default but allows selection with "-c command".

Best regards,
  Hans



From benjaminrk at gmail.com  Sun Jun  3 15:00:30 2012
From: benjaminrk at gmail.com (MinRK)
Date: Sun, 3 Jun 2012 12:00:30 -0700
Subject: [IPython-dev] Small config puzzle
In-Reply-To: <CAHAreOrR7-dtRwTD5ONbu7gtx-SzFzrZxbcn3TgjANvUgCHHFg@mail.gmail.com>
References: <CAHAreOrR7-dtRwTD5ONbu7gtx-SzFzrZxbcn3TgjANvUgCHHFg@mail.gmail.com>
Message-ID: <CAHNn8BV1ipzi33nnH+cyCLwGv8E+Th4gYj3+diTo-XDVA0FF_w@mail.gmail.com>

On Sat, Jun 2, 2012 at 8:18 PM, Fernando Perez <fperez.net at gmail.com> wrote:

> Howdy,
>
> (this is likely for Min, but perhaps somebody else knows) I'm kind of
> stumped trying to figure out why this works fine in my config file:
>
> c.InlineBackend.figure_format = 'png'  (or 'svg')
>
> but I can't seem to make this work:
>
> c.InlineBackend.rc['savefig.dpi'] = 96
>
> In fact, I get a traceback:
>
> [IPKernelApp] Exception while loading config file
> /home/fperez/.ipython/profile_default/ipython_notebook_config.py
> Traceback (most recent call last):
>  File
> "/home/fperez/usr/lib/python2.7/site-packages/IPython/config/application.py",
> line 447, in load_config_file
>    config = loader.load_config()
>  File
> "/home/fperez/usr/lib/python2.7/site-packages/IPython/config/loader.py",
> line 269, in load_config
>    self._read_file_as_dict()
>  File
> "/home/fperez/usr/lib/python2.7/site-packages/IPython/config/loader.py",
> line 322, in _read_file_as_dict
>    py3compat.execfile(conf_filename, namespace)
>  File
> "/home/fperez/usr/lib/python2.7/site-packages/IPython/utils/py3compat.py",
> line 178, in execfile
>    __builtin__.execfile(filename, *where)
>  File "/home/fperez/.ipython/profile_default/ipython_notebook_config.py",
> line 7, in <module>
>    c.InlineBackend.rc['savefig.dpi'] = 96
>  File
> "/home/fperez/usr/lib/python2.7/site-packages/IPython/config/loader.py",
> line 167, in __getattr__
>    raise AttributeError(e)
> AttributeError: 'rc'
>
>
> If I make the same change inside the backend_inline file in IPython
> itself it does have an effect, but not in the config file, and I'm
> curious why...  The rc field is a traitlet Dict.
>

The Config file has no idea that rc is a dict (or that rc is an option at
all).

The only thing you can do in config files is assignment:

c.InlineBackend.rc = {'savefig.dpi': 96}

Traitlets are not involved at all in the config files or the construction
of the config object, they determine how the config object (after it is
constructed by config files and command-line opts) is interpreted.

-MinRK


>
> Puzzled...  Before I dig into the traitlets machinery to track this
> down, I figured I'd ask...
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120603/74f46a60/attachment.html>

From benjaminrk at gmail.com  Sun Jun  3 15:13:20 2012
From: benjaminrk at gmail.com (MinRK)
Date: Sun, 3 Jun 2012 12:13:20 -0700
Subject: [IPython-dev] Add new commandline option from profile
In-Reply-To: <1338662744.15011.12.camel@bomberx.somewhere-in-the-space.org>
References: <1338662744.15011.12.camel@bomberx.somewhere-in-the-space.org>
Message-ID: <CAHNn8BUcz2Ws6pAAQYhK0XfykaYcRYP350e4Zp_xiU397gzbKQ@mail.gmail.com>

On Sat, Jun 2, 2012 at 11:45 AM, Arnaud Gardelein <arnaud at oscopy.org> wrote:

> Hi all,
>
> The new ipython configuration system allows to customize for particular
> application three classes, InteractiveShell, PrefilterManager and
> AliasManager all subclasses of Configurable as described in the
> documentation. Each option from those classes are settable from argument
> of ipython command.
> Assuming a new configurable object described in a ipython 'foo' profile:
>
> from IPython.config.configurable import Configurable
> from IPython.utils.traitlets import Int, Float, Unicode, Bool
> class Foo(Configurable):
>    name = Unicode(u'Foo')
>    bar = Bool(False, config=True)
>
> How to make the boolean 'bar' also an argument settable from ipython
> command with a '--bar' or '--no-bar' when invoking ipython
> --profile=foo?
>

You can't do precisely this, because the command-line args are fully parsed
by the time the profile is known (they are used to determine the profile!).

What is your *actual* goal here, because I doubt that it is to configure a
transient object in your config file that will be deleted immediately and
not importable, which would be the case if defined in a config file.

Note that there is a difference between "all configurables" being
accessible and the short '--foo' flags.  Those are manually defined, and
only for a short list of common options.  But *all* configurables are
available in the form:

    --Class.trait=foo

If your goal is to make a particular class of yours configurable, you can
set its options in this way, and then the only thing you need to do is pass
the IPython instance's config object to your constructor:


ipython --Foo.bar=True

In [1]: from IPython.config.configurable import Configurable
In [2]: from IPython.utils.traitlets import Bool

In [3]: class Foo(Configurable):
   ...:     bar = Bool(False, config=True)

In [4]: foo = Foo(config=get_ipython().config)

In [5]: foo.bar
Out[5]: True

-MinRK


>
> Thanks,
>
> Arnaud.
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120603/da583d0c/attachment.html>

From benjaminrk at gmail.com  Sun Jun  3 15:13:20 2012
From: benjaminrk at gmail.com (MinRK)
Date: Sun, 3 Jun 2012 12:13:20 -0700
Subject: [IPython-dev] Add new commandline option from profile
In-Reply-To: <1338662744.15011.12.camel@bomberx.somewhere-in-the-space.org>
References: <1338662744.15011.12.camel@bomberx.somewhere-in-the-space.org>
Message-ID: <CAHNn8BUcz2Ws6pAAQYhK0XfykaYcRYP350e4Zp_xiU397gzbKQ@mail.gmail.com>

On Sat, Jun 2, 2012 at 11:45 AM, Arnaud Gardelein <arnaud at oscopy.org> wrote:

> Hi all,
>
> The new ipython configuration system allows to customize for particular
> application three classes, InteractiveShell, PrefilterManager and
> AliasManager all subclasses of Configurable as described in the
> documentation. Each option from those classes are settable from argument
> of ipython command.
> Assuming a new configurable object described in a ipython 'foo' profile:
>
> from IPython.config.configurable import Configurable
> from IPython.utils.traitlets import Int, Float, Unicode, Bool
> class Foo(Configurable):
>    name = Unicode(u'Foo')
>    bar = Bool(False, config=True)
>
> How to make the boolean 'bar' also an argument settable from ipython
> command with a '--bar' or '--no-bar' when invoking ipython
> --profile=foo?
>

You can't do precisely this, because the command-line args are fully parsed
by the time the profile is known (they are used to determine the profile!).

What is your *actual* goal here, because I doubt that it is to configure a
transient object in your config file that will be deleted immediately and
not importable, which would be the case if defined in a config file.

Note that there is a difference between "all configurables" being
accessible and the short '--foo' flags.  Those are manually defined, and
only for a short list of common options.  But *all* configurables are
available in the form:

    --Class.trait=foo

If your goal is to make a particular class of yours configurable, you can
set its options in this way, and then the only thing you need to do is pass
the IPython instance's config object to your constructor:


ipython --Foo.bar=True

In [1]: from IPython.config.configurable import Configurable
In [2]: from IPython.utils.traitlets import Bool

In [3]: class Foo(Configurable):
   ...:     bar = Bool(False, config=True)

In [4]: foo = Foo(config=get_ipython().config)

In [5]: foo.bar
Out[5]: True

-MinRK


>
> Thanks,
>
> Arnaud.
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120603/da583d0c/attachment-0001.html>

From carl.input at gmail.com  Sun Jun  3 15:36:43 2012
From: carl.input at gmail.com (Carl Smith)
Date: Sun, 3 Jun 2012 20:36:43 +0100
Subject: [IPython-dev] Cell Magic names
In-Reply-To: <7754652.tIHPHViiSg@hmeine-pc>
References: <CAHNn8BWQduo4SUAhwzefVJu4BGSiy8WRv4oBCxxrGbrpzuAj6w@mail.gmail.com>
	<B497CED6-E119-436E-BBAC-5B8C5292AE7F@gmail.com>
	<CAOvn4qjWwTosKKdmbKC7zs68WjmutXb5v9RYOCP0G-7xd4zy9w@mail.gmail.com>
	<7754652.tIHPHViiSg@hmeine-pc>
Message-ID: <CAP-uhDcdFNWBnsnsMUpjoDavqb537wyrTuPx=OPSCGh_n3avgg@mail.gmail.com>

I'd suggest trying to make the interpreter used totally explicit for each
cell. I think notebook files should be readable as static HTML output
rather than full of stuff from the system it was written on.

Maybe have bookmarked interpreter paths so you can just do
%%script perl
if you ever wanted to.
On Jun 3, 2012 7:57 PM, "Hans Meine" <hans_meine at gmx.net> wrote:

> Am Sonntag, 3. Juni 2012, 14:38:54 schrieb Thomas Kluyver:
> > On 3 June 2012 01:54, Min RK <benjaminrk at gmail.com> wrote:
> > > I think script is probably best, and should then have a default
> > > interpreter
> > > of 'sh' (or $SHELL?).
> >
> > I'd lean towards not having a default, so if you come across a script
> > cell, it's immediately clear what kind of script it is. Also, we aim
> > to be cross platform, so requiring 'sh' or 'bash' is a clear reminder
> > to the author that it won't work on Windows.
>
> Good point.
>
> Interactively, I would rather like to have a default, but of course in a
> notebook (or similar) I would go with the Zen ("explicit is better?").
>  Maybe
> that explains the two opinions.
>
> A solution could be to require a specification, but offer completion (e.g.
> from /etc/shells, with $SHELL being the default)?
>
> Also note that %%script could remind of the 'script' program, whose main
> purpose is to copy(/tee) the fds 0,1,2 into a file.  That 'script' also
> has a
> default but allows selection with "-c command".
>
> Best regards,
>  Hans
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120603/16cad744/attachment.html>

From fperez.net at gmail.com  Sun Jun  3 16:11:13 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 3 Jun 2012 13:11:13 -0700
Subject: [IPython-dev] Small config puzzle
In-Reply-To: <CAHNn8BV1ipzi33nnH+cyCLwGv8E+Th4gYj3+diTo-XDVA0FF_w@mail.gmail.com>
References: <CAHAreOrR7-dtRwTD5ONbu7gtx-SzFzrZxbcn3TgjANvUgCHHFg@mail.gmail.com>
	<CAHNn8BV1ipzi33nnH+cyCLwGv8E+Th4gYj3+diTo-XDVA0FF_w@mail.gmail.com>
Message-ID: <CAHAreOqwY4tODwHtpKLa4DDJxd4TmFANibyKhy1Zbb7DKdDDgA@mail.gmail.com>

On Sun, Jun 3, 2012 at 12:00 PM, MinRK <benjaminrk at gmail.com> wrote:
> The Config file has no idea that rc is a dict (or that rc is an option at
> all).
>
> The only thing you can do in config files is assignment:
>
> c.InlineBackend.rc = {'savefig.dpi': 96}
>
> Traitlets are not involved at all in the config files or the construction of
> the config object, they determine how the config object (after it is
> constructed by config files and command-line opts) is interpreted.

Ah, understood.  Then the next question is: will the default rc object
be overridden or updated with these values?

Cheers,

f


From fperez.net at gmail.com  Sun Jun  3 16:17:52 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 3 Jun 2012 13:17:52 -0700
Subject: [IPython-dev] test_pr for 3.x picking up 2.x paths
In-Reply-To: <CAOvn4qjSigfoy8_SPC1USbg-TgSxceevxUhM7CW3FyJKYX0kYg@mail.gmail.com>
References: <CAHAreOrdBRdCtASk=edd1KOTuW7ntGph=O6QArM3-LR5QtOzwA@mail.gmail.com>
	<CAOvn4qjSigfoy8_SPC1USbg-TgSxceevxUhM7CW3FyJKYX0kYg@mail.gmail.com>
Message-ID: <CAHAreOo16P_DD4cXfSN5hvTt=13ufKxChsXNR7WATeGoQ8LXbQ@mail.gmail.com>

On Sun, Jun 3, 2012 at 6:29 AM, Thomas Kluyver <takowl at gmail.com> wrote:
> No flash of inspiration, sorry. I haven't seen that myself. If you
> check /home/fperez/.ipy_pr_tests/venv-python3.2/bin/iptest3 , does it
> have the correct shebang (should be pointing to a python executable in
> the same folder)?

It does, and it's indeed a python3 binary. At least now I see the
culprit.  If I wipe out PYTHONPATH and start that python, here's the
sys.path it sees:

>>> pprint(sys.path)
['',
 '/home/fperez/.ipy_pr_tests/venv-python3.2/lib/python3.2/site-packages/distribute-0.6.24-py3.2.egg',
 '/home/fperez/.ipy_pr_tests/venv-python3.2/lib/python3.2/site-packages/pip-1.1-py3.2.egg',
 '/home/fperez/.ipy_pr_tests/venv-python3.2/lib/python3.2/site-packages/ipython-0.13.dev-py3.2.egg',
 '/usr/lib/pymodules/python2.7',
 '/home/fperez/.ipy_pr_tests/venv-python3.2/bin',
 '/home/fperez/.ipy_pr_tests/venv-python3.2/lib/python3.2',
 '/home/fperez/.ipy_pr_tests/venv-python3.2/lib/python3.2/plat-linux2',
 '/home/fperez/.ipy_pr_tests/venv-python3.2/lib/python3.2/lib-dynload',
 '/usr/lib/python3.2',
 '/usr/lib/python3.2/plat-linux2',
 '/home/fperez/.ipy_pr_tests/venv-python3.2/lib/python3.2/site-packages',
 '/home/fperez/.local/lib/python3.2/site-packages',
 '/usr/lib/python3/dist-packages',
 '/usr/local/lib/python3.2/dist-packages']

That '/usr/lib/pymodules/python2.7' in the middle is what's messing
things up.  I wonder what in this Ubuntu box is setting that
variable...  It's not anything in my personal environment, b/c that's
all just PYTHONPATH.  It's as if a system-wide config file is getting
picked up somewhere...

Frustrating.

f


From fperez.net at gmail.com  Sun Jun  3 16:23:21 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 3 Jun 2012 13:23:21 -0700
Subject: [IPython-dev] Cell Magic names
In-Reply-To: <CAP-uhDcdFNWBnsnsMUpjoDavqb537wyrTuPx=OPSCGh_n3avgg@mail.gmail.com>
References: <CAHNn8BWQduo4SUAhwzefVJu4BGSiy8WRv4oBCxxrGbrpzuAj6w@mail.gmail.com>
	<B497CED6-E119-436E-BBAC-5B8C5292AE7F@gmail.com>
	<CAOvn4qjWwTosKKdmbKC7zs68WjmutXb5v9RYOCP0G-7xd4zy9w@mail.gmail.com>
	<7754652.tIHPHViiSg@hmeine-pc>
	<CAP-uhDcdFNWBnsnsMUpjoDavqb537wyrTuPx=OPSCGh_n3avgg@mail.gmail.com>
Message-ID: <CAHAreOqhDHnGVDtZf5MRmrm9q3mj=Wb9YyJOhqyOBChS2tXZQQ@mail.gmail.com>

On Sun, Jun 3, 2012 at 12:36 PM, Carl Smith <carl.input at gmail.com> wrote:
> I'd suggest trying to make the interpreter used totally explicit for each
> cell. I think notebook files should be readable as static HTML output rather
> than full of stuff from the system it was written on.

Agreed.

> Maybe have bookmarked interpreter paths so you can just do
> %%script perl
> if you ever wanted to.

I think %%script should always require an argument for the interpreter
to be used, while we can ship a few common defaults such as %%sh/bash,
%%cmd.exe, %%ruby, etc.  That way it's always explicit, but the common
cases don't need to be too verbose.

Cheers,

f


From benjaminrk at gmail.com  Sun Jun  3 16:28:37 2012
From: benjaminrk at gmail.com (Min RK)
Date: Sun, 3 Jun 2012 13:28:37 -0700
Subject: [IPython-dev] test_pr for 3.x picking up 2.x paths
In-Reply-To: <CAHAreOo16P_DD4cXfSN5hvTt=13ufKxChsXNR7WATeGoQ8LXbQ@mail.gmail.com>
References: <CAHAreOrdBRdCtASk=edd1KOTuW7ntGph=O6QArM3-LR5QtOzwA@mail.gmail.com>
	<CAOvn4qjSigfoy8_SPC1USbg-TgSxceevxUhM7CW3FyJKYX0kYg@mail.gmail.com>
	<CAHAreOo16P_DD4cXfSN5hvTt=13ufKxChsXNR7WATeGoQ8LXbQ@mail.gmail.com>
Message-ID: <8D30BB73-89C2-4B70-AC58-09FAD137B6F7@gmail.com>

Is it possible the venv hardcoded the PYTHONPATH into its site when it created the env?

-MinRK

On Jun 3, 2012, at 1:17 PM, Fernando Perez <fperez.net at gmail.com> wrote:

> On Sun, Jun 3, 2012 at 6:29 AM, Thomas Kluyver <takowl at gmail.com> wrote:
>> No flash of inspiration, sorry. I haven't seen that myself. If you
>> check /home/fperez/.ipy_pr_tests/venv-python3.2/bin/iptest3 , does it
>> have the correct shebang (should be pointing to a python executable in
>> the same folder)?
> 
> It does, and it's indeed a python3 binary. At least now I see the
> culprit.  If I wipe out PYTHONPATH and start that python, here's the
> sys.path it sees:
> 
>>>> pprint(sys.path)
> ['',
> '/home/fperez/.ipy_pr_tests/venv-python3.2/lib/python3.2/site-packages/distribute-0.6.24-py3.2.egg',
> '/home/fperez/.ipy_pr_tests/venv-python3.2/lib/python3.2/site-packages/pip-1.1-py3.2.egg',
> '/home/fperez/.ipy_pr_tests/venv-python3.2/lib/python3.2/site-packages/ipython-0.13.dev-py3.2.egg',
> '/usr/lib/pymodules/python2.7',
> '/home/fperez/.ipy_pr_tests/venv-python3.2/bin',
> '/home/fperez/.ipy_pr_tests/venv-python3.2/lib/python3.2',
> '/home/fperez/.ipy_pr_tests/venv-python3.2/lib/python3.2/plat-linux2',
> '/home/fperez/.ipy_pr_tests/venv-python3.2/lib/python3.2/lib-dynload',
> '/usr/lib/python3.2',
> '/usr/lib/python3.2/plat-linux2',
> '/home/fperez/.ipy_pr_tests/venv-python3.2/lib/python3.2/site-packages',
> '/home/fperez/.local/lib/python3.2/site-packages',
> '/usr/lib/python3/dist-packages',
> '/usr/local/lib/python3.2/dist-packages']
> 
> That '/usr/lib/pymodules/python2.7' in the middle is what's messing
> things up.  I wonder what in this Ubuntu box is setting that
> variable...  It's not anything in my personal environment, b/c that's
> all just PYTHONPATH.  It's as if a system-wide config file is getting
> picked up somewhere...
> 
> Frustrating.
> 
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev


From benjaminrk at gmail.com  Sun Jun  3 16:37:38 2012
From: benjaminrk at gmail.com (Min RK)
Date: Sun, 3 Jun 2012 13:37:38 -0700
Subject: [IPython-dev] Small config puzzle
In-Reply-To: <CAHAreOqwY4tODwHtpKLa4DDJxd4TmFANibyKhy1Zbb7DKdDDgA@mail.gmail.com>
References: <CAHAreOrR7-dtRwTD5ONbu7gtx-SzFzrZxbcn3TgjANvUgCHHFg@mail.gmail.com>
	<CAHNn8BV1ipzi33nnH+cyCLwGv8E+Th4gYj3+diTo-XDVA0FF_w@mail.gmail.com>
	<CAHAreOqwY4tODwHtpKLa4DDJxd4TmFANibyKhy1Zbb7DKdDDgA@mail.gmail.com>
Message-ID: <11322356-4DB7-4672-A6FB-A91F62BB6F18@gmail.com>



-MinRK

On Jun 3, 2012, at 1:11 PM, Fernando Perez <fperez.net at gmail.com> wrote:

> On Sun, Jun 3, 2012 at 12:00 PM, MinRK <benjaminrk at gmail.com> wrote:
>> The Config file has no idea that rc is a dict (or that rc is an option at
>> all).
>> 
>> The only thing you can do in config files is assignment:
>> 
>> c.InlineBackend.rc = {'savefig.dpi': 96}
>> 
>> Traitlets are not involved at all in the config files or the construction of
>> the config object, they determine how the config object (after it is
>> constructed by config files and command-line opts) is interpreted.
> 
> Ah, understood.  Then the next question is: will the default rc object
> be overridden or updated with these values?

Overridden. The only thing you can do in config is simple attribute assignment. It doesn't do anything fancy, so c.InlineBackend.rc = foo is the same as doing the actual assignment to the real object.

I don't know if you recall, but we discussed an API in your office to address this sort of thing for container traits, where we had an idea like:

c.InlineBackend._rc_update = dict(foo=bar)

for dicts or 

c.Foo._bar_extend = [more, entries]

for lists. 


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


From fperez.net at gmail.com  Sun Jun  3 19:21:32 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 3 Jun 2012 16:21:32 -0700
Subject: [IPython-dev] test_pr for 3.x picking up 2.x paths
In-Reply-To: <8D30BB73-89C2-4B70-AC58-09FAD137B6F7@gmail.com>
References: <CAHAreOrdBRdCtASk=edd1KOTuW7ntGph=O6QArM3-LR5QtOzwA@mail.gmail.com>
	<CAOvn4qjSigfoy8_SPC1USbg-TgSxceevxUhM7CW3FyJKYX0kYg@mail.gmail.com>
	<CAHAreOo16P_DD4cXfSN5hvTt=13ufKxChsXNR7WATeGoQ8LXbQ@mail.gmail.com>
	<8D30BB73-89C2-4B70-AC58-09FAD137B6F7@gmail.com>
Message-ID: <CAHAreOq7tvOxcKEAyE1jC9HZNU06bk+NrcBzL9Ash19jMsRW_A@mail.gmail.com>

On Sun, Jun 3, 2012 at 1:28 PM, Min RK <benjaminrk at gmail.com> wrote:
> Is it possible the venv hardcoded the PYTHONPATH into its site when it created the env?

Found it.  Very, very tricky debugging that required isntrumenting the
venv site.py with a custom class for sys.path that would trigger
pdb.set_trace() if anything attempted to insert a directory with '2.7'
in the name, eventually led me to finding this as the culprit:

blanca[~]> cat /home/fperez/.local/lib/python3.2/site-packages/easy-install.pth
import sys; sys.__plen = len(sys.path)
/usr/lib/pymodules/python2.7
import sys; new=sys.path[sys.__plen:]; del sys.path[sys.__plen:];
p=getattr(sys,'__egginsert',0); sys.path[p:p]=new; sys.__egginsert =
p+len(new)


For some completely incomprehensible reason, my distutils file in
~/.local for Python3 got built with a 2.7 path.  I'm not even going to
try to understand why that happened, I'm just sure that's what was
causing this problem, so I'll simply nuke it.

And that's why nobody else was seeing it.

Debugging the assembly of sys.path is not particularly pleasant, as
it's a global object that many codepaths jam directories into as the
interpreter spins up.

Oh well, one hour burned but one problem solved :) I can run test_pr again...

Cheers,

f


From fperez.net at gmail.com  Sun Jun  3 19:26:46 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 3 Jun 2012 16:26:46 -0700
Subject: [IPython-dev] Small config puzzle
In-Reply-To: <11322356-4DB7-4672-A6FB-A91F62BB6F18@gmail.com>
References: <CAHAreOrR7-dtRwTD5ONbu7gtx-SzFzrZxbcn3TgjANvUgCHHFg@mail.gmail.com>
	<CAHNn8BV1ipzi33nnH+cyCLwGv8E+Th4gYj3+diTo-XDVA0FF_w@mail.gmail.com>
	<CAHAreOqwY4tODwHtpKLa4DDJxd4TmFANibyKhy1Zbb7DKdDDgA@mail.gmail.com>
	<11322356-4DB7-4672-A6FB-A91F62BB6F18@gmail.com>
Message-ID: <CAHAreOrvA-S5xnq2Hk+Ge63D+rTqYU=NRRUC0XGev7k03covKA@mail.gmail.com>

On Sun, Jun 3, 2012 at 1:37 PM, Min RK <benjaminrk at gmail.com> wrote:
> Overridden. The only thing you can do in config is simple attribute assignment. It doesn't do anything fancy, so c.InlineBackend.rc = foo is the same as doing the actual assignment to the real object.
>
> I don't know if you recall, but we discussed an API in your office to address this sort of thing for container traits, where we had an idea like:
>
> c.InlineBackend._rc_update = dict(foo=bar)
>
> for dicts or
>
> c.Foo._bar_extend = [more, entries]
>
> for lists.

Yup, now I remember, and it might have been triggered by me trying to
mess around with this same guy. Though I still worry that it may be a
lot of special-case knowledge to expect users to remember...  I feel
like we haven't quite hit completely the sweet spot with the api for
this part (though by and large it works very well, given how complex
the problem it's faced with is).

Cheers,

f


From fperez.net at gmail.com  Sun Jun  3 19:27:12 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 3 Jun 2012 16:27:12 -0700
Subject: [IPython-dev] Fwd: notebook plots via javascript
In-Reply-To: <4FCBC545.5090607@gmail.com>
References: <4FCBC545.5090607@gmail.com>
Message-ID: <CAHAreOqzyg-nrm+wVHnbPWMdA8czPDe0hXD2VzKsb=kWB-E8Pw@mail.gmail.com>

Forwarding this from Zolt?n to the list, so we can continue the
discussion there.

---------- Forwarded message ----------
From: Zolt?n V?r?s <zvoros at gmail.com>
Date: Sun, Jun 3, 2012 at 1:12 PM
Subject: notebook plots via javascript
To: Fernando Perez <fperez.net at gmail.com>


Dear Fernando,

I hope you won't mind that I approach you in this way, bypassing the
mailing list. The reason is that I am not sure whether this would
interest many people, or whether this scheme is feasible at all, so I
wanted to have an opinion from the core development team first.

I have raised this issue a couple of times on the mailing list, but
after your announcement yesterday, I started to consider it more
seriously. In short, there seems to be a consensus that interactive
plots are within reach now, and in fact, using flot, it is already
doable. I have played with the flot.py script that you advertised
yesterday. Overall, I was quite impressed, however, I see one very
serious problem with it. At this point, it is not "compatible" with
matplotlib in the sense that one has to write separate scripts for
interactive (flot) and static (matplotlib) plots. I believe, down the
road it is going to be an annoying issue. Of course, one could just
write a wrapper of sort, take matplotlib-like plots, and turn them
into flot-like plots. This is what I started to do, but then I
realised that it might not be worthwhile at all, and perhaps, it is
easier to write a proper javascript backend to matplotlib than a
wrapper for flot.

So, I dug up the documentation and the source of the various backends,
and started to hack something. Based on what I already have, I am
quite convinced that this is not an insurmountable obstacle. I already
have static plots, and adding coordinate reporting, zooming, grid
toggling, and the like should not take me too long. I think, it is
only proper to acknowledge the expertise of John Hunter and his folk,
for they made sure that adding backends is doable, and in fact, it is
not difficult at all.

Now, my question really is whether there would be interest in a
javascript backend. This could be shipped with ipython as a module (it
is going to be something like 30-50 kB of code, depending on what kind
of functionality I implement), and then loaded whenever needed. I
could also make it modular in the sense that one could just have
templates for extra functionality, so one would not have to mess with
the python source itself.

I think, I would need 1-2 weeks for properly cleaning up the code.
Given my schedule, this is a lot of time, and I would probably not
spend it on a project that is used only by me. However, if you think
that there is potential in this approach, I would happily invest some
effort into it. I think I could also commit to maintaining the package
in the long run.

Let me know your opinion!

Cheers,
Zolt?n

PS: ipython is becoming more and more amazing by the hour. Many thanks
for your efforts!


From ellisonbg at gmail.com  Sun Jun  3 19:34:51 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Sun, 3 Jun 2012 16:34:51 -0700
Subject: [IPython-dev] Small config puzzle
In-Reply-To: <CAHAreOrvA-S5xnq2Hk+Ge63D+rTqYU=NRRUC0XGev7k03covKA@mail.gmail.com>
References: <CAHAreOrR7-dtRwTD5ONbu7gtx-SzFzrZxbcn3TgjANvUgCHHFg@mail.gmail.com>
	<CAHNn8BV1ipzi33nnH+cyCLwGv8E+Th4gYj3+diTo-XDVA0FF_w@mail.gmail.com>
	<CAHAreOqwY4tODwHtpKLa4DDJxd4TmFANibyKhy1Zbb7DKdDDgA@mail.gmail.com>
	<11322356-4DB7-4672-A6FB-A91F62BB6F18@gmail.com>
	<CAHAreOrvA-S5xnq2Hk+Ge63D+rTqYU=NRRUC0XGev7k03covKA@mail.gmail.com>
Message-ID: <CAH4pYpSqxj=NPeE18Gho0QUVgQej7UOaDfmqWsR8TTDkajyhmQ@mail.gmail.com>

I think that given our config system, the right solution is to move
the keys of rc to be top-level config attributes.

On Sun, Jun 3, 2012 at 4:26 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Sun, Jun 3, 2012 at 1:37 PM, Min RK <benjaminrk at gmail.com> wrote:
>> Overridden. The only thing you can do in config is simple attribute assignment. It doesn't do anything fancy, so c.InlineBackend.rc = foo is the same as doing the actual assignment to the real object.
>>
>> I don't know if you recall, but we discussed an API in your office to address this sort of thing for container traits, where we had an idea like:
>>
>> c.InlineBackend._rc_update = dict(foo=bar)
>>
>> for dicts or
>>
>> c.Foo._bar_extend = [more, entries]
>>
>> for lists.
>
> Yup, now I remember, and it might have been triggered by me trying to
> mess around with this same guy. Though I still worry that it may be a
> lot of special-case knowledge to expect users to remember... ?I feel
> like we haven't quite hit completely the sweet spot with the api for
> this part (though by and large it works very well, given how complex
> the problem it's faced with is).
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



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


From ellisonbg at gmail.com  Sun Jun  3 19:35:28 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Sun, 3 Jun 2012 16:35:28 -0700
Subject: [IPython-dev] Small config puzzle
In-Reply-To: <CAH4pYpSqxj=NPeE18Gho0QUVgQej7UOaDfmqWsR8TTDkajyhmQ@mail.gmail.com>
References: <CAHAreOrR7-dtRwTD5ONbu7gtx-SzFzrZxbcn3TgjANvUgCHHFg@mail.gmail.com>
	<CAHNn8BV1ipzi33nnH+cyCLwGv8E+Th4gYj3+diTo-XDVA0FF_w@mail.gmail.com>
	<CAHAreOqwY4tODwHtpKLa4DDJxd4TmFANibyKhy1Zbb7DKdDDgA@mail.gmail.com>
	<11322356-4DB7-4672-A6FB-A91F62BB6F18@gmail.com>
	<CAHAreOrvA-S5xnq2Hk+Ge63D+rTqYU=NRRUC0XGev7k03covKA@mail.gmail.com>
	<CAH4pYpSqxj=NPeE18Gho0QUVgQej7UOaDfmqWsR8TTDkajyhmQ@mail.gmail.com>
Message-ID: <CAH4pYpR-ugzGwmaecqi9YTeSxi2vxTFheTHmWtAhvrFQMSrbwA@mail.gmail.com>

Doing so will add 1) docuemenation and 2) typing.  Putting things into
dicts removes many of the benefits of our config system.

On Sun, Jun 3, 2012 at 4:34 PM, Brian Granger <ellisonbg at gmail.com> wrote:
> I think that given our config system, the right solution is to move
> the keys of rc to be top-level config attributes.
>
> On Sun, Jun 3, 2012 at 4:26 PM, Fernando Perez <fperez.net at gmail.com> wrote:
>> On Sun, Jun 3, 2012 at 1:37 PM, Min RK <benjaminrk at gmail.com> wrote:
>>> Overridden. The only thing you can do in config is simple attribute assignment. It doesn't do anything fancy, so c.InlineBackend.rc = foo is the same as doing the actual assignment to the real object.
>>>
>>> I don't know if you recall, but we discussed an API in your office to address this sort of thing for container traits, where we had an idea like:
>>>
>>> c.InlineBackend._rc_update = dict(foo=bar)
>>>
>>> for dicts or
>>>
>>> c.Foo._bar_extend = [more, entries]
>>>
>>> for lists.
>>
>> Yup, now I remember, and it might have been triggered by me trying to
>> mess around with this same guy. Though I still worry that it may be a
>> lot of special-case knowledge to expect users to remember... ?I feel
>> like we haven't quite hit completely the sweet spot with the api for
>> this part (though by and large it works very well, given how complex
>> the problem it's faced with is).
>>
>> Cheers,
>>
>> f
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu and ellisonbg at gmail.com



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


From fperez.net at gmail.com  Sun Jun  3 22:08:12 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 3 Jun 2012 19:08:12 -0700
Subject: [IPython-dev] Small config puzzle
In-Reply-To: <CAH4pYpR-ugzGwmaecqi9YTeSxi2vxTFheTHmWtAhvrFQMSrbwA@mail.gmail.com>
References: <CAHAreOrR7-dtRwTD5ONbu7gtx-SzFzrZxbcn3TgjANvUgCHHFg@mail.gmail.com>
	<CAHNn8BV1ipzi33nnH+cyCLwGv8E+Th4gYj3+diTo-XDVA0FF_w@mail.gmail.com>
	<CAHAreOqwY4tODwHtpKLa4DDJxd4TmFANibyKhy1Zbb7DKdDDgA@mail.gmail.com>
	<11322356-4DB7-4672-A6FB-A91F62BB6F18@gmail.com>
	<CAHAreOrvA-S5xnq2Hk+Ge63D+rTqYU=NRRUC0XGev7k03covKA@mail.gmail.com>
	<CAH4pYpSqxj=NPeE18Gho0QUVgQej7UOaDfmqWsR8TTDkajyhmQ@mail.gmail.com>
	<CAH4pYpR-ugzGwmaecqi9YTeSxi2vxTFheTHmWtAhvrFQMSrbwA@mail.gmail.com>
Message-ID: <CAHAreOpjwnGq3X1yd=vtRq-hboaxbE_p-kfSY=VEyFvU-_u-XQ@mail.gmail.com>

On Sun, Jun 3, 2012 at 4:35 PM, Brian Granger <ellisonbg at gmail.com> wrote:
> Doing so will add 1) docuemenation and 2) typing. ?Putting things into
> dicts removes many of the benefits of our config system.

Though keep in mind that in this case we're forwarding data to
matplotlib, so I don't think we should be in the business of
documenting each of those keys from their docs.  For the entire rc
object we can say 'Dict of options for matplotlib', but if we handle
each field by hand, we'd be essentially duplicating the matplotlib
docs and type info (and possibly going out of sync with them).

Plus, it then means we have to manually add code to sync each of these
values with the corresponding key in the mpl rc structure.  We'll have
say

c.InlineBackend.rc_savefig_dpi = 99

and then will need to manually update

plt.rcParams['savefig.dpi'] = ...rc_savefig_dpi

once for each field.  Right now we simply do plt.rcParams.update(c.rc)
and we're done.

Granted, since we're only handling a few keys this way the boilerplate
isn't too terrible, but I wouldn't want to write such code for all the
matplotlib options :)

The alternative is to tell users to first initialize the value with
the dict/list by importing the class object from our own code:

from IPython.core... import InlineBackend

c.InlineBackend.rc = InlineBackend.rc.copy()
c.InlineBackend.rc['foo'] = 'bar'


Each solution has some drawbacks, I'm not sure right now which are worse...

Cheers,

f


From benjaminrk at gmail.com  Sun Jun  3 22:55:19 2012
From: benjaminrk at gmail.com (MinRK)
Date: Sun, 3 Jun 2012 19:55:19 -0700
Subject: [IPython-dev] Small config puzzle
In-Reply-To: <CAHAreOpjwnGq3X1yd=vtRq-hboaxbE_p-kfSY=VEyFvU-_u-XQ@mail.gmail.com>
References: <CAHAreOrR7-dtRwTD5ONbu7gtx-SzFzrZxbcn3TgjANvUgCHHFg@mail.gmail.com>
	<CAHNn8BV1ipzi33nnH+cyCLwGv8E+Th4gYj3+diTo-XDVA0FF_w@mail.gmail.com>
	<CAHAreOqwY4tODwHtpKLa4DDJxd4TmFANibyKhy1Zbb7DKdDDgA@mail.gmail.com>
	<11322356-4DB7-4672-A6FB-A91F62BB6F18@gmail.com>
	<CAHAreOrvA-S5xnq2Hk+Ge63D+rTqYU=NRRUC0XGev7k03covKA@mail.gmail.com>
	<CAH4pYpSqxj=NPeE18Gho0QUVgQej7UOaDfmqWsR8TTDkajyhmQ@mail.gmail.com>
	<CAH4pYpR-ugzGwmaecqi9YTeSxi2vxTFheTHmWtAhvrFQMSrbwA@mail.gmail.com>
	<CAHAreOpjwnGq3X1yd=vtRq-hboaxbE_p-kfSY=VEyFvU-_u-XQ@mail.gmail.com>
Message-ID: <CAHNn8BX6yNg49=og25cXX97OpPqSHuLNzDn7A5Yxm54E1vT0dA@mail.gmail.com>

On Sun, Jun 3, 2012 at 7:08 PM, Fernando Perez <fperez.net at gmail.com> wrote:

> On Sun, Jun 3, 2012 at 4:35 PM, Brian Granger <ellisonbg at gmail.com> wrote:
> > Doing so will add 1) docuemenation and 2) typing.  Putting things into
> > dicts removes many of the benefits of our config system.
>

I definitely disagree that we should expose *all* of the little tweaks we
make for the inline backend defaults,
but maybe figsize and/or dpi.

Remember, the RC only exists because the matplotlib default config isn't
quite appropriate, so we tweak it.
If any of our overrides aren't right for you, you might as well ignore the
rest, because the margin / font
tweaks we make are probably irrelevant if you change the figure size and/or
dpi.

Also, it should be possible to uncomment the existing InlineBackend.rc line
for a no-op starting position,
which mitigates the issue (though on checking, I see that InlineBackend is
not included in the generated
config files, which I will get on now.

-MinRK


>
> Though keep in mind that in this case we're forwarding data to
> matplotlib, so I don't think we should be in the business of
> documenting each of those keys from their docs.  For the entire rc
> object we can say 'Dict of options for matplotlib', but if we handle
> each field by hand, we'd be essentially duplicating the matplotlib
> docs and type info (and possibly going out of sync with them).
>
> Plus, it then means we have to manually add code to sync each of these
> values with the corresponding key in the mpl rc structure.  We'll have
> say
>
> c.InlineBackend.rc_savefig_dpi = 99
>
> and then will need to manually update
>
> plt.rcParams['savefig.dpi'] = ...rc_savefig_dpi
>
> once for each field.  Right now we simply do plt.rcParams.update(c.rc)
> and we're done.
>
> Granted, since we're only handling a few keys this way the boilerplate
> isn't too terrible, but I wouldn't want to write such code for all the
> matplotlib options :)
>
> The alternative is to tell users to first initialize the value with
> the dict/list by importing the class object from our own code:
>
> from IPython.core... import InlineBackend
>
> c.InlineBackend.rc = InlineBackend.rc.copy()
> c.InlineBackend.rc['foo'] = 'bar'
>
>
> Each solution has some drawbacks, I'm not sure right now which are worse...
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120603/f02a8433/attachment.html>

From fperez.net at gmail.com  Sun Jun  3 23:03:31 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 3 Jun 2012 20:03:31 -0700
Subject: [IPython-dev] Removing pyparsing from IPython.external,
	any objections?
Message-ID: <CAHAreOrPJqciXsP9JfEnbm2QhwyHMZ4jC8A7n_6x6P9MYSp-WQ@mail.gmail.com>

Hi all,

in the past we've been shipping a (possibly outdated) copy of
pyparsing in IPython.external, but right now that code is unused by
IPython itself.  We'd like to get rid of it and simply let external
users who may need it use a system copy of pyparsing, rather than
carry around unused, untested code like this:

https://github.com/ipython/ipython/pull/1839

Any objections?

f


From takowl at gmail.com  Mon Jun  4 05:11:56 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 4 Jun 2012 10:11:56 +0100
Subject: [IPython-dev] test_pr for 3.x picking up 2.x paths
In-Reply-To: <CAHAreOq7tvOxcKEAyE1jC9HZNU06bk+NrcBzL9Ash19jMsRW_A@mail.gmail.com>
References: <CAHAreOrdBRdCtASk=edd1KOTuW7ntGph=O6QArM3-LR5QtOzwA@mail.gmail.com>
	<CAOvn4qjSigfoy8_SPC1USbg-TgSxceevxUhM7CW3FyJKYX0kYg@mail.gmail.com>
	<CAHAreOo16P_DD4cXfSN5hvTt=13ufKxChsXNR7WATeGoQ8LXbQ@mail.gmail.com>
	<8D30BB73-89C2-4B70-AC58-09FAD137B6F7@gmail.com>
	<CAHAreOq7tvOxcKEAyE1jC9HZNU06bk+NrcBzL9Ash19jMsRW_A@mail.gmail.com>
Message-ID: <CAOvn4qj-LAFW0X+sFjmYvH1uosWoG2PvjjCAUPm2HEaynAjoqA@mail.gmail.com>

On 4 June 2012 00:21, Fernando Perez <fperez.net at gmail.com> wrote:
> Oh well, one hour burned but one problem solved :) I can run test_pr again...

Ouch, that's bizarre. Glad you got it worked out, anyway.

Thomas


From takowl at gmail.com  Mon Jun  4 05:16:15 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 4 Jun 2012 10:16:15 +0100
Subject: [IPython-dev] Fwd: notebook plots via javascript
In-Reply-To: <CAHAreOqzyg-nrm+wVHnbPWMdA8czPDe0hXD2VzKsb=kWB-E8Pw@mail.gmail.com>
References: <4FCBC545.5090607@gmail.com>
	<CAHAreOqzyg-nrm+wVHnbPWMdA8czPDe0hXD2VzKsb=kWB-E8Pw@mail.gmail.com>
Message-ID: <CAOvn4qgMQUBequtKTNwNY4KVeXzGbnEyh_MbPsZv1jfuLoU8hA@mail.gmail.com>

> Now, my question really is whether there would be interest in a
> javascript backend.

I think there would be quite a lot of interest in that - I'd certainly
like to have interactive plots from matplotlib in the notebook. I'm
not sure whether it makes more sense for it to be shipped in IPython
or in matplotlib, but I'm sure it will find a home somewhere.

Thanks,
Thomas


From ludwig.schwardt at gmail.com  Mon Jun  4 07:08:09 2012
From: ludwig.schwardt at gmail.com (Ludwig Schwardt)
Date: Mon, 4 Jun 2012 21:08:09 +1000
Subject: [IPython-dev] Fwd: notebook plots via javascript
Message-ID: <CAJ3RG10PNCaL9p6S2d35RfHnNWufzyCWkmfUNugMJeTqZadJ1A@mail.gmail.com>

Hi Zolt?n,

> ---------- Forwarded message ----------
> So, I dug up the documentation and the source of the various backends,
> and started to hack something. Based on what I already have, I am
> quite convinced that this is not an insurmountable obstacle.
> ...
> Now, my question really is whether there would be interest in a
> javascript backend.

You might find the mplh5canvas backend (
http://code.google.com/p/mplh5canvas/) interesting. It is a JS backend for
matplotlib built around the HTML5 Canvas and WebSocket elements that
produces plots that compare well with those of other backends and also does
basic zooming and resizing. This backend has been around since matplotlib
1.0 and is independent of IPython.

We've also achieved basic integration with the IPython notebook a few
months ago (as witnessed by St?fan :-)), but that was before the latest JS
refactoring which should simplify things a lot.

I would love to hear any comments you might have, now that you have been
down a similar path.

Regards,
Ludwig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120604/a1fe79a6/attachment.html>

From jason-sage at creativetrax.com  Mon Jun  4 07:50:04 2012
From: jason-sage at creativetrax.com (Jason Grout)
Date: Mon, 04 Jun 2012 06:50:04 -0500
Subject: [IPython-dev] Fwd: notebook plots via javascript
In-Reply-To: <CAHAreOqzyg-nrm+wVHnbPWMdA8czPDe0hXD2VzKsb=kWB-E8Pw@mail.gmail.com>
References: <4FCBC545.5090607@gmail.com>
	<CAHAreOqzyg-nrm+wVHnbPWMdA8czPDe0hXD2VzKsb=kWB-E8Pw@mail.gmail.com>
Message-ID: <4FCCA0EC.2060400@creativetrax.com>

On 6/3/12 6:27 PM, Fernando Perez wrote:
> The reason is that I am not sure whether this would
> interest many people

I have long wanted to see something like this in Sage as well, so I'm 
definitely interested!

Jason



From zvoros at gmail.com  Mon Jun  4 08:48:05 2012
From: zvoros at gmail.com (=?UTF-8?B?Wm9sdMOhbiBWw7Zyw7Zz?=)
Date: Mon, 04 Jun 2012 14:48:05 +0200
Subject: [IPython-dev] Fwd: notebook plots via javascript
In-Reply-To: <CAJ3RG10PNCaL9p6S2d35RfHnNWufzyCWkmfUNugMJeTqZadJ1A@mail.gmail.com>
References: <CAJ3RG10PNCaL9p6S2d35RfHnNWufzyCWkmfUNugMJeTqZadJ1A@mail.gmail.com>
Message-ID: <4FCCAE85.4030306@gmail.com>

Greetings Ludwig,

Thanks for the comments! Below are mine.
>
> You might find the mplh5canvas backend 
> (http://code.google.com/p/mplh5canvas/) interesting. It is a JS 
> backend for matplotlib
I have seen this, in fact, about a month ago, it was I who suggested 
this to Fernando, but he convinced me that in the notebook one might 
want to have something different.

The first problem was the reliance on an external server. This could, of 
course, be fixed, at the expense of putting some extra load on the 
ipython kernel.

Second, for what I had in mind, a static javascript with basic 
functionalities, like coordinate reporting, grid toggling, and zooming 
should do. An example of this could be gnuplot's canvas terminal. 
http://gnuplot.sourceforge.net/demo_canvas_4.6/

I would bring two arguments in favour of a static file. First, if the 
plot does not require a server to run, then it can also be used in a 
static notebook, when you just save the notebook in html, and then open 
it on a computer that doesn't even have ipython installed. I think this 
is an advantage that should not be underestimated.

Second, I believe, the plot should not allow the user to significantly 
change the plot, e.g., removing data points and so on is probably not a 
good idea, because then the plot will be decoupled from the underlying 
code that generated it. (NB. zooming is already questionable in this 
regard.) One can go down that path, but that's a different paradigm, 
found in Origin and the like. However, if all one wants can be 
implemented in static code, why not implement it in static code? So, why 
I certainly see the enormous potential of the html5 backend, I am not 
convinced that that is the best option in the case at hand.

Well, these were my comments. Anyone else to chip in?

Best,
Zolt?n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120604/d32c6d63/attachment.html>

From zvoros at gmail.com  Mon Jun  4 09:00:01 2012
From: zvoros at gmail.com (=?ISO-8859-1?Q?Zolt=E1n_V=F6r=F6s?=)
Date: Mon, 04 Jun 2012 15:00:01 +0200
Subject: [IPython-dev]  Fwd: notebook plots via javascript
Message-ID: <4FCCB151.8060904@gmail.com>

Greetings Thomas, and Jason,

Thanks for the encouragement! I have replied to Ludwig Schwardt, the 
developer of the mpl5canvas backend. I had a couple of comments in my 
email. I think the first thing that should be established is whether the 
functionality that you want could be implemented in static code, and if 
so, we should implement it in static code, or do it via the 
kernel/server. In the latter case, one would only have to re-write parts 
of Ludwig's backend, and pass the plot request to the ipython kernel.

As for the place of the backend, I have read somewhere that matplotlib 
wants to do away with the plethora of backends, so I didn't even 
consider raising the issue there. Moreover, if we embark on implementing 
the backend "in-house", it could be implemented in a way that most suits 
ipython.

Cheers,
Zolt?n

> >/  Now, my question really is whether there would be interest in a
> />/  javascript backend.
> /
> I think there would be quite a lot of interest in that - I'd certainly
> like to have interactive plots from matplotlib in the notebook. I'm
> not sure whether it makes more sense for it to be shipped in IPython
> or in matplotlib, but I'm sure it will find a home somewhere.
>
> Thanks,
> Thomas

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

From ludwig.schwardt at gmail.com  Mon Jun  4 09:24:57 2012
From: ludwig.schwardt at gmail.com (Ludwig Schwardt)
Date: Mon, 4 Jun 2012 23:24:57 +1000
Subject: [IPython-dev] notebook plots via javascript
In-Reply-To: <4FCCAE85.4030306@gmail.com>
References: <CAJ3RG10PNCaL9p6S2d35RfHnNWufzyCWkmfUNugMJeTqZadJ1A@mail.gmail.com>
	<4FCCAE85.4030306@gmail.com>
Message-ID: <2AF5C02430F54CA6AAC47A344AAAD7F2@gmail.com>

Hi Zolt?n,  

Thanks for the comments - they are very insightful!

I agree that the static case is very useful, especially if it makes the notebook completely reproducible. In this case it improves on a static PNG or SVG by adding proper zooming via matplotlib (although I do agree with your concern regarding zooming). Here I also agree that mplh5canvas is overkill and probably not the way to go.

Just to highlight our use case: we use the mplh5canvas backend as part of a telescope control system based on IPython, where it displays interactive animated plots while commands are issued on the command line. We are interested in combining this functionality in the browser and thought of doing this within the notebook framework. Keeping up with the notebook is quite a challenge, however, so we probably need to do some rethinking based on the eventual 0.13 :-)  

Regards,
L.

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

From jdh2358 at gmail.com  Mon Jun  4 10:10:35 2012
From: jdh2358 at gmail.com (John Hunter)
Date: Mon, 4 Jun 2012 09:10:35 -0500
Subject: [IPython-dev] Fwd: notebook plots via javascript
In-Reply-To: <4FCCB151.8060904@gmail.com>
References: <4FCCB151.8060904@gmail.com>
Message-ID: <CAGD8yY9ZeUamF4677FRZ-zSbLxtZZebyJ5c4_notKcXhnpJP4A@mail.gmail.com>

On Mon, Jun 4, 2012 at 8:00 AM, Zolt?n V?r?s <zvoros at gmail.com> wrote:

> As for the place of the backend, I have read somewhere that matplotlib wants
> to do away with the plethora of backends, so I didn't even consider raising
> the issue there. Moreover, if we embark on implementing the backend
> "in-house", it could be implemented in a way that most suits ipython.

While we are definitely interested in reducing the number of backends
(eg native wx rendering) we are very interested in javascript in mpl,
primarily because there is such a compelling use case for it in the
notebook.

On the issue of interaction (pan/zoom/add or remove line) in the
notebook.  While I appreciate that there is value in
what-you-see-is-what-you-get vis-a-vis code in the notebook vs the
saved figure, I don't think it is our job to overly limit what the
user does.  Persistence is only one thing notebooks are good for,
others will use them as an interactive scratch pad, and interacting
with the figure in all sorts of ways is useful.  After they have
played around and want to persist the notebook, they always have the
option of re-running the cell to restore the original generated code
sans interaction.  I think it best to give people the maximally useful
thing, and let them make the right decisions about how they want to
use it.

In that vein, if you try to add rich interactions in a javascript
backend, I do think you will hit a wall at some point because the
backends are fairly dumbed down in mpl.  They are mostly a collection
of geometric primitives in display coordinates.  Eg, the axis tick
doesn't know it is part of the axis at the backend level, so
implementing interactive navigation might be challenging without
client/server cross-talk.

Another approach might be to not implement a backend at all, but a
matplotlib.figure.Figure persistence mechanism that outputs javascript
code.  Eg, if you hi-jacked the Figure.draw method, you might be able
to output more intelligent javascript because you would know "this is
the figure, this is the axes, this is the axis" and would have a
better view of the transformations, etc.  Just a thought about an
alternative approach.  We are also open to modifying the mpl
middle-ware to pass you more information as needed to the backend to
make sure you have what you need at the backend level.  Eg, we already
have the open_group/close_group methods, motivated by SVG to define
clickable groups (suppose you want to change the font of all the
ticklabels in inkscape), and we could extend this concept to pass
additional meta-data through.  Eg, the Axis open_group call could pass
"self" through if you wanted to grab some of the data from the
instance you were rendering.

I have been concerned for some time that the need for interactive
javascript plotting in the notebook would push efforts into yet
another plotting library, and hence fragment community resources.  If
we can get the job done in mpl, I would be very happy, and I'm sure we
can come up with some resources on our end to help you.

Thanks!
JDH


From zvoros at gmail.com  Mon Jun  4 10:17:57 2012
From: zvoros at gmail.com (=?UTF-8?B?Wm9sdMOhbiBWw7Zyw7Zz?=)
Date: Mon, 04 Jun 2012 16:17:57 +0200
Subject: [IPython-dev] notebook plots via javascript
In-Reply-To: <2AF5C02430F54CA6AAC47A344AAAD7F2@gmail.com>
References: <CAJ3RG10PNCaL9p6S2d35RfHnNWufzyCWkmfUNugMJeTqZadJ1A@mail.gmail.com>
	<4FCCAE85.4030306@gmail.com>
	<2AF5C02430F54CA6AAC47A344AAAD7F2@gmail.com>
Message-ID: <4FCCC395.3020008@gmail.com>

Hi Ludwig,
> I agree that the static case is very useful, especially if it makes 
> the notebook completely reproducible. In this case it improves on a 
> static PNG or SVG by adding proper zooming via matplotlib
Well, there is a long discussion, involving you, too, on the matplotlib 
development list:

http://sourceforge.net/mailarchive/forum.php?thread_name=4DF65B11.4070309%40head.cfa.harvard.edu&forum_name=matplotlib-devel

It is not clear to me at the moment whether interactive SVG would be 
better. There are some strong arguments in favour of SVG. But perhaps, 
some of the core developers of ipython could shed some light on what 
would be best in this case.
> Just to highlight our use case: we use the mplh5canvas backend as part 
> of a telescope control system based on IPython, where it displays 
> interactive animated plots while commands are issued on the command line.
In this case, I think the use of a server is completely justifiable. 
After all, you are controlling something real-time, so I understand that 
passing the plots though a websocket is really not an overkill.

Cheers,
Zolt?n


From krastanov.stefan at gmail.com  Mon Jun  4 10:53:52 2012
From: krastanov.stefan at gmail.com (krastanov.stefan at gmail.com)
Date: Mon, 4 Jun 2012 16:53:52 +0200
Subject: [IPython-dev] vim/emacs keybindings in the notebook
Message-ID: <CAD8szLwniLg1k-5gKeo20_JFPJLRBHSUnqHfuKcGhSXvQob-vA@mail.gmail.com>

Hello all,

I have found this in the archive:
http://mail.scipy.org/pipermail/ipython-dev/2012-January/008666.html

Was there a reason that the "default off" version of these keybindings
was not merged as suggested by Fernando Perez? Or had it just stalled
because of more important issues?

Best regards
Stefan Krastanov


From zvoros at gmail.com  Mon Jun  4 11:15:31 2012
From: zvoros at gmail.com (=?ISO-8859-1?Q?Zolt=E1n_V=F6r=F6s?=)
Date: Mon, 04 Jun 2012 17:15:31 +0200
Subject: [IPython-dev] Fwd: notebook plots via javascript
In-Reply-To: <CAGD8yY9ZeUamF4677FRZ-zSbLxtZZebyJ5c4_notKcXhnpJP4A@mail.gmail.com>
References: <4FCCB151.8060904@gmail.com>
	<CAGD8yY9ZeUamF4677FRZ-zSbLxtZZebyJ5c4_notKcXhnpJP4A@mail.gmail.com>
Message-ID: <4FCCD113.6050105@gmail.com>

Dear John,

Many thanks for your comments! I certainly didn't expect that you would 
chip in. Here are a couple of thoughts.
>> On the issue of interaction (pan/zoom/add or remove line) in the
>> notebook.  While I appreciate that there is value in
>> what-you-see-is-what-you-get vis-a-vis code in the notebook vs the
>> saved figure, I don't think it is our job to overly limit what the
>> user does.  Persistence is only one thing notebooks are good for,
>> others will use them as an interactive scratch pad, and interacting
>> with the figure in all sorts of ways is useful.
I definitely agree with this, and this is why I have said earlier that 
first we should sort out how interactive plots are going to be used. 
There are two things to consider, however. The first is that if one 
wants to have full interactivity, somewhere at the level of the Qt4, or 
GTK backends, then one has to go no further than Ludwig Schwardt's HTML5 
backend. The dependency on the extra web server could be removed, and 
everything could be handled in the ipython kernel. So, if this is indeed 
the case, then we should just slim down Ludwig's backend, and we are done.
The other comment I would add here is that once the decorators in the 
notebook are implemented (I have been given to understand that this is 
high on the list of the core developers), interactivity with the figure 
could be handled in a much easier way. Thus, I would probably not invest 
too much time in implementing a full-blown javascript backend.
>> After they have
>> played around and want to persist the notebook, they always have the
>> option of re-running the cell to restore the original generated code
>> sans interaction.  I think it best to give people the maximally useful
>> thing, and let them make the right decisions about how they want to
>> use it.
But this argument can be turned around: if I want to plot something else 
(e.g., remove a dataset from the plot), I can do that on the command 
line. Also, your argument hangs on the assumption that ipython is 
running in the background. But what if I print out the notebook with the 
"wrong" figures? I believe, this would lead to problems later on. The 
difficulty is that in the notebook you can see the code that actually 
generated the figure, while in Origin you can't, so it won't confuse 
you. Also, if you don't care about whether the figure that you see is 
related to the code above it, you could just use the notebook with the 
Qt4, or GTK backend. Then you would have interactivity, and in fact, 
there are already ways to connect all kinds of fancy functions to those 
backends. But you know this much better than me:)

But again, it would be great, if we could first sort out what is 
expected of the notebook.
>> In that vein, if you try to add rich interactions in a javascript
>> backend, I do think you will hit a wall at some point because the
>> backends are fairly dumbed down in mpl.  They are mostly a collection
>> of geometric primitives in display coordinates.  Eg, the axis tick
>> doesn't know it is part of the axis at the backend level, so
>> implementing interactive navigation might be challenging without
>> client/server cross-talk.
You are absolutely right, and simple things, like zooming, are already 
quite difficult with the present toolkit. What one could do in the 
notebook is return only the plot as javascript function, but then it 
would have to be "decorated" with helper functions that could be passed 
in from the python console. I believe, this is doable, though, not very 
elegant.
>> Another approach might be to not implement a backend at all, but a
>> matplotlib.figure.Figure persistence mechanism that outputs javascript
>> code.  Eg, if you hi-jacked the Figure.draw method, you might be able
>> to output more intelligent javascript because you would know "this is
>> the figure, this is the axes, this is the axis" and would have a
>> better view of the transformations, etc.  Just a thought about an
>> alternative approach.
Thanks for the pointer! I will try to look into that.
>> We are also open to modifying the mpl
>> middle-ware to pass you more information as needed to the backend to
>> make sure you have what you need at the backend level.  Eg, we already
>> have the open_group/close_group methods, motivated by SVG to define
>> clickable groups (suppose you want to change the font of all the
>> ticklabels in inkscape), and we could extend this concept to pass
>> additional meta-data through.  Eg, the Axis open_group call could pass
>> "self" through if you wanted to grab some of the data from the
>> instance you were rendering.
>>
>> I have been concerned for some time that the need for interactive
>> javascript plotting in the notebook would push efforts into yet
>> another plotting library, and hence fragment community resources.  If
>> we can get the job done in mpl, I would be very happy, and I'm sure we
>> can come up with some resources on our end to help you.
This sounds great, many thanks for offering your help! What could be 
useful is a tag for each path that would tell the user what that path 
belongs to. Whether it is a data point (if so, which dataset it belongs 
to), a tickmark, part of the legend, axis label and so on. So, instead 
of the code

  for points, control in path.iter_segments(transform, clip=None):
             if contol == Path.MOVETO:
                 ctx.moveTo(points[0], points[1])


it would be useful to have something like this

  for points, control, belongsto in path.iter_segments(transform, 
clip=None):
             if contol == Path.MOVETO:
                 if belongsto == path.TICKMARK:
                     pass
                 else;
                     ctx.moveTo(points[0], points[1])

or something like that. I just don't know what the least obtrusive way 
would be; my example would probably wreak havoc in other parts of the 
code. As you said above, some notion of the underlying data would be 
quite beneficial.

Beyond the notebook, having static, but interactive backends would be 
useful, anyway, because at this point, there is no easy way of producing 
an web-embeddable interactive figure. However, it is not clear to me, 
how one would handle the interactivity in the python code that produces 
the figures. Keyword arguments could, perhaps, do...?

Cheers,
Zolt?n



From bob+ipython at mcelrath.org  Mon Jun  4 12:40:33 2012
From: bob+ipython at mcelrath.org (Bob McElrath)
Date: Mon, 4 Jun 2012 16:40:33 +0000
Subject: [IPython-dev] notebook plots via javascript
Message-ID: <20120604164033.GH311@mcelrath.org>

I've played a bit with making matplotlib generate SVG through the IPython
notebook, but the rendering quality is below that of PNG's.  That can probably
be fixed, or maybe it's a renderer problem.  (lines seem to be improperly
anti-aliased in Chrome/Firefox/Inkscape) Anyway I just ran into this jQuery
library for SVG which could be very useful for IPython interactive plots:

    http://keith-wood.name/svg.html

I'd be a big fan of SVG+JS plots.

--
Cheers, Bob McElrath

"The individual has always had to struggle to keep from being overwhelmed by
the tribe.  If you try it, you will be lonely often, and sometimes frightened.
But no price is too high to pay for the privilege of owning yourself." 
    -- Friedrich Nietzsche


From zvoros at gmail.com  Mon Jun  4 13:12:14 2012
From: zvoros at gmail.com (=?ISO-8859-1?Q?Zolt=E1n_V=F6r=F6s?=)
Date: Mon, 04 Jun 2012 19:12:14 +0200
Subject: [IPython-dev] notebook plots via javascript
In-Reply-To: <20120604164033.GH311@mcelrath.org>
References: <20120604164033.GH311@mcelrath.org>
Message-ID: <4FCCEC6E.20101@gmail.com>

Hi Bob,

On 06/04/2012 06:40 PM, Bob McElrath wrote:
> I've played a bit with making matplotlib generate SVG through the IPython
> notebook, but the rendering quality is below that of PNG's.  That can probably
> be fixed, or maybe it's a renderer problem.  (lines seem to be improperly
> anti-aliased in Chrome/Firefox/Inkscape) Anyway I just ran into this jQuery
> library for SVG which could be very useful for IPython interactive plots:
>
>      http://keith-wood.name/svg.html
>
> I'd be a big fan of SVG+JS plots.
I saw this a couple of weeks ago, and it is really cool. The only 
objection I would have is that one would still have to write a quite 
complicated wrapper around it, if one wants to retain compatibility with 
matplotlib. The greatest appeal of a matplotlib backend is that all 
older python scripts would run as usual.

Cheers,
Zolt?n


From bob+ipython at mcelrath.org  Mon Jun  4 13:33:20 2012
From: bob+ipython at mcelrath.org (Bob McElrath)
Date: Mon, 4 Jun 2012 17:33:20 +0000
Subject: [IPython-dev] notebook plots via javascript
In-Reply-To: <4FCCEC6E.20101@gmail.com>
References: <20120604164033.GH311@mcelrath.org>
 <4FCCEC6E.20101@gmail.com>
Message-ID: <20120604173320.GA6159@mcelrath.org>

It seems to me that the majority of this work should actually be in the
matplotlib SVG backend.  IPython should just throw whatever matplotlib hands it
into the notebook.  Why does mplh5canvas require a server?!?

Modifying the output of matplotlib will be fragile.

Zolt?n V?r?s [zvoros at gmail.com] wrote:
> Hi Bob,
> 
> On 06/04/2012 06:40 PM, Bob McElrath wrote:
> >
> >     http://keith-wood.name/svg.html
> >
> >I'd be a big fan of SVG+JS plots.
> I saw this a couple of weeks ago, and it is really cool. The only
> objection I would have is that one would still have to write a quite
> complicated wrapper around it, if one wants to retain compatibility
> with matplotlib. The greatest appeal of a matplotlib backend is that
> all older python scripts would run as usual.
--
Cheers, Bob McElrath

"The individual has always had to struggle to keep from being overwhelmed by
the tribe.  If you try it, you will be lonely often, and sometimes frightened.
But no price is too high to pay for the privilege of owning yourself." 
    -- Friedrich Nietzsche


From zvoros at gmail.com  Mon Jun  4 13:35:18 2012
From: zvoros at gmail.com (=?ISO-8859-1?Q?Zolt=E1n_V=F6r=F6s?=)
Date: Mon, 04 Jun 2012 19:35:18 +0200
Subject: [IPython-dev] notebook plots via javascript
In-Reply-To: <20120604173320.GA6159@mcelrath.org>
References: <20120604164033.GH311@mcelrath.org> <4FCCEC6E.20101@gmail.com>
	<20120604173320.GA6159@mcelrath.org>
Message-ID: <4FCCF1D6.90808@gmail.com>

Hi Bob,
> It seems to me that the majority of this work should actually be in the
> matplotlib SVG backend.
This could be the case. I would be OK with that.

> IPython should just throw whatever matplotlib hands it
> into the notebook.  Why does mplh5canvas require a server?!?
Because that is how resizing, zooming, coordinate reporting and so on is 
done. As John Hunter pointed out earlier, by the time matplotlib reaches 
the backend, there is no notion of the data objects, there are only 
lines and letters, nothing more. Based on that, it would be hard to know 
how to zoom, e.g.
Cheers,
Zolt?n



From bob+ipython at mcelrath.org  Mon Jun  4 15:03:26 2012
From: bob+ipython at mcelrath.org (Bob McElrath)
Date: Mon, 4 Jun 2012 19:03:26 +0000
Subject: [IPython-dev] [PATCH] Jumpy notebook fixes
In-Reply-To: <20120604040558.GG311@mcelrath.org>
References: <20120604040558.GG311@mcelrath.org>
Message-ID: <20120604190326.GB6159@mcelrath.org>

I was bothered that in a number of different circumstances, the contents of the
Notebook would "jump".  For instance, when I focus on different cells in the
notebook, the text would jump over and down by 1px due to the added border.  The
menu bar has the same problem.  Also, clicking on a large cell that is partially
off screen would cause the window to recenter on its input cell, making it
difficult to select or examine part of a long output cell.

So attached is a tiny patch for these problems.  (against git head)

Explanation: 

Menu: the menu items need a 1px border so that when one is added by jQuery, the
menu item doesn't shift by 1px.  (ui-menu and ui-menu-item classes)

Cell focus: The jQuery class .ui-widget-content draws the border on the focused
cell, but the unfocused cell doesn't have a border, causing 1px jumping.  The
solution is to add a border for it, but then this will have higher specificity
than the jQuery class.  So I also added a redefinition of the focused cell
border with div.ui-widget-content, which has higher specificity.  A selected
cell was additionally getting an outline from jQuery when :active.  I also
disabled this by setting 'outline: none', to prevent flashing of the border when
a cell is clicked on.

Cell focus scrolling: The CodeMirror focus() call causes the window to scroll to
the CodeMirror input cell.  I removed this call from CodeCell.prototype.select()
and RawCell.prototype.select().  Additionally, the CodeMirror refresh() call is
only required if the input cell changes and must be redrawn.  This doesn't
happen on focus, it happens on edit, and refresh() is properly called in
TextCell.prototype.edit(), so isn't required in select().  I removed these
superfluous refresh() calls too.

In the future I'll use git, because I anticipate doing more work on IPython, but
for this tiny first patch, I thought I'd send it here.

Aside: nice job guys, you've managed to get me to do real mathematical work in
something other than Maple.  I *love* the IPython Notebook.  I've been cursing
and screaming at Maple/Mathematica, wanting something like the IPython notebook
for *years*.  (Some years ago I wrote an Axiom/TiddlyWiki "notebook"-like
interface that's very similar to your notebook, but didn't have the time/energy
to take it further)  If anyone is interested in a TiddlyWiki/IPython
combination, talk to me.

--
Cheers, Bob McElrath

"The individual has always had to struggle to keep from being overwhelmed by
the tribe.  If you try it, you will be lonely often, and sometimes frightened.
But no price is too high to pay for the privilege of owning yourself." 
    -- Friedrich Nietzsche
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipython-focused-cell-no-jump.patch
Type: text/x-diff
Size: 2102 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120604/aaa98b66/attachment.patch>

From ellisonbg at gmail.com  Mon Jun  4 15:26:31 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Mon, 4 Jun 2012 12:26:31 -0700
Subject: [IPython-dev] [PATCH] Jumpy notebook fixes
In-Reply-To: <20120604190326.GB6159@mcelrath.org>
References: <20120604040558.GG311@mcelrath.org>
	<20120604190326.GB6159@mcelrath.org>
Message-ID: <CAH4pYpS9vK2r2StpBZTT2W+qYbo7ngBwB-k4ZYU6MXTyJAD=vw@mail.gmail.com>

Bob,

Thanks for this - we have been meaning to look at this.  Can you open
a pull request on github so we can review it there.

Thanks!

Brian

On Mon, Jun 4, 2012 at 12:03 PM, Bob McElrath <bob+ipython at mcelrath.org> wrote:
> I was bothered that in a number of different circumstances, the contents of the
> Notebook would "jump". ?For instance, when I focus on different cells in the
> notebook, the text would jump over and down by 1px due to the added border. ?The
> menu bar has the same problem. ?Also, clicking on a large cell that is partially
> off screen would cause the window to recenter on its input cell, making it
> difficult to select or examine part of a long output cell.
>
> So attached is a tiny patch for these problems. ?(against git head)
>
> Explanation:
>
> Menu: the menu items need a 1px border so that when one is added by jQuery, the
> menu item doesn't shift by 1px. ?(ui-menu and ui-menu-item classes)
>
> Cell focus: The jQuery class .ui-widget-content draws the border on the focused
> cell, but the unfocused cell doesn't have a border, causing 1px jumping. ?The
> solution is to add a border for it, but then this will have higher specificity
> than the jQuery class. ?So I also added a redefinition of the focused cell
> border with div.ui-widget-content, which has higher specificity. ?A selected
> cell was additionally getting an outline from jQuery when :active. ?I also
> disabled this by setting 'outline: none', to prevent flashing of the border when
> a cell is clicked on.
>
> Cell focus scrolling: The CodeMirror focus() call causes the window to scroll to
> the CodeMirror input cell. ?I removed this call from CodeCell.prototype.select()
> and RawCell.prototype.select(). ?Additionally, the CodeMirror refresh() call is
> only required if the input cell changes and must be redrawn. ?This doesn't
> happen on focus, it happens on edit, and refresh() is properly called in
> TextCell.prototype.edit(), so isn't required in select(). ?I removed these
> superfluous refresh() calls too.
>
> In the future I'll use git, because I anticipate doing more work on IPython, but
> for this tiny first patch, I thought I'd send it here.
>
> Aside: nice job guys, you've managed to get me to do real mathematical work in
> something other than Maple. ?I *love* the IPython Notebook. ?I've been cursing
> and screaming at Maple/Mathematica, wanting something like the IPython notebook
> for *years*. ?(Some years ago I wrote an Axiom/TiddlyWiki "notebook"-like
> interface that's very similar to your notebook, but didn't have the time/energy
> to take it further) ?If anyone is interested in a TiddlyWiki/IPython
> combination, talk to me.
>
> --
> Cheers, Bob McElrath
>
> "The individual has always had to struggle to keep from being overwhelmed by
> the tribe. ?If you try it, you will be lonely often, and sometimes frightened.
> But no price is too high to pay for the privilege of owning yourself."
> ? ?-- Friedrich Nietzsche
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



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


From arnaud at oscopy.org  Mon Jun  4 15:30:09 2012
From: arnaud at oscopy.org (Arnaud Gardelein)
Date: Mon, 04 Jun 2012 21:30:09 +0200
Subject: [IPython-dev] Add new commandline option from profile
In-Reply-To: <CAHNn8BUcz2Ws6pAAQYhK0XfykaYcRYP350e4Zp_xiU397gzbKQ@mail.gmail.com>
References: <1338662744.15011.12.camel@bomberx.somewhere-in-the-space.org>
	<CAHNn8BUcz2Ws6pAAQYhK0XfykaYcRYP350e4Zp_xiU397gzbKQ@mail.gmail.com>
Message-ID: <1338838209.15011.44.camel@bomberx.somewhere-in-the-space.org>

> What is your *actual* goal here, because I doubt that it is to
> configure a transient object in your config file that will be deleted
> immediately and not importable, which would be the case if defined in
> a config file.
I should had started from here... I'm working on oscopy ( oscopy.org ,
latest features in experimental branch and -dev mailing list for doc).
It started as a pure python app and became some time ago yet another
ipython-based app during 0.10 era.
After making the transition to 0.11, now I want to restore the support
of commandline arguments that it had before the Switch (eg. batch,
interactive, quiet...) before adding others.

> If your goal is to make a particular class of yours configurable, you
> can set its options in this way, and then the only thing you need to
> do is pass the IPython instance's config object to your constructor:
> 
> ipython --Foo.bar=True
> In [1]: from IPython.config.configurable import Configurable
> In [2]: from IPython.utils.traitlets import Bool

> In [3]: class Foo(Configurable):
>    ...:     bar = Bool(False, config=True)

> In [4]: foo = Foo(config=get_ipython().config)

> In [5]: foo.bar
> Out[5]: True
> 
Now I understand that processing of the configurable options shall be
performed not from profile but from the app. I'm not sure of my
understanding, does this means that at time of args processing it is not
mandatory to have ipython's config loader is aware of the Foo class?
What I want to do is to add options to ipython when invoked with oscopy
profile and those options appear when doing 'ipython --profile=ioscopy
--help' as --term-title or --nosep do.
Is there a way to define aliases of --Foo.bar=True as -bar? I had a look
at IPython/core/{interactiveshell,alias,application}.py without success,
where are the manually defined flags? To define some for oscopy, shall
BaseIPythonApplication be derived?

Arnaud.






From benjaminrk at gmail.com  Mon Jun  4 15:44:56 2012
From: benjaminrk at gmail.com (MinRK)
Date: Mon, 4 Jun 2012 12:44:56 -0700
Subject: [IPython-dev] Add new commandline option from profile
In-Reply-To: <1338838209.15011.44.camel@bomberx.somewhere-in-the-space.org>
References: <1338662744.15011.12.camel@bomberx.somewhere-in-the-space.org>
	<CAHNn8BUcz2Ws6pAAQYhK0XfykaYcRYP350e4Zp_xiU397gzbKQ@mail.gmail.com>
	<1338838209.15011.44.camel@bomberx.somewhere-in-the-space.org>
Message-ID: <CAHNn8BXYKVXdDocB95zed4_NwXr0MvcPKOU9KQo3SLCYaAoWFQ@mail.gmail.com>

On Mon, Jun 4, 2012 at 12:30 PM, Arnaud Gardelein <arnaud at oscopy.org> wrote:

> > What is your *actual* goal here, because I doubt that it is to
> > configure a transient object in your config file that will be deleted
> > immediately and not importable, which would be the case if defined in
> > a config file.
> I should had started from here... I'm working on oscopy ( oscopy.org ,
> latest features in experimental branch and -dev mailing list for doc).
> It started as a pure python app and became some time ago yet another
> ipython-based app during 0.10 era.
> After making the transition to 0.11, now I want to restore the support
> of commandline arguments that it had before the Switch (eg. batch,
> interactive, quiet...) before adding others.
>
> > If your goal is to make a particular class of yours configurable, you
> > can set its options in this way, and then the only thing you need to
> > do is pass the IPython instance's config object to your constructor:
> >
> > ipython --Foo.bar=True
> > In [1]: from IPython.config.configurable import Configurable
> > In [2]: from IPython.utils.traitlets import Bool
>
> > In [3]: class Foo(Configurable):
> >    ...:     bar = Bool(False, config=True)
>
> > In [4]: foo = Foo(config=get_ipython().config)
>
> > In [5]: foo.bar
> > Out[5]: True
> >
> Now I understand that processing of the configurable options shall be
> performed not from profile but from the app. I'm not sure of my
> understanding, does this means that at time of args processing it is not
> mandatory to have ipython's config loader is aware of the Foo class?
>

Correct, the config object is just a dict-like object, so:

config.Class.trait = foo

gives something very similar to:

{ 'Class' : {'trait' : foo } }

There is no checking on the config object.  The way the config system works
is we pass this object to the constructors of Configurables, and that is
where values, etc. are extracted based on class names, and validated with
traitlets.

For this reason, you can pass config for Foo at the command-line, and then
import (or even define) the Foo class at a later point.


> What I want to do is to add options to ipython when invoked with oscopy
> profile and those options appear when doing 'ipython --profile=ioscopy
> --help' as --term-title or --nosep do.

Is there a way to define aliases of --Foo.bar=True as -bar?


No, this is not possible.  Command-line args have been fully processed by
the time the config files are known.  It is impossible for profiles to
affect the Application's parsing of the command-line.  The only thing you
can do if you want to piggy-back on IPython's command-line args is to use
the full --Class.trait=foo form, which is passed entirely without
validation.


> I had a look
> at IPython/core/{interactiveshell,alias,application}.py without success,
> where are the manually defined flags? To define some for oscopy, shall
> BaseIPythonApplication be derived?
>

If you wanted to create your own entry point (ipython-oscopy), this would
be how you would go about it.  But any such subclassing will have no effect
on how the command `ipython` starts or parses args.

-MinRK


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

From arnaud at oscopy.org  Mon Jun  4 16:13:44 2012
From: arnaud at oscopy.org (Arnaud Gardelein)
Date: Mon, 04 Jun 2012 22:13:44 +0200
Subject: [IPython-dev] Add new commandline option from profile
In-Reply-To: <CAHNn8BXYKVXdDocB95zed4_NwXr0MvcPKOU9KQo3SLCYaAoWFQ@mail.gmail.com>
References: <1338662744.15011.12.camel@bomberx.somewhere-in-the-space.org>
	<CAHNn8BUcz2Ws6pAAQYhK0XfykaYcRYP350e4Zp_xiU397gzbKQ@mail.gmail.com>
	<1338838209.15011.44.camel@bomberx.somewhere-in-the-space.org>
	<CAHNn8BXYKVXdDocB95zed4_NwXr0MvcPKOU9KQo3SLCYaAoWFQ@mail.gmail.com>
Message-ID: <1338840824.15011.47.camel@bomberx.somewhere-in-the-space.org>

Ok therefore I will use the --Class.trait=foo form. Many thanks!

Arnaud.

Le lundi 04 juin 2012 ? 12:44 -0700, MinRK a ?crit :
> 
> 
> On Mon, Jun 4, 2012 at 12:30 PM, Arnaud Gardelein <arnaud at oscopy.org>
> wrote:
>         > What is your *actual* goal here, because I doubt that it is
>         to
>         > configure a transient object in your config file that will
>         be deleted
>         > immediately and not importable, which would be the case if
>         defined in
>         > a config file.
>         
>         I should had started from here... I'm working on oscopy
>         ( oscopy.org ,
>         latest features in experimental branch and -dev mailing list
>         for doc).
>         It started as a pure python app and became some time ago yet
>         another
>         ipython-based app during 0.10 era.
>         After making the transition to 0.11, now I want to restore the
>         support
>         of commandline arguments that it had before the Switch (eg.
>         batch,
>         interactive, quiet...) before adding others.
>         
>         > If your goal is to make a particular class of yours
>         configurable, you
>         > can set its options in this way, and then the only thing you
>         need to
>         > do is pass the IPython instance's config object to your
>         constructor:
>         >
>         > ipython --Foo.bar=True
>         > In [1]: from IPython.config.configurable import Configurable
>         > In [2]: from IPython.utils.traitlets import Bool
>         
>         > In [3]: class Foo(Configurable):
>         >    ...:     bar = Bool(False, config=True)
>         
>         > In [4]: foo = Foo(config=get_ipython().config)
>         
>         > In [5]: foo.bar
>         > Out[5]: True
>         >
>         
>         Now I understand that processing of the configurable options
>         shall be
>         performed not from profile but from the app. I'm not sure of
>         my
>         understanding, does this means that at time of args processing
>         it is not
>         mandatory to have ipython's config loader is aware of the Foo
>         class?
> 
> 
> Correct, the config object is just a dict-like object, so:
> 
> 
> config.Class.trait = foo
> 
> 
> gives something very similar to:
> 
> 
> { 'Class' : {'trait' : foo } }
> 
> 
> There is no checking on the config object.  The way the config system
> works is we pass this object to the constructors of Configurables, and
> that is where values, etc. are extracted based on class names, and
> validated with traitlets.
> 
> 
> For this reason, you can pass config for Foo at the command-line, and
> then import (or even define) the Foo class at a later point.
>  
>         What I want to do is to add options to ipython when invoked
>         with oscopy
>         profile and those options appear when doing 'ipython
>         --profile=ioscopy
>         --help' as --term-title or --nosep do. 
>         Is there a way to define aliases of --Foo.bar=True as -bar?
> 
> 
> No, this is not possible.  Command-line args have been fully processed
> by the time the config files are known.  It is impossible for profiles
> to affect the Application's parsing of the command-line.  The only
> thing you can do if you want to piggy-back on IPython's command-line
> args is to use the full --Class.trait=foo form, which is passed
> entirely without validation.
>  
>         I had a look
>         at IPython/core/{interactiveshell,alias,application}.py
>         without success,
>         where are the manually defined flags? To define some for
>         oscopy, shall
>         BaseIPythonApplication be derived?
> 
> 
> If you wanted to create your own entry point (ipython-oscopy), this
> would be how you would go about it.  But any such subclassing will
> have no effect on how the command `ipython` starts or parses args.
> 
> 
> -MinRK
>  
>         
>         Arnaud.

> 




From ellisonbg at gmail.com  Mon Jun  4 17:42:16 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Mon, 4 Jun 2012 14:42:16 -0700
Subject: [IPython-dev] Small config puzzle
In-Reply-To: <CAHNn8BX6yNg49=og25cXX97OpPqSHuLNzDn7A5Yxm54E1vT0dA@mail.gmail.com>
References: <CAHAreOrR7-dtRwTD5ONbu7gtx-SzFzrZxbcn3TgjANvUgCHHFg@mail.gmail.com>
	<CAHNn8BV1ipzi33nnH+cyCLwGv8E+Th4gYj3+diTo-XDVA0FF_w@mail.gmail.com>
	<CAHAreOqwY4tODwHtpKLa4DDJxd4TmFANibyKhy1Zbb7DKdDDgA@mail.gmail.com>
	<11322356-4DB7-4672-A6FB-A91F62BB6F18@gmail.com>
	<CAHAreOrvA-S5xnq2Hk+Ge63D+rTqYU=NRRUC0XGev7k03covKA@mail.gmail.com>
	<CAH4pYpSqxj=NPeE18Gho0QUVgQej7UOaDfmqWsR8TTDkajyhmQ@mail.gmail.com>
	<CAH4pYpR-ugzGwmaecqi9YTeSxi2vxTFheTHmWtAhvrFQMSrbwA@mail.gmail.com>
	<CAHAreOpjwnGq3X1yd=vtRq-hboaxbE_p-kfSY=VEyFvU-_u-XQ@mail.gmail.com>
	<CAHNn8BX6yNg49=og25cXX97OpPqSHuLNzDn7A5Yxm54E1vT0dA@mail.gmail.com>
Message-ID: <CAH4pYpRL4SgupfauZ9-ywRyxJ60oWaq26uYJN0_CuQNREK+Bcg@mail.gmail.com>

On Sun, Jun 3, 2012 at 7:55 PM, MinRK <benjaminrk at gmail.com> wrote:
>
>
> On Sun, Jun 3, 2012 at 7:08 PM, Fernando Perez <fperez.net at gmail.com> wrote:
>>
>> On Sun, Jun 3, 2012 at 4:35 PM, Brian Granger <ellisonbg at gmail.com> wrote:
>> > Doing so will add 1) docuemenation and 2) typing. ?Putting things into
>> > dicts removes many of the benefits of our config system.
>
>
> I definitely disagree that we should expose *all* of the little tweaks we
> make for the inline backend defaults,
> but maybe figsize and/or dpi.
>
> Remember, the RC only exists because the matplotlib default config isn't
> quite appropriate, so we tweak it.
> If any of our overrides aren't right for you, you might as well ignore the
> rest, because the margin / font
> tweaks we make are probably irrelevant if you change the figure size and/or
> dpi.

Ahh, I didn't realize that any matplotlib config information could be
in the rc dict.  We definitely dont' want to mirror theirs.

> Also, it should be possible to uncomment the existing InlineBackend.rc line
> for a no-op starting position,
> which mitigates the issue (though on checking, I see that InlineBackend is
> not included in the generated
> config files, which I will get on now.

Cheers,

Brian

> -MinRK
>
>>
>>
>> Though keep in mind that in this case we're forwarding data to
>> matplotlib, so I don't think we should be in the business of
>> documenting each of those keys from their docs. ?For the entire rc
>> object we can say 'Dict of options for matplotlib', but if we handle
>> each field by hand, we'd be essentially duplicating the matplotlib
>> docs and type info (and possibly going out of sync with them).
>>
>> Plus, it then means we have to manually add code to sync each of these
>> values with the corresponding key in the mpl rc structure. ?We'll have
>> say
>>
>> c.InlineBackend.rc_savefig_dpi = 99
>>
>> and then will need to manually update
>>
>> plt.rcParams['savefig.dpi'] = ...rc_savefig_dpi
>>
>> once for each field. ?Right now we simply do plt.rcParams.update(c.rc)
>> and we're done.
>>
>> Granted, since we're only handling a few keys this way the boilerplate
>> isn't too terrible, but I wouldn't want to write such code for all the
>> matplotlib options :)
>>
>> The alternative is to tell users to first initialize the value with
>> the dict/list by importing the class object from our own code:
>>
>> from IPython.core... import InlineBackend
>>
>> c.InlineBackend.rc = InlineBackend.rc.copy()
>> c.InlineBackend.rc['foo'] = 'bar'
>>
>>
>> Each solution has some drawbacks, I'm not sure right now which are
>> worse...
>>
>> Cheers,
>>
>> f
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



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


From ellisonbg at gmail.com  Mon Jun  4 17:53:43 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Mon, 4 Jun 2012 14:53:43 -0700
Subject: [IPython-dev] vim/emacs keybindings in the notebook
In-Reply-To: <CAD8szLwniLg1k-5gKeo20_JFPJLRBHSUnqHfuKcGhSXvQob-vA@mail.gmail.com>
References: <CAD8szLwniLg1k-5gKeo20_JFPJLRBHSUnqHfuKcGhSXvQob-vA@mail.gmail.com>
Message-ID: <CAH4pYpRvvqtoqnGgDFh2bPWb2JZhJCeWkTOQ9Ck550yA6=mqWA@mail.gmail.com>

I think it just got stalled.

On Mon, Jun 4, 2012 at 7:53 AM, krastanov.stefan at gmail.com
<krastanov.stefan at gmail.com> wrote:
> Hello all,
>
> I have found this in the archive:
> http://mail.scipy.org/pipermail/ipython-dev/2012-January/008666.html
>
> Was there a reason that the "default off" version of these keybindings
> was not merged as suggested by Fernando Perez? Or had it just stalled
> because of more important issues?
>
> Best regards
> Stefan Krastanov
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



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


From bob+ipython at mcelrath.org  Mon Jun  4 18:05:24 2012
From: bob+ipython at mcelrath.org (Bob McElrath)
Date: Mon, 4 Jun 2012 22:05:24 +0000
Subject: [IPython-dev] [PATCH] Jumpy notebook fixes
In-Reply-To: <CAH4pYpS9vK2r2StpBZTT2W+qYbo7ngBwB-k4ZYU6MXTyJAD=vw@mail.gmail.com>
References: <20120604040558.GG311@mcelrath.org>
	<20120604190326.GB6159@mcelrath.org>
	<CAH4pYpS9vK2r2StpBZTT2W+qYbo7ngBwB-k4ZYU6MXTyJAD=vw@mail.gmail.com>
Message-ID: <20120604220524.GC6159@mcelrath.org>

Pull request submitted.  Let me know if I've done something wrong, I'm new to
git and github.

Brian Granger [ellisonbg at gmail.com] wrote:
> Bob,
> 
> Thanks for this - we have been meaning to look at this.  Can you open
> a pull request on github so we can review it there.
> 
> Thanks!
> 
> Brian
> 
> On Mon, Jun 4, 2012 at 12:03 PM, Bob McElrath <bob+ipython at mcelrath.org> wrote:
> > I was bothered that in a number of different circumstances, the contents of the
> > Notebook would "jump". ?For instance, when I focus on different cells in the
> > notebook, the text would jump over and down by 1px due to the added border. ?The
> > menu bar has the same problem. ?Also, clicking on a large cell that is partially
> > off screen would cause the window to recenter on its input cell, making it
> > difficult to select or examine part of a long output cell.
> >
> > So attached is a tiny patch for these problems. ?(against git head)
> >
> > Explanation:
> >
> > Menu: the menu items need a 1px border so that when one is added by jQuery, the
> > menu item doesn't shift by 1px. ?(ui-menu and ui-menu-item classes)
> >
> > Cell focus: The jQuery class .ui-widget-content draws the border on the focused
> > cell, but the unfocused cell doesn't have a border, causing 1px jumping. ?The
> > solution is to add a border for it, but then this will have higher specificity
> > than the jQuery class. ?So I also added a redefinition of the focused cell
> > border with div.ui-widget-content, which has higher specificity. ?A selected
> > cell was additionally getting an outline from jQuery when :active. ?I also
> > disabled this by setting 'outline: none', to prevent flashing of the border when
> > a cell is clicked on.
> >
> > Cell focus scrolling: The CodeMirror focus() call causes the window to scroll to
> > the CodeMirror input cell. ?I removed this call from CodeCell.prototype.select()
> > and RawCell.prototype.select(). ?Additionally, the CodeMirror refresh() call is
> > only required if the input cell changes and must be redrawn. ?This doesn't
> > happen on focus, it happens on edit, and refresh() is properly called in
> > TextCell.prototype.edit(), so isn't required in select(). ?I removed these
> > superfluous refresh() calls too.
> >
> > In the future I'll use git, because I anticipate doing more work on IPython, but
> > for this tiny first patch, I thought I'd send it here.
> >
> > Aside: nice job guys, you've managed to get me to do real mathematical work in
> > something other than Maple. ?I *love* the IPython Notebook. ?I've been cursing
> > and screaming at Maple/Mathematica, wanting something like the IPython notebook
> > for *years*. ?(Some years ago I wrote an Axiom/TiddlyWiki "notebook"-like
> > interface that's very similar to your notebook, but didn't have the time/energy
> > to take it further) ?If anyone is interested in a TiddlyWiki/IPython
> > combination, talk to me.
> >
> > --
> > Cheers, Bob McElrath
> >
> > "The individual has always had to struggle to keep from being overwhelmed by
> > the tribe. ?If you try it, you will be lonely often, and sometimes frightened.
> > But no price is too high to pay for the privilege of owning yourself."
> > ? ?-- Friedrich Nietzsche
> >
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> >
> 
> 
> 
> -- 
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu and ellisonbg at gmail.com
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
--
Cheers, Bob McElrath

"The individual has always had to struggle to keep from being overwhelmed by
the tribe.  If you try it, you will be lonely often, and sometimes frightened.
But no price is too high to pay for the privilege of owning yourself." 
    -- Friedrich Nietzsche


From fperez.net at gmail.com  Mon Jun  4 18:51:07 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 4 Jun 2012 15:51:07 -0700
Subject: [IPython-dev] vim/emacs keybindings in the notebook
In-Reply-To: <CAH4pYpRvvqtoqnGgDFh2bPWb2JZhJCeWkTOQ9Ck550yA6=mqWA@mail.gmail.com>
References: <CAD8szLwniLg1k-5gKeo20_JFPJLRBHSUnqHfuKcGhSXvQob-vA@mail.gmail.com>
	<CAH4pYpRvvqtoqnGgDFh2bPWb2JZhJCeWkTOQ9Ck550yA6=mqWA@mail.gmail.com>
Message-ID: <CAHAreOpWdSRad-dzHyK6CnYkUDw9CGD13Jk52uP4zE7dwgCn6Q@mail.gmail.com>

On Mon, Jun 4, 2012 at 2:53 PM, Brian Granger <ellisonbg at gmail.com> wrote:
> I think it just got stalled.

Yup, we're severely bandwidth limited.  Help on finishing up that work
would be greatly appreciated, as I'm sure many people would love more
powerful and familiar kebindings as an option.

Cheers,

f


From bob+ipython at mcelrath.org  Mon Jun  4 19:40:18 2012
From: bob+ipython at mcelrath.org (Bob McElrath)
Date: Mon, 4 Jun 2012 23:40:18 +0000
Subject: [IPython-dev] vim/emacs keybindings in the notebook
In-Reply-To: <CAHAreOpWdSRad-dzHyK6CnYkUDw9CGD13Jk52uP4zE7dwgCn6Q@mail.gmail.com>
References: <CAD8szLwniLg1k-5gKeo20_JFPJLRBHSUnqHfuKcGhSXvQob-vA@mail.gmail.com>
	<CAH4pYpRvvqtoqnGgDFh2bPWb2JZhJCeWkTOQ9Ck550yA6=mqWA@mail.gmail.com>
	<CAHAreOpWdSRad-dzHyK6CnYkUDw9CGD13Jk52uP4zE7dwgCn6Q@mail.gmail.com>
Message-ID: <20120604234018.GE6159@mcelrath.org>

Fernando Perez [fperez.net at gmail.com] wrote:
> On Mon, Jun 4, 2012 at 2:53 PM, Brian Granger <ellisonbg at gmail.com> wrote:
> > I think it just got stalled.
> 
> Yup, we're severely bandwidth limited.  Help on finishing up that work
> would be greatly appreciated, as I'm sure many people would love more
> powerful and familiar kebindings as an option.

I want vim keybidings.  I'll help.

In principle this should be easy, as CodeMirror already contains both emacs and
vim keybindings.  Edit IPython/frontend/html/notebook/static/js/codecell.js line
38 and add the keyMap option.  See:
    http://codemirror.net/doc/manual.html#option_keyMap
    http://codemirror.net/doc/manual.html#keymaps

This doesn't work though as ipython handles a lot of keys by itself, but it's a
starting point.

--
Cheers, Bob McElrath

"The individual has always had to struggle to keep from being overwhelmed by
the tribe.  If you try it, you will be lonely often, and sometimes frightened.
But no price is too high to pay for the privilege of owning yourself." 
    -- Friedrich Nietzsche


From fperez.net at gmail.com  Mon Jun  4 20:31:47 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 4 Jun 2012 17:31:47 -0700
Subject: [IPython-dev] R inside IPython (notebook,
	qtconsole or regular terminal)
Message-ID: <CAHAreOqLcvYirnAQCawBQ20+Mmv85sWkUdjX=DKGj+28K9BY5Q@mail.gmail.com>

Hi folks,

thanks to Jonathan Taylor (and those who contributed with review),
we've just merged this PR:

https://github.com/ipython/ipython/pull/1780

that lets you seamlessly use R from any IPython client.  This is what
it looks like in the notebook:

http://i.imgur.com/ShKEz.png

but you can equally use it from a terminal:

In [5]: X = np.array([0,1,2,3,4])

In [6]: Y = np.array([3,5,4,6,7])

In [7]: %load_ext rmagic

In [8]: %%R -i X,Y -o XYcoef
   ...: XYlm = lm(Y~X)
   ...: XYcoef = coef(XYlm)
   ...: print(summary(XYlm))
   ...:

Call:
lm(formula = Y ~ X)

Residuals:
   1    2    3    4    5
-0.2  0.9 -1.0  0.1  0.2

Coefficients:
            Estimate Std. Error t value Pr(>|t|)
(Intercept)   3.2000     0.6164   5.191   0.0139 *
X             0.9000     0.2517   3.576   0.0374 *
---
Signif. codes:  0 ?***? 0.001 ?**? 0.01 ?*? 0.05 ?.? 0.1 ? ? 1

Residual standard error: 0.7958 on 3 degrees of freedom
Multiple R-squared:  0.81,	Adjusted R-squared: 0.7467
F-statistic: 12.79 on 1 and 3 DF,  p-value: 0.03739

In [9]: XYcoef
Out[9]: array([ 3.2,  0.9])


We also have an octave one coming
(https://github.com/ipython/ipython/pull/1849) by Stefan, as well as
magics to access the shell and save files in the notebook server
(https://github.com/ipython/ipython/pull/1855).

I figured this group would particularly like the R one.  Many thanks
to Jonathan for the patient work during the fairly detailed review we
had prior to merging!

Cheers,

f


From vagabondaero at gmail.com  Mon Jun  4 21:21:45 2012
From: vagabondaero at gmail.com (Vagabond_Aero)
Date: Mon, 4 Jun 2012 18:21:45 -0700
Subject: [IPython-dev] vim/emacs keybindings in the notebook
In-Reply-To: <20120604234018.GE6159@mcelrath.org>
References: <CAD8szLwniLg1k-5gKeo20_JFPJLRBHSUnqHfuKcGhSXvQob-vA@mail.gmail.com>
	<CAH4pYpRvvqtoqnGgDFh2bPWb2JZhJCeWkTOQ9Ck550yA6=mqWA@mail.gmail.com>
	<CAHAreOpWdSRad-dzHyK6CnYkUDw9CGD13Jk52uP4zE7dwgCn6Q@mail.gmail.com>
	<20120604234018.GE6159@mcelrath.org>
Message-ID: <CAMHhCEWcXzkc5UkYvZX737Es=S20fU315t3daW2xiAsGGxeK=w@mail.gmail.com>

I, too, want vi keybindings.  I'll support this if possible!

On Mon, Jun 4, 2012 at 4:40 PM, Bob McElrath <bob+ipython at mcelrath.org>wrote:

> Fernando Perez [fperez.net at gmail.com] wrote:
> > On Mon, Jun 4, 2012 at 2:53 PM, Brian Granger <ellisonbg at gmail.com>
> wrote:
> > > I think it just got stalled.
> >
> > Yup, we're severely bandwidth limited.  Help on finishing up that work
> > would be greatly appreciated, as I'm sure many people would love more
> > powerful and familiar kebindings as an option.
>
> I want vim keybidings.  I'll help.
>
> In principle this should be easy, as CodeMirror already contains both
> emacs and
> vim keybindings.  Edit
> IPython/frontend/html/notebook/static/js/codecell.js line
> 38 and add the keyMap option.  See:
>    http://codemirror.net/doc/manual.html#option_keyMap
>    http://codemirror.net/doc/manual.html#keymaps
>
> This doesn't work though as ipython handles a lot of keys by itself, but
> it's a
> starting point.
>
> --
> Cheers, Bob McElrath
>
> "The individual has always had to struggle to keep from being overwhelmed
> by
> the tribe.  If you try it, you will be lonely often, and sometimes
> frightened.
> But no price is too high to pay for the privilege of owning yourself."
>    -- Friedrich Nietzsche
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Co-discoverer of KBO:
IH-X-694190<http://www.icehunters.org/object.php?id=694190>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120604/aa73a259/attachment.html>

From ellisonbg at gmail.com  Mon Jun  4 23:18:23 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Mon, 4 Jun 2012 20:18:23 -0700
Subject: [IPython-dev] MultiKernelManager vs. ipcluster
In-Reply-To: <4FC92F19.10308@creativetrax.com>
References: <4FC92F19.10308@creativetrax.com>
Message-ID: <CAH4pYpTivifwEUSbUZSNYu4qMb+wu+fwYJbft4VcPkpOGPfeNw@mail.gmail.com>

Jason,

Sorry it has taken me so long to get back to you...

On Fri, Jun 1, 2012 at 2:07 PM, Jason Grout <jason-sage at creativetrax.com> wrote:
> Hi everyone,
>
> As mentioned yesterday, we've been exploring ways to implement the Sage
> cell server using the IPython capabilities better. ?This message is a
> call for comments, as well as a few questions about the directions of
> things like ipcluster.
>
> Our goals are to:
>
> * start multiple kernels/engines very quickly (e.g., through forking a
> master kernel)
> * connect single kernels to single web sessions
> * be able to transfer files back and forth between the executing
> environment and the web browser
> * do things as securely as is reasonable (e.g., workers are running on a
> firewalled virtual instance, etc.)
> * be able to use an enterprise-level web server, such as Google App Engine.

Honestly I am not sure it makes sense to use IPython at all.  The
design requirements for IPython are very different from this.  I worry
that you are always going to be fighting the design.  ZeroMQ/PyZMQ
makes so much of this type of thing really easy.

>
> We've explored two approaches, and have somewhat-barely-working partial
> proofs-of-concepts of each:
>
> IPCLUSTER
> ---------
>
> We implemented a forking engine factory which is run on the worker
> computer. ?A cluster can start up new engines by sshing into the worker
> computer and sending a message to the forking engine factory. ?A new
> engine starts and then registers with the controller. ?We're thinking it
> might be best to implement a new scheduler that would take messages,
> check to see if the session id matches up with one of the
> currently-running engines, and send the message to the appropriate
> engine if so. ?If the message id does not match up to a currently
> running engine, then the scheduler would start up a new engine (can the
> scheduler do this?)
>
> The client would basically be the zmq/socket.io bridge, translating
> messages to/from the controller and the browser. ?I guess we could
> implement one client per session, or we could implement one overall
> client that would route cluster output to the appropriate browser.

ipcluster is a very specialized tool for starting engines in various
environments.  If I had your design constraints I would not try to use
ipcluster.

>
> MULTI FORKING KERNEL MANAGER
> ----------------------------
>
> This approach stays much closer to the current IPython notebook
> architecture. ?A MultiKernelManager starts up kernels using a
> ForkingKernelManager (based on Min's gist the other day). ?Each kernel
> sets up a connection to a specific set of websocket channels through a
> tornado-based bridge. ?We still have to implement things like separation
> of the forked kernels (on a separate ssh account somewhere) and the
> tornado handler, and things like that.

You will have to be very careful about the security aspects of this.
You should assume that the kernel running process is entirely hostile
and allow no traffic that originates from it to reach the tornado web
server.

>
> THOUGHTS
> --------
> It seems that the multikernel manager is much lighter-weight, but we'd
> have to implement a lot of the enterprise-level functionality that the
> cluster already has. ?On the other hand, the ipcluster approach really
> does more than we need, so, in a sense, we need to trim it back. ?We're
> not asking you to make a decision for us, obviously, but it would be
> valuable to hear any comments or suggestions.

If security is important I think you will have to roll your own.
If security is important you will have to come up with a system level
solution - not something that is simply a python library.

> SPECIFIC QUESTIONS
> ------------------
>
> 1. Brian, why did you decide to make a new multikernel manager instead
> of trying to leverage the ipcluster functionality to execute multiple
> engines?

1) ipcluster just does too much that is irrelevant to starting kernels
for the notebook.
2) ipcluster doesn't do any of the more advanced things that you need
for starting kernels across many systems.

> 2. Some time ago, on this list or on a pull request, there was some
> discussion about the difference between kernels and engines (or the lack
> of difference). ?Are there some plans to simplify the ipcluster
> architecture a bit to merge the concepts of engines and kernels?

I think Min has answered this, but the answer is now that engine = kernel.

> 3. Any idea about how much overhead the cluster introduces for lots of
> short computations involving lots of output? ?We'll test this too, but
> I'm curious if there was thought towards this use-case in the design.

This one is tough to answer.  In general the overhead of
PyZMQ/ZeroMQ/IPython is extremely low.  The overheads you will run
into will be completely determined by things like network throughput,
etc.

Cheers,

Brian

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



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


From ellisonbg at gmail.com  Mon Jun  4 23:52:04 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Mon, 4 Jun 2012 20:52:04 -0700
Subject: [IPython-dev] notebook plots via javascript
In-Reply-To: <4FCCF1D6.90808@gmail.com>
References: <20120604164033.GH311@mcelrath.org> <4FCCEC6E.20101@gmail.com>
	<20120604173320.GA6159@mcelrath.org> <4FCCF1D6.90808@gmail.com>
Message-ID: <CAH4pYpT40b3w8rwwQ+yVcNp+kHDr603j3K5KuDaeeNoXdVTf+A@mail.gmail.com>

Hi,

Great discussion!  Some general thoughts:

* I agree that interactive plotting in the notebook is really important.
* I would love to see that emerge out of matplotlib, rather than YAPL
(yet another plotting library).
* Someone is going to have to write very complex JavaScript code (or
we use an existing library) to create and manipulate the plots on the
browser side of things.  As mentioned above, this logic extends far
beyond the low-level primitives that the matplotlib backend API knows
about.  Because of this, I don't think we can approach this as purely
a matplotlib backend.
* Ideally the code produced in this effort would not only work in
IPython, but it would work in IPython.  Given the very specific
architecture of IPython, that is going to be challening.

Based on these observations, I am thinking of something like the following:

* We implement a JSON backend for matplotlib.  Basically, whenever one
of the backend methods is called, it would write to a JSON structure.
At the end of the day, there would be a JSON structure that has the
entire set of drawing primitives and all their details.  This part of
the code would be fully reusable by other "frontends" and would
provide a serialization format for matplotlib.
* We implement a JavaScript plugin/widget that works with the IPython
Notebook that consumes that JSON and creates an interactive plot based
on that information.  This part of the code would be specific to
IPython.

Does this sound reasonable?

Cheers,

Brian

On Mon, Jun 4, 2012 at 10:35 AM, Zolt?n V?r?s <zvoros at gmail.com> wrote:
> Hi Bob,
>> It seems to me that the majority of this work should actually be in the
>> matplotlib SVG backend.
> This could be the case. I would be OK with that.
>
>> IPython should just throw whatever matplotlib hands it
>> into the notebook. ?Why does mplh5canvas require a server?!?
> Because that is how resizing, zooming, coordinate reporting and so on is
> done. As John Hunter pointed out earlier, by the time matplotlib reaches
> the backend, there is no notion of the data objects, there are only
> lines and letters, nothing more. Based on that, it would be hard to know
> how to zoom, e.g.
> Cheers,
> Zolt?n
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



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


From ellisonbg at gmail.com  Tue Jun  5 00:07:33 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Mon, 4 Jun 2012 21:07:33 -0700
Subject: [IPython-dev] [PATCH] Jumpy notebook fixes
In-Reply-To: <20120604220524.GC6159@mcelrath.org>
References: <20120604040558.GG311@mcelrath.org>
	<20120604190326.GB6159@mcelrath.org>
	<CAH4pYpS9vK2r2StpBZTT2W+qYbo7ngBwB-k4ZYU6MXTyJAD=vw@mail.gmail.com>
	<20120604220524.GC6159@mcelrath.org>
Message-ID: <CAH4pYpSSNYzo1zSo9CGpg7NRNMML0qcWUH=mUtPjoYPWOsW4WA@mail.gmail.com>

Great, will follow up there.  Thanks!

On Mon, Jun 4, 2012 at 3:05 PM, Bob McElrath <bob+ipython at mcelrath.org> wrote:
> Pull request submitted. ?Let me know if I've done something wrong, I'm new to
> git and github.
>
> Brian Granger [ellisonbg at gmail.com] wrote:
>> Bob,
>>
>> Thanks for this - we have been meaning to look at this. ?Can you open
>> a pull request on github so we can review it there.
>>
>> Thanks!
>>
>> Brian
>>
>> On Mon, Jun 4, 2012 at 12:03 PM, Bob McElrath <bob+ipython at mcelrath.org> wrote:
>> > I was bothered that in a number of different circumstances, the contents of the
>> > Notebook would "jump". ?For instance, when I focus on different cells in the
>> > notebook, the text would jump over and down by 1px due to the added border. ?The
>> > menu bar has the same problem. ?Also, clicking on a large cell that is partially
>> > off screen would cause the window to recenter on its input cell, making it
>> > difficult to select or examine part of a long output cell.
>> >
>> > So attached is a tiny patch for these problems. ?(against git head)
>> >
>> > Explanation:
>> >
>> > Menu: the menu items need a 1px border so that when one is added by jQuery, the
>> > menu item doesn't shift by 1px. ?(ui-menu and ui-menu-item classes)
>> >
>> > Cell focus: The jQuery class .ui-widget-content draws the border on the focused
>> > cell, but the unfocused cell doesn't have a border, causing 1px jumping. ?The
>> > solution is to add a border for it, but then this will have higher specificity
>> > than the jQuery class. ?So I also added a redefinition of the focused cell
>> > border with div.ui-widget-content, which has higher specificity. ?A selected
>> > cell was additionally getting an outline from jQuery when :active. ?I also
>> > disabled this by setting 'outline: none', to prevent flashing of the border when
>> > a cell is clicked on.
>> >
>> > Cell focus scrolling: The CodeMirror focus() call causes the window to scroll to
>> > the CodeMirror input cell. ?I removed this call from CodeCell.prototype.select()
>> > and RawCell.prototype.select(). ?Additionally, the CodeMirror refresh() call is
>> > only required if the input cell changes and must be redrawn. ?This doesn't
>> > happen on focus, it happens on edit, and refresh() is properly called in
>> > TextCell.prototype.edit(), so isn't required in select(). ?I removed these
>> > superfluous refresh() calls too.
>> >
>> > In the future I'll use git, because I anticipate doing more work on IPython, but
>> > for this tiny first patch, I thought I'd send it here.
>> >
>> > Aside: nice job guys, you've managed to get me to do real mathematical work in
>> > something other than Maple. ?I *love* the IPython Notebook. ?I've been cursing
>> > and screaming at Maple/Mathematica, wanting something like the IPython notebook
>> > for *years*. ?(Some years ago I wrote an Axiom/TiddlyWiki "notebook"-like
>> > interface that's very similar to your notebook, but didn't have the time/energy
>> > to take it further) ?If anyone is interested in a TiddlyWiki/IPython
>> > combination, talk to me.
>> >
>> > --
>> > Cheers, Bob McElrath
>> >
>> > "The individual has always had to struggle to keep from being overwhelmed by
>> > the tribe. ?If you try it, you will be lonely often, and sometimes frightened.
>> > But no price is too high to pay for the privilege of owning yourself."
>> > ? ?-- Friedrich Nietzsche
>> >
>> > _______________________________________________
>> > IPython-dev mailing list
>> > IPython-dev at scipy.org
>> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >
>>
>>
>>
>> --
>> Brian E. Granger
>> Cal Poly State University, San Luis Obispo
>> bgranger at calpoly.edu and ellisonbg at gmail.com
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> --
> Cheers, Bob McElrath
>
> "The individual has always had to struggle to keep from being overwhelmed by
> the tribe. ?If you try it, you will be lonely often, and sometimes frightened.
> But no price is too high to pay for the privilege of owning yourself."
> ? ?-- Friedrich Nietzsche
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



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


From jason-sage at creativetrax.com  Tue Jun  5 00:17:10 2012
From: jason-sage at creativetrax.com (Jason Grout)
Date: Mon, 04 Jun 2012 23:17:10 -0500
Subject: [IPython-dev] MultiKernelManager vs. ipcluster
In-Reply-To: <CAH4pYpTivifwEUSbUZSNYu4qMb+wu+fwYJbft4VcPkpOGPfeNw@mail.gmail.com>
References: <4FC92F19.10308@creativetrax.com>
	<CAH4pYpTivifwEUSbUZSNYu4qMb+wu+fwYJbft4VcPkpOGPfeNw@mail.gmail.com>
Message-ID: <4FCD8846.4080903@creativetrax.com>

On 6/4/12 10:18 PM, Brian Granger wrote:

>> Our goals are to:
>>
>> * start multiple kernels/engines very quickly (e.g., through forking a
>> master kernel)
>> * connect single kernels to single web sessions
>> * be able to transfer files back and forth between the executing
>> environment and the web browser
>> * do things as securely as is reasonable (e.g., workers are running on a
>> firewalled virtual instance, etc.)
>> * be able to use an enterprise-level web server, such as Google App Engine.
>
> Honestly I am not sure it makes sense to use IPython at all.  The
> design requirements for IPython are very different from this.  I worry
> that you are always going to be fighting the design.  ZeroMQ/PyZMQ
> makes so much of this type of thing really easy.

We fleshed out today what I think is a decent approach to accomplishing 
all of our objectives.  It uses parts of the kernel class, and probably 
will reuse the javascript kernel object and the zmq/websocket bridge for 
our initial implementation.  We're rolling our own kernel managers to 
handle security and forking.  We'll draw up a short diagram of the 
design soon.


> ipcluster is a very specialized tool for starting engines in various
> environments.  If I had your design constraints I would not try to use
> ipcluster.

That's what we decided today too.  We fleshed out two designs, ended up 
realizing they were basically equivalent, but that there was a lot of 
extra baggage in the ipcluster-based solution, and decided against it. 
Thanks for the validation of not using ipcluster.

>
> You will have to be very careful about the security aspects of this.
> You should assume that the kernel running process is entirely hostile
> and allow no traffic that originates from it to reach the tornado web
> server.

Yes, that is the assumption.  The messages the web server pulls from a 
kernel will be directly relayed to the browser client; the tornado 
server should treat all such messages as strings.


> If security is important I think you will have to roll your own.
> If security is important you will have to come up with a system level
> solution - not something that is simply a python library.

We are using virtual machines, Unix accounts, unix file permissions, and 
unix resource limits to isolate and contain the process executing 
untrusted code.  We're definitely not executing untrusted code in the 
same process, or even as the same user, as the webserver.


>
>> SPECIFIC QUESTIONS
>> ------------------
>>
>> 1. Brian, why did you decide to make a new multikernel manager instead
>> of trying to leverage the ipcluster functionality to execute multiple
>> engines?
>
> 1) ipcluster just does too much that is irrelevant to starting kernels
> for the notebook.
> 2) ipcluster doesn't do any of the more advanced things that you need
> for starting kernels across many systems.

Thanks; that was basically the conclusion we came to today.  I was 
hoping that some of the more advanced capabilities of ipcluster would 
make our job easier, but it seemed to be too much baggage and didn't 
really do what we wanted (i.e., we'd still have to roll a lot of code on 
our own).



>
>> 2. Some time ago, on this list or on a pull request, there was some
>> discussion about the difference between kernels and engines (or the lack
>> of difference).  Are there some plans to simplify the ipcluster
>> architecture a bit to merge the concepts of engines and kernels?
>
> I think Min has answered this, but the answer is now that engine = kernel.

Thanks.  I like the distinction between binding and connecting kernels.


>
>> 3. Any idea about how much overhead the cluster introduces for lots of
>> short computations involving lots of output?  We'll test this too, but
>> I'm curious if there was thought towards this use-case in the design.
>
> This one is tough to answer.  In general the overhead of
> PyZMQ/ZeroMQ/IPython is extremely low.  The overheads you will run
> into will be completely determined by things like network throughput,
> etc.

Thanks for your input!  We hope to have a demo up soon (in the next 
couple of weeks).  If the code looks interesting to you guys, we hope to 
submit a pull request for relevant parts.  We're trying to do this in a 
way that would be useful to the larger community as well.

Jason


From fperez.net at gmail.com  Tue Jun  5 01:16:42 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 4 Jun 2012 22:16:42 -0700
Subject: [IPython-dev] MultiKernelManager vs. ipcluster
In-Reply-To: <4FCD8846.4080903@creativetrax.com>
References: <4FC92F19.10308@creativetrax.com>
	<CAH4pYpTivifwEUSbUZSNYu4qMb+wu+fwYJbft4VcPkpOGPfeNw@mail.gmail.com>
	<4FCD8846.4080903@creativetrax.com>
Message-ID: <CAHAreOrGk3-URkdYD3UjyJ2HKj7pAoBr4aGS54ETpuSev_LxDw@mail.gmail.com>

On Mon, Jun 4, 2012 at 9:17 PM, Jason Grout <jason-sage at creativetrax.com> wrote:
> If the code looks interesting to you guys, we hope to
> submit a pull request for relevant parts. ?We're trying to do this in a
> way that would be useful to the larger community as well.

That would be great.  The more we can find ways of making the core
code modular and reusable for related (but not identical) use cases
like this, the more we all win in the end.

Cheers,

f


From benjaminrk at gmail.com  Tue Jun  5 01:21:00 2012
From: benjaminrk at gmail.com (MinRK)
Date: Mon, 4 Jun 2012 22:21:00 -0700
Subject: [IPython-dev] MultiKernelManager vs. ipcluster
In-Reply-To: <CAHAreOrGk3-URkdYD3UjyJ2HKj7pAoBr4aGS54ETpuSev_LxDw@mail.gmail.com>
References: <4FC92F19.10308@creativetrax.com>
	<CAH4pYpTivifwEUSbUZSNYu4qMb+wu+fwYJbft4VcPkpOGPfeNw@mail.gmail.com>
	<4FCD8846.4080903@creativetrax.com>
	<CAHAreOrGk3-URkdYD3UjyJ2HKj7pAoBr4aGS54ETpuSev_LxDw@mail.gmail.com>
Message-ID: <CAHNn8BUee5HWbpoPrev7fVA5z-BqPrkTuSdhgywKv==dRY5P3w@mail.gmail.com>

On Mon, Jun 4, 2012 at 10:16 PM, Fernando Perez <fperez.net at gmail.com>wrote:

> On Mon, Jun 4, 2012 at 9:17 PM, Jason Grout <jason-sage at creativetrax.com>
> wrote:
> > If the code looks interesting to you guys, we hope to
> > submit a pull request for relevant parts.  We're trying to do this in a
> > way that would be useful to the larger community as well.
>
> That would be great.  The more we can find ways of making the core
> code modular and reusable for related (but not identical) use cases
> like this, the more we all win in the end.
>

Yes, and we have already had great success with new uses for existing code
twice before:

Paul Ivanov's vim-ipython (the first kernel client after the QtConsole),
and the zmq terminal console both revealed various boundaries in the code
that needed to move, and the code in general is a lot better for it.

-MinRK


>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120604/7f2d7328/attachment.html>

From zvoros at gmail.com  Tue Jun  5 03:03:59 2012
From: zvoros at gmail.com (=?ISO-8859-1?Q?Zolt=E1n_V=F6r=F6s?=)
Date: Tue, 05 Jun 2012 09:03:59 +0200
Subject: [IPython-dev] notebook plots via javascript
In-Reply-To: <CAH4pYpT40b3w8rwwQ+yVcNp+kHDr603j3K5KuDaeeNoXdVTf+A@mail.gmail.com>
References: <20120604164033.GH311@mcelrath.org> <4FCCEC6E.20101@gmail.com>
	<20120604173320.GA6159@mcelrath.org> <4FCCF1D6.90808@gmail.com>
	<CAH4pYpT40b3w8rwwQ+yVcNp+kHDr603j3K5KuDaeeNoXdVTf+A@mail.gmail.com>
Message-ID: <4FCDAF5F.7000109@gmail.com>

Hi Brian,

Thanks for commenting on this issue, and also, pointing out an 
alternative approach! Here are a couple of questions.

> * I agree that interactive plotting in the notebook is really important.

We all agree on this:), but the question is still how much interactivity 
one would want. Some want to have functionality at the level of the 
Qt4/GTK backends. I think, that cannot possibly be done without 
resorting to some underlying server, but in that case, we should re-use 
Ludwig's code. Also, I can't stress enough, if we go down this path, the 
plots might be decoupled from the code that generated them. I am really 
not a great fan of any modification that cannot be back-traced, and 
modifying the plot by mouse clicks is a huge step in this direction.

Then there are those, myself included, who say that they only want to 
get more information from the plot, but they don't want to change the 
plot, except for zooming, perhaps. What could be done in pure and simple 
javascript at the moment is coordinate reporting, grid toggling, and 
cross-hairs, if there is interest in that. These I could roll out pretty 
soon. For zooming we might need a little bit of extra info from the 
middleware, as John Hunter called it, so that would require modification 
of the matplotlib code itself. The other option could be to catch the 
object returned by the backend, and insert a couple of lines in IPython 
itself. The inline backend works in a similar fashion.

One more thing that, I think, could relatively easily be implemented is 
displaying extra info as a tool-tip. An example of this is in 
http://people.iola.dk/olau/flot/examples/interacting.html .

To me, the biggest appeal of doing things at the backend's level, even 
if its capabilities are somewhat limited, is that we don't have to upset 
the code base of matplotlib.

> * I would love to see that emerge out of matplotlib, rather than YAPL
> (yet another plotting library).

Right. If we just wanted another library, then flot would probably do. 
Though, for me, one of the turn-offs is that there is no straightforward 
way of adding axis labels to a plot. I just can't imagine a plot without 
axis labels...

> Based on these observations, I am thinking of something like the following:
>
> * We implement a JSON backend for matplotlib.  Basically, whenever one
> of the backend methods is called, it would write to a JSON structure.
> At the end of the day, there would be a JSON structure that has the
> entire set of drawing primitives and all their details.  This part of
> the code would be fully reusable by other "frontends" and would
> provide a serialization format for matplotlib.

This seems to me as a major change in the matplotlib core itself, so we 
should call out to John Hunter, and ask his opinion...

> * We implement a JavaScript plugin/widget that works with the IPython
> Notebook that consumes that JSON and creates an interactive plot based
> on that information.  This part of the code would be specific to
> IPython.
>
> Does this sound reasonable?

I think this is an interesting approach, and we should mull over it. 
It's a bit of an undertaking, but it would be worthwhile.
Cheers,
Zolt?n


From krastanov.stefan at gmail.com  Tue Jun  5 04:57:12 2012
From: krastanov.stefan at gmail.com (krastanov.stefan at gmail.com)
Date: Tue, 5 Jun 2012 10:57:12 +0200
Subject: [IPython-dev] vim/emacs keybindings in the notebook
In-Reply-To: <CAMHhCEWcXzkc5UkYvZX737Es=S20fU315t3daW2xiAsGGxeK=w@mail.gmail.com>
References: <CAD8szLwniLg1k-5gKeo20_JFPJLRBHSUnqHfuKcGhSXvQob-vA@mail.gmail.com>
	<CAH4pYpRvvqtoqnGgDFh2bPWb2JZhJCeWkTOQ9Ck550yA6=mqWA@mail.gmail.com>
	<CAHAreOpWdSRad-dzHyK6CnYkUDw9CGD13Jk52uP4zE7dwgCn6Q@mail.gmail.com>
	<20120604234018.GE6159@mcelrath.org>
	<CAMHhCEWcXzkc5UkYvZX737Es=S20fU315t3daW2xiAsGGxeK=w@mail.gmail.com>
Message-ID: <CAD8szLy+EA4jZWQYVj-CTjKKEjDkb3KJ1cOQyPWsnVLQr4kFug@mail.gmail.com>

Fernando Perez already implemented this in one of his branches
https://github.com/fperez/ipython/tree/cm-keymaps

The archived message in the first post mentions what is necessary for
this to get merged.


From ludwig.schwardt at gmail.com  Tue Jun  5 05:37:01 2012
From: ludwig.schwardt at gmail.com (Ludwig Schwardt)
Date: Tue, 5 Jun 2012 19:37:01 +1000
Subject: [IPython-dev] notebook plots via javascript
In-Reply-To: <4FCDAF5F.7000109@gmail.com>
References: <20120604164033.GH311@mcelrath.org> <4FCCEC6E.20101@gmail.com>
	<20120604173320.GA6159@mcelrath.org> <4FCCF1D6.90808@gmail.com>
	<CAH4pYpT40b3w8rwwQ+yVcNp+kHDr603j3K5KuDaeeNoXdVTf+A@mail.gmail.com>
	<4FCDAF5F.7000109@gmail.com>
Message-ID: <2212640E6CD14A2D8323DC91D1FB3E8E@gmail.com>

Hi,

On Tuesday 05 June 2012 at 5:03 PM, Zolt?n V?r?s wrote:  
> We all agree on this:), but the question is still how much interactivity
> one would want. Some want to have functionality at the level of the  
> Qt4/GTK backends. I think, that cannot possibly be done without  
> resorting to some underlying server, but in that case, we should re-use  
> Ludwig's code.
>  
>  

I feel bad every time you call it "my" code when I wrote less than 5% of it? It's really Simon Ratcliffe's code :-) He is also much more knowledgeable on the JS and Canvas side and was primarily responsible for that part of the design.

On another note, we would love more people to get involved or for some new backend to succeed mplh5canvas, as we have not had much time to spend on it recently (as much as we would have loved to!). I also find this discussion on a possible interactive IPython-based backend very useful.

Regards,

L.

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

From fperez.net at gmail.com  Tue Jun  5 14:57:30 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 5 Jun 2012 11:57:30 -0700
Subject: [IPython-dev] Bug in our magic_arguments decorator for building
	docstrings (ping R. Kern)?
Message-ID: <CAHAreOpfo8qDLLm_Sj=x4OcWBxzVv+teMveOXustvobLhRzWMw@mail.gmail.com>

Hey folks,

I'm sending this in case anyone already knows what's going on, or is
willing to dig into this issue a bit.

A while back we added (from R. Kern) the new magic_arguments module:

https://github.com/ipython/ipython/blob/master/IPython/core/magic_arguments.py

that allows you to build magics with a more friendly decorator-based
syntax.  But it seems that this decorator is severely mangling
docstrings, consider how the new Rmagic docs look:

http://ipython.org/ipython-doc/dev/config/extensions/rmagic.html

The problem can even be seen with a simple example:

###
from IPython.core.magic_arguments import magic_arguments

@magic_arguments()
def f():
    """A long

    docstring

    with::

       code
       blocks

    and more text:

    * one
    * two
    * three
   """
####

If we run this, we get:

In [5]: run ~/margs.py

In [6]: f?
Type:       function
Base Class: <type 'function'>
String Form:<function f at 0x2dce410>
Namespace:  Interactive
File:       /home/fperez/margs.py
Definition: f()
Docstring:
%f

A long docstring with:: code blocks and more text: * one * two * three

In [7]:

As can be seen above, the entire docstring got rammed into a single line.

Has anyone encountered this before?  Robert, any ideas?

Cheers,

f


From robert.kern at gmail.com  Tue Jun  5 16:57:47 2012
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 05 Jun 2012 21:57:47 +0100
Subject: [IPython-dev] Bug in our magic_arguments decorator for building
 docstrings (ping R. Kern)?
In-Reply-To: <CAHAreOpfo8qDLLm_Sj=x4OcWBxzVv+teMveOXustvobLhRzWMw@mail.gmail.com>
References: <CAHAreOpfo8qDLLm_Sj=x4OcWBxzVv+teMveOXustvobLhRzWMw@mail.gmail.com>
Message-ID: <jqlrsb$kia$1@dough.gmane.org>

On 6/5/12 7:57 PM, Fernando Perez wrote:
> Hey folks,
>
> I'm sending this in case anyone already knows what's going on, or is
> willing to dig into this issue a bit.
>
> A while back we added (from R. Kern) the new magic_arguments module:
>
> https://github.com/ipython/ipython/blob/master/IPython/core/magic_arguments.py
>
> that allows you to build magics with a more friendly decorator-based
> syntax.  But it seems that this decorator is severely mangling
> docstrings, consider how the new Rmagic docs look:
>
> http://ipython.org/ipython-doc/dev/config/extensions/rmagic.html
>
> The problem can even be seen with a simple example:
>
> ###
> from IPython.core.magic_arguments import magic_arguments
>
> @magic_arguments()
> def f():
>      """A long
>
>      docstring
>
>      with::
>
>         code
>         blocks
>
>      and more text:
>
>      * one
>      * two
>      * three
>     """
> ####
>
> If we run this, we get:
>
> In [5]: run ~/margs.py
>
> In [6]: f?
> Type:       function
> Base Class:<type 'function'>
> String Form:<function f at 0x2dce410>
> Namespace:  Interactive
> File:       /home/fperez/margs.py
> Definition: f()
> Docstring:
> %f
>
> A long docstring with:: code blocks and more text: * one * two * three
>
> In [7]:
>
> As can be seen above, the entire docstring got rammed into a single line.
>
> Has anyone encountered this before?  Robert, any ideas?

We probably want to use the RawDescriptionHelpFormatter:

   http://docs.python.org/library/argparse#argparse.RawDescriptionHelpFormatter

Or a custom implementation that removes the leading indentation but otherwise 
leaves the line breaks and indents alone.

Sorry for not noticing that earlier. All of my magics had single-line 
descriptions. :-)

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco



From fperez.net at gmail.com  Tue Jun  5 17:00:51 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 5 Jun 2012 14:00:51 -0700
Subject: [IPython-dev] Bug in our magic_arguments decorator for building
 docstrings (ping R. Kern)?
In-Reply-To: <jqlrsb$kia$1@dough.gmane.org>
References: <CAHAreOpfo8qDLLm_Sj=x4OcWBxzVv+teMveOXustvobLhRzWMw@mail.gmail.com>
	<jqlrsb$kia$1@dough.gmane.org>
Message-ID: <CAHAreOpV=qcnrFd9M3OGPPwPDKrmRoCFqt4dR5-okNozYnmKGw@mail.gmail.com>

On Tue, Jun 5, 2012 at 1:57 PM, Robert Kern <robert.kern at gmail.com> wrote:
> We probably want to use the RawDescriptionHelpFormatter:
>
> ? http://docs.python.org/library/argparse#argparse.RawDescriptionHelpFormatter
>
> Or a custom implementation that removes the leading indentation but otherwise
> leaves the line breaks and indents alone.
>
> Sorry for not noticing that earlier. All of my magics had single-line
> descriptions. :-)

Great, thanks for tracking down at least a path to a solution.

If anyone has the bandwidth to whip out a fix for this, we'd be very
very grateful.  Right now the docs for any magic with more than one
line docstring that uses the argparse decorators is completely
unreadable, so the karma-to-effort ratio of this one is huge.

Cheers,

f


From fperez.net at gmail.com  Tue Jun  5 17:00:51 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 5 Jun 2012 14:00:51 -0700
Subject: [IPython-dev] Bug in our magic_arguments decorator for building
 docstrings (ping R. Kern)?
In-Reply-To: <jqlrsb$kia$1@dough.gmane.org>
References: <CAHAreOpfo8qDLLm_Sj=x4OcWBxzVv+teMveOXustvobLhRzWMw@mail.gmail.com>
	<jqlrsb$kia$1@dough.gmane.org>
Message-ID: <CAHAreOpV=qcnrFd9M3OGPPwPDKrmRoCFqt4dR5-okNozYnmKGw@mail.gmail.com>

On Tue, Jun 5, 2012 at 1:57 PM, Robert Kern <robert.kern at gmail.com> wrote:
> We probably want to use the RawDescriptionHelpFormatter:
>
> ? http://docs.python.org/library/argparse#argparse.RawDescriptionHelpFormatter
>
> Or a custom implementation that removes the leading indentation but otherwise
> leaves the line breaks and indents alone.
>
> Sorry for not noticing that earlier. All of my magics had single-line
> descriptions. :-)

Great, thanks for tracking down at least a path to a solution.

If anyone has the bandwidth to whip out a fix for this, we'd be very
very grateful.  Right now the docs for any magic with more than one
line docstring that uses the argparse decorators is completely
unreadable, so the karma-to-effort ratio of this one is huge.

Cheers,

f


From takowl at gmail.com  Wed Jun  6 20:26:18 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Thu, 7 Jun 2012 01:26:18 +0100
Subject: [IPython-dev] Cell magics and extensions
Message-ID: <CAOvn4qhfRNMgpXOjYq-GCYjuuXpBJqNLWF5D6voOfVRvrmP2Fw@mail.gmail.com>

A recent pull request for a graphviz %%dot cell magic [1] brings up
some questions about our scope.

What range of extensions do we envisage shipping with IPython?
Obviously there's a lot of possibilities for the new cell magics, but
in my opinion the benefit of an extension system is that things like
this can live outside the main repository and be installed separately.

What more can we do for third party extensions? As a minimum, I think
we should have a list of available extensions, perhaps on
wiki.ipython.org .

We can easily install extensions inside IPython with the %install_ext
magic. Should we make it easier to install extensions outside IPython
- e.g. by finding a way to register them on PyPI and install them with
pip? Further ahead, if there are important extensions, would it be
easy for distributions to package them?

[1] https://github.com/ipython/ipython/pull/1854

Thanks,
Thomas


From takowl at gmail.com  Thu Jun  7 17:16:46 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Thu, 7 Jun 2012 22:16:46 +0100
Subject: [IPython-dev] IPython notebook on Windows Azure
Message-ID: <CAOvn4qgqT578_fU5t-YXQCw7FqwAWuT5XOxfrJ3S4hOULx=J-Q@mail.gmail.com>

Just scanning through the documentation for Windows Azure, I notice
that they have instructions for setting up the IPython notebook both
on Linux and Windows (it's not clear why you'd want the extra hassle
of setting everything up on Windows, but I guess someone will want
to).

http://www.windowsazure.com/en-us/develop/python/tutorials/ipython-notebook/

I note that they recommend installing directly from master, which
reinforces our preference for keeping master largely working, and
using test_pr before merging.

Thomas


From ellisonbg at gmail.com  Thu Jun  7 17:24:13 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Thu, 7 Jun 2012 14:24:13 -0700
Subject: [IPython-dev] IPython notebook on Windows Azure
In-Reply-To: <CAOvn4qgqT578_fU5t-YXQCw7FqwAWuT5XOxfrJ3S4hOULx=J-Q@mail.gmail.com>
References: <CAOvn4qgqT578_fU5t-YXQCw7FqwAWuT5XOxfrJ3S4hOULx=J-Q@mail.gmail.com>
Message-ID: <CAH4pYpSAcW8Q7RJ=xP5GJPPFuKsBRWFTt9-npfnox9=7G-c7_g@mail.gmail.com>

Hi,

On Thu, Jun 7, 2012 at 2:16 PM, Thomas Kluyver <takowl at gmail.com> wrote:
> Just scanning through the documentation for Windows Azure, I notice
> that they have instructions for setting up the IPython notebook both
> on Linux and Windows (it's not clear why you'd want the extra hassle
> of setting everything up on Windows, but I guess someone will want
> to).
>
> http://www.windowsazure.com/en-us/develop/python/tutorials/ipython-notebook/
>
> I note that they recommend installing directly from master, which
> reinforces our preference for keeping master largely working, and
> using test_pr before merging.

The "they" in this case was Fernando and I ;-) and we were meaning to
email the list about this today, but you beat us to it.  We have been
working with Microsoft for the last month or so to work out the
details of deploying the notebook to Azure.  We worked with them to
write the documentation and up at the top (it is not obvious) there is
even a nice screencast that Fernando did showing how all of it works.
They have been very cooperative and helpful and we feel like this is
some nice visibility for the project in a somewhat different context
than usual.  We are actually quite impressed with how easy everything
was - Azure has come a long way for sure!

Cheers,

Brian




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



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


From ellisonbg at gmail.com  Thu Jun  7 17:37:19 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Thu, 7 Jun 2012 14:37:19 -0700
Subject: [IPython-dev] Cell magics and extensions
In-Reply-To: <CAOvn4qhfRNMgpXOjYq-GCYjuuXpBJqNLWF5D6voOfVRvrmP2Fw@mail.gmail.com>
References: <CAOvn4qhfRNMgpXOjYq-GCYjuuXpBJqNLWF5D6voOfVRvrmP2Fw@mail.gmail.com>
Message-ID: <CAH4pYpT9FgC=290Wuy9N0BeXCBNTjgLkyV-5BZPKS2di1guRoA@mail.gmail.com>

[let's discuss and decide about this soon as it affects multiple PRs in flight]

This is a good topic, thanks for bringing it up.  Fernando and I
talked about this briefly the other day and had the following
thoughts:

* At least getting started, I think we can err on the side of putting
cell magics in IPython/extensions.
* In the long run, our policy should be two fold:
  - We should ship cell magics that a good fraction of IPython's users
will use.  So things like cythonmagic, shell, file, or sympyprinting
definitely makes sense.  Not sure if the dot or heirarchy ones make
sense.  One pro of having them in IPython is that our test machinery
makes it easy to write tests for them.
  - When it makes sense, we should encourage third part projects to
ship IPython extensions with the magics for their project.  So it
would *completely* make sense for sympy to ship sympyprinting and for
cython to ship cythonmagic.  One pro for having these outside IPython
is that we don't have to manage an ever growing list of exclusions in
iptest.
* There is absolutely no reason whatsoever that extensions need to be
installed into the IPython source tree.  They are perfectly valid
python packages that can be loaded using the following syntax:

%load_ext sympy.magics

This way the 3rd party projects and put the extension where-ever they
want and keep it in sync with their code base.  Copying them into
IPython/extensions is just asking for problems as we would become a
mini site-packages.  The only case where I can see %install_ext making
sense is for simple magics that have no upstream Python project to
bundle with.  This raises other questions:

* Where should users host standalone magics?  Should we create a
separate repo?  Gists?  Let the user decide?


Cheers,

Brian





On Wed, Jun 6, 2012 at 5:26 PM, Thomas Kluyver <takowl at gmail.com> wrote:
> A recent pull request for a graphviz %%dot cell magic [1] brings up
> some questions about our scope.
>
> What range of extensions do we envisage shipping with IPython?
> Obviously there's a lot of possibilities for the new cell magics, but
> in my opinion the benefit of an extension system is that things like
> this can live outside the main repository and be installed separately.
>
> What more can we do for third party extensions? As a minimum, I think
> we should have a list of available extensions, perhaps on
> wiki.ipython.org .
>
> We can easily install extensions inside IPython with the %install_ext
> magic. Should we make it easier to install extensions outside IPython
> - e.g. by finding a way to register them on PyPI and install them with
> pip? Further ahead, if there are important extensions, would it be
> easy for distributions to package them?
>
> [1] https://github.com/ipython/ipython/pull/1854
>
> Thanks,
> Thomas
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



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


From bob+ipython at mcelrath.org  Thu Jun  7 17:50:35 2012
From: bob+ipython at mcelrath.org (Bob McElrath)
Date: Thu, 7 Jun 2012 21:50:35 +0000
Subject: [IPython-dev] notebook plots via javascript
In-Reply-To: <2212640E6CD14A2D8323DC91D1FB3E8E@gmail.com>
References: <20120604164033.GH311@mcelrath.org> <4FCCEC6E.20101@gmail.com>
	<20120604173320.GA6159@mcelrath.org> <4FCCF1D6.90808@gmail.com>
	<CAH4pYpT40b3w8rwwQ+yVcNp+kHDr603j3K5KuDaeeNoXdVTf+A@mail.gmail.com>
	<4FCDAF5F.7000109@gmail.com>
	<2212640E6CD14A2D8323DC91D1FB3E8E@gmail.com>
Message-ID: <20120607215035.GF6159@mcelrath.org>

I really want to improve the figure quality of the notebook.  So, I made a stab
in this direction by changing the default figure to SVG, making them
transparent, and improving their quality a bit.  You can see it in my branch:
    https://github.com/mcelrath/ipython/tree/svg_figures

While this isn't interactive javascript yet, we can begin attaching some
javascript to the SVG DOM elements.

It turns out to get decent quality SVG figures, you have to set the
figure.figsize fairly high.  SVG doesn't know about or obey the DPI setting, but
the low value of figsize was causing some pixelation, which is why the SVG
figures produced by the notebook looked worse than the PNG figures.

--
Cheers, Bob McElrath

"The individual has always had to struggle to keep from being overwhelmed by
the tribe.  If you try it, you will be lonely often, and sometimes frightened.
But no price is too high to pay for the privilege of owning yourself." 
    -- Friedrich Nietzsche


From carl.input at gmail.com  Thu Jun  7 18:01:14 2012
From: carl.input at gmail.com (Carl Smith)
Date: Thu, 7 Jun 2012 23:01:14 +0100
Subject: [IPython-dev] Easy Installation
Message-ID: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>

I'm working on a web app that allows users to set up IPython Notebook
servers on EC2 with a few clicks.

Along the way, I created a simpler app that just takes a few details in a
form and launches a generic instance for you when you hit submit. Is this
at all useful to anyone?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120607/0ab99b11/attachment.html>

From takowl at gmail.com  Thu Jun  7 18:17:07 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Thu, 7 Jun 2012 23:17:07 +0100
Subject: [IPython-dev] IPython notebook on Windows Azure
In-Reply-To: <CAH4pYpSAcW8Q7RJ=xP5GJPPFuKsBRWFTt9-npfnox9=7G-c7_g@mail.gmail.com>
References: <CAOvn4qgqT578_fU5t-YXQCw7FqwAWuT5XOxfrJ3S4hOULx=J-Q@mail.gmail.com>
	<CAH4pYpSAcW8Q7RJ=xP5GJPPFuKsBRWFTt9-npfnox9=7G-c7_g@mail.gmail.com>
Message-ID: <CAOvn4qgA3rANUgVCQF5JeNc-JKt+AuDZTsR7NJPRuGi4BOoTDQ@mail.gmail.com>

On 7 June 2012 22:24, Brian Granger <ellisonbg at gmail.com> wrote:
> The "they" in this case was Fernando and I ;-) and we were meaning to
> email the list about this today, but you beat us to it.

Ah, apologies for stealing your thunder ;-). There was a bit of buzz
about Linux instances on Azure, which made me go and look at it.

We should make sure this - and equivalent instructions for AWS - are
clearly linked from our own site.

Also, if we're getting people to install from master, we should think
a bit about the future:
- These docs will probably be around for some time: will we always
recommend installing unreleased versions, or is that just while the
notebook is still improving so rapidly?
- What's the upgrade situation? We could easily end up with lots of
people running arbitrary development releases from whichever day they
ran the setup, with no obvious 'update' command.

For the latter point, I think Ubuntu with Julian's ipython-dev PPA is
a decent answer. It delivers new versions automatically, but if we
break something and the tests fail, no new package is built until the
tests are passing again. It also simplifies installation, because it
automatically pulls in pyzmq and tornado.

Thomas


From carl.input at gmail.com  Thu Jun  7 18:33:03 2012
From: carl.input at gmail.com (Carl Smith)
Date: Thu, 7 Jun 2012 23:33:03 +0100
Subject: [IPython-dev] IPython notebook on Windows Azure
In-Reply-To: <CAOvn4qgA3rANUgVCQF5JeNc-JKt+AuDZTsR7NJPRuGi4BOoTDQ@mail.gmail.com>
References: <CAOvn4qgqT578_fU5t-YXQCw7FqwAWuT5XOxfrJ3S4hOULx=J-Q@mail.gmail.com>
	<CAH4pYpSAcW8Q7RJ=xP5GJPPFuKsBRWFTt9-npfnox9=7G-c7_g@mail.gmail.com>
	<CAOvn4qgA3rANUgVCQF5JeNc-JKt+AuDZTsR7NJPRuGi4BOoTDQ@mail.gmail.com>
Message-ID: <CAP-uhDcOBu-8v85WgEEiJYwbcu-x97NGVAaYD4YUBeF0D7_evw@mail.gmail.com>

I recently wrote an installation guide for getting IPython master on EC2.
Using Ubuntu at both ends. The guide could be easily translated to use
other OSs, it's only using ssh to log in that'll differ.
The guide could do with checking for accuracy, anyone?, but it's there if
you can use it. I don't mind working on some docs for EC2 if someone a bit
more clued up on IPython would offer to act as an editor, just to make sure
my stuff is correct and current.
On Jun 7, 2012 11:17 PM, "Thomas Kluyver" <takowl at gmail.com> wrote:

> On 7 June 2012 22:24, Brian Granger <ellisonbg at gmail.com> wrote:
> > The "they" in this case was Fernando and I ;-) and we were meaning to
> > email the list about this today, but you beat us to it.
>
> Ah, apologies for stealing your thunder ;-). There was a bit of buzz
> about Linux instances on Azure, which made me go and look at it.
>
> We should make sure this - and equivalent instructions for AWS - are
> clearly linked from our own site.
>
> Also, if we're getting people to install from master, we should think
> a bit about the future:
> - These docs will probably be around for some time: will we always
> recommend installing unreleased versions, or is that just while the
> notebook is still improving so rapidly?
> - What's the upgrade situation? We could easily end up with lots of
> people running arbitrary development releases from whichever day they
> ran the setup, with no obvious 'update' command.
>
> For the latter point, I think Ubuntu with Julian's ipython-dev PPA is
> a decent answer. It delivers new versions automatically, but if we
> break something and the tests fail, no new package is built until the
> tests are passing again. It also simplifies installation, because it
> automatically pulls in pyzmq and tornado.
>
> Thomas
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120607/255806d6/attachment.html>

From takowl at gmail.com  Thu Jun  7 18:55:41 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Thu, 7 Jun 2012 23:55:41 +0100
Subject: [IPython-dev] Cell magics and extensions
In-Reply-To: <CAH4pYpT9FgC=290Wuy9N0BeXCBNTjgLkyV-5BZPKS2di1guRoA@mail.gmail.com>
References: <CAOvn4qhfRNMgpXOjYq-GCYjuuXpBJqNLWF5D6voOfVRvrmP2Fw@mail.gmail.com>
	<CAH4pYpT9FgC=290Wuy9N0BeXCBNTjgLkyV-5BZPKS2di1guRoA@mail.gmail.com>
Message-ID: <CAOvn4qjRbaGrrohaviMEh+GRJwUviKo1W2b8_X5nBKfH-bEamw@mail.gmail.com>

> One pro of having them in IPython is that our test machinery
> makes it easy to write tests for them.

We should work out a simple way to test third party extensions - I
think it should be as simple as a couple of lines of setup code, but
we should check that and put it in our extension docs.

> * Where should users host standalone magics? ?Should we create a
> separate repo? ?Gists? ?Let the user decide?

Gists would be a neat solution, but unfortunately I can't see a way to
get a URL which points to the latest version of a file in a gist. I
think for now it's up to extension writers, but we should offer a list
on the wiki with names, URLs and brief descriptions.

>  - We should ship cell magics that a good fraction of IPython's users
> will use.  So things like cythonmagic, shell, file, or sympyprinting
> definitely makes sense.  Not sure if the dot or heirarchy ones make
> sense.

I think dot is a fairly specialised need. %hierarchy is perhaps more
generally relevant, but I'm not sure how often it would actually be
useful. I've suggested to the author that it start out as a separate
extension, and if it's widely used, we could ship it with IPython in
future.

Thanks,
Thomas


From benjaminrk at gmail.com  Thu Jun  7 19:03:43 2012
From: benjaminrk at gmail.com (MinRK)
Date: Thu, 7 Jun 2012 16:03:43 -0700
Subject: [IPython-dev] notebook plots via javascript
In-Reply-To: <20120607215035.GF6159@mcelrath.org>
References: <20120604164033.GH311@mcelrath.org> <4FCCEC6E.20101@gmail.com>
	<20120604173320.GA6159@mcelrath.org> <4FCCF1D6.90808@gmail.com>
	<CAH4pYpT40b3w8rwwQ+yVcNp+kHDr603j3K5KuDaeeNoXdVTf+A@mail.gmail.com>
	<4FCDAF5F.7000109@gmail.com>
	<2212640E6CD14A2D8323DC91D1FB3E8E@gmail.com>
	<20120607215035.GF6159@mcelrath.org>
Message-ID: <CAHNn8BXTQ36kAUCT=dU1ACCtexj47FasnjZB11a4LsfW=S0wgA@mail.gmail.com>

On Thu, Jun 7, 2012 at 2:50 PM, Bob McElrath <bob+ipython at mcelrath.org>wrote:

> I really want to improve the figure quality of the notebook.  So, I made a
> stab
> in this direction by changing the default figure to SVG, making them
> transparent, and improving their quality a bit.  You can see it in my
> branch:
>    https://github.com/mcelrath/ipython/tree/svg_figures
>
> While this isn't interactive javascript yet, we can begin attaching some
> javascript to the SVG DOM elements.
>
> It turns out to get decent quality SVG figures, you have to set the
> figure.figsize fairly high.  SVG doesn't know about or obey the DPI
> setting, but
> the low value of figsize was causing some pixelation, which is why the SVG
> figures produced by the notebook looked worse than the PNG figures.
>

The PNG default is actually *because* the SVGs are so much worse.

If you do succeed in making them a net improvement, then it certainly makes
sense to switch back to the original default of SVG.

-MinRK


>
> --
> Cheers, Bob McElrath
>
> "The individual has always had to struggle to keep from being overwhelmed
> by
> the tribe.  If you try it, you will be lonely often, and sometimes
> frightened.
> But no price is too high to pay for the privilege of owning yourself."
>    -- Friedrich Nietzsche
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120607/d72094cf/attachment.html>

From ellisonbg at gmail.com  Thu Jun  7 19:10:58 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Thu, 7 Jun 2012 16:10:58 -0700
Subject: [IPython-dev] notebook plots via javascript
In-Reply-To: <20120607215035.GF6159@mcelrath.org>
References: <20120604164033.GH311@mcelrath.org> <4FCCEC6E.20101@gmail.com>
	<20120604173320.GA6159@mcelrath.org> <4FCCF1D6.90808@gmail.com>
	<CAH4pYpT40b3w8rwwQ+yVcNp+kHDr603j3K5KuDaeeNoXdVTf+A@mail.gmail.com>
	<4FCDAF5F.7000109@gmail.com>
	<2212640E6CD14A2D8323DC91D1FB3E8E@gmail.com>
	<20120607215035.GF6159@mcelrath.org>
Message-ID: <CAH4pYpT9aUNyZBELDCj5hcuCOksNv3GOORR0ufcKcEHz_yG60w@mail.gmail.com>

Bob,

This is great.  In my work on this branch to make svg images resizable:

https://github.com/ipython/ipython/pull/1832

I noticed that the svg created by matplotlib was pixelated.

On Thu, Jun 7, 2012 at 2:50 PM, Bob McElrath <bob+ipython at mcelrath.org> wrote:
> I really want to improve the figure quality of the notebook. ?So, I made a stab
> in this direction by changing the default figure to SVG, making them
> transparent, and improving their quality a bit. ?You can see it in my branch:
> ? ?https://github.com/mcelrath/ipython/tree/svg_figures

I didn't play with this yet, but left some comments.  Maybe open up
pull request for this just to have a good place to discuss things.
There is another question about the svg that matplotlib generates.
Currently, the main svg tag has a width and height that is specified
in pts.  I am finding that in the notebook this is very difficult to
deal with.  Do you think it is possible to specify the width/height in
the svg tag in pixels?

> While this isn't interactive javascript yet, we can begin attaching some
> javascript to the SVG DOM elements.

And the figure resizing in my branch above would be a good start.

> It turns out to get decent quality SVG figures, you have to set the
> figure.figsize fairly high. ?SVG doesn't know about or obey the DPI setting, but
> the low value of figsize was causing some pixelation, which is why the SVG
> figures produced by the notebook looked worse than the PNG figures.
>
> --
> Cheers, Bob McElrath
>
> "The individual has always had to struggle to keep from being overwhelmed by
> the tribe. ?If you try it, you will be lonely often, and sometimes frightened.
> But no price is too high to pay for the privilege of owning yourself."
> ? ?-- Friedrich Nietzsche
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



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


From takowl at gmail.com  Thu Jun  7 19:34:52 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Fri, 8 Jun 2012 00:34:52 +0100
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
Message-ID: <CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>

On 7 June 2012 23:01, Carl Smith <carl.input at gmail.com> wrote:
> I'm working on a web app that allows users to set up IPython Notebook
> servers on EC2 with a few clicks.

I look forward to seeing this - I think a dead-simple way to get
started with IPython in the clouds would be really useful.

For bonus points, I'd love to see it integrated with something like
the terminal forwarding code that pythonanywhere uses. With a shell in
your browser, you could set up any extra stuff you need without
needing to set up SSH to your instance.

Thanks,
Thomas


From bob+ipython at mcelrath.org  Thu Jun  7 19:58:41 2012
From: bob+ipython at mcelrath.org (Bob McElrath)
Date: Thu, 7 Jun 2012 23:58:41 +0000
Subject: [IPython-dev] notebook plots via javascript
In-Reply-To: <CAH4pYpT9aUNyZBELDCj5hcuCOksNv3GOORR0ufcKcEHz_yG60w@mail.gmail.com>
References: <20120604164033.GH311@mcelrath.org> <4FCCEC6E.20101@gmail.com>
	<20120604173320.GA6159@mcelrath.org> <4FCCF1D6.90808@gmail.com>
	<CAH4pYpT40b3w8rwwQ+yVcNp+kHDr603j3K5KuDaeeNoXdVTf+A@mail.gmail.com>
	<4FCDAF5F.7000109@gmail.com>
	<2212640E6CD14A2D8323DC91D1FB3E8E@gmail.com>
	<20120607215035.GF6159@mcelrath.org>
	<CAH4pYpT9aUNyZBELDCj5hcuCOksNv3GOORR0ufcKcEHz_yG60w@mail.gmail.com>
Message-ID: <20120607235841.GH6159@mcelrath.org>

Brian Granger [ellisonbg at gmail.com] wrote:
> Bob,
> 
> This is great.  In my work on this branch to make svg images resizable:
> 
> https://github.com/ipython/ipython/pull/1832
> 
> I noticed that the svg created by matplotlib was pixelated.

I'll take a look at that...

> I didn't play with this yet, but left some comments.  Maybe open up
> pull request for this just to have a good place to discuss things.
> There is another question about the svg that matplotlib generates.
> Currently, the main svg tag has a width and height that is specified
> in pts.  I am finding that in the notebook this is very difficult to
> deal with.  Do you think it is possible to specify the width/height in
> the svg tag in pixels?

So far I was trying to get the SVG to simply fill the available space with the
CSS:
    div.output_svg svg {
        width: 100%;
        height: 32em;
    }
You can set the width and height arbitrarily, using px if you want using that,
however you will be unable to change the aspect ratio.

Turns out even filling the space is difficult because SVG maintaining a fixed
aspect ratio.  We would need some javascript to switch that to 
    width: 100%; 
    height: (aspect ratio)*(measured width);
for the case when the browser window is narrower than 32em/(aspect ratio).

In a nutshell, if you want to change the aspect ratio, you will have to dig into
the matplotlib code, and change the SVG it generates.

> > While this isn't interactive javascript yet, we can begin attaching some
> > javascript to the SVG DOM elements.
> 
> And the figure resizing in my branch above would be a good start.

Yes...of course, what we *really* want in resize-able circumstances is to change
the tick marks, axis/label fonts, etc to maintain a reasonable figure.  This is
really beyond the scope of what we can do with matplotlib.  As far as I can see,
matplotlib is really oriented to producing printable output.

I don't know where you want to go with ipython's graphics, but I think adding
axis labels, legends, modifying scaling and tick marks (etc) by typing a
sequence of plt.*() calls is a horrible thing to do to a person.  What I would
love to see is:
1. A new matplotlib backend that generates a blob of data wrapped in svg and
    javascript.
2. Interactive ability to scale/rotate/label that data in the browser.
3. A reverse tie-in so that interactive modifications to the figure become
    python commands in the corresponding code block.

However, that's a much longer-term project if someone wants to take it on...
There are a lot of javascript plotting libraries out there these days that one
might look to for inspiration...

--
Cheers, Bob McElrath

"The individual has always had to struggle to keep from being overwhelmed by
the tribe.  If you try it, you will be lonely often, and sometimes frightened.
But no price is too high to pay for the privilege of owning yourself." 
    -- Friedrich Nietzsche


From fperez.net at gmail.com  Thu Jun  7 20:33:18 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 7 Jun 2012 17:33:18 -0700
Subject: [IPython-dev] notebook plots via javascript
In-Reply-To: <20120607215035.GF6159@mcelrath.org>
References: <20120604164033.GH311@mcelrath.org> <4FCCEC6E.20101@gmail.com>
	<20120604173320.GA6159@mcelrath.org> <4FCCF1D6.90808@gmail.com>
	<CAH4pYpT40b3w8rwwQ+yVcNp+kHDr603j3K5KuDaeeNoXdVTf+A@mail.gmail.com>
	<4FCDAF5F.7000109@gmail.com>
	<2212640E6CD14A2D8323DC91D1FB3E8E@gmail.com>
	<20120607215035.GF6159@mcelrath.org>
Message-ID: <CAHAreOoOydjc0y4R4Hjh+Ew-sWEEEZgV5=tuNsjhqDTj3=z2PA@mail.gmail.com>

On Thu, Jun 7, 2012 at 2:50 PM, Bob McElrath <bob+ipython at mcelrath.org> wrote:
>
> It turns out to get decent quality SVG figures, you have to set the
> figure.figsize fairly high.

Unfortunately it's much more complicated than that.  I experimented a
LOT when I first wrote the inline backend, hoping to make SVG the
default. And unfortunately, while most simple plots do indeed look
much nicer as SVG, in production work I kept running into corner cases
where the SVG generated by MPL was just not quite right (missing
elements, clipping lines wrong, poor transparency handling, etc.).  Of
course, if I was a good citizen I'd have taken the time to record
those as test cases so we could fix them in MPL, but I just didn't
have the bandwidth to to both ipython and mpl work (this is when we
were just building the kernel system and the qtconsole, so our task
list was monstrous).

I would *love* to be able to switch to SVG by default, but until we
can trust that the SVG that comes out of MPL is consistently as solid
as the pngs, or have the time to spend fixing those issues, I think
it's best to keep the png defaults.

The problem with fixing this is that I've never been able to see the
issues in easy to reproduce examples.  They tend to only happen with
very complex figures that I only can generate pulling full-blown
research datasets out, so they make for poor test cases.

I'll make it a priority from now on to try to at least record these
cases in an isolated place, so that hopefully we can dig into them in
MPL.  Because I know it's terrible behavior to put down mpl's
rendering without providing a test case we can use to improve the
situation.

Cheers,

f


From fperez.net at gmail.com  Thu Jun  7 20:39:18 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 7 Jun 2012 17:39:18 -0700
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
Message-ID: <CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>

On Thu, Jun 7, 2012 at 4:34 PM, Thomas Kluyver <takowl at gmail.com> wrote:
> I look forward to seeing this - I think a dead-simple way to get
> started with IPython in the clouds would be really useful.
>
> For bonus points, I'd love to see it integrated with something like
> the terminal forwarding code that pythonanywhere uses. With a shell in
> your browser, you could set up any extra stuff you need without
> needing to set up SSH to your instance.

It's worth pointing out that the starcluster AMIs come preconfigured
with ipython, the entire scipy stack, and will automatically boot up
as an ipython cluster with the notebook running in the head node.  SSH
is also preconfigured, as is file transfer and just about anything
else imaginable.  This is all it takes to configure all this (I choose
a qiime starcluster AMI with the qiime genomics toolkit installed, but
the base starcluster AMIs work the same):

[plugin ipcluster]
setup_class = starcluster.plugins.ipcluster.IPCluster
enable_notebook = true
# If you leave notebook_passwd out, a random password
# will be generated instead.
notebook_passwd = YOUR-PASSWORD

[cluster qiime]
node_image_id = ami-2faa7346
keyname = YOUR-KEY
cluster_size = 4
node_instance_type = m2.4xlarge
plugins = ipcluster

### - end config

You can then boot this cluster by running:

starcluster start -c qiime myqiime

I'm happy to learn of other approaches, but this is about as easy as I
can imagine already...

Cheers,

f


From fperez.net at gmail.com  Thu Jun  7 21:10:29 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 7 Jun 2012 18:10:29 -0700
Subject: [IPython-dev] IPython notebook on Windows Azure
In-Reply-To: <CAOvn4qgA3rANUgVCQF5JeNc-JKt+AuDZTsR7NJPRuGi4BOoTDQ@mail.gmail.com>
References: <CAOvn4qgqT578_fU5t-YXQCw7FqwAWuT5XOxfrJ3S4hOULx=J-Q@mail.gmail.com>
	<CAH4pYpSAcW8Q7RJ=xP5GJPPFuKsBRWFTt9-npfnox9=7G-c7_g@mail.gmail.com>
	<CAOvn4qgA3rANUgVCQF5JeNc-JKt+AuDZTsR7NJPRuGi4BOoTDQ@mail.gmail.com>
Message-ID: <CAHAreOo=ocevYroKcRph_F_xVs8E1DEa4guGkc7xLC=X9hOCbQ@mail.gmail.com>

On Thu, Jun 7, 2012 at 3:17 PM, Thomas Kluyver <takowl at gmail.com> wrote:
> Ah, apologies for stealing your thunder ;-). There was a bit of buzz
> about Linux instances on Azure, which made me go and look at it.

We were also busy today turning in a report for a grant that has
funded much of the recent parallel work, so we just didn't have any
time to do decent PR, thanks for pitching in, actually!

> We should make sure this - and equivalent instructions for AWS - are
> clearly linked from our own site.

By all means do so, if you have a minute.  If not I'll try to spend
some time on the site this weekend.

> Also, if we're getting people to install from master, we should think
> a bit about the future:
> - These docs will probably be around for some time: will we always
> recommend installing unreleased versions, or is that just while the
> notebook is still improving so rapidly?

I'd hope that will change over time and we'll settle into a slower
pace, but we're not there yet.  Note that we can update these
instructions as well (not immediately, but we can feed updates to MS
on them, it was actually a very nice workflow with markdown docs on
github, believe it or not.  As Brian says, the azure stuff has come a
*long* ways, and in more than one aspect it was much nicer to set up
than Amazon is).

One thing we didn't know (or maybe it wasn't available when we set
things up, I'm honestly not sure) was that it's possible to freeze the
instances and offer them up.  What I'd like to do is eventually to
offer stable instances with ubuntu and windows and everything
pre-loaded, from a reasonably solid version (even if it's a git master
checkout, but at least one *we* are sure of).  Just like Justin does
with Starcluster.

During the introduction today I saw how to do it, and it was very
straightforward, I just wasn't aware of this before.  We'll look into
it soon.

> - What's the upgrade situation? We could easily end up with lots of
> people running arbitrary development releases from whichever day they
> ran the setup, with no obvious 'update' command.

git pull, baby :)

> For the latter point, I think Ubuntu with Julian's ipython-dev PPA is
> a decent answer. It delivers new versions automatically, but if we
> break something and the tests fail, no new package is built until the
> tests are passing again. It also simplifies installation, because it
> automatically pulls in pyzmq and tornado.

True.  When we set things up, the ubuntu images weren't ready yet so
we had to go with Suse; today I would have used ubuntu, obviously.

Cheers,

f


From jason-sage at creativetrax.com  Thu Jun  7 22:11:49 2012
From: jason-sage at creativetrax.com (Jason Grout)
Date: Thu, 07 Jun 2012 21:11:49 -0500
Subject: [IPython-dev] notebook plots via javascript
In-Reply-To: <CAHAreOoOydjc0y4R4Hjh+Ew-sWEEEZgV5=tuNsjhqDTj3=z2PA@mail.gmail.com>
References: <20120604164033.GH311@mcelrath.org> <4FCCEC6E.20101@gmail.com>
	<20120604173320.GA6159@mcelrath.org> <4FCCF1D6.90808@gmail.com>
	<CAH4pYpT40b3w8rwwQ+yVcNp+kHDr603j3K5KuDaeeNoXdVTf+A@mail.gmail.com>
	<4FCDAF5F.7000109@gmail.com>
	<2212640E6CD14A2D8323DC91D1FB3E8E@gmail.com>
	<20120607215035.GF6159@mcelrath.org>
	<CAHAreOoOydjc0y4R4Hjh+Ew-sWEEEZgV5=tuNsjhqDTj3=z2PA@mail.gmail.com>
Message-ID: <4FD15F65.1030101@creativetrax.com>

On 6/7/12 7:33 PM, Fernando Perez wrote:
> Unfortunately it's much more complicated than that.  I experimented a
> LOT when I first wrote the inline backend, hoping to make SVG the
> default. And unfortunately, while most simple plots do indeed look
> much nicer as SVG, in production work I kept running into corner cases
> where the SVG generated by MPL was just not quite right (missing
> elements, clipping lines wrong, poor transparency handling, etc.).  Of
> course, if I was a good citizen I'd have taken the time to record
> those as test cases so we could fix them in MPL, but I just didn't
> have the bandwidth to to both ipython and mpl work (this is when we
> were just building the kernel system and the qtconsole, so our task
> list was monstrous).

We also experimented with making SVG default for the Sage cell server, 
and our experience was that complicated plots were a *lot* slower (at 
least in last year's browsers).  Often with a contour plot or something 
like that, we could see the SVG drawing the plot layer by layer 
(quickly, but still...).  Also, the time it took to get the plot finally 
on screen varied pretty widely.  In the end, we went back to png as 
default because it had approximately the same amount of time to show a 
plot no matter how complicated it was.

Jason


From carl.input at gmail.com  Thu Jun  7 22:14:59 2012
From: carl.input at gmail.com (Carl Smith)
Date: Fri, 8 Jun 2012 03:14:59 +0100
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
	<CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
Message-ID: <CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>

Thanks for your replies. I used StarCluster to set up first time, but you
need to install software locally to use it and download a key. I'm really
looking make it work for stuff like Chrome OS and just anyone who wants an
option that is fully browser based. A fun, gui, web app.

Re. ssh, You have the same functionality in the notebook. It's just lacking
stdin for now, you have to put -q and -y flags everywhere, but that'll be
sorted soon enough.

Eventually, I want a web app you can use to launch a keyless, Ubuntu server
on your EC2 account, with all the Python stuff installed, and IPython as
the sole interface to the VM itself. It'll be free to use. It just calls
AWS for the user and provides a link to their server, so I can run it on
App Engine for free.

Sorry if this is a bit poorly written, I'm on my phone.

Carl
On Jun 8, 2012 1:39 AM, "Fernando Perez" <fperez.net at gmail.com> wrote:

> On Thu, Jun 7, 2012 at 4:34 PM, Thomas Kluyver <takowl at gmail.com> wrote:
> > I look forward to seeing this - I think a dead-simple way to get
> > started with IPython in the clouds would be really useful.
> >
> > For bonus points, I'd love to see it integrated with something like
> > the terminal forwarding code that pythonanywhere uses. With a shell in
> > your browser, you could set up any extra stuff you need without
> > needing to set up SSH to your instance.
>
> It's worth pointing out that the starcluster AMIs come preconfigured
> with ipython, the entire scipy stack, and will automatically boot up
> as an ipython cluster with the notebook running in the head node.  SSH
> is also preconfigured, as is file transfer and just about anything
> else imaginable.  This is all it takes to configure all this (I choose
> a qiime starcluster AMI with the qiime genomics toolkit installed, but
> the base starcluster AMIs work the same):
>
> [plugin ipcluster]
> setup_class = starcluster.plugins.ipcluster.IPCluster
> enable_notebook = true
> # If you leave notebook_passwd out, a random password
> # will be generated instead.
> notebook_passwd = YOUR-PASSWORD
>
> [cluster qiime]
> node_image_id = ami-2faa7346
> keyname = YOUR-KEY
> cluster_size = 4
> node_instance_type = m2.4xlarge
> plugins = ipcluster
>
> ### - end config
>
> You can then boot this cluster by running:
>
> starcluster start -c qiime myqiime
>
> I'm happy to learn of other approaches, but this is about as easy as I
> can imagine already...
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120608/74ab3c58/attachment.html>

From fperez.net at gmail.com  Thu Jun  7 22:33:28 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 7 Jun 2012 19:33:28 -0700
Subject: [IPython-dev] notebook plots via javascript
In-Reply-To: <4FD15F65.1030101@creativetrax.com>
References: <20120604164033.GH311@mcelrath.org> <4FCCEC6E.20101@gmail.com>
	<20120604173320.GA6159@mcelrath.org> <4FCCF1D6.90808@gmail.com>
	<CAH4pYpT40b3w8rwwQ+yVcNp+kHDr603j3K5KuDaeeNoXdVTf+A@mail.gmail.com>
	<4FCDAF5F.7000109@gmail.com>
	<2212640E6CD14A2D8323DC91D1FB3E8E@gmail.com>
	<20120607215035.GF6159@mcelrath.org>
	<CAHAreOoOydjc0y4R4Hjh+Ew-sWEEEZgV5=tuNsjhqDTj3=z2PA@mail.gmail.com>
	<4FD15F65.1030101@creativetrax.com>
Message-ID: <CAHAreOrarTrPD=Ys4QoF8D0+GMSX=shrJND7qq9sw_-0o3wCdg@mail.gmail.com>

On Thu, Jun 7, 2012 at 7:11 PM, Jason Grout <jason-sage at creativetrax.com> wrote:
> ?In the end, we went back to png as
> default because it had approximately the same amount of time to show a
> plot no matter how complicated it was.

Good point I'd forgotten about, that was also my experience.

Cheers,

f


From fperez.net at gmail.com  Thu Jun  7 22:34:20 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 7 Jun 2012 19:34:20 -0700
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
	<CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
	<CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>
Message-ID: <CAHAreOryjSpoJpwwTwq6EeE7b1wwHQndoRTGD3R+0tYCF+CsWg@mail.gmail.com>

On Thu, Jun 7, 2012 at 7:14 PM, Carl Smith <carl.input at gmail.com> wrote:
> Eventually, I want a web app you can use to launch a keyless, Ubuntu server
> on your EC2 account, with all the Python stuff installed, and IPython as the
> sole interface to the VM itself. It'll be free to use. It just calls AWS for
> the user and provides a link to their server, so I can run it on App Engine
> for free.

Got it, thanks.  Definitely keep us posted on the progress, as it
sounds very useful.

Cheers,

f


From fperez.net at gmail.com  Thu Jun  7 22:58:55 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 7 Jun 2012 19:58:55 -0700
Subject: [IPython-dev] %gui wx completely borked on Ubuntu 12.04,
	how about other OSes?
Message-ID: <CAHAreOo-TvePFTpCxtYT7std5phT39SHJ6q4qB-Pnf8iWSaW1w@mail.gmail.com>

Hi all,

I just noticed that '%gui wx' (or --gui wx at startup) goes into an
infinite loop of this error message:

Traceback (most recent call last):
  File "_ctypes/callbacks.c", line 314, in 'calling callback function'
  File "/home/fperez/usr/lib/python2.7/site-packages/IPython/lib/inputhookwx.py",
line 128, in inputhook_wx3
    ea = wx.EventLoopActivator(evtloop)
AttributeError: 'module' object has no attribute 'EventLoopActivator'


Has anyone else noticed this?  It's not just me, as I found it
reported against ubuntu:

https://bugs.launchpad.net/ubuntu/+source/wxwidgets2.8/+bug/998716

Is it working on osx/windows/ other linuxes?

Cheers,

f


From fperez.net at gmail.com  Thu Jun  7 23:01:27 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 7 Jun 2012 20:01:27 -0700
Subject: [IPython-dev] %gui wx completely borked on Ubuntu 12.04,
	how about other OSes?
In-Reply-To: <CAHAreOo-TvePFTpCxtYT7std5phT39SHJ6q4qB-Pnf8iWSaW1w@mail.gmail.com>
References: <CAHAreOo-TvePFTpCxtYT7std5phT39SHJ6q4qB-Pnf8iWSaW1w@mail.gmail.com>
Message-ID: <CAHAreOoK9W6+cNT-CHqpRWosUJ27D7T7V5yRqiE0UeDZUzEwBA@mail.gmail.com>

On Thu, Jun 7, 2012 at 7:58 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> I just noticed that '%gui wx' (or --gui wx at startup) goes into an
> infinite loop of this error message:

Oddly enough, --pylab wx works fine, which means that

a) those with matplotlib can use it as a workaround
b) there's obviously a way to get the event loop integration with Wx
that doesn't involve a call to EventLoopActivator...

f


From fperez.net at gmail.com  Thu Jun  7 23:53:07 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 7 Jun 2012 20:53:07 -0700
Subject: [IPython-dev] Cell magics and extensions
In-Reply-To: <CAH4pYpT9FgC=290Wuy9N0BeXCBNTjgLkyV-5BZPKS2di1guRoA@mail.gmail.com>
References: <CAOvn4qhfRNMgpXOjYq-GCYjuuXpBJqNLWF5D6voOfVRvrmP2Fw@mail.gmail.com>
	<CAH4pYpT9FgC=290Wuy9N0BeXCBNTjgLkyV-5BZPKS2di1guRoA@mail.gmail.com>
Message-ID: <CAHAreOqrF756cuESHtYp6x9mUe3S25tAmJCFCzeT-rEG+xrfDQ@mail.gmail.com>

On Thu, Jun 7, 2012 at 2:37 PM, Brian Granger <ellisonbg at gmail.com> wrote:

[...]

I agree with everything you said above, and thanks also to Thomas for
bumping this up in priority...

>
> * Where should users host standalone magics? ?Should we create a
> separate repo? ?Gists? ?Let the user decide?

I was just thinking that if we specify that an extension is *only* a
setup.py and a foo.py file, and that its PyPI name is something like
ipython_ext_foo, then we could then just let people use PyPI for
hosting, and we could write an %install_ext magic that does the
installation, by default going into the user's own IPYTHONDIR (or
perhaps into the dir written to by --user, with a pseudo-package
ipython_ext?).

This is only half-baked, so there's quite likely a very good reason
why it's a terrible idea; please do shoot it down as needed.

f


From jason-sage at creativetrax.com  Thu Jun  7 23:59:05 2012
From: jason-sage at creativetrax.com (Jason Grout)
Date: Thu, 07 Jun 2012 22:59:05 -0500
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAHAreOryjSpoJpwwTwq6EeE7b1wwHQndoRTGD3R+0tYCF+CsWg@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
	<CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
	<CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>
	<CAHAreOryjSpoJpwwTwq6EeE7b1wwHQndoRTGD3R+0tYCF+CsWg@mail.gmail.com>
Message-ID: <4FD17889.50800@creativetrax.com>

On 6/7/12 9:34 PM, Fernando Perez wrote:
> On Thu, Jun 7, 2012 at 7:14 PM, Carl Smith<carl.input at gmail.com>  wrote:
>> Eventually, I want a web app you can use to launch a keyless, Ubuntu server
>> on your EC2 account, with all the Python stuff installed, and IPython as the
>> sole interface to the VM itself. It'll be free to use. It just calls AWS for
>> the user and provides a link to their server, so I can run it on App Engine
>> for free.
>
> Got it, thanks.  Definitely keep us posted on the progress, as it
> sounds very useful.

Yes, please.  It sounds useful for our project as well, since we are 
keeping an eye on moving the web project to app engine and the 
computation part to EC2.

Thanks,

jason




From ellisonbg at gmail.com  Fri Jun  8 01:17:17 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Thu, 7 Jun 2012 22:17:17 -0700
Subject: [IPython-dev] Cell magics and extensions
In-Reply-To: <CAHAreOqrF756cuESHtYp6x9mUe3S25tAmJCFCzeT-rEG+xrfDQ@mail.gmail.com>
References: <CAOvn4qhfRNMgpXOjYq-GCYjuuXpBJqNLWF5D6voOfVRvrmP2Fw@mail.gmail.com>
	<CAH4pYpT9FgC=290Wuy9N0BeXCBNTjgLkyV-5BZPKS2di1guRoA@mail.gmail.com>
	<CAHAreOqrF756cuESHtYp6x9mUe3S25tAmJCFCzeT-rEG+xrfDQ@mail.gmail.com>
Message-ID: <CAH4pYpR9pDTyy2-00M8t+90SUNXJg9b4USdKkg=r0cufxZ_VJw@mail.gmail.com>

I guess my initial intuition is that we shouldn't get into the
business of managing packages for users.  Not sure how to balance that
with the need to make it somewhat easy for users to get extensions.

On Thu, Jun 7, 2012 at 8:53 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Thu, Jun 7, 2012 at 2:37 PM, Brian Granger <ellisonbg at gmail.com> wrote:
>
> [...]
>
> I agree with everything you said above, and thanks also to Thomas for
> bumping this up in priority...
>
>>
>> * Where should users host standalone magics? ?Should we create a
>> separate repo? ?Gists? ?Let the user decide?
>
> I was just thinking that if we specify that an extension is *only* a
> setup.py and a foo.py file, and that its PyPI name is something like
> ipython_ext_foo, then we could then just let people use PyPI for
> hosting, and we could write an %install_ext magic that does the
> installation, by default going into the user's own IPYTHONDIR (or
> perhaps into the dir written to by --user, with a pseudo-package
> ipython_ext?).
>
> This is only half-baked, so there's quite likely a very good reason
> why it's a terrible idea; please do shoot it down as needed.
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



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


From jason-sage at creativetrax.com  Fri Jun  8 01:29:10 2012
From: jason-sage at creativetrax.com (Jason Grout)
Date: Fri, 08 Jun 2012 00:29:10 -0500
Subject: [IPython-dev] Cell magics and extensions
In-Reply-To: <CAOvn4qjRbaGrrohaviMEh+GRJwUviKo1W2b8_X5nBKfH-bEamw@mail.gmail.com>
References: <CAOvn4qhfRNMgpXOjYq-GCYjuuXpBJqNLWF5D6voOfVRvrmP2Fw@mail.gmail.com>
	<CAH4pYpT9FgC=290Wuy9N0BeXCBNTjgLkyV-5BZPKS2di1guRoA@mail.gmail.com>
	<CAOvn4qjRbaGrrohaviMEh+GRJwUviKo1W2b8_X5nBKfH-bEamw@mail.gmail.com>
Message-ID: <4FD18DA6.8040708@creativetrax.com>

On 6/7/12 5:55 PM, Thomas Kluyver wrote:
> Gists would be a neat solution, but unfortunately I can't see a way to
> get a URL which points to the latest version of a file in a gist.

Doesn't something like this work?

https://raw.github.com/gist/GISTNUMBER/FILENAME?

It seems to work for my test example: 
https://raw.github.com/gist/2893763/gistfile1.txt

Thanks,

Jason


From ellisonbg at gmail.com  Fri Jun  8 01:30:10 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Thu, 7 Jun 2012 22:30:10 -0700
Subject: [IPython-dev] Cell magics and extensions
In-Reply-To: <4FD18DA6.8040708@creativetrax.com>
References: <CAOvn4qhfRNMgpXOjYq-GCYjuuXpBJqNLWF5D6voOfVRvrmP2Fw@mail.gmail.com>
	<CAH4pYpT9FgC=290Wuy9N0BeXCBNTjgLkyV-5BZPKS2di1guRoA@mail.gmail.com>
	<CAOvn4qjRbaGrrohaviMEh+GRJwUviKo1W2b8_X5nBKfH-bEamw@mail.gmail.com>
	<4FD18DA6.8040708@creativetrax.com>
Message-ID: <CAH4pYpRv3u14wqyCp6tPYiuS-UyH=+2VOJAMKVqrhjdcMHpiig@mail.gmail.com>

That is great, thanks.

On Thu, Jun 7, 2012 at 10:29 PM, Jason Grout
<jason-sage at creativetrax.com> wrote:
> On 6/7/12 5:55 PM, Thomas Kluyver wrote:
>> Gists would be a neat solution, but unfortunately I can't see a way to
>> get a URL which points to the latest version of a file in a gist.
>
> Doesn't something like this work?
>
> https://raw.github.com/gist/GISTNUMBER/FILENAME?
>
> It seems to work for my test example:
> https://raw.github.com/gist/2893763/gistfile1.txt
>
> Thanks,
>
> Jason
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



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


From jonathan.taylor at stanford.edu  Fri Jun  8 02:52:24 2012
From: jonathan.taylor at stanford.edu (Jonathan Taylor)
Date: Thu, 7 Jun 2012 23:52:24 -0700
Subject: [IPython-dev] running through a notebook in terminal or command line
Message-ID: <CANmCCuTfJCRGGde+JgzYFxZCTpv76dMHHUpu6GyDHq2G2R3MSQ@mail.gmail.com>

I am wondering if it's possible to take an .ipynb file, effectively hit
"run all" in the notebook and then hit "save" via a script.
I imagine it's possible to do via a request to the web server if there is
one running but I'm not sure how to generate the request.

-- 
Jonathan Taylor
Dept. of Statistics
Sequoia Hall, 137
390 Serra Mall
Stanford, CA 94305
Tel:   650.723.9230
Fax:   650.725.8977
Web: http://www-stat.stanford.edu/~jtaylo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120607/aba1a52b/attachment.html>

From fperez.net at gmail.com  Fri Jun  8 03:11:23 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 8 Jun 2012 00:11:23 -0700
Subject: [IPython-dev] running through a notebook in terminal or command
	line
In-Reply-To: <CANmCCuTfJCRGGde+JgzYFxZCTpv76dMHHUpu6GyDHq2G2R3MSQ@mail.gmail.com>
References: <CANmCCuTfJCRGGde+JgzYFxZCTpv76dMHHUpu6GyDHq2G2R3MSQ@mail.gmail.com>
Message-ID: <CAHAreOpDBzA685-xxP7CLDGVfHG+QHL3BA6p3283FmJmszhN8w@mail.gmail.com>

On Thu, Jun 7, 2012 at 11:52 PM, Jonathan Taylor
<jonathan.taylor at stanford.edu> wrote:
> I am wondering if it's possible to take an .ipynb file, effectively hit "run
> all" in the notebook and then hit "save" via a script.
> I imagine it's possible to do via a request to the web server if there is
> one running but I'm not sure how to generate the request.

did you see the reply to your question on the user list?  Min posted
the url to two gists that do 90% of the job:

http://mail.scipy.org/pipermail/ipython-user/2012-June/010330.html

This stuff will eventually become official code, as I'm sure we're
going to want a solid set of command-line utilities to manipulate
notebooks (not just the conversion code in nbconvert).

Cheers,

f


From jonathan.taylor at stanford.edu  Fri Jun  8 03:24:18 2012
From: jonathan.taylor at stanford.edu (Jonathan Taylor)
Date: Fri, 8 Jun 2012 00:24:18 -0700
Subject: [IPython-dev] running through a notebook in terminal or command
	line
In-Reply-To: <CAHAreOpDBzA685-xxP7CLDGVfHG+QHL3BA6p3283FmJmszhN8w@mail.gmail.com>
References: <CANmCCuTfJCRGGde+JgzYFxZCTpv76dMHHUpu6GyDHq2G2R3MSQ@mail.gmail.com>
	<CAHAreOpDBzA685-xxP7CLDGVfHG+QHL3BA6p3283FmJmszhN8w@mail.gmail.com>
Message-ID: <CANmCCuR1vxn6jaFgc-jU3B9Z4f-938XQ54rd_C5N8ai-3f+B=w@mail.gmail.com>

Sorry -- I missed this reply. Will read it.

Thanks... Jonathan

On Fri, Jun 8, 2012 at 12:11 AM, Fernando Perez <fperez.net at gmail.com>wrote:

> On Thu, Jun 7, 2012 at 11:52 PM, Jonathan Taylor
> <jonathan.taylor at stanford.edu> wrote:
> > I am wondering if it's possible to take an .ipynb file, effectively hit
> "run
> > all" in the notebook and then hit "save" via a script.
> > I imagine it's possible to do via a request to the web server if there is
> > one running but I'm not sure how to generate the request.
>
> did you see the reply to your question on the user list?  Min posted
> the url to two gists that do 90% of the job:
>
> http://mail.scipy.org/pipermail/ipython-user/2012-June/010330.html
>
> This stuff will eventually become official code, as I'm sure we're
> going to want a solid set of command-line utilities to manipulate
> notebooks (not just the conversion code in nbconvert).
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Jonathan Taylor
Dept. of Statistics
Sequoia Hall, 137
390 Serra Mall
Stanford, CA 94305
Tel:   650.723.9230
Fax:   650.725.8977
Web: http://www-stat.stanford.edu/~jtaylo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120608/d1e32904/attachment.html>

From takowl at gmail.com  Fri Jun  8 06:03:28 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Fri, 8 Jun 2012 11:03:28 +0100
Subject: [IPython-dev] Cell magics and extensions
In-Reply-To: <CAHAreOqrF756cuESHtYp6x9mUe3S25tAmJCFCzeT-rEG+xrfDQ@mail.gmail.com>
References: <CAOvn4qhfRNMgpXOjYq-GCYjuuXpBJqNLWF5D6voOfVRvrmP2Fw@mail.gmail.com>
	<CAH4pYpT9FgC=290Wuy9N0BeXCBNTjgLkyV-5BZPKS2di1guRoA@mail.gmail.com>
	<CAHAreOqrF756cuESHtYp6x9mUe3S25tAmJCFCzeT-rEG+xrfDQ@mail.gmail.com>
Message-ID: <CAOvn4qhqvZ0zK=cDyPryGJOo9tisrG3zmPTTOg5UcyGFMSRqeA@mail.gmail.com>

On 8 June 2012 04:53, Fernando Perez <fperez.net at gmail.com> wrote:
> I was just thinking that if we specify that an extension is *only* a
> setup.py and a foo.py file, and that its PyPI name is something like
> ipython_ext_foo, then we could then just let people use PyPI for
> hosting, and we could write an %install_ext magic that does the
> installation, by default going into the user's own IPYTHONDIR (or
> perhaps into the dir written to by --user, with a pseudo-package
> ipython_ext?).

At present, %install_ext just takes a URL which points directly to
foo.py - it downloads that and puts it in the user's IPYTHONDIR. I'm
pretty happy with this workflow for user-level installation inside
IPython.

For systemwide installation, I wonder if we need to do something like
making IPython.extensions a namespace package, so that pip can install
other packages into it. I'm sure it's possible, but I don't know
precisely what we need to do.

> Doesn't something like this work?
> https://raw.github.com/gist/GISTNUMBER/FILENAME?

Brilliant, thanks Jason. Then I think we can point extension authors
to gist if they don't want to set up a regular repository.

Best wishes,
Thomas


From takowl at gmail.com  Fri Jun  8 06:26:42 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Fri, 8 Jun 2012 11:26:42 +0100
Subject: [IPython-dev] Cell magics and extensions
In-Reply-To: <CAOvn4qhqvZ0zK=cDyPryGJOo9tisrG3zmPTTOg5UcyGFMSRqeA@mail.gmail.com>
References: <CAOvn4qhfRNMgpXOjYq-GCYjuuXpBJqNLWF5D6voOfVRvrmP2Fw@mail.gmail.com>
	<CAH4pYpT9FgC=290Wuy9N0BeXCBNTjgLkyV-5BZPKS2di1guRoA@mail.gmail.com>
	<CAHAreOqrF756cuESHtYp6x9mUe3S25tAmJCFCzeT-rEG+xrfDQ@mail.gmail.com>
	<CAOvn4qhqvZ0zK=cDyPryGJOo9tisrG3zmPTTOg5UcyGFMSRqeA@mail.gmail.com>
Message-ID: <CAOvn4qhaZ6_-wES+3G8C7vHS68LG+nYPaCpLH0RKeboNEYfiTQ@mail.gmail.com>

I've created a wiki page to list third party extensions:

http://wiki.ipython.org/Extensions_Index

So far, the only one I know of is Georg Brandl's physics extension,
but hopefully there will be more soon. I'll update the extension docs
later as well.

Thanks,
Thomas


From nicolas.chauvat at logilab.fr  Fri Jun  8 07:44:22 2012
From: nicolas.chauvat at logilab.fr (Nicolas Chauvat)
Date: Fri, 8 Jun 2012 13:44:22 +0200
Subject: [IPython-dev] Cell magics and extensions
In-Reply-To: <CAH4pYpR9pDTyy2-00M8t+90SUNXJg9b4USdKkg=r0cufxZ_VJw@mail.gmail.com>
References: <CAOvn4qhfRNMgpXOjYq-GCYjuuXpBJqNLWF5D6voOfVRvrmP2Fw@mail.gmail.com>
	<CAH4pYpT9FgC=290Wuy9N0BeXCBNTjgLkyV-5BZPKS2di1guRoA@mail.gmail.com>
	<CAHAreOqrF756cuESHtYp6x9mUe3S25tAmJCFCzeT-rEG+xrfDQ@mail.gmail.com>
	<CAH4pYpR9pDTyy2-00M8t+90SUNXJg9b4USdKkg=r0cufxZ_VJw@mail.gmail.com>
Message-ID: <20120608114422.GB30778@volans.logilab.fr>

Hi,

On Thu, Jun 07, 2012 at 10:17:17PM -0700, Brian Granger wrote:
> I guess my initial intuition is that we shouldn't get into the
> business of managing packages for users.

+1

setuptools, distribute, packaging, pip... years after it all started,
IMHO it is still a mess and never became reliable.

Just make sure people can easily write extensions and easily plug them
in (file path + couple keys/values) and do not try to rule how these
extensions are fetched from the net or where they are stored on the
hard drive.

Mercurial, for example, has an extremely active extension community
thanks to the simplicity of the extension system:
http://mercurial.selenic.com/wiki/UsingExtensions


-- 
Nicolas Chauvat

logilab.fr - services en informatique scientifique et gestion de connaissances  


From lev at columbia.edu  Fri Jun  8 08:04:26 2012
From: lev at columbia.edu (Lev Givon)
Date: Fri, 8 Jun 2012 08:04:26 -0400
Subject: [IPython-dev] %gui wx completely borked on Ubuntu 12.04,
 how about other OSes?
In-Reply-To: <CAHAreOo-TvePFTpCxtYT7std5phT39SHJ6q4qB-Pnf8iWSaW1w@mail.gmail.com>
References: <CAHAreOo-TvePFTpCxtYT7std5phT39SHJ6q4qB-Pnf8iWSaW1w@mail.gmail.com>
Message-ID: <20120608120426.GL20661@avicenna.ee.columbia.edu>

Received from Fernando Perez on Thu, Jun 07, 2012 at 10:58:55PM EDT:
> Hi all,
> 
> I just noticed that '%gui wx' (or --gui wx at startup) goes into an
> infinite loop of this error message:
> 
> Traceback (most recent call last):
>   File "_ctypes/callbacks.c", line 314, in 'calling callback function'
>   File "/home/fperez/usr/lib/python2.7/site-packages/IPython/lib/inputhookwx.py",
> line 128, in inputhook_wx3
>     ea = wx.EventLoopActivator(evtloop)
> AttributeError: 'module' object has no attribute 'EventLoopActivator'
> 
> 
> Has anyone else noticed this?  It's not just me, as I found it
> reported against ubuntu:
> 
> https://bugs.launchpad.net/ubuntu/+source/wxwidgets2.8/+bug/998716
> 
> Is it working on osx/windows/ other linuxes?

No error on Mandriva Linux 2011 (wxgtk 2.8.12). I also can't replicate
the error on Ubuntu 12.04.

						L.G.


From zvoros at gmail.com  Fri Jun  8 08:07:28 2012
From: zvoros at gmail.com (=?ISO-8859-1?Q?Zolt=E1n_V=F6r=F6s?=)
Date: Fri, 08 Jun 2012 14:07:28 +0200
Subject: [IPython-dev] notebook plots via javascript
In-Reply-To: <20120607235841.GH6159@mcelrath.org>
References: <20120604164033.GH311@mcelrath.org> <4FCCEC6E.20101@gmail.com>
	<20120604173320.GA6159@mcelrath.org> <4FCCF1D6.90808@gmail.com>
	<CAH4pYpT40b3w8rwwQ+yVcNp+kHDr603j3K5KuDaeeNoXdVTf+A@mail.gmail.com>
	<4FCDAF5F.7000109@gmail.com>
	<2212640E6CD14A2D8323DC91D1FB3E8E@gmail.com>
	<20120607215035.GF6159@mcelrath.org>
	<CAH4pYpT9aUNyZBELDCj5hcuCOksNv3GOORR0ufcKcEHz_yG60w@mail.gmail.com>
	<20120607235841.GH6159@mcelrath.org>
Message-ID: <4FD1EB00.1080409@gmail.com>

Hi All,

On 06/08/2012 01:58 AM, Bob McElrath wrote:
> In a nutshell, if you want to change the aspect ratio, you will have 
> to dig into the matplotlib code, and change the SVG it generates.
>>> While this isn't interactive javascript yet, we can begin attaching some
>>> javascript to the SVG DOM elements.
>> And the figure resizing in my branch above would be a good start.
> Yes...of course, what we *really* want in resize-able circumstances is to change
> the tick marks, axis/label fonts, etc to maintain a reasonable figure.  This is
> really beyond the scope of what we can do with matplotlib.  As far as I can see,
> matplotlib is really oriented to producing printable output.
>
> I don't know where you want to go with ipython's graphics, but I think adding
> axis labels, legends, modifying scaling and tick marks (etc) by typing a
> sequence of plt.*() calls is a horrible thing to do to a person.  What I would
> love to see is:
> 1. A new matplotlib backend that generates a blob of data wrapped in svg and
>      javascript.
> 2. Interactive ability to scale/rotate/label that data in the browser.
> 3. A reverse tie-in so that interactive modifications to the figure become
>      python commands in the corresponding code block.
I have the feeling that these goals are too ambitious. I think, there is 
a desire to keep plotting within the realm of matplotlib, but add some 
interactivity to it. We have already discussed that this approach has 
some limitations, and the number of things one can do with it is 
definitely finite.

But I just fail to see why plots should be resizable, and why plots 
should be able to emit python code for tracking the changes. The vision 
for ipython was, and I believe, still is, is to provide a tool for 
exploratory computing. What you described above goes far beyond 
exploration. I don't think that changing the plot labels or the legend 
would qualify for exploration. I see only two instances where 
interactivity beyond the scope of matplotlib would be useful in this 
context. One is zooming/panning, which cannot be done without having 
some sort of access to the data, and the other is rotation of surfaces 
(here, again, data access is necessary). However, one should keep in 
mind that this latter one will be awfully slow in javascript/svg, anyway.

My concern here is that by demanding too much of the new backend, we 
won't get anywhere, simply because these requirements are just too 
stringent. I have a javascript backend now that produces stand-alone 
javascript, and allows for grid toggling, and coordinate reporting + 
cross-hairs. I could release that soon, but that is basically all what 
can be done without upsetting the code base of matplotlib. If the 
matplotlib people are willing to provide some interface to the data and 
so on, we could pick it up from there. Brian's proposal would be a good 
starting point for that.

What could, perhaps, help for the time being is, if there was a way of 
switching backends on the fly. I think one could live with interactive 
plots, if limited in capabilities, and whenever needed, switching to a 
truly interactive backend, like gtk/qt4. I recall that Fernando 
mentioned it at one point that he was working on this, but I don't know 
whether this is still on his list.

Cheers,
Zolt?n








From jason-sage at creativetrax.com  Fri Jun  8 09:49:14 2012
From: jason-sage at creativetrax.com (Jason Grout)
Date: Fri, 08 Jun 2012 08:49:14 -0500
Subject: [IPython-dev] Cell magics and extensions
In-Reply-To: <CAOvn4qhqvZ0zK=cDyPryGJOo9tisrG3zmPTTOg5UcyGFMSRqeA@mail.gmail.com>
References: <CAOvn4qhfRNMgpXOjYq-GCYjuuXpBJqNLWF5D6voOfVRvrmP2Fw@mail.gmail.com>
	<CAH4pYpT9FgC=290Wuy9N0BeXCBNTjgLkyV-5BZPKS2di1guRoA@mail.gmail.com>
	<CAHAreOqrF756cuESHtYp6x9mUe3S25tAmJCFCzeT-rEG+xrfDQ@mail.gmail.com>
	<CAOvn4qhqvZ0zK=cDyPryGJOo9tisrG3zmPTTOg5UcyGFMSRqeA@mail.gmail.com>
Message-ID: <4FD202DA.6010103@creativetrax.com>

On 6/8/12 5:03 AM, Thomas Kluyver wrote:
> Brilliant, thanks Jason. Then I think we can point extension authors
> to gist if they don't want to set up a regular repository.

Is there any commitment on githubs part for how long gists last?  I 
thought they were rather short term things.

Jason



From takowl at gmail.com  Fri Jun  8 10:18:35 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Fri, 8 Jun 2012 15:18:35 +0100
Subject: [IPython-dev] Cell magics and extensions
In-Reply-To: <4FD202DA.6010103@creativetrax.com>
References: <CAOvn4qhfRNMgpXOjYq-GCYjuuXpBJqNLWF5D6voOfVRvrmP2Fw@mail.gmail.com>
	<CAH4pYpT9FgC=290Wuy9N0BeXCBNTjgLkyV-5BZPKS2di1guRoA@mail.gmail.com>
	<CAHAreOqrF756cuESHtYp6x9mUe3S25tAmJCFCzeT-rEG+xrfDQ@mail.gmail.com>
	<CAOvn4qhqvZ0zK=cDyPryGJOo9tisrG3zmPTTOg5UcyGFMSRqeA@mail.gmail.com>
	<4FD202DA.6010103@creativetrax.com>
Message-ID: <CAOvn4qiQa=3To+Ji08L6uvXi0jsOocnuyn=EvhViLXCEBFVxTQ@mail.gmail.com>

On 8 June 2012 14:49, Jason Grout <jason-sage at creativetrax.com> wrote:
> Is there any commitment on githubs part for how long gists last? ?I
> thought they were rather short term things.

Good point. I can't see any statement about it, but I don't get the
impression that they're short term - they are mini repositories, after
all. I can still access my gists from over a year ago.

Thanks,
Thomas


From carl.input at gmail.com  Fri Jun  8 10:26:55 2012
From: carl.input at gmail.com (Carl Smith)
Date: Fri, 8 Jun 2012 15:26:55 +0100
Subject: [IPython-dev] Easy Installation
In-Reply-To: <4FD17889.50800@creativetrax.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
	<CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
	<CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>
	<CAHAreOryjSpoJpwwTwq6EeE7b1wwHQndoRTGD3R+0tYCF+CsWg@mail.gmail.com>
	<4FD17889.50800@creativetrax.com>
Message-ID: <CAP-uhDdeY0KKSdGuH_X6rFxeKC=JH60OeUrkXqcSH-vm_bh6qQ@mail.gmail.com>

No problem at all, I'm happy to share what I have.

It's not at all difficult to set this up. There's a few parts to it,
but they're all really simple. The only work is in making a nice GUI
for the users. There's a ton of extras you can optionally add, on the
AMI as well as the GUI, but if you only want your stack and a simple
page on App Engine for launching instances, it's a weekend project.
All the real work has been done by the IPython developers.

I've not used Sage, but I'm sure it'll be much the same there.

All the best

Carl

On 8 June 2012 04:59, Jason Grout <jason-sage at creativetrax.com> wrote:
> On 6/7/12 9:34 PM, Fernando Perez wrote:
>> On Thu, Jun 7, 2012 at 7:14 PM, Carl Smith<carl.input at gmail.com> ?wrote:
>>> Eventually, I want a web app you can use to launch a keyless, Ubuntu server
>>> on your EC2 account, with all the Python stuff installed, and IPython as the
>>> sole interface to the VM itself. It'll be free to use. It just calls AWS for
>>> the user and provides a link to their server, so I can run it on App Engine
>>> for free.
>>
>> Got it, thanks. ?Definitely keep us posted on the progress, as it
>> sounds very useful.
>
> Yes, please. ?It sounds useful for our project as well, since we are
> keeping an eye on moving the web project to app engine and the
> computation part to EC2.
>
> Thanks,
>
> jason
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev


From jason-sage at creativetrax.com  Fri Jun  8 11:06:30 2012
From: jason-sage at creativetrax.com (Jason Grout)
Date: Fri, 08 Jun 2012 10:06:30 -0500
Subject: [IPython-dev] Cell magics and extensions
In-Reply-To: <CAOvn4qiQa=3To+Ji08L6uvXi0jsOocnuyn=EvhViLXCEBFVxTQ@mail.gmail.com>
References: <CAOvn4qhfRNMgpXOjYq-GCYjuuXpBJqNLWF5D6voOfVRvrmP2Fw@mail.gmail.com>
	<CAH4pYpT9FgC=290Wuy9N0BeXCBNTjgLkyV-5BZPKS2di1guRoA@mail.gmail.com>
	<CAHAreOqrF756cuESHtYp6x9mUe3S25tAmJCFCzeT-rEG+xrfDQ@mail.gmail.com>
	<CAOvn4qhqvZ0zK=cDyPryGJOo9tisrG3zmPTTOg5UcyGFMSRqeA@mail.gmail.com>
	<4FD202DA.6010103@creativetrax.com>
	<CAOvn4qiQa=3To+Ji08L6uvXi0jsOocnuyn=EvhViLXCEBFVxTQ@mail.gmail.com>
Message-ID: <4FD214F6.1090504@creativetrax.com>

On 6/8/12 9:18 AM, Thomas Kluyver wrote:
> On 8 June 2012 14:49, Jason Grout<jason-sage at creativetrax.com>  wrote:
>> Is there any commitment on githubs part for how long gists last?  I
>> thought they were rather short term things.
>
> Good point. I can't see any statement about it, but I don't get the
> impression that they're short term - they are mini repositories, after
> all. I can still access my gists from over a year ago.
>

If we point people to using gists, we probably should also tell them 
that it is a convenient way to host their code (with no guarantees about 
future availability), and they should maintain a copy (i.e., a clone of 
the gist repository) somewhere where they know it is more permanent.

Or maybe IPython can use git submodules to track an "official" list of 
plugins?  I don't know.  Having a contrib directory of sorts opens up a 
can of worms, but it also lends a stamp of authority and permanence to 
what may be rather transient development efforts.

Thanks,

Jason


From bob+ipython at mcelrath.org  Fri Jun  8 11:49:21 2012
From: bob+ipython at mcelrath.org (Bob McElrath)
Date: Fri, 8 Jun 2012 15:49:21 +0000
Subject: [IPython-dev] notebook plots via javascript
In-Reply-To: <4FD1EB00.1080409@gmail.com>
References: <4FCCEC6E.20101@gmail.com> <20120604173320.GA6159@mcelrath.org>
	<4FCCF1D6.90808@gmail.com>
	<CAH4pYpT40b3w8rwwQ+yVcNp+kHDr603j3K5KuDaeeNoXdVTf+A@mail.gmail.com>
	<4FCDAF5F.7000109@gmail.com>
	<2212640E6CD14A2D8323DC91D1FB3E8E@gmail.com>
	<20120607215035.GF6159@mcelrath.org>
	<CAH4pYpT9aUNyZBELDCj5hcuCOksNv3GOORR0ufcKcEHz_yG60w@mail.gmail.com>
	<20120607235841.GH6159@mcelrath.org> <4FD1EB00.1080409@gmail.com>
Message-ID: <20120608154921.GL6159@mcelrath.org>

Zolt?n V?r?s [zvoros at gmail.com] wrote:
> I have the feeling that these goals are too ambitious. I think, there is a
> desire to keep plotting within the realm of matplotlib, but add some
> interactivity to it. 

Well I'll just say that IPython and matplotlib have quickly become my primary
computational tool.  So I would not simply call it an "exploratory" tool.  I
could already do exploratory computing with the (i)python command line.  The
notebook allows me to save, repeat/reproduce, and communicate a computation.  In
particular it allows me to record how I produced the final version of a plot.

I have been cursing the capabilities, failures, and crashes of Maple and
Mathematica for more than a decade now.  One of the major things where both of
those packages fall down is plotting.  For years I have been exporting data to
flat files and importing it into xmgrace, because the quality of their plots was
so poor.  Matplotlib is substantially better than any of the above.  So, I will
be producing my plots using it from now on.  (And I will undoubtedly be
exporting data from Maple into an IPython notebook for plotting purposes soon)
I see the IPython notebook as a replacement for Maple, for me.

The interface for creating matplotlib plots is no worse than Gnuplot, Maple, or
Mathematica, in terms of having to construct the plot using a script.  There is
a lot of room for improvement there.  What I would like is to eventually have a
GUI-like way to do simple manipulation of plots, along the lines of xmgrace and
xfig...

Anyway, it's a long term goal.  For now I'm just going to try to get a
reasonable vector-based rather than rasterized output for the notebook.  This is
required so that different screen/browser sizes, font sizes look reasonable.

> But I just fail to see why plots should be resizable, and why plots should be
> able to emit python code for tracking the changes. 

Personally I do not find zooming/panning terribly useful.  If I need to
zoom/pan, it always means either
1. I will have to re-plot to pan anyway
2. I will have to recompute at higher resolution so the zoom/pan is smooth
About the only thing I do with the gtk matplotlib GUI that is useful is change
the margins.

The things that are easier to do with an interactive plot are logged axes, tick
mark spacing, line type/color, axis labels, legend, title, grid, 3d rotation.
None of which you can do with the matplotlib gui.

> I have a javascript backend now that produces stand-alone javascript, and
> allows for grid toggling, and coordinate reporting + cross-hairs. 

That would be great!  Coordinate reporting is also one thing the GUI is useful
for...

--
Cheers, Bob McElrath

"The individual has always had to struggle to keep from being overwhelmed by
the tribe.  If you try it, you will be lonely often, and sometimes frightened.
But no price is too high to pay for the privilege of owning yourself." 
    -- Friedrich Nietzsche


From ellisonbg at gmail.com  Fri Jun  8 12:30:38 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Fri, 8 Jun 2012 09:30:38 -0700
Subject: [IPython-dev] Cell magics and extensions
In-Reply-To: <4FD214F6.1090504@creativetrax.com>
References: <CAOvn4qhfRNMgpXOjYq-GCYjuuXpBJqNLWF5D6voOfVRvrmP2Fw@mail.gmail.com>
	<CAH4pYpT9FgC=290Wuy9N0BeXCBNTjgLkyV-5BZPKS2di1guRoA@mail.gmail.com>
	<CAHAreOqrF756cuESHtYp6x9mUe3S25tAmJCFCzeT-rEG+xrfDQ@mail.gmail.com>
	<CAOvn4qhqvZ0zK=cDyPryGJOo9tisrG3zmPTTOg5UcyGFMSRqeA@mail.gmail.com>
	<4FD202DA.6010103@creativetrax.com>
	<CAOvn4qiQa=3To+Ji08L6uvXi0jsOocnuyn=EvhViLXCEBFVxTQ@mail.gmail.com>
	<4FD214F6.1090504@creativetrax.com>
Message-ID: <CAH4pYpRJ_+GzXs8pfND3gdxs0zxV2jBnCZkgjp1qW+tP=ci7UA@mail.gmail.com>

It might make sense to create a separate repo in the ipython github
org to put all of the third party extensions into.  The benefit of
this is that we could make %install_ext work by name for those
extensions, rather than full URL.

On Fri, Jun 8, 2012 at 8:06 AM, Jason Grout <jason-sage at creativetrax.com> wrote:
> On 6/8/12 9:18 AM, Thomas Kluyver wrote:
>> On 8 June 2012 14:49, Jason Grout<jason-sage at creativetrax.com> ?wrote:
>>> Is there any commitment on githubs part for how long gists last? ?I
>>> thought they were rather short term things.
>>
>> Good point. I can't see any statement about it, but I don't get the
>> impression that they're short term - they are mini repositories, after
>> all. I can still access my gists from over a year ago.
>>
>
> If we point people to using gists, we probably should also tell them
> that it is a convenient way to host their code (with no guarantees about
> future availability), and they should maintain a copy (i.e., a clone of
> the gist repository) somewhere where they know it is more permanent.
>
> Or maybe IPython can use git submodules to track an "official" list of
> plugins? ?I don't know. ?Having a contrib directory of sorts opens up a
> can of worms, but it also lends a stamp of authority and permanence to
> what may be rather transient development efforts.
>
> Thanks,
>
> Jason
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



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


From jtaylor.debian at googlemail.com  Fri Jun  8 13:18:11 2012
From: jtaylor.debian at googlemail.com (Julian Taylor)
Date: Fri, 08 Jun 2012 19:18:11 +0200
Subject: [IPython-dev] %gui wx completely borked on Ubuntu 12.04,
 how about other OSes?
In-Reply-To: <CAHAreOo-TvePFTpCxtYT7std5phT39SHJ6q4qB-Pnf8iWSaW1w@mail.gmail.com>
References: <CAHAreOo-TvePFTpCxtYT7std5phT39SHJ6q4qB-Pnf8iWSaW1w@mail.gmail.com>
Message-ID: <4FD233D3.9030107@googlemail.com>

On 06/08/2012 04:58 AM, Fernando Perez wrote:
> Hi all,
> 
> I just noticed that '%gui wx' (or --gui wx at startup) goes into an
> infinite loop of this error message:
> 
> Traceback (most recent call last):
>   File "_ctypes/callbacks.c", line 314, in 'calling callback function'
>   File "/home/fperez/usr/lib/python2.7/site-packages/IPython/lib/inputhookwx.py",
> line 128, in inputhook_wx3
>     ea = wx.EventLoopActivator(evtloop)
> AttributeError: 'module' object has no attribute 'EventLoopActivator'
> 
> 
> Has anyone else noticed this?  It's not just me, as I found it
> reported against ubuntu:
> 
> https://bugs.launchpad.net/ubuntu/+source/wxwidgets2.8/+bug/998716
> 
> Is it working on osx/windows/ other linuxes?
> 

can you test if this helps?
https://bugs.launchpad.net/ubuntu/+source/wxwidgets2.8/+bug/998716/comments/2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120608/1c311235/attachment.sig>

From ellisonbg at gmail.com  Fri Jun  8 19:10:24 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Fri, 8 Jun 2012 16:10:24 -0700
Subject: [IPython-dev] Great coding everyone!
Message-ID: <CAH4pYpRGaXtp+so=koKm=6G4nWNjgg+73ffugExD-Fn+-4QA=Q@mail.gmail.com>

HI,

I just wanted to say great job coding to everyone.  We have merged ~20
pull requests in the last week and have many more in the queue.
Having an ever growing pull request queue is a nice problem to have
:-) To those of you who have recently started to contribute (there are
a number of you), it is great to have your help - we really appreciate
it.

Cheers,

Brian



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


From takowl at gmail.com  Fri Jun  8 19:23:24 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Sat, 9 Jun 2012 00:23:24 +0100
Subject: [IPython-dev] Great coding everyone!
In-Reply-To: <CAH4pYpRGaXtp+so=koKm=6G4nWNjgg+73ffugExD-Fn+-4QA=Q@mail.gmail.com>
References: <CAH4pYpRGaXtp+so=koKm=6G4nWNjgg+73ffugExD-Fn+-4QA=Q@mail.gmail.com>
Message-ID: <CAOvn4qi4niDvg9NQCx99yGWCnjGNyn89Fq+TpgWmT0pG9pD0ZA@mail.gmail.com>

I'll second that - thanks everyone who's contributed. Keep up the good
work - it's great to see everything evolving so quickly. We're trying
to keep reviewing and merging pull requests, but if you feel like
we've overlooked yours, please do remind us about it.

This also reminds me: Fernando, do you have the scripts for that graph
you generated, showing change volume by committer for several
scientific Python projects? I remember the graph from Euroscipy last
year, illustrating that most projects were reliant on a couple of
contributors doing nearly all the work. It would be interesting to
rerun that and see how it's changed.

Thanks,
Thomas

On 9 June 2012 00:10, Brian Granger <ellisonbg at gmail.com> wrote:
> HI,
>
> I just wanted to say great job coding to everyone. ?We have merged ~20
> pull requests in the last week and have many more in the queue.
> Having an ever growing pull request queue is a nice problem to have
> :-) To those of you who have recently started to contribute (there are
> a number of you), it is great to have your help - we really appreciate
> it.
>
> Cheers,
>
> Brian
>
>
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu and ellisonbg at gmail.com
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev


From fperez.net at gmail.com  Fri Jun  8 20:51:51 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 8 Jun 2012 17:51:51 -0700
Subject: [IPython-dev] Great coding everyone!
In-Reply-To: <CAOvn4qi4niDvg9NQCx99yGWCnjGNyn89Fq+TpgWmT0pG9pD0ZA@mail.gmail.com>
References: <CAH4pYpRGaXtp+so=koKm=6G4nWNjgg+73ffugExD-Fn+-4QA=Q@mail.gmail.com>
	<CAOvn4qi4niDvg9NQCx99yGWCnjGNyn89Fq+TpgWmT0pG9pD0ZA@mail.gmail.com>
Message-ID: <CAHAreOr_S8OaVdhsRj89SXuNM1RNSU4rbcdz-B+W+fouO034Ew@mail.gmail.com>

On Fri, Jun 8, 2012 at 4:23 PM, Thomas Kluyver <takowl at gmail.com> wrote:
> I'll second that - thanks everyone who's contributed. Keep up the good
> work - it's great to see everything evolving so quickly. We're trying
> to keep reviewing and merging pull requests, but if you feel like
> we've overlooked yours, please do remind us about it.

And I'll third it... I have to say: right now I'm starting to cower in
terror every time I'm away from a computer for a few hours b/c of the
inbox explosion of PRs, emails and discussion, but as Brian said,
that's a great problem to have :)

It's really a thrill to see this happen, and to see what started as
'just an afternoon hack' I did really just for myself (partly to learn
python, as IPython was the first Python program I ever wrote, and at
this clip it's going to be my last too :), grow into such a dynamic
project.  The time and energy that everyone puts into it is something
I personally *really* appreciate, and I only hope more of you will
choose to join us.  The project is getting more cleanly structured by
the day, with more separation between its components that make it
easier to work on only one problem without having to understand the
whole monster (as it used to be).  It also is growing in size which
does come with its own challenges, but I do think that we've made good
progress on having a sustainable architecture.  So jump in!

> This also reminds me: Fernando, do you have the scripts for that graph
> you generated, showing change volume by committer for several
> scientific Python projects? I remember the graph from Euroscipy last
> year, illustrating that most projects were reliant on a couple of
> contributors doing nearly all the work. It would be interesting to
> rerun that and see how it's changed.

Yup, coincidentally I'd cleaned it up a few days ago b/c Gael asked me
for it on the sklearn list...  I thought about putting it in as a
notebook example in master, but I'm not sure it's general enough to
warrant that, so here it goes for now; we can later decide if we want
it in:

https://gist.github.com/cbac490896e968839555

Incidentally, it took me quite a while to track down why the data
collection wasn't working, until I think I was able to pin it on a git
shortlog bug that's only apparent when run in a process like our zmq
kernels that lack a tty.  Our pexpect-based ip.system() call saved the
day in the end, where no amount of twisting and turning with any of
popen*, subprocess or os.system would make git produce *any* output.
I thought I was going positively insane...

Cheers,

f


From hemmecke at gmail.com  Fri Jun  8 23:17:51 2012
From: hemmecke at gmail.com (Ralf Hemmecke)
Date: Sat, 09 Jun 2012 05:17:51 +0200
Subject: [IPython-dev] doc problem in Rmagic
Message-ID: <4FD2C05F.4060807@gmail.com>

Looks like a problem with not rendering the first code block correctly.

http://ipython.org/ipython-doc/dev/config/extensions/rmagic.html

Ralf


From fperez.net at gmail.com  Sat Jun  9 01:05:05 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 8 Jun 2012 22:05:05 -0700
Subject: [IPython-dev] doc problem in Rmagic
In-Reply-To: <4FD2C05F.4060807@gmail.com>
References: <4FD2C05F.4060807@gmail.com>
Message-ID: <CAHAreOqixM=rtJ-vkqR=W=nyRhsHfEaqkUZq+LyN0FNE86-2Cw@mail.gmail.com>

On Fri, Jun 8, 2012 at 8:17 PM, Ralf Hemmecke <hemmecke at gmail.com> wrote:
> Looks like a problem with not rendering the first code block correctly.
>
> http://ipython.org/ipython-doc/dev/config/extensions/rmagic.html

Known problem:

http://mail.scipy.org/pipermail/ipython-dev/2012-June/009424.html

I just realized I'd forgotten to open an issue for it, so here goes:

https://github.com/ipython/ipython/issues/1890

Cheers,

f


From fperez.net at gmail.com  Sat Jun  9 04:56:28 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 9 Jun 2012 01:56:28 -0700
Subject: [IPython-dev] %gui wx completely borked on Ubuntu 12.04,
 how about other OSes?
In-Reply-To: <4FD233D3.9030107@googlemail.com>
References: <CAHAreOo-TvePFTpCxtYT7std5phT39SHJ6q4qB-Pnf8iWSaW1w@mail.gmail.com>
	<4FD233D3.9030107@googlemail.com>
Message-ID: <CAHAreOrLNJUCNCypKwExm__JK_qmFu-QaHJQx5OeyHD6KtNmPw@mail.gmail.com>

On Fri, Jun 8, 2012 at 10:18 AM, Julian Taylor
<jtaylor.debian at googlemail.com> wrote:
> can you test if this helps?
> https://bugs.launchpad.net/ubuntu/+source/wxwidgets2.8/+bug/998716/comments/2

Yup!  Thanks a ton Julian, all fixed.

Cheers,

f


From fperez.net at gmail.com  Sat Jun  9 17:00:59 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 9 Jun 2012 14:00:59 -0700
Subject: [IPython-dev] live coding
In-Reply-To: <4FC3963B.8080900@creativetrax.com>
References: <4FC3963B.8080900@creativetrax.com>
Message-ID: <CAHAreOoCPO85OYJqXWtsy9DLhjK9pXzd5MJjimQ30PSr8oR5XA@mail.gmail.com>

On Mon, May 28, 2012 at 8:14 AM, Jason Grout
<jason-sage at creativetrax.com> wrote:
> This is an amazing vision of (among other things) live interactive coding:
>
> http://vimeo.com/36579366
>
> Bret Victor (who gave the above talk) "has designed experimental UI
> concepts at Apple, interactive data graphics for Al Gore, and musical
> instruments at Alesis." He shows several amazing demos of what coding
> could be like if it was really truly interactive.
>
> Some real-life implementations of some of these ideas are here:
>
> http://mainstem.org/ (click on an example, and then click any number or
> color in the code)
>
> http://gabrielflor.it/water (click on any number)
>
> I challenge us to think of ways to implement some of these principles in
> our tools. ?I don't usually use the word transformative, but I think
> this really would be transformative in how we approach coding and the
> ipython or sage tools.

I see that you took your own advice seriously with your new canvas
experiments, impressive job!

In a sense this goes a bit along the lines of the contrast between
notebook-type environments like the ones ipython and sage use that
come from the mathematica lineage, vs. open-workspace approaches, of
which the oldest implementation I remember was MathCad (haven't used
it in ~10 years).

I have to say that for 'production work' I always hated mathcad and
vastly preferred mathematica (talking just about the canvas-vs-linear
notebook question, not about the language/libraries/mathematical
capabilities).  As a grad student in physics I had to teach
undergraduate labs taht used mathcad to construct the lab reports, and
I really never liked it too much, partly because it was clear that the
approach didn't really scale to more complex problems with large
documents.

But many people did like a lot the freedom and convenience of the
'click and plot' approach it offered, where you could just star typing
a few numbers anywhere on the page and get a plot right at that spot.

So there's definitely room for inspiration from those approaches.  I
have no idea what mathcad looks like these days, btw.

Cheers,

f


From fperez.net at gmail.com  Sat Jun  9 17:31:49 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 9 Jun 2012 14:31:49 -0700
Subject: [IPython-dev] notebook plots via javascript
In-Reply-To: <20120608154921.GL6159@mcelrath.org>
References: <4FCCEC6E.20101@gmail.com> <20120604173320.GA6159@mcelrath.org>
	<4FCCF1D6.90808@gmail.com>
	<CAH4pYpT40b3w8rwwQ+yVcNp+kHDr603j3K5KuDaeeNoXdVTf+A@mail.gmail.com>
	<4FCDAF5F.7000109@gmail.com>
	<2212640E6CD14A2D8323DC91D1FB3E8E@gmail.com>
	<20120607215035.GF6159@mcelrath.org>
	<CAH4pYpT9aUNyZBELDCj5hcuCOksNv3GOORR0ufcKcEHz_yG60w@mail.gmail.com>
	<20120607235841.GH6159@mcelrath.org> <4FD1EB00.1080409@gmail.com>
	<20120608154921.GL6159@mcelrath.org>
Message-ID: <CAHAreOqf4Dy4QdPDA0nAAJsRU0fDkq4WExC22h8rCKdDVuXyyw@mail.gmail.com>

On Fri, Jun 8, 2012 at 8:49 AM, Bob McElrath <bob+ipython at mcelrath.org> wrote:
> Well I'll just say that IPython and matplotlib have quickly become my primary
> computational tool. ?So I would not simply call it an "exploratory" tool. ?I
> could already do exploratory computing with the (i)python command line. ?The
> notebook allows me to save, repeat/reproduce, and communicate a computation. ?In
> particular it allows me to record how I produced the final version of a plot.

Absolutely!  This is how I've been pitching things to scientific
colleagues lately... IPython is an envrionment for the full lifecycle
of computationally-based scientific work, which can be simplified for
the sake of discussion to the following phases:

1. Individual exploratory work: play with some code, some data, some
algorithms, on a problem you have some ideas about.  I used to do this
with ipython(terminal) + a good text editor, others used more IDE-type
systems like Spyder, but even here the notebook is already a major
step forward for the reasons you point above.

... Let's say the above exploration is promising, typically you then move to...

2. Collaboration with colleagues.  We used to email scripts or share
version control repos.  Now the notebook lets us collaborate *live* by
inviting a colleague onto the same notebook and working together on a
common computation.  My most recent two projects (papers in review or
in progress) have been developed in this way, and I can't imagine
going back.


... if things continue to work out, then you're likely to need to move
to a parallel/larger environment for production runs...

3. Parallel production work: we support local parallelism,
cluster/supercomputing environments and the cloud (Amazon and Azure).
The two papers mentioned above were one done in the Amazon cloud and
the other on MPI environments including both beefy 16-core servers and
supercomputers.


 ... if your results do pan out, you'll want to publish them!...

4. The same notebook can then be exported to latex or html for
publication.  We're not really at the point of the notebook being what
you send to a journal, but the notebooks right now are perfect as
supplementary materials that remain *executable*.  Send a PDF for
others to read, put up the ipynb for them to execute, hopefully along
with the machine image that has the actual code and data.  Again, this
is already a reality:

Titus Brown did it before us: http://ged.msu.edu/papers/2012-diginorm/
A few weeks later we had a similar one:
http://qiime.org/home_static/nih-cloud-apr2012/

... Hopefully the material is good enough not just for a paper, but
you actually want to teach it further...

5. The same notebooks can be used for live education.  I've started to
see lots of repos on github popping up with notebooks as tutorials,
and again Titus is leading the charge here:

http://ivory.idyll.org/blog/jun-12/teaching-with-ipynb.html


With the traditional approaches we've mostly used so far, each of the
steps above typically required shifting tools completely.  That hurts
productivity, kills reproducibility, and fundamentally impairs your
ability to *iterate* on an idea.  We've all seen it: the figures look
good, write up the paper, quick!  Forget about trying to rerun the
code later if a question arises, just fix up the figure in
Illustrator!

This is a horrific way to work and yet is how most of today's
computational work is done.  We're trying to change that.

> I have been cursing the capabilities, failures, and crashes of Maple and
> Mathematica for more than a decade now. ?One of the major things where both of
> those packages fall down is plotting. ?For years I have been exporting data to
> flat files and importing it into xmgrace, because the quality of their plots was
> so poor. ?Matplotlib is substantially better than any of the above. ?So, I will
> be producing my plots using it from now on. ?(And I will undoubtedly be
> exporting data from Maple into an IPython notebook for plotting purposes soon)
> I see the IPython notebook as a replacement for Maple, for me.

I had shifted from Maple to Mathematica long ago, but that path is
very similar to ours.

> The interface for creating matplotlib plots is no worse than Gnuplot, Maple, or
> Mathematica, in terms of having to construct the plot using a script. ?There is
> a lot of room for improvement there. ?What I would like is to eventually have a
> GUI-like way to do simple manipulation of plots, along the lines of xmgrace and
> xfig...

Absolutely.  It's been years since I've used xmgrace, but it did have
some very interesting features.

> Anyway, it's a long term goal. ?For now I'm just going to try to get a
> reasonable vector-based rather than rasterized output for the notebook. ?This is
> required so that different screen/browser sizes, font sizes look reasonable.

Yup, and we greatly appreciate the energy you've put into it!

>> But I just fail to see why plots should be resizable, and why plots should be
>> able to emit python code for tracking the changes.
>
> Personally I do not find zooming/panning terribly useful. ?If I need to
> zoom/pan, it always means either
> 1. I will have to re-plot to pan anyway
> 2. I will have to recompute at higher resolution so the zoom/pan is smooth
> About the only thing I do with the gtk matplotlib GUI that is useful is change
> the margins.

Zooming and panning in matplotlib (in the interactive gui windows) can
be very useful for analyzing long time series, for example.  But
that's obviously zooming with replot, not just pixel-boosting.

> The things that are easier to do with an interactive plot are logged axes, tick
> mark spacing, line type/color, axis labels, legend, title, grid, 3d rotation.
> None of which you can do with the matplotlib gui.

Matplotlib does 3d axis rotation, and can toggle log/linear axes (not
sure what you meant by the word 'logged' axes), but you're right that
it doesn't do the others.

In any case, we have a ton of work ahead of us on this front.  Glad to
have more hands on deck!

f


From fperez.net at gmail.com  Sat Jun  9 17:52:48 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 9 Jun 2012 14:52:48 -0700
Subject: [IPython-dev] ipython notebook installation instructions
In-Reply-To: <CAH4pYpREwokDri5PWq5q7Pp2+xnVyzvUdb=SBjeDpZqAAN=n6g@mail.gmail.com>
References: <CAHAreOrozM5LTbsrTd3Hc4CLwEvUhfu+azXZePGGuGHuyfMPkw@mail.gmail.com>
	<4FC74053.5060509@gmail.com>
	<CAHAreOo5acS26fr8ktWhyfA8KbwfepvkX7xyOM9-7srs-MhyXQ@mail.gmail.com>
	<CAH4pYpQA4_mGfuYZXS2hSjxGm7TUD9yjtisDCTzicZYHSNrhiQ@mail.gmail.com>
	<4FC7AA82.4030103@creativetrax.com>
	<CAH4pYpQ4PFzeokbjaDoteKb75K+U1wn7+LTAf3EOeZhCexhkaA@mail.gmail.com>
	<CAHAreOrZyEwURwu++rskq2irpy_t1TYrqGJg_4LUr7Zjk5ZE0g@mail.gmail.com>
	<CAH4pYpR40kjAW3sfhJsE_K6QnNpLar-jdGPPM2hd-YSYEoYYFg@mail.gmail.com>
	<CAHAreOr3PgSqzcmWwDB1fEzNzPTEyTjsaH60ohtxqwAU+RR98w@mail.gmail.com>
	<CAH4pYpREwokDri5PWq5q7Pp2+xnVyzvUdb=SBjeDpZqAAN=n6g@mail.gmail.com>
Message-ID: <CAHAreOrjD9VPr79v1waF4d+T92DC_ju2qD8_3KPjBBeGj4y8gw@mail.gmail.com>

On Thu, May 31, 2012 at 12:12 PM, Brian Granger <ellisonbg at gmail.com> wrote:
> This requires a separate notebook server or kernel manager for each
> such type of notebook. ?What happens when I have users that have R
> notebooks, Matlab notebooks, etc., etc. ?You end up with an incredibly
> difficult situation to manage, both for users, the person running the
> notebook server and the developers of the notebook. ?I think the
> reality is that most users will want to switch back and forth between
> different syntaxes. ?We need to make that simple, easy and lightweight
> and I don't see how to do that with a kernel-side approach.

I'm not convinced that doing it client-side works completely either,
but honestly, this problem is so tricky and full of branching logic to
worry about, that I suggest we just punt on it for now.  We just don't
have the time or mental bandwidth right now to deal with it well, I'm
afraid (at least I don't).  Hopefully in a few months when the base
architecture is more stable we can return to it with a clear head...

I also think that after a few months of using the cell magics system
extensively we'll also have a better understanding and intuition on
some of these questions.

Cheers,

f


From fperez.net at gmail.com  Sat Jun  9 21:19:30 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 9 Jun 2012 18:19:30 -0700
Subject: [IPython-dev] A 'static demo' mode for the notebook,
 so we could keep a more visible version of the examples up?
Message-ID: <CAHAreOo5QvKDD1PGcWZ6qRCum7n+xH5Z0A_sQ0003-_TL2CfDQ@mail.gmail.com>

Hi folks,

I was just thinking: would it make sense to have something like a
`--no-kernels` flag to the notebook that would behave like a 'hard
read-only' mode, where the server would simply never instantiate any
kernel whatsoever (neither for a notebook nor exposing the cluster
tab)?

I'm thinking that such a flag would be very useful in order to run a
very safe notebook server to simply present the nicely rendered
version of all the files in it.  I'm specifically thinking this would
let us have a persistent address to show our example notebooks, for
which we currently resort to just pointing people to the repo:

https://github.com/ipython/ipython/tree/master/docs/examples/notebooks

This isn't a very useful way of showing that content to interested
users, but if we could run a persistent server without any risk that
would solve this problem easily for now.   Eventually we'll fold
high-quality notebook conversion into our built docs, etc, but this
seemed like a useful solution anyways...

Thoughts?

f


From jason-sage at creativetrax.com  Sat Jun  9 21:56:26 2012
From: jason-sage at creativetrax.com (Jason Grout)
Date: Sat, 09 Jun 2012 20:56:26 -0500
Subject: [IPython-dev] A 'static demo' mode for the notebook,
 so we could keep a more visible version of the examples up?
In-Reply-To: <CAHAreOo5QvKDD1PGcWZ6qRCum7n+xH5Z0A_sQ0003-_TL2CfDQ@mail.gmail.com>
References: <CAHAreOo5QvKDD1PGcWZ6qRCum7n+xH5Z0A_sQ0003-_TL2CfDQ@mail.gmail.com>
Message-ID: <4FD3FECA.4040306@creativetrax.com>

On 6/9/12 8:19 PM, Fernando Perez wrote:
> Hi folks,
>
> I was just thinking: would it make sense to have something like a
> `--no-kernels` flag to the notebook that would behave like a 'hard
> read-only' mode, where the server would simply never instantiate any
> kernel whatsoever (neither for a notebook nor exposing the cluster
> tab)?
>
> I'm thinking that such a flag would be very useful in order to run a
> very safe notebook server to simply present the nicely rendered
> version of all the files in it.  I'm specifically thinking this would
> let us have a persistent address to show our example notebooks, for
> which we currently resort to just pointing people to the repo:
>
> https://github.com/ipython/ipython/tree/master/docs/examples/notebooks
>
> This isn't a very useful way of showing that content to interested
> users, but if we could run a persistent server without any risk that
> would solve this problem easily for now.   Eventually we'll fold
> high-quality notebook conversion into our built docs, etc, but this
> seemed like a useful solution anyways...
>
> Thoughts?
>

+1.  Very much so.  Our rough equivalent, the published worksheets on 
sagenb.org, are a wealth of expertise and knowledge, and it's often fun 
to just see what new things I can learn by browsing interesting looking 
ones.

Jason


From damianavila at gmail.com  Sat Jun  9 21:59:26 2012
From: damianavila at gmail.com (=?ISO-8859-1?Q?Dami=E1n_Avila?=)
Date: Sat, 09 Jun 2012 22:59:26 -0300
Subject: [IPython-dev] A 'static demo' mode for the notebook,
 so we could keep a more visible version of the examples up?
In-Reply-To: <4FD3FECA.4040306@creativetrax.com>
References: <CAHAreOo5QvKDD1PGcWZ6qRCum7n+xH5Z0A_sQ0003-_TL2CfDQ@mail.gmail.com>
	<4FD3FECA.4040306@creativetrax.com>
Message-ID: <4FD3FF7E.7010903@gmail.com>

El 09/06/12 22:56, Jason Grout escribi?:
> On 6/9/12 8:19 PM, Fernando Perez wrote:
>> Hi folks,
>>
>> I was just thinking: would it make sense to have something like a
>> `--no-kernels` flag to the notebook that would behave like a 'hard
>> read-only' mode, where the server would simply never instantiate any
>> kernel whatsoever (neither for a notebook nor exposing the cluster
>> tab)?
>>
>> I'm thinking that such a flag would be very useful in order to run a
>> very safe notebook server to simply present the nicely rendered
>> version of all the files in it.  I'm specifically thinking this would
>> let us have a persistent address to show our example notebooks, for
>> which we currently resort to just pointing people to the repo:
>>
>> https://github.com/ipython/ipython/tree/master/docs/examples/notebooks
>>
>> This isn't a very useful way of showing that content to interested
>> users, but if we could run a persistent server without any risk that
>> would solve this problem easily for now.   Eventually we'll fold
>> high-quality notebook conversion into our built docs, etc, but this
>> seemed like a useful solution anyways...
>>
>> Thoughts?
>>
> +1.  Very much so.  Our rough equivalent, the published worksheets on
> sagenb.org, are a wealth of expertise and knowledge, and it's often fun
> to just see what new things I can learn by browsing interesting looking
> ones.
>
> Jason
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev


I believed this would be a great solution until we get a more robust 
conversion tool for IPython Notebooks.

Currently, I am working in a html static view for the notebooks but more 
work have to be done to get it like I/we want.
The app I am developing (IPViewer) is featured with html views and html 
presentation slides for the IPython notebooks (you can see the 
screenshots attached for the html static view and the html5slides).
I hope to get it done soon (I am integrating video recording now...), 
but much work has to be done yet to get the "perfect" html stactic view, 
so I will work more on this to contribute a little bit to the project.

Regards.

Dami?n.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: IPViewer_image1.png
Type: image/png
Size: 111992 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120609/e86ee064/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IPViewer_image2.png
Type: image/png
Size: 86964 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120609/e86ee064/attachment-0001.png>

From carl.input at gmail.com  Sat Jun  9 22:15:56 2012
From: carl.input at gmail.com (Carl Smith)
Date: Sun, 10 Jun 2012 03:15:56 +0100
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAP-uhDdeY0KKSdGuH_X6rFxeKC=JH60OeUrkXqcSH-vm_bh6qQ@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
	<CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
	<CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>
	<CAHAreOryjSpoJpwwTwq6EeE7b1wwHQndoRTGD3R+0tYCF+CsWg@mail.gmail.com>
	<4FD17889.50800@creativetrax.com>
	<CAP-uhDdeY0KKSdGuH_X6rFxeKC=JH60OeUrkXqcSH-vm_bh6qQ@mail.gmail.com>
Message-ID: <CAP-uhDct7nOmjoGZXPmD-UGuhQtAMsVARUn7Jvd=ENOgxCYHMQ@mail.gmail.com>

Hi all

The first version of my app is live. I've called it NotebookCloud.
There's a lot more bells and whistles I'd like to add, but I want to
tidy up the code before I add anything new now. All the main features
are there and it all seems to work well. I've only tested it the
interface on Chromium, but it's standard stuff, so it should work in
all but IE.

notebookcloud.appspot.com

You'll need an AWS and a Google account for this to work, but it only
takes a minute to set up if you have those already. You can delete
your account in one click and you can obviously log into AWS and
change your keys if you need to be sure my app hasn't got access any
more.

I've set it up so that it will not recognise, or effect, anything on
your AWS account that wasn't launched by your NotebookCloud account.
Obviously, if you delete your account and create a new one, which
takes about a minute, it won't recognise anything it did from your old
account on your new one. You can only have up to one NotebookCloud
account per Google Account at any given time.

I'd be really pleased to know how you got on.

Cheers

Carl


On 8 June 2012 15:26, Carl Smith <carl.input at gmail.com> wrote:
> No problem at all, I'm happy to share what I have.
>
> It's not at all difficult to set this up. There's a few parts to it,
> but they're all really simple. The only work is in making a nice GUI
> for the users. There's a ton of extras you can optionally add, on the
> AMI as well as the GUI, but if you only want your stack and a simple
> page on App Engine for launching instances, it's a weekend project.
> All the real work has been done by the IPython developers.
>
> I've not used Sage, but I'm sure it'll be much the same there.
>
> All the best
>
> Carl
>
> On 8 June 2012 04:59, Jason Grout <jason-sage at creativetrax.com> wrote:
>> On 6/7/12 9:34 PM, Fernando Perez wrote:
>>> On Thu, Jun 7, 2012 at 7:14 PM, Carl Smith<carl.input at gmail.com> ?wrote:
>>>> Eventually, I want a web app you can use to launch a keyless, Ubuntu server
>>>> on your EC2 account, with all the Python stuff installed, and IPython as the
>>>> sole interface to the VM itself. It'll be free to use. It just calls AWS for
>>>> the user and provides a link to their server, so I can run it on App Engine
>>>> for free.
>>>
>>> Got it, thanks. ?Definitely keep us posted on the progress, as it
>>> sounds very useful.
>>
>> Yes, please. ?It sounds useful for our project as well, since we are
>> keeping an eye on moving the web project to app engine and the
>> computation part to EC2.
>>
>> Thanks,
>>
>> jason
>>
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev


From satra at mit.edu  Sat Jun  9 22:24:16 2012
From: satra at mit.edu (Satrajit Ghosh)
Date: Sat, 9 Jun 2012 22:24:16 -0400
Subject: [IPython-dev] A 'static demo' mode for the notebook,
 so we could keep a more visible version of the examples up?
In-Reply-To: <CAHAreOo5QvKDD1PGcWZ6qRCum7n+xH5Z0A_sQ0003-_TL2CfDQ@mail.gmail.com>
References: <CAHAreOo5QvKDD1PGcWZ6qRCum7n+xH5Z0A_sQ0003-_TL2CfDQ@mail.gmail.com>
Message-ID: <CA+A4wO=MhGeNJqWZS-SKwPsdCmuwhPJpMoX87CiuABAqrhB3CQ@mail.gmail.com>

>
> I was just thinking: would it make sense to have something like a
> `--no-kernels` flag to the notebook that would behave like a 'hard
> read-only' mode, where the server would simply never instantiate any
> kernel whatsoever (neither for a notebook nor exposing the cluster
> tab)?
>

+1

it would be cool if this could be done with a client side javascript
viewer? so no server to instantiate at all.

cheers,

satra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120609/8ca64787/attachment.html>

From benjaminrk at gmail.com  Sun Jun 10 01:34:21 2012
From: benjaminrk at gmail.com (Min RK)
Date: Sat, 9 Jun 2012 22:34:21 -0700
Subject: [IPython-dev] A 'static demo' mode for the notebook,
	so we could keep a more visible version of the examples up?
In-Reply-To: <CAHAreOo5QvKDD1PGcWZ6qRCum7n+xH5Z0A_sQ0003-_TL2CfDQ@mail.gmail.com>
References: <CAHAreOo5QvKDD1PGcWZ6qRCum7n+xH5Z0A_sQ0003-_TL2CfDQ@mail.gmail.com>
Message-ID: <C1977584-DC81-4526-8B7A-899D29480898@gmail.com>

The old read-only did exactly this if no password was set, but if I recall the reorg totally broke read only.

-MinRK

On Jun 9, 2012, at 6:19 PM, Fernando Perez <fperez.net at gmail.com> wrote:

> Hi folks,
> 
> I was just thinking: would it make sense to have something like a
> `--no-kernels` flag to the notebook that would behave like a 'hard
> read-only' mode, where the server would simply never instantiate any
> kernel whatsoever (neither for a notebook nor exposing the cluster
> tab)?
> 
> I'm thinking that such a flag would be very useful in order to run a
> very safe notebook server to simply present the nicely rendered
> version of all the files in it.  I'm specifically thinking this would
> let us have a persistent address to show our example notebooks, for
> which we currently resort to just pointing people to the repo:
> 
> https://github.com/ipython/ipython/tree/master/docs/examples/notebooks
> 
> This isn't a very useful way of showing that content to interested
> users, but if we could run a persistent server without any risk that
> would solve this problem easily for now.   Eventually we'll fold
> high-quality notebook conversion into our built docs, etc, but this
> seemed like a useful solution anyways...
> 
> Thoughts?
> 
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev


From bob+ipython at mcelrath.org  Sun Jun 10 02:48:19 2012
From: bob+ipython at mcelrath.org (Bob McElrath)
Date: Sun, 10 Jun 2012 06:48:19 +0000
Subject: [IPython-dev] A 'static demo' mode for the notebook,
 so we could keep a more visible version of the examples up?
In-Reply-To: <CA+A4wO=MhGeNJqWZS-SKwPsdCmuwhPJpMoX87CiuABAqrhB3CQ@mail.gmail.com>
References: <CAHAreOo5QvKDD1PGcWZ6qRCum7n+xH5Z0A_sQ0003-_TL2CfDQ@mail.gmail.com>
	<CA+A4wO=MhGeNJqWZS-SKwPsdCmuwhPJpMoX87CiuABAqrhB3CQ@mail.gmail.com>
Message-ID: <20120610064817.GR6159@mcelrath.org>

+1!!!

Satrajit Ghosh [satra at mit.edu] wrote:
> it would be cool if this could be done with a client side javascript viewer? so
> no server to instantiate at all.

Is anyone familiar with TiddlyWiki (tiddlywiki.org)?  It's a single-html file
application for personal note-taking.  People have written server-side
implementations (including me) but the single-file html paradigm is very
powerful.  It's easily thrown on the web, and easily passed around.  I've been
using it as a "scientific notebook" for years (I wrote a tex plugin for it).

Anyway, I think the single-html-file could be a very powerful paradigm for an
IPython notebook.  All necessary javascript, json worksheet, css, etc can be
embedded in the file.  The "worksheet" part (json) could be programatically
extracted to upgrade.  (TiddlyWiki does all that)  Plugins could interface
python, sage, maple, mathematica, or start remote server (ec2) instances.

Some years ago I built an interface in TiddlyWiki that communicated with the
computer algebra software Axiom, it was extremely similar to the IPython
notebook (though, less developed).

Currently I'm already interfacing TW and IPython, in that I've embedded the
dashboard in a tiddler (iframe).  ("tiddler" = single, titled note in the wiki)
I can't embed worksheets currently because IPython does not produce stable URL's
-- the URL hash changes when the server is restarted.  For me, it's important to
link an idea/note in my wiki with a corresponding calculation in a worksheet.
Notes are always idea->discussion->literature search->calculation->graph->more
discussion->(repeat).

I think the concept of a "unit" of code as a tiddler may also be a very powerful
paradigm.  It aligns with the "light table" idea that has gotten a lot of press
recently.  Something I've been thinking about a lot...

Any takers?  It would be fairly straightforward to write a TiddlyWiki plugin
containing the existing IPython notebook javascript and CSS.  It would have to
be served from the IPython HTTP server, due to cross-origin restrictions.

I do have some concerns about how to make a consistent "state" of the kernel
when the code can be spread around in multiple "tiddler", that's a challenge
shared with the light table idea.  But one worksheet per tiddler is an easy way
to start.

--
Cheers, Bob McElrath

"The individual has always had to struggle to keep from being overwhelmed by
the tribe.  If you try it, you will be lonely often, and sometimes frightened.
But no price is too high to pay for the privilege of owning yourself." 
    -- Friedrich Nietzsche


From carl.input at gmail.com  Sun Jun 10 09:08:38 2012
From: carl.input at gmail.com (Carl Smith)
Date: Sun, 10 Jun 2012 14:08:38 +0100
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAP-uhDct7nOmjoGZXPmD-UGuhQtAMsVARUn7Jvd=ENOgxCYHMQ@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
	<CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
	<CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>
	<CAHAreOryjSpoJpwwTwq6EeE7b1wwHQndoRTGD3R+0tYCF+CsWg@mail.gmail.com>
	<4FD17889.50800@creativetrax.com>
	<CAP-uhDdeY0KKSdGuH_X6rFxeKC=JH60OeUrkXqcSH-vm_bh6qQ@mail.gmail.com>
	<CAP-uhDct7nOmjoGZXPmD-UGuhQtAMsVARUn7Jvd=ENOgxCYHMQ@mail.gmail.com>
Message-ID: <CAP-uhDfVT36Ji-33AV9BPNXcxN=eutOOhMq8xBAk7m=zGTaB1g@mail.gmail.com>

Works with FF :)


From takowl at gmail.com  Sun Jun 10 09:14:04 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Sun, 10 Jun 2012 14:14:04 +0100
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAP-uhDct7nOmjoGZXPmD-UGuhQtAMsVARUn7Jvd=ENOgxCYHMQ@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
	<CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
	<CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>
	<CAHAreOryjSpoJpwwTwq6EeE7b1wwHQndoRTGD3R+0tYCF+CsWg@mail.gmail.com>
	<4FD17889.50800@creativetrax.com>
	<CAP-uhDdeY0KKSdGuH_X6rFxeKC=JH60OeUrkXqcSH-vm_bh6qQ@mail.gmail.com>
	<CAP-uhDct7nOmjoGZXPmD-UGuhQtAMsVARUn7Jvd=ENOgxCYHMQ@mail.gmail.com>
Message-ID: <CAOvn4qgF-CQMvOTv5WdMDZRt+BgZ5npG9ZtFMD+7-hmvsrkAjg@mail.gmail.com>

On 10 June 2012 03:15, Carl Smith <carl.input at gmail.com> wrote:
> The first version of my app is live. I've called it NotebookCloud.
> There's a lot more bells and whistles I'd like to add, but I want to
> tidy up the code before I add anything new now. All the main features
> are there and it all seems to work well. I've only tested it the
> interface on Chromium, but it's standard stuff, so it should work in
> all but IE.

Thanks Carl, that looks really nice.

I don't have an AWS account, so I got as far as the 'Update your
details' screen - can you briefly summarise what the user would see
after that? If you've got time, a few screenshots would be great.

Once we've had a few people use it successfully, I think this is
something we should promote from the IPython website.

Best wishes,
Thomas


From dave.hirschfeld at gmail.com  Sun Jun 10 09:39:32 2012
From: dave.hirschfeld at gmail.com (Dave Hirschfeld)
Date: Sun, 10 Jun 2012 13:39:32 +0000 (UTC)
Subject: [IPython-dev] IPython notebook on Windows Azure
References: <CAOvn4qgqT578_fU5t-YXQCw7FqwAWuT5XOxfrJ3S4hOULx=J-Q@mail.gmail.com>
Message-ID: <loom.20120610T141014-629@post.gmane.org>

Thomas Kluyver <takowl <at> gmail.com> writes:

> 
> Just scanning through the documentation for Windows Azure, I notice
> that they have instructions for setting up the IPython notebook both
> on Linux and Windows (it's not clear why you'd want the extra hassle
> of setting everything up on Windows, but I guess someone will want
> to).
> 
> http://www.windowsazure.com/en-us/develop/python/tutorials/ipython-notebook/
> 

Thanks Brian & Fernando for the great tutorial - I've been meaning to try out 
Azure for a while so this gave me the perfect excuse to finally give it a go!

For anyone else going through the hassle of setting it up on Windows, here's a 
few things I learnt along the way:

After setting up a Windows Server VM you start out with Internet Explorer having 
security settings which prevent you for visiting any website without a security 
alert popping up. More importantly, you also can't download anything. To fix 
this you need to got to Security tab in the Tools -> Internet Options dialog. In 
the "Internet Zone" you can't change the level from High so you have to click 
the Custom Level button and enable the required functionality. At this point I 
enabled everything, downloaded Chrome and proceeded from there.

Having got the notebook server up & running I then tried to view it locally on 
"http://localhost:9999". This didn't work and in the terminal where the notebook 
server was running I got the following error message:

_ssl.c:503: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request

A little bit of googling seemed to suggest this had something to do with trying 
to access a https site using the http protocol and sure enough 
"https://localhost:9999" took me to the notebook login page.

Finally, despite confirming it was running locally I couldn't access it via 
"https://ipython-demo.cloudapp.net". I confirmed this was a firewall issue by 
turning off the firewall entirely. With a bit of trial and error I found that it 
was only necessary to open port 9999 in the firewall to have external access.

This can be done from the firewall gui: go to Start -> Run, enter wf.msc then 
create a new Inbound rule to open port 9999 on the Public Profile.

Alternatively, entering the following command in a terminal will also do the 
job:

netsh firewall set portopening protocol = TCP port = 9999 name = nbserver mode = 
ENABLE scope = ALL profile = CURRENT


AFAICS you get charged for your VM whether or not it's running? Is the only way 
to stop being charged is to delete all your VMs and recreate them when you want 
to use them again? If that is the case, you'll probably want to create an image
so when you create a new VM you can pick up from where you left off. Following 
the instructions below it was fairly easy to do:

https://www.windowsazure.com/en-us/manage/windows/how-to-guides/capture-an-
image/

I'll have to look into setting up an ipython cluster on Azure next!

Cheers,
Dave




From carl.input at gmail.com  Sun Jun 10 10:53:38 2012
From: carl.input at gmail.com (Carl Smith)
Date: Sun, 10 Jun 2012 15:53:38 +0100
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAOvn4qgF-CQMvOTv5WdMDZRt+BgZ5npG9ZtFMD+7-hmvsrkAjg@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
	<CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
	<CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>
	<CAHAreOryjSpoJpwwTwq6EeE7b1wwHQndoRTGD3R+0tYCF+CsWg@mail.gmail.com>
	<4FD17889.50800@creativetrax.com>
	<CAP-uhDdeY0KKSdGuH_X6rFxeKC=JH60OeUrkXqcSH-vm_bh6qQ@mail.gmail.com>
	<CAP-uhDct7nOmjoGZXPmD-UGuhQtAMsVARUn7Jvd=ENOgxCYHMQ@mail.gmail.com>
	<CAOvn4qgF-CQMvOTv5WdMDZRt+BgZ5npG9ZtFMD+7-hmvsrkAjg@mail.gmail.com>
Message-ID: <CAP-uhDeas4=xNYE39KBm0JKg0fMDLuAK5ZidqdMqmnRij7Ma3Q@mail.gmail.com>

Hi Thomas

I'm on my phone at the moment, but I'll do some shots of it today and write
a bit about it, then post it somewhere.

In short, once you've got your details saved you're redirected to a
launcher screen that has a bunch of buttons, Update Screen, Launch New,
Update Account Details, Delete Account and a link to AWS. Any notebook
servers you've launched will appear below with a status. I split the EC2
status, "running", into two, booting and serving. If your instance is
serving you can click it and go to your notebook server.

I'll be on my PC in a few hours so I can expain better then.

Nice one

Carl
On Jun 10, 2012 2:14 PM, "Thomas Kluyver" <takowl at gmail.com> wrote:

> On 10 June 2012 03:15, Carl Smith <carl.input at gmail.com> wrote:
> > The first version of my app is live. I've called it NotebookCloud.
> > There's a lot more bells and whistles I'd like to add, but I want to
> > tidy up the code before I add anything new now. All the main features
> > are there and it all seems to work well. I've only tested it the
> > interface on Chromium, but it's standard stuff, so it should work in
> > all but IE.
>
> Thanks Carl, that looks really nice.
>
> I don't have an AWS account, so I got as far as the 'Update your
> details' screen - can you briefly summarise what the user would see
> after that? If you've got time, a few screenshots would be great.
>
> Once we've had a few people use it successfully, I think this is
> something we should promote from the IPython website.
>
> Best wishes,
> Thomas
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120610/ded9b915/attachment.html>

From carl.input at gmail.com  Sun Jun 10 13:14:41 2012
From: carl.input at gmail.com (Carl Smith)
Date: Sun, 10 Jun 2012 18:14:41 +0100
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAP-uhDeas4=xNYE39KBm0JKg0fMDLuAK5ZidqdMqmnRij7Ma3Q@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
	<CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
	<CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>
	<CAHAreOryjSpoJpwwTwq6EeE7b1wwHQndoRTGD3R+0tYCF+CsWg@mail.gmail.com>
	<4FD17889.50800@creativetrax.com>
	<CAP-uhDdeY0KKSdGuH_X6rFxeKC=JH60OeUrkXqcSH-vm_bh6qQ@mail.gmail.com>
	<CAP-uhDct7nOmjoGZXPmD-UGuhQtAMsVARUn7Jvd=ENOgxCYHMQ@mail.gmail.com>
	<CAOvn4qgF-CQMvOTv5WdMDZRt+BgZ5npG9ZtFMD+7-hmvsrkAjg@mail.gmail.com>
	<CAP-uhDeas4=xNYE39KBm0JKg0fMDLuAK5ZidqdMqmnRij7Ma3Q@mail.gmail.com>
Message-ID: <CAP-uhDewWs-JdREQdEVmopEyVZH9UJd7NpsPTv0W-m7=yKQfXg@mail.gmail.com>

Hi all

I'm just posting a couple of sceenshots I took of the Launcher. It's
pretty minimal, but I find it works nicely for now. There's one as it
looks when you first see it, when it's empty, and one of with some
stuff going on.

Thanks

Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: empty_launcher.png
Type: image/png
Size: 15591 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120610/ffe9b87d/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: example_launcher.png
Type: image/png
Size: 20678 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120610/ffe9b87d/attachment-0001.png>

From satra at mit.edu  Sun Jun 10 13:44:20 2012
From: satra at mit.edu (Satrajit Ghosh)
Date: Sun, 10 Jun 2012 13:44:20 -0400
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAOvn4qgF-CQMvOTv5WdMDZRt+BgZ5npG9ZtFMD+7-hmvsrkAjg@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
	<CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
	<CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>
	<CAHAreOryjSpoJpwwTwq6EeE7b1wwHQndoRTGD3R+0tYCF+CsWg@mail.gmail.com>
	<4FD17889.50800@creativetrax.com>
	<CAP-uhDdeY0KKSdGuH_X6rFxeKC=JH60OeUrkXqcSH-vm_bh6qQ@mail.gmail.com>
	<CAP-uhDct7nOmjoGZXPmD-UGuhQtAMsVARUn7Jvd=ENOgxCYHMQ@mail.gmail.com>
	<CAOvn4qgF-CQMvOTv5WdMDZRt+BgZ5npG9ZtFMD+7-hmvsrkAjg@mail.gmail.com>
Message-ID: <CA+A4wOkXkgV76mEUCri=hJEEHdD3Msie8+s5mwSa3Va9W1XVKA@mail.gmail.com>

for those wanting to try this out, amazon provides a free minimal aws
account.

cheers,

satra


On Sun, Jun 10, 2012 at 9:14 AM, Thomas Kluyver <takowl at gmail.com> wrote:

> On 10 June 2012 03:15, Carl Smith <carl.input at gmail.com> wrote:
> > The first version of my app is live. I've called it NotebookCloud.
> > There's a lot more bells and whistles I'd like to add, but I want to
> > tidy up the code before I add anything new now. All the main features
> > are there and it all seems to work well. I've only tested it the
> > interface on Chromium, but it's standard stuff, so it should work in
> > all but IE.
>
> Thanks Carl, that looks really nice.
>
> I don't have an AWS account, so I got as far as the 'Update your
> details' screen - can you briefly summarise what the user would see
> after that? If you've got time, a few screenshots would be great.
>
> Once we've had a few people use it successfully, I think this is
> something we should promote from the IPython website.
>
> Best wishes,
> Thomas
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120610/646029a7/attachment.html>

From carl.input at gmail.com  Sun Jun 10 16:59:22 2012
From: carl.input at gmail.com (Carl Smith)
Date: Sun, 10 Jun 2012 21:59:22 +0100
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CA+A4wOkXkgV76mEUCri=hJEEHdD3Msie8+s5mwSa3Va9W1XVKA@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
	<CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
	<CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>
	<CAHAreOryjSpoJpwwTwq6EeE7b1wwHQndoRTGD3R+0tYCF+CsWg@mail.gmail.com>
	<4FD17889.50800@creativetrax.com>
	<CAP-uhDdeY0KKSdGuH_X6rFxeKC=JH60OeUrkXqcSH-vm_bh6qQ@mail.gmail.com>
	<CAP-uhDct7nOmjoGZXPmD-UGuhQtAMsVARUn7Jvd=ENOgxCYHMQ@mail.gmail.com>
	<CAOvn4qgF-CQMvOTv5WdMDZRt+BgZ5npG9ZtFMD+7-hmvsrkAjg@mail.gmail.com>
	<CA+A4wOkXkgV76mEUCri=hJEEHdD3Msie8+s5mwSa3Va9W1XVKA@mail.gmail.com>
Message-ID: <CAP-uhDdysAdEDOAmyw7UGAzuU94GKecdV68RCcoF2ksETNOQAg@mail.gmail.com>

I've put a draft user guide together that you can access here.

https://docs.google.com/document/d/17XqF6yedliNVvSg6nHIL0gx0yfUnhq0euGqPzf0AUnw/edit

Let me know if anyone has any questions.

Cheers

Carl


From takowl at gmail.com  Sun Jun 10 19:15:07 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 11 Jun 2012 00:15:07 +0100
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAP-uhDewWs-JdREQdEVmopEyVZH9UJd7NpsPTv0W-m7=yKQfXg@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
	<CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
	<CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>
	<CAHAreOryjSpoJpwwTwq6EeE7b1wwHQndoRTGD3R+0tYCF+CsWg@mail.gmail.com>
	<4FD17889.50800@creativetrax.com>
	<CAP-uhDdeY0KKSdGuH_X6rFxeKC=JH60OeUrkXqcSH-vm_bh6qQ@mail.gmail.com>
	<CAP-uhDct7nOmjoGZXPmD-UGuhQtAMsVARUn7Jvd=ENOgxCYHMQ@mail.gmail.com>
	<CAOvn4qgF-CQMvOTv5WdMDZRt+BgZ5npG9ZtFMD+7-hmvsrkAjg@mail.gmail.com>
	<CAP-uhDeas4=xNYE39KBm0JKg0fMDLuAK5ZidqdMqmnRij7Ma3Q@mail.gmail.com>
	<CAP-uhDewWs-JdREQdEVmopEyVZH9UJd7NpsPTv0W-m7=yKQfXg@mail.gmail.com>
Message-ID: <CAOvn4qjAZRYwvKTSKytSgR8UtDmXFy=vguaHZmRCoHBrspJ5wQ@mail.gmail.com>

On 10 June 2012 18:14, Carl Smith <carl.input at gmail.com> wrote:
> I'm just posting a couple of sceenshots I took of the Launcher. It's
> pretty minimal, but I find it works nicely for now. There's one as it
> looks when you first see it, when it's empty, and one of with some
> stuff going on.

Thanks, that looks pretty handy. A couple of questions/suggestions:

- I don't see any 'stop serving' button in the screenshots. Can the
user stop a notebook server from this interface, or do you have to go
to AWS? Also, are the notebooks stored somewhere that persists when
you stop the server, or are they only there as long as you keep the
instance running?
- The UI and/or the guide could mention what sort of instance you
start up, and what the hourly price is. (And an obvious future
expansion is to let the user choose the instance type).
- If you're storing AWS keys, the data needs to be stored securely. I
imagine Google mostly take care of that for the app engine datastore,
but it would be good to have a note to reassure the user about it.

Best wishes,
Thomas


From carl.input at gmail.com  Sun Jun 10 20:10:11 2012
From: carl.input at gmail.com (Carl Smith)
Date: Mon, 11 Jun 2012 01:10:11 +0100
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAOvn4qjAZRYwvKTSKytSgR8UtDmXFy=vguaHZmRCoHBrspJ5wQ@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
	<CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
	<CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>
	<CAHAreOryjSpoJpwwTwq6EeE7b1wwHQndoRTGD3R+0tYCF+CsWg@mail.gmail.com>
	<4FD17889.50800@creativetrax.com>
	<CAP-uhDdeY0KKSdGuH_X6rFxeKC=JH60OeUrkXqcSH-vm_bh6qQ@mail.gmail.com>
	<CAP-uhDct7nOmjoGZXPmD-UGuhQtAMsVARUn7Jvd=ENOgxCYHMQ@mail.gmail.com>
	<CAOvn4qgF-CQMvOTv5WdMDZRt+BgZ5npG9ZtFMD+7-hmvsrkAjg@mail.gmail.com>
	<CAP-uhDeas4=xNYE39KBm0JKg0fMDLuAK5ZidqdMqmnRij7Ma3Q@mail.gmail.com>
	<CAP-uhDewWs-JdREQdEVmopEyVZH9UJd7NpsPTv0W-m7=yKQfXg@mail.gmail.com>
	<CAOvn4qjAZRYwvKTSKytSgR8UtDmXFy=vguaHZmRCoHBrspJ5wQ@mail.gmail.com>
Message-ID: <CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>

No worries.

I've put the guide on the site now, so you just go to it from the home page.

> - I don't see any 'stop serving' button in the screenshots. Can the
> user stop a notebook server from this interface, or do you have to go
> to AWS? Also, are the notebooks stored somewhere that persists when
> you stop the server, or are they only there as long as you keep the
> instance running?

You can only launch an instance at the moment, but adding Stop, Start,
Reboot and Terminate is pretty easy to do.

As for the notebooks, they're persistent for so long as you don't
terminate the instance altogether. You can shut it down and restart it
later, just like a regular machine, but terminating it, will wipe it
out. It uses EBS, which are a bit like virtual discs that are just
made available to your instances. It's all very cloud :)

> - The UI and/or the guide could mention what sort of instance you
> start up, and what the hourly price is. (And an obvious future
> expansion is to let the user choose the instance type).

I'm going to add some more options soon, so you can use other instance
types and so on. At the moment it launches instances that qualify for
the Free Tier, but you're right, users need to know quite a bit more
about what they're launching. And many don't qualify for freebies
anyway, they're only for the first year after you sign up.

> - If you're storing AWS keys, the data needs to be stored securely. I
> imagine Google mostly take care of that for the app engine datastore,
> but it would be good to have a note to reassure the user about it.

Good point, I'll keep that in mind when I go over the docs.

Thanks for your input Thomas, nice one.

All the best

Carl


From takowl at gmail.com  Sun Jun 10 20:20:49 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 11 Jun 2012 01:20:49 +0100
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
	<CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
	<CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>
	<CAHAreOryjSpoJpwwTwq6EeE7b1wwHQndoRTGD3R+0tYCF+CsWg@mail.gmail.com>
	<4FD17889.50800@creativetrax.com>
	<CAP-uhDdeY0KKSdGuH_X6rFxeKC=JH60OeUrkXqcSH-vm_bh6qQ@mail.gmail.com>
	<CAP-uhDct7nOmjoGZXPmD-UGuhQtAMsVARUn7Jvd=ENOgxCYHMQ@mail.gmail.com>
	<CAOvn4qgF-CQMvOTv5WdMDZRt+BgZ5npG9ZtFMD+7-hmvsrkAjg@mail.gmail.com>
	<CAP-uhDeas4=xNYE39KBm0JKg0fMDLuAK5ZidqdMqmnRij7Ma3Q@mail.gmail.com>
	<CAP-uhDewWs-JdREQdEVmopEyVZH9UJd7NpsPTv0W-m7=yKQfXg@mail.gmail.com>
	<CAOvn4qjAZRYwvKTSKytSgR8UtDmXFy=vguaHZmRCoHBrspJ5wQ@mail.gmail.com>
	<CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
Message-ID: <CAOvn4qjTxPynSEbztdY2KgMK-v8H+rWDDNA-kH9aDdZ_jS_BdQ@mail.gmail.com>

On 11 June 2012 01:10, Carl Smith <carl.input at gmail.com> wrote:
> As for the notebooks, they're persistent for so long as you don't
> terminate the instance altogether. You can shut it down and restart it
> later, just like a regular machine, but terminating it, will wipe it
> out. It uses EBS, which are a bit like virtual discs that are just
> made available to your instances. It's all very cloud :)

Cloud indeed ;-). And do you pay for the instance while it's shut
down? Is EBS storage billed separately from the instance run time?

(I'm saving my year's free usage until I think I've got something to
use it for, otherwise I'd sign up & play around with it now)

Thanks,
Thomas


From fperez.net at gmail.com  Sun Jun 10 20:55:32 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 10 Jun 2012 17:55:32 -0700
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
	<CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
	<CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>
	<CAHAreOryjSpoJpwwTwq6EeE7b1wwHQndoRTGD3R+0tYCF+CsWg@mail.gmail.com>
	<4FD17889.50800@creativetrax.com>
	<CAP-uhDdeY0KKSdGuH_X6rFxeKC=JH60OeUrkXqcSH-vm_bh6qQ@mail.gmail.com>
	<CAP-uhDct7nOmjoGZXPmD-UGuhQtAMsVARUn7Jvd=ENOgxCYHMQ@mail.gmail.com>
	<CAOvn4qgF-CQMvOTv5WdMDZRt+BgZ5npG9ZtFMD+7-hmvsrkAjg@mail.gmail.com>
	<CAP-uhDeas4=xNYE39KBm0JKg0fMDLuAK5ZidqdMqmnRij7Ma3Q@mail.gmail.com>
	<CAP-uhDewWs-JdREQdEVmopEyVZH9UJd7NpsPTv0W-m7=yKQfXg@mail.gmail.com>
	<CAOvn4qjAZRYwvKTSKytSgR8UtDmXFy=vguaHZmRCoHBrspJ5wQ@mail.gmail.com>
	<CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
Message-ID: <CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>

On Sun, Jun 10, 2012 at 5:10 PM, Carl Smith <carl.input at gmail.com> wrote:

First, let me say you've done an awesome job.  It took me probably
less than a minute to be up and running, that's very impressive (I
already had my amazon key info in my starcluster file, so it was
literally copy/paste two strings, type a password twice, done).

One suggestion: add a hidden force-refresh tag to the page so that it
refreshes status when starting instances, say every 10s.  I assumed it
would and it took me a while to realize I had to manually refresh the
page to see the instance was up and running

>
> You can only launch an instance at the moment, but adding Stop, Start,
> Reboot and Terminate is pretty easy to do.

Yes, those are pretty high priority to make it self contained.  With
starcluster I never go to the (god-awful) AWS web interface, so it
would be nice not to have to visit that interface with your tool
either.

> As for the notebooks, they're persistent for so long as you don't
> terminate the instance altogether. You can shut it down and restart it
> later, just like a regular machine, but terminating it, will wipe it
> out. It uses EBS, which are a bit like virtual discs that are just
> made available to your instances. It's all very cloud :)

You could offer the option for the user to register an EBS disk they
have access to and mount it as the home directory for the notebook.
That way they don't have to pay for the instance being stored, only
for their own data.  And it also means they can use `!pip install
--user` to add local packages stored in their user area and that is
persisted too.

Just an idea :)

Great job anyways, thanks!!

f


From takowl at gmail.com  Sun Jun 10 21:03:19 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 11 Jun 2012 02:03:19 +0100
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
	<CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
	<CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>
	<CAHAreOryjSpoJpwwTwq6EeE7b1wwHQndoRTGD3R+0tYCF+CsWg@mail.gmail.com>
	<4FD17889.50800@creativetrax.com>
	<CAP-uhDdeY0KKSdGuH_X6rFxeKC=JH60OeUrkXqcSH-vm_bh6qQ@mail.gmail.com>
	<CAP-uhDct7nOmjoGZXPmD-UGuhQtAMsVARUn7Jvd=ENOgxCYHMQ@mail.gmail.com>
	<CAOvn4qgF-CQMvOTv5WdMDZRt+BgZ5npG9ZtFMD+7-hmvsrkAjg@mail.gmail.com>
	<CAP-uhDeas4=xNYE39KBm0JKg0fMDLuAK5ZidqdMqmnRij7Ma3Q@mail.gmail.com>
	<CAP-uhDewWs-JdREQdEVmopEyVZH9UJd7NpsPTv0W-m7=yKQfXg@mail.gmail.com>
	<CAOvn4qjAZRYwvKTSKytSgR8UtDmXFy=vguaHZmRCoHBrspJ5wQ@mail.gmail.com>
	<CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
	<CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>
Message-ID: <CAOvn4qjs5ifL_HKj1qJWkmNdQ+4KUSQtgCE37QbLX3Yy_y6DcA@mail.gmail.com>

On 11 June 2012 01:55, Fernando Perez <fperez.net at gmail.com> wrote:
> And it also means they can use `!pip install
> --user` to add local packages stored in their user area and that is
> persisted too.

At the risk of taking this off topic, is it worth having a magic
command to do this?

I think it's a significant shortcoming of Python that the normal way
of installing a package requires a separate shell, outside the
interpreter. In R, the default way to install a package is the
install.package function, so new users don't need to bother with using
a system command line as well.

Thomas


From carl.input at gmail.com  Sun Jun 10 21:06:33 2012
From: carl.input at gmail.com (Carl Smith)
Date: Mon, 11 Jun 2012 02:06:33 +0100
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
	<CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
	<CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>
	<CAHAreOryjSpoJpwwTwq6EeE7b1wwHQndoRTGD3R+0tYCF+CsWg@mail.gmail.com>
	<4FD17889.50800@creativetrax.com>
	<CAP-uhDdeY0KKSdGuH_X6rFxeKC=JH60OeUrkXqcSH-vm_bh6qQ@mail.gmail.com>
	<CAP-uhDct7nOmjoGZXPmD-UGuhQtAMsVARUn7Jvd=ENOgxCYHMQ@mail.gmail.com>
	<CAOvn4qgF-CQMvOTv5WdMDZRt+BgZ5npG9ZtFMD+7-hmvsrkAjg@mail.gmail.com>
	<CAP-uhDeas4=xNYE39KBm0JKg0fMDLuAK5ZidqdMqmnRij7Ma3Q@mail.gmail.com>
	<CAP-uhDewWs-JdREQdEVmopEyVZH9UJd7NpsPTv0W-m7=yKQfXg@mail.gmail.com>
	<CAOvn4qjAZRYwvKTSKytSgR8UtDmXFy=vguaHZmRCoHBrspJ5wQ@mail.gmail.com>
	<CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
	<CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>
Message-ID: <CAP-uhDeMkQux3mxiB1mmDLhHmQND1hoJ21xB0i9wVkAQUgsiMQ@mail.gmail.com>

Thank you very much Fernando, I'm really pleased you like it.

> One suggestion: add a hidden force-refresh tag to the page so that it
> refreshes status when starting instances, say every 10s. ?I assumed it
> would and it took me a while to realize I had to manually refresh the
> page to see the instance was up and running

I did try this, but it racks up a lot of requests if you leave it open
for a while and you do pay for them if there's loads. I think you get
10,000 a month on the Free Tier, but that isn't that many at one every
10 seconds. As you suggested, it needs to just do it when there's
something pending, then settle down when all is quiet. The problem is
that refreshing the page refreshes the namespace, so you can't modify
the time between each refresh easily. I'm thinking about how to solve
that??

> Yes, those are pretty high priority to make it self contained. ?With
> starcluster I never go to the (god-awful) AWS web interface, so it
> would be nice not to have to visit that interface with your tool
> either.

The AWS console always hogs all my RAM. It's not good. I upgraded to
the new look. Now, it looks nice, but still runs like jam.

> You could offer the option for the user to register an EBS disk they
> have access to and mount it as the home directory for the notebook.
> That way they don't have to pay for the instance being stored, only
> for their own data. ?And it also means they can use `!pip install
> --user` to add local packages stored in their user area and that is
> persisted too.

I have to be honest, you lost me a bit here. I'll have to do a bit of
homework and get back to you. It sounds like an awesome idea, I'm just
not sure how to do it. I might be back for some advice on that one.

Thanks again

Carl


From fperez.net at gmail.com  Sun Jun 10 21:06:41 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 10 Jun 2012 18:06:41 -0700
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAOvn4qjs5ifL_HKj1qJWkmNdQ+4KUSQtgCE37QbLX3Yy_y6DcA@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
	<CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
	<CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>
	<CAHAreOryjSpoJpwwTwq6EeE7b1wwHQndoRTGD3R+0tYCF+CsWg@mail.gmail.com>
	<4FD17889.50800@creativetrax.com>
	<CAP-uhDdeY0KKSdGuH_X6rFxeKC=JH60OeUrkXqcSH-vm_bh6qQ@mail.gmail.com>
	<CAP-uhDct7nOmjoGZXPmD-UGuhQtAMsVARUn7Jvd=ENOgxCYHMQ@mail.gmail.com>
	<CAOvn4qgF-CQMvOTv5WdMDZRt+BgZ5npG9ZtFMD+7-hmvsrkAjg@mail.gmail.com>
	<CAP-uhDeas4=xNYE39KBm0JKg0fMDLuAK5ZidqdMqmnRij7Ma3Q@mail.gmail.com>
	<CAP-uhDewWs-JdREQdEVmopEyVZH9UJd7NpsPTv0W-m7=yKQfXg@mail.gmail.com>
	<CAOvn4qjAZRYwvKTSKytSgR8UtDmXFy=vguaHZmRCoHBrspJ5wQ@mail.gmail.com>
	<CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
	<CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>
	<CAOvn4qjs5ifL_HKj1qJWkmNdQ+4KUSQtgCE37QbLX3Yy_y6DcA@mail.gmail.com>
Message-ID: <CAHAreOp_+joxdeZTQ1ZEOOU4w=euqtESMTisVSDA8oRx=RdCHg@mail.gmail.com>

On Sun, Jun 10, 2012 at 6:03 PM, Thomas Kluyver <takowl at gmail.com> wrote:
> At the risk of taking this off topic, is it worth having a magic
> command to do this?
>
> I think it's a significant shortcoming of Python that the normal way
> of installing a package requires a separate shell, outside the
> interpreter. In R, the default way to install a package is the
> install.package function, so new users don't need to bother with using
> a system command line as well.

Well, it was precisely seeing Jonathan Taylor install packages in R
recently that led me to making more or less that suggestion a few days
ago, but I think several people said we should stay away from any the
package management minefield...


From carl.input at gmail.com  Sun Jun 10 21:12:12 2012
From: carl.input at gmail.com (Carl Smith)
Date: Mon, 11 Jun 2012 02:12:12 +0100
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAOvn4qjTxPynSEbztdY2KgMK-v8H+rWDDNA-kH9aDdZ_jS_BdQ@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
	<CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
	<CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>
	<CAHAreOryjSpoJpwwTwq6EeE7b1wwHQndoRTGD3R+0tYCF+CsWg@mail.gmail.com>
	<4FD17889.50800@creativetrax.com>
	<CAP-uhDdeY0KKSdGuH_X6rFxeKC=JH60OeUrkXqcSH-vm_bh6qQ@mail.gmail.com>
	<CAP-uhDct7nOmjoGZXPmD-UGuhQtAMsVARUn7Jvd=ENOgxCYHMQ@mail.gmail.com>
	<CAOvn4qgF-CQMvOTv5WdMDZRt+BgZ5npG9ZtFMD+7-hmvsrkAjg@mail.gmail.com>
	<CAP-uhDeas4=xNYE39KBm0JKg0fMDLuAK5ZidqdMqmnRij7Ma3Q@mail.gmail.com>
	<CAP-uhDewWs-JdREQdEVmopEyVZH9UJd7NpsPTv0W-m7=yKQfXg@mail.gmail.com>
	<CAOvn4qjAZRYwvKTSKytSgR8UtDmXFy=vguaHZmRCoHBrspJ5wQ@mail.gmail.com>
	<CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
	<CAOvn4qjTxPynSEbztdY2KgMK-v8H+rWDDNA-kH9aDdZ_jS_BdQ@mail.gmail.com>
Message-ID: <CAP-uhDcwV8XAReP-rS8F7YBF54gOyS4CFZtiZr+EeoyxKz96kg@mail.gmail.com>

Hi Thomas

Yeah, you do pay for storage separately, but it isn't very expensive,
it's covered by Free Tier, so I didn't do much math. Fernando had an
idea about that above, so there may be a more sophisticated approach
to take. I need to look into it more really.

In short, it's not costly for storage. It's instance hours, and
instance size that seem to be the main factors.

Thanks again

Carl


From fperez.net at gmail.com  Sun Jun 10 21:12:32 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 10 Jun 2012 18:12:32 -0700
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAP-uhDeMkQux3mxiB1mmDLhHmQND1hoJ21xB0i9wVkAQUgsiMQ@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
	<CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
	<CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>
	<CAHAreOryjSpoJpwwTwq6EeE7b1wwHQndoRTGD3R+0tYCF+CsWg@mail.gmail.com>
	<4FD17889.50800@creativetrax.com>
	<CAP-uhDdeY0KKSdGuH_X6rFxeKC=JH60OeUrkXqcSH-vm_bh6qQ@mail.gmail.com>
	<CAP-uhDct7nOmjoGZXPmD-UGuhQtAMsVARUn7Jvd=ENOgxCYHMQ@mail.gmail.com>
	<CAOvn4qgF-CQMvOTv5WdMDZRt+BgZ5npG9ZtFMD+7-hmvsrkAjg@mail.gmail.com>
	<CAP-uhDeas4=xNYE39KBm0JKg0fMDLuAK5ZidqdMqmnRij7Ma3Q@mail.gmail.com>
	<CAP-uhDewWs-JdREQdEVmopEyVZH9UJd7NpsPTv0W-m7=yKQfXg@mail.gmail.com>
	<CAOvn4qjAZRYwvKTSKytSgR8UtDmXFy=vguaHZmRCoHBrspJ5wQ@mail.gmail.com>
	<CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
	<CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>
	<CAP-uhDeMkQux3mxiB1mmDLhHmQND1hoJ21xB0i9wVkAQUgsiMQ@mail.gmail.com>
Message-ID: <CAHAreOo1ZO+N=zWjUng1WVEmV8f9biXs4QVrJdGzJifuNekxqg@mail.gmail.com>

On Sun, Jun 10, 2012 at 6:06 PM, Carl Smith <carl.input at gmail.com> wrote:
> I did try this, but it racks up a lot of requests if you leave it open
> for a while and you do pay for them if there's loads. I think you get
> 10,000 a month on the Free Tier, but that isn't that many at one every
> 10 seconds. As you suggested, it needs to just do it when there's
> something pending, then settle down when all is quiet. The problem is
> that refreshing the page refreshes the namespace, so you can't modify
> the time between each refresh easily. I'm thinking about how to solve
> that??

Ah, got it.  I didn't realize this would happen.  It should be
possilbe with javascript to have an expiring refresh, that is called
periodically but times out after  a bit.  It can also use a mild
exponential backoff scheme.  With that in place and a 1hour timeout,
you can guarantee that no more than a few dozen requests are generated
per requested instance.

> The AWS console always hogs all my RAM. It's not good. I upgraded to
> the new look. Now, it looks nice, but still runs like jam.

I have to say, from our recent experience with Azure, this is one area
where Microsoft is miles ahead of Amazon: the azure console is a
pleasure to work with, lightweight, pretty and functional.  Granted
Amazon has many more services so it's not a totally fair comparison,
but I've seen few things on the modern web worse than the horror
Amazon managed to cook up, and none from a market leader.  I thank
Justin Riley for Starcluster every time I use Amazon stuff, because I
very rarely have to deal with their disaster directly.

>> You could offer the option for the user to register an EBS disk they
>> have access to and mount it as the home directory for the notebook.
>> That way they don't have to pay for the instance being stored, only
>> for their own data. ?And it also means they can use `!pip install
>> --user` to add local packages stored in their user area and that is
>> persisted too.
>
> I have to be honest, you lost me a bit here. I'll have to do a bit of
> homework and get back to you. It sounds like an awesome idea, I'm just
> not sure how to do it. I might be back for some advice on that one.

I'm not an expert, but from what little I understand about AWS, this
should be pretty easy to do.

Best,

f


From takowl at gmail.com  Sun Jun 10 21:16:50 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 11 Jun 2012 02:16:50 +0100
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAP-uhDeMkQux3mxiB1mmDLhHmQND1hoJ21xB0i9wVkAQUgsiMQ@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
	<CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
	<CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>
	<CAHAreOryjSpoJpwwTwq6EeE7b1wwHQndoRTGD3R+0tYCF+CsWg@mail.gmail.com>
	<4FD17889.50800@creativetrax.com>
	<CAP-uhDdeY0KKSdGuH_X6rFxeKC=JH60OeUrkXqcSH-vm_bh6qQ@mail.gmail.com>
	<CAP-uhDct7nOmjoGZXPmD-UGuhQtAMsVARUn7Jvd=ENOgxCYHMQ@mail.gmail.com>
	<CAOvn4qgF-CQMvOTv5WdMDZRt+BgZ5npG9ZtFMD+7-hmvsrkAjg@mail.gmail.com>
	<CAP-uhDeas4=xNYE39KBm0JKg0fMDLuAK5ZidqdMqmnRij7Ma3Q@mail.gmail.com>
	<CAP-uhDewWs-JdREQdEVmopEyVZH9UJd7NpsPTv0W-m7=yKQfXg@mail.gmail.com>
	<CAOvn4qjAZRYwvKTSKytSgR8UtDmXFy=vguaHZmRCoHBrspJ5wQ@mail.gmail.com>
	<CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
	<CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>
	<CAP-uhDeMkQux3mxiB1mmDLhHmQND1hoJ21xB0i9wVkAQUgsiMQ@mail.gmail.com>
Message-ID: <CAOvn4qgCcWNHhM-hPT0Snvd8ez2eJb5u6Y24Msed=Btkf0Dpfg@mail.gmail.com>

On 11 June 2012 02:06, Carl Smith <carl.input at gmail.com> wrote:
> I did try this, but it racks up a lot of requests if you leave it open
> for a while and you do pay for them if there's loads. I think you get
> 10,000 a month on the Free Tier, but that isn't that many at one every
> 10 seconds. As you suggested, it needs to just do it when there's
> something pending, then settle down when all is quiet. The problem is
> that refreshing the page refreshes the namespace, so you can't modify
> the time between each refresh easily. I'm thinking about how to solve
> that??

A simple approach: if there's an instance in a transient state
(starting up), set a timeout to do a refresh. When you're not
expecting anything to change soon, don't do it automatically, but
perhaps offer the user a reset button.

Thanks for answering all my questions about AWS :-)

Thomas


From takowl at gmail.com  Sun Jun 10 21:20:39 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 11 Jun 2012 02:20:39 +0100
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAHAreOp_+joxdeZTQ1ZEOOU4w=euqtESMTisVSDA8oRx=RdCHg@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
	<CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
	<CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>
	<CAHAreOryjSpoJpwwTwq6EeE7b1wwHQndoRTGD3R+0tYCF+CsWg@mail.gmail.com>
	<4FD17889.50800@creativetrax.com>
	<CAP-uhDdeY0KKSdGuH_X6rFxeKC=JH60OeUrkXqcSH-vm_bh6qQ@mail.gmail.com>
	<CAP-uhDct7nOmjoGZXPmD-UGuhQtAMsVARUn7Jvd=ENOgxCYHMQ@mail.gmail.com>
	<CAOvn4qgF-CQMvOTv5WdMDZRt+BgZ5npG9ZtFMD+7-hmvsrkAjg@mail.gmail.com>
	<CAP-uhDeas4=xNYE39KBm0JKg0fMDLuAK5ZidqdMqmnRij7Ma3Q@mail.gmail.com>
	<CAP-uhDewWs-JdREQdEVmopEyVZH9UJd7NpsPTv0W-m7=yKQfXg@mail.gmail.com>
	<CAOvn4qjAZRYwvKTSKytSgR8UtDmXFy=vguaHZmRCoHBrspJ5wQ@mail.gmail.com>
	<CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
	<CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>
	<CAOvn4qjs5ifL_HKj1qJWkmNdQ+4KUSQtgCE37QbLX3Yy_y6DcA@mail.gmail.com>
	<CAHAreOp_+joxdeZTQ1ZEOOU4w=euqtESMTisVSDA8oRx=RdCHg@mail.gmail.com>
Message-ID: <CAOvn4qhKg9QM8u-BQvrk+PazfRBpAYtF_7Vh7-YHGYAWmHiABw@mail.gmail.com>

On 11 June 2012 02:06, Fernando Perez <fperez.net at gmail.com> wrote:
> Well, it was precisely seeing Jonathan Taylor install packages in R
> recently that led me to making more or less that suggestion a few days
> ago, but I think several people said we should stay away from any the
> package management minefield...

I agree that package management itself is something we don't want to
get tied up in, but I think making a simple interface to existing
tools is within our scope. The interface is (hopefully) the easy bit
of package management.

Thomas


From carl.input at gmail.com  Sun Jun 10 21:21:07 2012
From: carl.input at gmail.com (Carl Smith)
Date: Mon, 11 Jun 2012 02:21:07 +0100
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAHAreOo1ZO+N=zWjUng1WVEmV8f9biXs4QVrJdGzJifuNekxqg@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
	<CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
	<CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>
	<CAHAreOryjSpoJpwwTwq6EeE7b1wwHQndoRTGD3R+0tYCF+CsWg@mail.gmail.com>
	<4FD17889.50800@creativetrax.com>
	<CAP-uhDdeY0KKSdGuH_X6rFxeKC=JH60OeUrkXqcSH-vm_bh6qQ@mail.gmail.com>
	<CAP-uhDct7nOmjoGZXPmD-UGuhQtAMsVARUn7Jvd=ENOgxCYHMQ@mail.gmail.com>
	<CAOvn4qgF-CQMvOTv5WdMDZRt+BgZ5npG9ZtFMD+7-hmvsrkAjg@mail.gmail.com>
	<CAP-uhDeas4=xNYE39KBm0JKg0fMDLuAK5ZidqdMqmnRij7Ma3Q@mail.gmail.com>
	<CAP-uhDewWs-JdREQdEVmopEyVZH9UJd7NpsPTv0W-m7=yKQfXg@mail.gmail.com>
	<CAOvn4qjAZRYwvKTSKytSgR8UtDmXFy=vguaHZmRCoHBrspJ5wQ@mail.gmail.com>
	<CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
	<CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>
	<CAP-uhDeMkQux3mxiB1mmDLhHmQND1hoJ21xB0i9wVkAQUgsiMQ@mail.gmail.com>
	<CAHAreOo1ZO+N=zWjUng1WVEmV8f9biXs4QVrJdGzJifuNekxqg@mail.gmail.com>
Message-ID: <CAP-uhDeTSAy2_5d271qbsOAcYfuu4QtWB23vUm2cR0EpZN9Ypw@mail.gmail.com>

Thanks again Fernando, I'll look into it. The JavaScript thing sounds
fun to figure out, and it's not every day you have any fun with
JavaScript, so I'll have a pop at it soon.

Your sentiments towards that console are shared. As for Azure, I
haven't even seen it to be honest. I used to be a bit anti-MS in my
younger days, but I've matured and they seem to have tidied up their
act a bit, so I will have to give it a look in. I still like App
Engine. It's cool. It's just a bit limited too.

Cheers

Carl


From fperez.net at gmail.com  Sun Jun 10 21:23:18 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 10 Jun 2012 18:23:18 -0700
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAOvn4qhKg9QM8u-BQvrk+PazfRBpAYtF_7Vh7-YHGYAWmHiABw@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
	<CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
	<CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>
	<CAHAreOryjSpoJpwwTwq6EeE7b1wwHQndoRTGD3R+0tYCF+CsWg@mail.gmail.com>
	<4FD17889.50800@creativetrax.com>
	<CAP-uhDdeY0KKSdGuH_X6rFxeKC=JH60OeUrkXqcSH-vm_bh6qQ@mail.gmail.com>
	<CAP-uhDct7nOmjoGZXPmD-UGuhQtAMsVARUn7Jvd=ENOgxCYHMQ@mail.gmail.com>
	<CAOvn4qgF-CQMvOTv5WdMDZRt+BgZ5npG9ZtFMD+7-hmvsrkAjg@mail.gmail.com>
	<CAP-uhDeas4=xNYE39KBm0JKg0fMDLuAK5ZidqdMqmnRij7Ma3Q@mail.gmail.com>
	<CAP-uhDewWs-JdREQdEVmopEyVZH9UJd7NpsPTv0W-m7=yKQfXg@mail.gmail.com>
	<CAOvn4qjAZRYwvKTSKytSgR8UtDmXFy=vguaHZmRCoHBrspJ5wQ@mail.gmail.com>
	<CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
	<CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>
	<CAOvn4qjs5ifL_HKj1qJWkmNdQ+4KUSQtgCE37QbLX3Yy_y6DcA@mail.gmail.com>
	<CAHAreOp_+joxdeZTQ1ZEOOU4w=euqtESMTisVSDA8oRx=RdCHg@mail.gmail.com>
	<CAOvn4qhKg9QM8u-BQvrk+PazfRBpAYtF_7Vh7-YHGYAWmHiABw@mail.gmail.com>
Message-ID: <CAHAreOr+c3CS_NWOMPwUuCXN=-t5vPswzEvS6QUtX+sUKq=yrw@mail.gmail.com>

On Sun, Jun 10, 2012 at 6:20 PM, Thomas Kluyver <takowl at gmail.com> wrote:
> I agree that package management itself is something we don't want to
> get tied up in, but I think making a simple interface to existing
> tools is within our scope. The interface is (hopefully) the easy bit
> of package management.

I guess the question is, given that IPython already makes it very easy to type

!pip whatever

!easy_install whatever

%%bash
wget ppyi/something
tar xzf something
python setup.py install --user


I'm not 100% sure we want to write any new code that simply wraps
those things.  But perhaps we do...


From carl.input at gmail.com  Sun Jun 10 21:24:54 2012
From: carl.input at gmail.com (Carl Smith)
Date: Mon, 11 Jun 2012 02:24:54 +0100
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAOvn4qgCcWNHhM-hPT0Snvd8ez2eJb5u6Y24Msed=Btkf0Dpfg@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
	<CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
	<CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>
	<CAHAreOryjSpoJpwwTwq6EeE7b1wwHQndoRTGD3R+0tYCF+CsWg@mail.gmail.com>
	<4FD17889.50800@creativetrax.com>
	<CAP-uhDdeY0KKSdGuH_X6rFxeKC=JH60OeUrkXqcSH-vm_bh6qQ@mail.gmail.com>
	<CAP-uhDct7nOmjoGZXPmD-UGuhQtAMsVARUn7Jvd=ENOgxCYHMQ@mail.gmail.com>
	<CAOvn4qgF-CQMvOTv5WdMDZRt+BgZ5npG9ZtFMD+7-hmvsrkAjg@mail.gmail.com>
	<CAP-uhDeas4=xNYE39KBm0JKg0fMDLuAK5ZidqdMqmnRij7Ma3Q@mail.gmail.com>
	<CAP-uhDewWs-JdREQdEVmopEyVZH9UJd7NpsPTv0W-m7=yKQfXg@mail.gmail.com>
	<CAOvn4qjAZRYwvKTSKytSgR8UtDmXFy=vguaHZmRCoHBrspJ5wQ@mail.gmail.com>
	<CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
	<CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>
	<CAP-uhDeMkQux3mxiB1mmDLhHmQND1hoJ21xB0i9wVkAQUgsiMQ@mail.gmail.com>
	<CAOvn4qgCcWNHhM-hPT0Snvd8ez2eJb5u6Y24Msed=Btkf0Dpfg@mail.gmail.com>
Message-ID: <CAP-uhDe5v1CxQNfLBn+COVkXayKjWFv9_ME6HB7DM_iTfyF_zA@mail.gmail.com>

> A simple approach: if there's an instance in a transient state
> (starting up), set a timeout to do a refresh. When you're not
> expecting anything to change soon, don't do it automatically, but
> perhaps offer the user a reset button.

This seems pretty doable. I'll have a play with it later.

> Thanks for answering all my questions about AWS :-)

You're very welcome, but don't quote me on it :)

Carl


From fperez.net at gmail.com  Sun Jun 10 21:28:20 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 10 Jun 2012 18:28:20 -0700
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAP-uhDeTSAy2_5d271qbsOAcYfuu4QtWB23vUm2cR0EpZN9Ypw@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
	<CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
	<CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>
	<CAHAreOryjSpoJpwwTwq6EeE7b1wwHQndoRTGD3R+0tYCF+CsWg@mail.gmail.com>
	<4FD17889.50800@creativetrax.com>
	<CAP-uhDdeY0KKSdGuH_X6rFxeKC=JH60OeUrkXqcSH-vm_bh6qQ@mail.gmail.com>
	<CAP-uhDct7nOmjoGZXPmD-UGuhQtAMsVARUn7Jvd=ENOgxCYHMQ@mail.gmail.com>
	<CAOvn4qgF-CQMvOTv5WdMDZRt+BgZ5npG9ZtFMD+7-hmvsrkAjg@mail.gmail.com>
	<CAP-uhDeas4=xNYE39KBm0JKg0fMDLuAK5ZidqdMqmnRij7Ma3Q@mail.gmail.com>
	<CAP-uhDewWs-JdREQdEVmopEyVZH9UJd7NpsPTv0W-m7=yKQfXg@mail.gmail.com>
	<CAOvn4qjAZRYwvKTSKytSgR8UtDmXFy=vguaHZmRCoHBrspJ5wQ@mail.gmail.com>
	<CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
	<CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>
	<CAP-uhDeMkQux3mxiB1mmDLhHmQND1hoJ21xB0i9wVkAQUgsiMQ@mail.gmail.com>
	<CAHAreOo1ZO+N=zWjUng1WVEmV8f9biXs4QVrJdGzJifuNekxqg@mail.gmail.com>
	<CAP-uhDeTSAy2_5d271qbsOAcYfuu4QtWB23vUm2cR0EpZN9Ypw@mail.gmail.com>
Message-ID: <CAHAreOo3NouQ0OY+dd-wJeiiqt_UNSKP0Lo-q+=Zr-U0QoMgKA@mail.gmail.com>

On Sun, Jun 10, 2012 at 6:21 PM, Carl Smith <carl.input at gmail.com> wrote:
> Your sentiments towards that console are shared. As for Azure, I
> haven't even seen it to be honest. I used to be a bit anti-MS in my
> younger days, but I've matured and they seem to have tidied up their
> act a bit, so I will have to give it a look in.

Oh believe me, if you google around I'm on record multiple times
saying some rather colorful things about MS tools, to the point of
having had to apologize to MS users on one of the IPython lists a few
years ago :)

But the Azure process really was pretty amazing.  Keep in mind that I
did *everything* from a linux box, I spun up a remote linux box, SSH'd
in, configured the whole setup using linux tools, etc.  The azure
document:

https://www.windowsazure.com/en-us/develop/python/tutorials/ipython-notebook/

was written as Markdown and we collaborated with MS over a shared
github repo, and then the video was recorded on my linux laptop using
gtk-recordmydesktop:

http://www.youtube.com/watch?v=ljrSOkMs7DQ

If you watched the MS web conference on Thursday where they 'rebooted'
Azure to the world, you'd see a MS VP doing demos from a Mac, doing
everything at the terminal and editing files in vi, and highlighting
how with one command you could create a website that was
pre-configured as a git repo so you could push to it.  My jaw pretty
much dropped to the floor.

Cheers,

f


From carl.input at gmail.com  Sun Jun 10 21:34:18 2012
From: carl.input at gmail.com (Carl Smith)
Date: Mon, 11 Jun 2012 02:34:18 +0100
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAHAreOo3NouQ0OY+dd-wJeiiqt_UNSKP0Lo-q+=Zr-U0QoMgKA@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
	<CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
	<CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>
	<CAHAreOryjSpoJpwwTwq6EeE7b1wwHQndoRTGD3R+0tYCF+CsWg@mail.gmail.com>
	<4FD17889.50800@creativetrax.com>
	<CAP-uhDdeY0KKSdGuH_X6rFxeKC=JH60OeUrkXqcSH-vm_bh6qQ@mail.gmail.com>
	<CAP-uhDct7nOmjoGZXPmD-UGuhQtAMsVARUn7Jvd=ENOgxCYHMQ@mail.gmail.com>
	<CAOvn4qgF-CQMvOTv5WdMDZRt+BgZ5npG9ZtFMD+7-hmvsrkAjg@mail.gmail.com>
	<CAP-uhDeas4=xNYE39KBm0JKg0fMDLuAK5ZidqdMqmnRij7Ma3Q@mail.gmail.com>
	<CAP-uhDewWs-JdREQdEVmopEyVZH9UJd7NpsPTv0W-m7=yKQfXg@mail.gmail.com>
	<CAOvn4qjAZRYwvKTSKytSgR8UtDmXFy=vguaHZmRCoHBrspJ5wQ@mail.gmail.com>
	<CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
	<CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>
	<CAP-uhDeMkQux3mxiB1mmDLhHmQND1hoJ21xB0i9wVkAQUgsiMQ@mail.gmail.com>
	<CAHAreOo1ZO+N=zWjUng1WVEmV8f9biXs4QVrJdGzJifuNekxqg@mail.gmail.com>
	<CAP-uhDeTSAy2_5d271qbsOAcYfuu4QtWB23vUm2cR0EpZN9Ypw@mail.gmail.com>
	<CAHAreOo3NouQ0OY+dd-wJeiiqt_UNSKP0Lo-q+=Zr-U0QoMgKA@mail.gmail.com>
Message-ID: <CAP-uhDfmCW4jwphBdkmmJTNHDhaudEegVKWFNyn3jb+ge41NYg@mail.gmail.com>

> Oh believe me, if you google around I'm on record multiple times
> saying some rather colorful things about MS tools, to the point of
> having had to apologize to MS users on one of the IPython lists a few
> years ago :)

Tehe ~ bless 'em.

> But the Azure process really was pretty amazing. ?Keep in mind that I
> did *everything* from a linux box, I spun up a remote linux box, SSH'd
> in, configured the whole setup using linux tools, etc. ?The azure
> document:
>
> https://www.windowsazure.com/en-us/develop/python/tutorials/ipython-notebook/
>
> was written as Markdown and we collaborated with MS over a shared
> github repo, and then the video was recorded on my linux laptop using
> gtk-recordmydesktop:
>
> http://www.youtube.com/watch?v=ljrSOkMs7DQ
>
> If you watched the MS web conference on Thursday where they 'rebooted'
> Azure to the world, you'd see a MS VP doing demos from a Mac, doing
> everything at the terminal and editing files in vi, and highlighting
> how with one command you could create a website that was
> pre-configured as a git repo so you could push to it. ?My jaw pretty
> much dropped to the floor.

Wow!?! That's literally incredible. I'm gonna have a look for myself.


Thanks again people, you're awesome.


From takowl at gmail.com  Sun Jun 10 21:36:22 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 11 Jun 2012 02:36:22 +0100
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAHAreOr+c3CS_NWOMPwUuCXN=-t5vPswzEvS6QUtX+sUKq=yrw@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
	<CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
	<CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>
	<CAHAreOryjSpoJpwwTwq6EeE7b1wwHQndoRTGD3R+0tYCF+CsWg@mail.gmail.com>
	<4FD17889.50800@creativetrax.com>
	<CAP-uhDdeY0KKSdGuH_X6rFxeKC=JH60OeUrkXqcSH-vm_bh6qQ@mail.gmail.com>
	<CAP-uhDct7nOmjoGZXPmD-UGuhQtAMsVARUn7Jvd=ENOgxCYHMQ@mail.gmail.com>
	<CAOvn4qgF-CQMvOTv5WdMDZRt+BgZ5npG9ZtFMD+7-hmvsrkAjg@mail.gmail.com>
	<CAP-uhDeas4=xNYE39KBm0JKg0fMDLuAK5ZidqdMqmnRij7Ma3Q@mail.gmail.com>
	<CAP-uhDewWs-JdREQdEVmopEyVZH9UJd7NpsPTv0W-m7=yKQfXg@mail.gmail.com>
	<CAOvn4qjAZRYwvKTSKytSgR8UtDmXFy=vguaHZmRCoHBrspJ5wQ@mail.gmail.com>
	<CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
	<CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>
	<CAOvn4qjs5ifL_HKj1qJWkmNdQ+4KUSQtgCE37QbLX3Yy_y6DcA@mail.gmail.com>
	<CAHAreOp_+joxdeZTQ1ZEOOU4w=euqtESMTisVSDA8oRx=RdCHg@mail.gmail.com>
	<CAOvn4qhKg9QM8u-BQvrk+PazfRBpAYtF_7Vh7-YHGYAWmHiABw@mail.gmail.com>
	<CAHAreOr+c3CS_NWOMPwUuCXN=-t5vPswzEvS6QUtX+sUKq=yrw@mail.gmail.com>
Message-ID: <CAOvn4qgF+am8ScvsCtC7pXxxmtfEsY6EixnbHdYwsWLO+HQ31g@mail.gmail.com>

On 11 June 2012 02:23, Fernando Perez <fperez.net at gmail.com> wrote:
> I'm not 100% sure we want to write any new code that simply wraps
> those things. ?But perhaps we do...

Your mention of --user had me thinking of something that will do
standard installation if it has the necessary privileges (e.g. in a
virtualenv) and the equivalent of --user otherwise.

Also, for novice users, something tab-completable with an obvious name
(%installpkg?) would be handy.

Ideally I'd like it not to depend on anything beyond the standard
library, but I have a feeling it might require distribute. Although
'packaging' in Python 3.3 should resolve that.

Thomas


From fperez.net at gmail.com  Sun Jun 10 21:40:41 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 10 Jun 2012 18:40:41 -0700
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAOvn4qgF+am8ScvsCtC7pXxxmtfEsY6EixnbHdYwsWLO+HQ31g@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
	<CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
	<CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>
	<CAHAreOryjSpoJpwwTwq6EeE7b1wwHQndoRTGD3R+0tYCF+CsWg@mail.gmail.com>
	<4FD17889.50800@creativetrax.com>
	<CAP-uhDdeY0KKSdGuH_X6rFxeKC=JH60OeUrkXqcSH-vm_bh6qQ@mail.gmail.com>
	<CAP-uhDct7nOmjoGZXPmD-UGuhQtAMsVARUn7Jvd=ENOgxCYHMQ@mail.gmail.com>
	<CAOvn4qgF-CQMvOTv5WdMDZRt+BgZ5npG9ZtFMD+7-hmvsrkAjg@mail.gmail.com>
	<CAP-uhDeas4=xNYE39KBm0JKg0fMDLuAK5ZidqdMqmnRij7Ma3Q@mail.gmail.com>
	<CAP-uhDewWs-JdREQdEVmopEyVZH9UJd7NpsPTv0W-m7=yKQfXg@mail.gmail.com>
	<CAOvn4qjAZRYwvKTSKytSgR8UtDmXFy=vguaHZmRCoHBrspJ5wQ@mail.gmail.com>
	<CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
	<CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>
	<CAOvn4qjs5ifL_HKj1qJWkmNdQ+4KUSQtgCE37QbLX3Yy_y6DcA@mail.gmail.com>
	<CAHAreOp_+joxdeZTQ1ZEOOU4w=euqtESMTisVSDA8oRx=RdCHg@mail.gmail.com>
	<CAOvn4qhKg9QM8u-BQvrk+PazfRBpAYtF_7Vh7-YHGYAWmHiABw@mail.gmail.com>
	<CAHAreOr+c3CS_NWOMPwUuCXN=-t5vPswzEvS6QUtX+sUKq=yrw@mail.gmail.com>
	<CAOvn4qgF+am8ScvsCtC7pXxxmtfEsY6EixnbHdYwsWLO+HQ31g@mail.gmail.com>
Message-ID: <CAHAreOpqk=KuSLJdDS1n7w_DYjGhjtA_RJdxAfur_iQ2Lq_iig@mail.gmail.com>

On Sun, Jun 10, 2012 at 6:36 PM, Thomas Kluyver <takowl at gmail.com> wrote:
> Your mention of --user had me thinking of something that will do
> standard installation if it has the necessary privileges (e.g. in a
> virtualenv) and the equivalent of --user otherwise.
>
> Also, for novice users, something tab-completable with an obvious name
> (%installpkg?) would be handy.
>
> Ideally I'd like it not to depend on anything beyond the standard
> library, but I have a feeling it might require distribute. Although
> 'packaging' in Python 3.3 should resolve that.

Knock yourself out... But as I said, packaging is a minefield, and
many brave souls have already died on it.  We'd hate to lose you ;)

f


From carl.input at gmail.com  Sun Jun 10 22:11:39 2012
From: carl.input at gmail.com (Carl Smith)
Date: Mon, 11 Jun 2012 03:11:39 +0100
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAHAreOpqk=KuSLJdDS1n7w_DYjGhjtA_RJdxAfur_iQ2Lq_iig@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
	<CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
	<CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>
	<CAHAreOryjSpoJpwwTwq6EeE7b1wwHQndoRTGD3R+0tYCF+CsWg@mail.gmail.com>
	<4FD17889.50800@creativetrax.com>
	<CAP-uhDdeY0KKSdGuH_X6rFxeKC=JH60OeUrkXqcSH-vm_bh6qQ@mail.gmail.com>
	<CAP-uhDct7nOmjoGZXPmD-UGuhQtAMsVARUn7Jvd=ENOgxCYHMQ@mail.gmail.com>
	<CAOvn4qgF-CQMvOTv5WdMDZRt+BgZ5npG9ZtFMD+7-hmvsrkAjg@mail.gmail.com>
	<CAP-uhDeas4=xNYE39KBm0JKg0fMDLuAK5ZidqdMqmnRij7Ma3Q@mail.gmail.com>
	<CAP-uhDewWs-JdREQdEVmopEyVZH9UJd7NpsPTv0W-m7=yKQfXg@mail.gmail.com>
	<CAOvn4qjAZRYwvKTSKytSgR8UtDmXFy=vguaHZmRCoHBrspJ5wQ@mail.gmail.com>
	<CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
	<CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>
	<CAOvn4qjs5ifL_HKj1qJWkmNdQ+4KUSQtgCE37QbLX3Yy_y6DcA@mail.gmail.com>
	<CAHAreOp_+joxdeZTQ1ZEOOU4w=euqtESMTisVSDA8oRx=RdCHg@mail.gmail.com>
	<CAOvn4qhKg9QM8u-BQvrk+PazfRBpAYtF_7Vh7-YHGYAWmHiABw@mail.gmail.com>
	<CAHAreOr+c3CS_NWOMPwUuCXN=-t5vPswzEvS6QUtX+sUKq=yrw@mail.gmail.com>
	<CAOvn4qgF+am8ScvsCtC7pXxxmtfEsY6EixnbHdYwsWLO+HQ31g@mail.gmail.com>
	<CAHAreOpqk=KuSLJdDS1n7w_DYjGhjtA_RJdxAfur_iQ2Lq_iig@mail.gmail.com>
Message-ID: <CAP-uhDcMnCaM=47=qQFmO+LoxMACOsECEU=_HETvPmJGBcdEFQ@mail.gmail.com>

I don't know if this already exists, but in case it doesn't: I'd
suggest a simple magic for doing an upgrade from a standard IPython,
got from a distro's repo, to a recent version, with all the cool bits.
I found it difficult to get the HTML or the regular GUIs working at
first, it's a case of "easy once you know how", which can really kill
efforts to increase the user-base. After all, why would you spend a
hour learning how to set up something you've never used, if you're not
even sure it's any good? You have to see some solid media to be
convinced first.

It's easy to get a working IPython 0.12 from a new distro, else 0.11
or something, but too difficult to upgrade as a new user. If there is
an easy way, it isn't documented?

%theworks

Sorry, I'm just rambling now.

All the best.

On 11 June 2012 02:40, Fernando Perez <fperez.net at gmail.com> wrote:
> On Sun, Jun 10, 2012 at 6:36 PM, Thomas Kluyver <takowl at gmail.com> wrote:
>> Your mention of --user had me thinking of something that will do
>> standard installation if it has the necessary privileges (e.g. in a
>> virtualenv) and the equivalent of --user otherwise.
>>
>> Also, for novice users, something tab-completable with an obvious name
>> (%installpkg?) would be handy.
>>
>> Ideally I'd like it not to depend on anything beyond the standard
>> library, but I have a feeling it might require distribute. Although
>> 'packaging' in Python 3.3 should resolve that.
>
> Knock yourself out... But as I said, packaging is a minefield, and
> many brave souls have already died on it. ?We'd hate to lose you ;)
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev


From fperez.net at gmail.com  Sun Jun 10 22:18:59 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 10 Jun 2012 19:18:59 -0700
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAP-uhDcMnCaM=47=qQFmO+LoxMACOsECEU=_HETvPmJGBcdEFQ@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
	<CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
	<CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>
	<CAHAreOryjSpoJpwwTwq6EeE7b1wwHQndoRTGD3R+0tYCF+CsWg@mail.gmail.com>
	<4FD17889.50800@creativetrax.com>
	<CAP-uhDdeY0KKSdGuH_X6rFxeKC=JH60OeUrkXqcSH-vm_bh6qQ@mail.gmail.com>
	<CAP-uhDct7nOmjoGZXPmD-UGuhQtAMsVARUn7Jvd=ENOgxCYHMQ@mail.gmail.com>
	<CAOvn4qgF-CQMvOTv5WdMDZRt+BgZ5npG9ZtFMD+7-hmvsrkAjg@mail.gmail.com>
	<CAP-uhDeas4=xNYE39KBm0JKg0fMDLuAK5ZidqdMqmnRij7Ma3Q@mail.gmail.com>
	<CAP-uhDewWs-JdREQdEVmopEyVZH9UJd7NpsPTv0W-m7=yKQfXg@mail.gmail.com>
	<CAOvn4qjAZRYwvKTSKytSgR8UtDmXFy=vguaHZmRCoHBrspJ5wQ@mail.gmail.com>
	<CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
	<CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>
	<CAOvn4qjs5ifL_HKj1qJWkmNdQ+4KUSQtgCE37QbLX3Yy_y6DcA@mail.gmail.com>
	<CAHAreOp_+joxdeZTQ1ZEOOU4w=euqtESMTisVSDA8oRx=RdCHg@mail.gmail.com>
	<CAOvn4qhKg9QM8u-BQvrk+PazfRBpAYtF_7Vh7-YHGYAWmHiABw@mail.gmail.com>
	<CAHAreOr+c3CS_NWOMPwUuCXN=-t5vPswzEvS6QUtX+sUKq=yrw@mail.gmail.com>
	<CAOvn4qgF+am8ScvsCtC7pXxxmtfEsY6EixnbHdYwsWLO+HQ31g@mail.gmail.com>
	<CAHAreOpqk=KuSLJdDS1n7w_DYjGhjtA_RJdxAfur_iQ2Lq_iig@mail.gmail.com>
	<CAP-uhDcMnCaM=47=qQFmO+LoxMACOsECEU=_HETvPmJGBcdEFQ@mail.gmail.com>
Message-ID: <CAHAreOpbfAQks4H=w9spOCXpk0QDHSA7+_Gj83g2fnDhQknUFQ@mail.gmail.com>

On Sun, Jun 10, 2012 at 7:11 PM, Carl Smith <carl.input at gmail.com> wrote:
> It's easy to get a working IPython 0.12 from a new distro, else 0.11
> or something, but too difficult to upgrade as a new user. If there is
> an easy way, it isn't documented?

Unfortunately what you're asking is really "why is package management
not easy in Python".  Cf. remark about minefield above :)

I think Thomas wants to target something with a much narrower focus,
which may be OK.  Your question goes to the heart of the mess that is
package management in Python in general, and that's certainly NOT
something we're about to tackle.  Despite the fact it costs users of
all projects wasted time (and many may simply abandon python
altogether), that's something beyond our scope to fix, I'm afraid.


From carl.input at gmail.com  Sun Jun 10 22:30:40 2012
From: carl.input at gmail.com (Carl Smith)
Date: Mon, 11 Jun 2012 03:30:40 +0100
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAHAreOpbfAQks4H=w9spOCXpk0QDHSA7+_Gj83g2fnDhQknUFQ@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
	<CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
	<CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>
	<CAHAreOryjSpoJpwwTwq6EeE7b1wwHQndoRTGD3R+0tYCF+CsWg@mail.gmail.com>
	<4FD17889.50800@creativetrax.com>
	<CAP-uhDdeY0KKSdGuH_X6rFxeKC=JH60OeUrkXqcSH-vm_bh6qQ@mail.gmail.com>
	<CAP-uhDct7nOmjoGZXPmD-UGuhQtAMsVARUn7Jvd=ENOgxCYHMQ@mail.gmail.com>
	<CAOvn4qgF-CQMvOTv5WdMDZRt+BgZ5npG9ZtFMD+7-hmvsrkAjg@mail.gmail.com>
	<CAP-uhDeas4=xNYE39KBm0JKg0fMDLuAK5ZidqdMqmnRij7Ma3Q@mail.gmail.com>
	<CAP-uhDewWs-JdREQdEVmopEyVZH9UJd7NpsPTv0W-m7=yKQfXg@mail.gmail.com>
	<CAOvn4qjAZRYwvKTSKytSgR8UtDmXFy=vguaHZmRCoHBrspJ5wQ@mail.gmail.com>
	<CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
	<CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>
	<CAOvn4qjs5ifL_HKj1qJWkmNdQ+4KUSQtgCE37QbLX3Yy_y6DcA@mail.gmail.com>
	<CAHAreOp_+joxdeZTQ1ZEOOU4w=euqtESMTisVSDA8oRx=RdCHg@mail.gmail.com>
	<CAOvn4qhKg9QM8u-BQvrk+PazfRBpAYtF_7Vh7-YHGYAWmHiABw@mail.gmail.com>
	<CAHAreOr+c3CS_NWOMPwUuCXN=-t5vPswzEvS6QUtX+sUKq=yrw@mail.gmail.com>
	<CAOvn4qgF+am8ScvsCtC7pXxxmtfEsY6EixnbHdYwsWLO+HQ31g@mail.gmail.com>
	<CAHAreOpqk=KuSLJdDS1n7w_DYjGhjtA_RJdxAfur_iQ2Lq_iig@mail.gmail.com>
	<CAP-uhDcMnCaM=47=qQFmO+LoxMACOsECEU=_HETvPmJGBcdEFQ@mail.gmail.com>
	<CAHAreOpbfAQks4H=w9spOCXpk0QDHSA7+_Gj83g2fnDhQknUFQ@mail.gmail.com>
Message-ID: <CAP-uhDduigs0CTURGcbGRnXg6EqRE2568Rkh6kczMdpjMLH56A@mail.gmail.com>

> Unfortunately what you're asking is really "why is package management
> not easy in Python". ?Cf. remark about minefield above :)

Point taken. I was thinking it'd be doable on Linux, but wasn't
considering other systems, and it probably wouldn't be that doable on
Linux. Just thinking out loud really. Never mind.

It is really refreshing to see MS working with the industry now days.
I didn't realise they'd come this far. Now, we'll have to start
watching what Apple do to wreck the place instead :)


From fperez.net at gmail.com  Sun Jun 10 22:34:00 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 10 Jun 2012 19:34:00 -0700
Subject: [IPython-dev] zmq/embed_kernel failure in master
Message-ID: <CAHAreOpMFVD+hoFKwnEUb_L8HFxsk=xgdXr3gJka8hdHjPDrZg@mail.gmail.com>

Does anyone else see this in master?

IPython test group: IPython.zmq
.E....................................................................................................................................................
======================================================================
ERROR: IPython.embed_kernel() is basically functional
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/home/fperez/usr/lib/python2.7/site-packages/IPython/zmq/tests/test_embed_kernel.py",
line 113, in test_embed_kernel_basic
    msg = shell.get_msg(block=True, timeout=2)
  File "/home/fperez/usr/lib/python2.7/site-packages/IPython/zmq/blockingkernelmanager.py",
line 93, in get_msg
    return self._in_queue.get(block, timeout)
  File "/usr/lib/python2.7/Queue.py", line 176, in get
    raise Empty
Empty


f


From fperez.net at gmail.com  Sun Jun 10 22:36:53 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 10 Jun 2012 19:36:53 -0700
Subject: [IPython-dev] zmq/embed_kernel failure in master
In-Reply-To: <CAHAreOpMFVD+hoFKwnEUb_L8HFxsk=xgdXr3gJka8hdHjPDrZg@mail.gmail.com>
References: <CAHAreOpMFVD+hoFKwnEUb_L8HFxsk=xgdXr3gJka8hdHjPDrZg@mail.gmail.com>
Message-ID: <CAHAreOqYFZoaXxFgA1A7MTp=2pPsWnCX0PSxN3s3XqiS2hp=vA@mail.gmail.com>

Note: it's not deterministic, but my system was under heavy load at
the time when it did occur.  That might give Min some ideas...


From fperez.net at gmail.com  Sun Jun 10 22:39:05 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 10 Jun 2012 19:39:05 -0700
Subject: [IPython-dev] zmq/embed_kernel failure in master
In-Reply-To: <CAHAreOqYFZoaXxFgA1A7MTp=2pPsWnCX0PSxN3s3XqiS2hp=vA@mail.gmail.com>
References: <CAHAreOpMFVD+hoFKwnEUb_L8HFxsk=xgdXr3gJka8hdHjPDrZg@mail.gmail.com>
	<CAHAreOqYFZoaXxFgA1A7MTp=2pPsWnCX0PSxN3s3XqiS2hp=vA@mail.gmail.com>
Message-ID: <CAHAreOq3d9O1T+1GhLU+Ps+j31BsZLejPPZNw7fgKARfa6jyxA@mail.gmail.com>

On Sun, Jun 10, 2012 at 7:36 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> Note: it's not deterministic, but my system was under heavy load at
> the time when it did occur. ?That might give Min some ideas...

These other two also occured only under heavy load, I can't reproduce
them now that the system isn't being hit so hard:

======================================================================
FAIL: %%px --group-outputs=engine
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/fperez/usr/lib/python2.7/site-packages/IPython/parallel/tests/test_magics.py",
line 131, in test_cellpx_groupby_engine
    self.assertEquals(len(lines), len(expected), io.stdout)
AssertionError: Parallel execution on engine(s): [1, 2, 3, 4, 5, 6, 7, 8]
[stdout:1]
stdout
stdout2
[output:1]
<IPython.core.display.HTML at 0x3c65e50>
<IPython.core.display.Math at 0x3c65e50>
Out[1:1]: <IPython.core.display.Math at 0x3c65e50>
[stdout:2]
stdout
stdout2
[output:2]
<IPython.core.display.HTML at 0x3afead0>
<IPython.core.display.Math at 0x3afead0>
Out[2:1]: <IPython.core.display.Math at 0x3afead0>
[stdout:3]
stdout
stdout2
[output:3]
<IPython.core.display.HTML at 0x2dddad0>
<IPython.core.display.Math at 0x2dddad0>
Out[3:1]: <IPython.core.display.Math at 0x2dddad0>
[stdout:4]
stdout
stdout2
[output:4]
<IPython.core.display.HTML at 0x29c2210>
<IPython.core.display.Math at 0x29c2210>
Out[4:1]: <IPython.core.display.Math at 0x29c2210>
[stdout:5]
stdout
stdout2
[output:5]
<IPython.core.display.HTML at 0x2749250>
<IPython.core.display.Math at 0x2749250>
[stdout:6] stdout
[output:6]
<IPython.core.display.HTML at 0x2bf6210>
[stdout:7]
stdout
stdout2
[output:7]
<IPython.core.display.HTML at 0x30dded0>
<IPython.core.display.Math at 0x30dded0>
Out[7:1]: <IPython.core.display.Math at 0x30dded0>
[stdout:8]
stdout
stdout2
[output:8]
<IPython.core.display.HTML at 0x3b1dcd0>
<IPython.core.display.Math at 0x3b1dcd0>
Out[8:16]: <IPython.core.display.Math at 0x3b1dcd0>

    '51 != 56' = '%s != %s' % (safe_repr(51), safe_repr(56))
    u'Parallel execution on engine(s): [1, 2, 3, 4, 5, 6, 7,
8]\n[stdout:1] \nstdout\nstdout2\n[output:1]\n<IPython.core.display.HTML
at 0x3c65e50>\n<IPython.core.display.Math at 0x3c65e50>\nOut[1:1]:
<IPython.core.display.Math at 0x3c65e50>\n[stdout:2]
\nstdout\nstdout2\n[output:2]\n<IPython.core.display.HTML at
0x3afead0>\n<IPython.core.display.Math at 0x3afead0>\nOut[2:1]:
<IPython.core.display.Math at 0x3afead0>\n[stdout:3]
\nstdout\nstdout2\n[output:3]\n<IPython.core.display.HTML at
0x2dddad0>\n<IPython.core.display.Math at 0x2dddad0>\nOut[3:1]:
<IPython.core.display.Math at 0x2dddad0>\n[stdout:4]
\nstdout\nstdout2\n[output:4]\n<IPython.core.display.HTML at
0x29c2210>\n<IPython.core.display.Math at 0x29c2210>\nOut[4:1]:
<IPython.core.display.Math at 0x29c2210>\n[stdout:5]
\nstdout\nstdout2\n[output:5]\n<IPython.core.display.HTML at
0x2749250>\n<IPython.core.display.Math at 0x2749250>\n[stdout:6]
stdout\n[output:6]\n<IPython.core.display.HTML at
0x2bf6210>\n[stdout:7]
\nstdout\nstdout2\n[output:7]\n<IPython.core.display.HTML at
0x30dded0>\n<IPython.core.display.Math at 0x30dded0>\nOut[7:1]:
<IPython.core.display.Math at 0x30dded0>\n[stdout:8]
\nstdout\nstdout2\n[output:8]\n<IPython.core.display.HTML at
0x3b1dcd0>\n<IPython.core.display.Math at 0x3b1dcd0>\nOut[8:16]:
<IPython.core.display.Math at 0x3b1dcd0>\n' =
self._formatMessage(u'Parallel execution on engine(s): [1, 2, 3, 4, 5,
6, 7, 8]\n[stdout:1]
\nstdout\nstdout2\n[output:1]\n<IPython.core.display.HTML at
0x3c65e50>\n<IPython.core.display.Math at 0x3c65e50>\nOut[1:1]:
<IPython.core.display.Math at 0x3c65e50>\n[stdout:2]
\nstdout\nstdout2\n[output:2]\n<IPython.core.display.HTML at
0x3afead0>\n<IPython.core.display.Math at 0x3afead0>\nOut[2:1]:
<IPython.core.display.Math at 0x3afead0>\n[stdout:3]
\nstdout\nstdout2\n[output:3]\n<IPython.core.display.HTML at
0x2dddad0>\n<IPython.core.display.Math at 0x2dddad0>\nOut[3:1]:
<IPython.core.display.Math at 0x2dddad0>\n[stdout:4]
\nstdout\nstdout2\n[output:4]\n<IPython.core.display.HTML at
0x29c2210>\n<IPython.core.display.Math at 0x29c2210>\nOut[4:1]:
<IPython.core.display.Math at 0x29c2210>\n[stdout:5]
\nstdout\nstdout2\n[output:5]\n<IPython.core.display.HTML at
0x2749250>\n<IPython.core.display.Math at 0x2749250>\n[stdout:6]
stdout\n[output:6]\n<IPython.core.display.HTML at
0x2bf6210>\n[stdout:7]
\nstdout\nstdout2\n[output:7]\n<IPython.core.display.HTML at
0x30dded0>\n<IPython.core.display.Math at 0x30dded0>\nOut[7:1]:
<IPython.core.display.Math at 0x30dded0>\n[stdout:8]
\nstdout\nstdout2\n[output:8]\n<IPython.core.display.HTML at
0x3b1dcd0>\n<IPython.core.display.Math at 0x3b1dcd0>\nOut[8:16]:
<IPython.core.display.Math at 0x3b1dcd0>\n', '51 != 56')
>>  raise self.failureException(u'Parallel execution on engine(s): [1, 2, 3, 4, 5, 6, 7, 8]\n[stdout:1] \nstdout\nstdout2\n[output:1]\n<IPython.core.display.HTML at 0x3c65e50>\n<IPython.core.display.Math at 0x3c65e50>\nOut[1:1]: <IPython.core.display.Math at 0x3c65e50>\n[stdout:2] \nstdout\nstdout2\n[output:2]\n<IPython.core.display.HTML at 0x3afead0>\n<IPython.core.display.Math at 0x3afead0>\nOut[2:1]: <IPython.core.display.Math at 0x3afead0>\n[stdout:3] \nstdout\nstdout2\n[output:3]\n<IPython.core.display.HTML at 0x2dddad0>\n<IPython.core.display.Math at 0x2dddad0>\nOut[3:1]: <IPython.core.display.Math at 0x2dddad0>\n[stdout:4] \nstdout\nstdout2\n[output:4]\n<IPython.core.display.HTML at 0x29c2210>\n<IPython.core.display.Math at 0x29c2210>\nOut[4:1]: <IPython.core.display.Math at 0x29c2210>\n[stdout:5] \nstdout\nstdout2\n[output:5]\n<IPython.core.display.HTML at 0x2749250>\n<IPython.core.display.Math at 0x2749250>\n[stdout:6] stdout\n[output:6]\n<IPython.core.display.HTML at 0x2bf6210>\n[stdout:7] \nstdout\nstdout2\n[output:7]\n<IPython.core.display.HTML at 0x30dded0>\n<IPython.core.display.Math at 0x30dded0>\nOut[7:1]: <IPython.core.display.Math at 0x30dded0>\n[stdout:8] \nstdout\nstdout2\n[output:8]\n<IPython.core.display.HTML at 0x3b1dcd0>\n<IPython.core.display.Math at 0x3b1dcd0>\nOut[8:16]: <IPython.core.display.Math at 0x3b1dcd0>\n')


======================================================================
FAIL: %%px --group-outputs=order
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/fperez/usr/lib/python2.7/site-packages/IPython/parallel/tests/test_magics.py",
line 173, in test_cellpx_groupby_order
    self.assertEquals(len(lines), len(expected), io.stdout)
AssertionError: Parallel execution on engine(s): [1, 2, 3, 4, 5, 6, 7, 8]

    '0 != 64' = '%s != %s' % (safe_repr(0), safe_repr(64))
    'Parallel execution on engine(s): [1, 2, 3, 4, 5, 6, 7, 8]\n' =
self._formatMessage('Parallel execution on engine(s): [1, 2, 3, 4, 5,
6, 7, 8]\n', '0 != 64')
>>  raise self.failureException('Parallel execution on engine(s): [1, 2, 3, 4, 5, 6, 7, 8]\n')


From benjaminrk at gmail.com  Sun Jun 10 22:57:57 2012
From: benjaminrk at gmail.com (MinRK)
Date: Sun, 10 Jun 2012 19:57:57 -0700
Subject: [IPython-dev] zmq/embed_kernel failure in master
In-Reply-To: <CAHAreOq3d9O1T+1GhLU+Ps+j31BsZLejPPZNw7fgKARfa6jyxA@mail.gmail.com>
References: <CAHAreOpMFVD+hoFKwnEUb_L8HFxsk=xgdXr3gJka8hdHjPDrZg@mail.gmail.com>
	<CAHAreOqYFZoaXxFgA1A7MTp=2pPsWnCX0PSxN3s3XqiS2hp=vA@mail.gmail.com>
	<CAHAreOq3d9O1T+1GhLU+Ps+j31BsZLejPPZNw7fgKARfa6jyxA@mail.gmail.com>
Message-ID: <CAHNn8BW0kSgaqX16JdP0mEjhaUBe7YPSokW_eE65x2q0y3LSwg@mail.gmail.com>

I don't see any way around issues like this for multiprocess tests.  I've
added tons of shenanigans to try to prevent it, but it simply cannot be
perfect.  There are sleeps everywhere, and some smarter waits, but if you
want the parallel test suite to finish in under 20 minutes, then never
having non-deterministic failures is not achievable.

My answer: don't run the test suite while under heavy load.

-MinRK

On Sun, Jun 10, 2012 at 7:39 PM, Fernando Perez <fperez.net at gmail.com>wrote:

> On Sun, Jun 10, 2012 at 7:36 PM, Fernando Perez <fperez.net at gmail.com>
> wrote:
> > Note: it's not deterministic, but my system was under heavy load at
> > the time when it did occur.  That might give Min some ideas...
>
> These other two also occured only under heavy load, I can't reproduce
> them now that the system isn't being hit so hard:
>
> ======================================================================
> FAIL: %%px --group-outputs=engine
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File
> "/home/fperez/usr/lib/python2.7/site-packages/IPython/parallel/tests/test_magics.py",
> line 131, in test_cellpx_groupby_engine
>    self.assertEquals(len(lines), len(expected), io.stdout)
> AssertionError: Parallel execution on engine(s): [1, 2, 3, 4, 5, 6, 7, 8]
> [stdout:1]
> stdout
> stdout2
> [output:1]
> <IPython.core.display.HTML at 0x3c65e50>
> <IPython.core.display.Math at 0x3c65e50>
> Out[1:1]: <IPython.core.display.Math at 0x3c65e50>
> [stdout:2]
> stdout
> stdout2
> [output:2]
> <IPython.core.display.HTML at 0x3afead0>
> <IPython.core.display.Math at 0x3afead0>
> Out[2:1]: <IPython.core.display.Math at 0x3afead0>
> [stdout:3]
> stdout
> stdout2
> [output:3]
> <IPython.core.display.HTML at 0x2dddad0>
> <IPython.core.display.Math at 0x2dddad0>
> Out[3:1]: <IPython.core.display.Math at 0x2dddad0>
> [stdout:4]
> stdout
> stdout2
> [output:4]
> <IPython.core.display.HTML at 0x29c2210>
> <IPython.core.display.Math at 0x29c2210>
> Out[4:1]: <IPython.core.display.Math at 0x29c2210>
> [stdout:5]
> stdout
> stdout2
> [output:5]
> <IPython.core.display.HTML at 0x2749250>
> <IPython.core.display.Math at 0x2749250>
> [stdout:6] stdout
> [output:6]
> <IPython.core.display.HTML at 0x2bf6210>
> [stdout:7]
> stdout
> stdout2
> [output:7]
> <IPython.core.display.HTML at 0x30dded0>
> <IPython.core.display.Math at 0x30dded0>
> Out[7:1]: <IPython.core.display.Math at 0x30dded0>
> [stdout:8]
> stdout
> stdout2
> [output:8]
> <IPython.core.display.HTML at 0x3b1dcd0>
> <IPython.core.display.Math at 0x3b1dcd0>
> Out[8:16]: <IPython.core.display.Math at 0x3b1dcd0>
>
>    '51 != 56' = '%s != %s' % (safe_repr(51), safe_repr(56))
>    u'Parallel execution on engine(s): [1, 2, 3, 4, 5, 6, 7,
> 8]\n[stdout:1] \nstdout\nstdout2\n[output:1]\n<IPython.core.display.HTML
> at 0x3c65e50>\n<IPython.core.display.Math at 0x3c65e50>\nOut[1:1]:
> <IPython.core.display.Math at 0x3c65e50>\n[stdout:2]
> \nstdout\nstdout2\n[output:2]\n<IPython.core.display.HTML at
> 0x3afead0>\n<IPython.core.display.Math at 0x3afead0>\nOut[2:1]:
> <IPython.core.display.Math at 0x3afead0>\n[stdout:3]
> \nstdout\nstdout2\n[output:3]\n<IPython.core.display.HTML at
> 0x2dddad0>\n<IPython.core.display.Math at 0x2dddad0>\nOut[3:1]:
> <IPython.core.display.Math at 0x2dddad0>\n[stdout:4]
> \nstdout\nstdout2\n[output:4]\n<IPython.core.display.HTML at
> 0x29c2210>\n<IPython.core.display.Math at 0x29c2210>\nOut[4:1]:
> <IPython.core.display.Math at 0x29c2210>\n[stdout:5]
> \nstdout\nstdout2\n[output:5]\n<IPython.core.display.HTML at
> 0x2749250>\n<IPython.core.display.Math at 0x2749250>\n[stdout:6]
> stdout\n[output:6]\n<IPython.core.display.HTML at
> 0x2bf6210>\n[stdout:7]
> \nstdout\nstdout2\n[output:7]\n<IPython.core.display.HTML at
> 0x30dded0>\n<IPython.core.display.Math at 0x30dded0>\nOut[7:1]:
> <IPython.core.display.Math at 0x30dded0>\n[stdout:8]
> \nstdout\nstdout2\n[output:8]\n<IPython.core.display.HTML at
> 0x3b1dcd0>\n<IPython.core.display.Math at 0x3b1dcd0>\nOut[8:16]:
> <IPython.core.display.Math at 0x3b1dcd0>\n' =
> self._formatMessage(u'Parallel execution on engine(s): [1, 2, 3, 4, 5,
> 6, 7, 8]\n[stdout:1]
> \nstdout\nstdout2\n[output:1]\n<IPython.core.display.HTML at
> 0x3c65e50>\n<IPython.core.display.Math at 0x3c65e50>\nOut[1:1]:
> <IPython.core.display.Math at 0x3c65e50>\n[stdout:2]
> \nstdout\nstdout2\n[output:2]\n<IPython.core.display.HTML at
> 0x3afead0>\n<IPython.core.display.Math at 0x3afead0>\nOut[2:1]:
> <IPython.core.display.Math at 0x3afead0>\n[stdout:3]
> \nstdout\nstdout2\n[output:3]\n<IPython.core.display.HTML at
> 0x2dddad0>\n<IPython.core.display.Math at 0x2dddad0>\nOut[3:1]:
> <IPython.core.display.Math at 0x2dddad0>\n[stdout:4]
> \nstdout\nstdout2\n[output:4]\n<IPython.core.display.HTML at
> 0x29c2210>\n<IPython.core.display.Math at 0x29c2210>\nOut[4:1]:
> <IPython.core.display.Math at 0x29c2210>\n[stdout:5]
> \nstdout\nstdout2\n[output:5]\n<IPython.core.display.HTML at
> 0x2749250>\n<IPython.core.display.Math at 0x2749250>\n[stdout:6]
> stdout\n[output:6]\n<IPython.core.display.HTML at
> 0x2bf6210>\n[stdout:7]
> \nstdout\nstdout2\n[output:7]\n<IPython.core.display.HTML at
> 0x30dded0>\n<IPython.core.display.Math at 0x30dded0>\nOut[7:1]:
> <IPython.core.display.Math at 0x30dded0>\n[stdout:8]
> \nstdout\nstdout2\n[output:8]\n<IPython.core.display.HTML at
> 0x3b1dcd0>\n<IPython.core.display.Math at 0x3b1dcd0>\nOut[8:16]:
> <IPython.core.display.Math at 0x3b1dcd0>\n', '51 != 56')
> >>  raise self.failureException(u'Parallel execution on engine(s): [1, 2,
> 3, 4, 5, 6, 7, 8]\n[stdout:1]
> \nstdout\nstdout2\n[output:1]\n<IPython.core.display.HTML at
> 0x3c65e50>\n<IPython.core.display.Math at 0x3c65e50>\nOut[1:1]:
> <IPython.core.display.Math at 0x3c65e50>\n[stdout:2]
> \nstdout\nstdout2\n[output:2]\n<IPython.core.display.HTML at
> 0x3afead0>\n<IPython.core.display.Math at 0x3afead0>\nOut[2:1]:
> <IPython.core.display.Math at 0x3afead0>\n[stdout:3]
> \nstdout\nstdout2\n[output:3]\n<IPython.core.display.HTML at
> 0x2dddad0>\n<IPython.core.display.Math at 0x2dddad0>\nOut[3:1]:
> <IPython.core.display.Math at 0x2dddad0>\n[stdout:4]
> \nstdout\nstdout2\n[output:4]\n<IPython.core.display.HTML at
> 0x29c2210>\n<IPython.core.display.Math at 0x29c2210>\nOut[4:1]:
> <IPython.core.display.Math at 0x29c2210>\n[stdout:5]
> \nstdout\nstdout2\n[output:5]\n<IPython.core.display.HTML at
> 0x2749250>\n<IPython.core.display.Math at 0x2749250>\n[stdout:6]
> stdout\n[output:6]\n<IPython.core.display.HTML at 0x2bf6210>\n[stdout:7]
> \nstdout\nstdout2\n[output:7]\n<IPython.core.display.HTML at
> 0x30dded0>\n<IPython.core.display.Math at 0x30dded0>\nOut[7:1]:
> <IPython.core.display.Math at 0x30dded0>\n[stdout:8]
> \nstdout\nstdout2\n[output:8]\n<IPython.core.display.HTML at
> 0x3b1dcd0>\n<IPython.core.display.Math at 0x3b1dcd0>\nOut[8:16]:
> <IPython.core.display.Math at 0x3b1dcd0>\n')
>
>
> ======================================================================
> FAIL: %%px --group-outputs=order
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File
> "/home/fperez/usr/lib/python2.7/site-packages/IPython/parallel/tests/test_magics.py",
> line 173, in test_cellpx_groupby_order
>    self.assertEquals(len(lines), len(expected), io.stdout)
> AssertionError: Parallel execution on engine(s): [1, 2, 3, 4, 5, 6, 7, 8]
>
>    '0 != 64' = '%s != %s' % (safe_repr(0), safe_repr(64))
>    'Parallel execution on engine(s): [1, 2, 3, 4, 5, 6, 7, 8]\n' =
> self._formatMessage('Parallel execution on engine(s): [1, 2, 3, 4, 5,
> 6, 7, 8]\n', '0 != 64')
> >>  raise self.failureException('Parallel execution on engine(s): [1, 2,
> 3, 4, 5, 6, 7, 8]\n')
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120610/da28e349/attachment.html>

From fperez.net at gmail.com  Sun Jun 10 23:00:29 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 10 Jun 2012 20:00:29 -0700
Subject: [IPython-dev] zmq/embed_kernel failure in master
In-Reply-To: <CAHNn8BW0kSgaqX16JdP0mEjhaUBe7YPSokW_eE65x2q0y3LSwg@mail.gmail.com>
References: <CAHAreOpMFVD+hoFKwnEUb_L8HFxsk=xgdXr3gJka8hdHjPDrZg@mail.gmail.com>
	<CAHAreOqYFZoaXxFgA1A7MTp=2pPsWnCX0PSxN3s3XqiS2hp=vA@mail.gmail.com>
	<CAHAreOq3d9O1T+1GhLU+Ps+j31BsZLejPPZNw7fgKARfa6jyxA@mail.gmail.com>
	<CAHNn8BW0kSgaqX16JdP0mEjhaUBe7YPSokW_eE65x2q0y3LSwg@mail.gmail.com>
Message-ID: <CAHAreOpedjbq5ApnxYb2Rz2t8M0X_m2FLcDkDiVHkJDrXA9=SQ@mail.gmail.com>

On Sun, Jun 10, 2012 at 7:57 PM, MinRK <benjaminrk at gmail.com> wrote:
> I don't see any way around issues like this for multiprocess tests. ?I've
> added tons of shenanigans to try to prevent it, but it simply cannot be
> perfect. ?There are sleeps everywhere, and some smarter waits, but if you
> want the parallel test suite to finish in under 20 minutes, then never
> having non-deterministic failures is not achievable.
>
> My answer: don't run the test suite while under heavy load.

Fair enough, no worries.  Thanks!


From benjaminrk at gmail.com  Sun Jun 10 23:07:34 2012
From: benjaminrk at gmail.com (MinRK)
Date: Sun, 10 Jun 2012 20:07:34 -0700
Subject: [IPython-dev] zmq/embed_kernel failure in master
In-Reply-To: <CAHAreOpedjbq5ApnxYb2Rz2t8M0X_m2FLcDkDiVHkJDrXA9=SQ@mail.gmail.com>
References: <CAHAreOpMFVD+hoFKwnEUb_L8HFxsk=xgdXr3gJka8hdHjPDrZg@mail.gmail.com>
	<CAHAreOqYFZoaXxFgA1A7MTp=2pPsWnCX0PSxN3s3XqiS2hp=vA@mail.gmail.com>
	<CAHAreOq3d9O1T+1GhLU+Ps+j31BsZLejPPZNw7fgKARfa6jyxA@mail.gmail.com>
	<CAHNn8BW0kSgaqX16JdP0mEjhaUBe7YPSokW_eE65x2q0y3LSwg@mail.gmail.com>
	<CAHAreOpedjbq5ApnxYb2Rz2t8M0X_m2FLcDkDiVHkJDrXA9=SQ@mail.gmail.com>
Message-ID: <CAHNn8BXCSW6XoNR-Ph-rsO+QZYv+fF9LDeoXJPL4eNBM4J9g-w@mail.gmail.com>

On Sun, Jun 10, 2012 at 8:00 PM, Fernando Perez <fperez.net at gmail.com>wrote:

> On Sun, Jun 10, 2012 at 7:57 PM, MinRK <benjaminrk at gmail.com> wrote:
> > I don't see any way around issues like this for multiprocess tests.  I've
> > added tons of shenanigans to try to prevent it, but it simply cannot be
> > perfect.  There are sleeps everywhere, and some smarter waits, but if you
> > want the parallel test suite to finish in under 20 minutes, then never
> > having non-deterministic failures is not achievable.
> >
> > My answer: don't run the test suite while under heavy load.
>
> Fair enough, no worries.  Thanks!
>

If there are ones of these that are more reliable than others, do keep
letting me know, and I can try to relax the ones causing more consistent
trouble.

The problem is that it's rarely a simple timeout that's too short, and
things usually need to be moved around in weird ways to ensure a certain
order of events.


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

From fperez.net at gmail.com  Sun Jun 10 23:12:18 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 10 Jun 2012 20:12:18 -0700
Subject: [IPython-dev] zmq/embed_kernel failure in master
In-Reply-To: <CAHNn8BXCSW6XoNR-Ph-rsO+QZYv+fF9LDeoXJPL4eNBM4J9g-w@mail.gmail.com>
References: <CAHAreOpMFVD+hoFKwnEUb_L8HFxsk=xgdXr3gJka8hdHjPDrZg@mail.gmail.com>
	<CAHAreOqYFZoaXxFgA1A7MTp=2pPsWnCX0PSxN3s3XqiS2hp=vA@mail.gmail.com>
	<CAHAreOq3d9O1T+1GhLU+Ps+j31BsZLejPPZNw7fgKARfa6jyxA@mail.gmail.com>
	<CAHNn8BW0kSgaqX16JdP0mEjhaUBe7YPSokW_eE65x2q0y3LSwg@mail.gmail.com>
	<CAHAreOpedjbq5ApnxYb2Rz2t8M0X_m2FLcDkDiVHkJDrXA9=SQ@mail.gmail.com>
	<CAHNn8BXCSW6XoNR-Ph-rsO+QZYv+fF9LDeoXJPL4eNBM4J9g-w@mail.gmail.com>
Message-ID: <CAHAreOqochzuPjzPGpr2t_T1tR17xJz3KYtUtahf3Yt7F9d3vg@mail.gmail.com>

On Sun, Jun 10, 2012 at 8:07 PM, MinRK <benjaminrk at gmail.com> wrote:
> If there are ones of these that are more reliable than others, do keep
> letting me know, and I can try to relax the ones causing more consistent
> trouble.
>
> The problem is that it's rarely a simple timeout that's too short, and
> things usually need to be moved around in weird ways to ensure a certain
> order of events.

Will do, I'll post them as they appear in case you see something worth
taking action on, but not necessarily expecting that to be the case.

Thanks!

f


From fperez.net at gmail.com  Mon Jun 11 02:54:00 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 10 Jun 2012 23:54:00 -0700
Subject: [IPython-dev] Let's get 0.13 released...
Message-ID: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>

Hi all,

I think it's high time we start getting things in gear for a 0.13
release.  We've had a *massive* amount of new work since 0.12, to give
you a quick idea:

(master)dreamweaver[ipython]> git diff rel-0.12 | wc -l
76699
(master)dreamweaver[ipython]> git log --oneline rel-0.12.. | wc -l
1413

1400 commits and a 77000 line diff is bigger than many open source
projects, so it's probably OK for us to release now :)


In order to do that, we basically need to:

1. Decide what new work is *necessary* before the release is ready.
Right now we have zero issues marked as blockers for this milestone:

https://github.com/ipython/ipython/issues?labels=prio-blocker&milestone=7&page=1&state=open

but 12 marked as high priority:

https://github.com/ipython/ipython/issues?labels=prio-high&milestone=7&page=1&state=open

and there may be other things for which we haven't made a proper issue.

2.  Merging PRs in flight.  We have 21 open ones, probably not all of
these need to go in for 0.13.

3. Try to organize the team to do the necessary release work.


Let's look at these questions now.

1. New code that needs to be written.  I'd like to ask everyone to
bring here for discussion any issues (make one on GH if it doesn't
exist) that they feel are *critical* for 0.13.

Personally, I would *love* to see #1905 done (expose worksheets UI) as
I think it would be a major, massive improvement to the notebook and
don't think it's too hard.  I will also try to fix #1904, which is a
serious usability problem right now for some magics and shouldn't be
hard to do (but if anyone beats me with a fix, even better!).

So let's try to decide what from this list really needs to be promoted
to release blocker, and the rest will simply have to get reassigned to
the 0.14 milestone.

2. PRs in flight.  I've tried to tag the ones I think are either
almost done or quite important and viable to finish with a small
amount of effort, with the 0.13 milestone:

https://github.com/ipython/ipython/pull/1825: long output in notebook
https://github.com/ipython/ipython/pull/1849: Octave magics
https://github.com/ipython/ipython/pull/1858: window jumping fix in notebook
https://github.com/ipython/ipython/pull/1865: X11/svg support for R magic
https://github.com/ipython/ipython/pull/1891: Virtualenv cell magic
https://github.com/ipython/ipython/pull/1893: parallel magics improvements

It's only 6 PRs, so with a bit of collective effort, we should be able
to finish them up soon.

Of the remaining 15, if you think one of them is *really* important to
have in before 0.13, please bring it up here for discussion and we'll
see if it's realistic.


3. In the past I've tended to be the bottleneck on that, as I try to
do too much.  It would be great if we can split the load of the work
running up to the release process amongst more people, so that pulling
the trigger at the end is easier.

The main issue is doing lots of test runs, which I think thanks to
Thomas' extraordinary work on testing and CI will be less of an issue
this time, and writing up solid release notes, checking documentation,
etc.

I'd like to know if we have some hands on deck that can volunteer to
help start writing *now* a nice set of release notes/what's new
document.  That work can be done and merged quickly but it's time
consuming, and we have so many new features that having a good
document here, with some nice screenshots and other visual flair,
would be great.  I think I spent easily a day or two writing the one
for 0.12, and I simply don't have that time right now.  But if people
start helping with that, and we merge quickly even partial
contributions to it, we should be able to have a good set of release
notes without anyone having to sacrifice two straight days on it.

So I'd propose that all in the core team who are willing to help out
with this simply make their changes and merge them straight into
master, so others can pull quickly and contribute their own parts.
And let's have a show of hands of *who* might be willing to help here,
so those people can coordinate a bit the work (at least letting each
other know they are going to do it, to avoid a true clash of major
work overlapping by accident).


In terms of a timeline, I'd like to cut a first beta very, very soon,
as in two or three days.  This would start making it clear that we're
serious about the release, and it would give us something we can
mention also on the user list to ask for testers, in particular on
windows.  After the beta, we'll spend a week or so landing PRs for a
first RC, and then we'll have a good idea of how much more work will
be needed for the actual release.

I think the code is in pretty good shape, and this is doable soon, but
I'd like to ask that everyone focus your energy for a short time on
code review, fixing whatever issues we deem critical, and helping out
with the release process.  It's awesome to keep getting new code every
day, but at some point we do need to shift gears into making a release
happen, so that users who don't follow git master like most of us here
do, can also benefit from all these great improvements.

So please pitch in, and let's get this done quickly.  The faster we
make a release, the sooner we can all get back to coding new fun
stuff!

Thanks,

f


From fperez.net at gmail.com  Mon Jun 11 03:28:19 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Jun 2012 00:28:19 -0700
Subject: [IPython-dev] Persistent test_pr problems on python3
Message-ID: <CAHAreOo0TZctDWqB5OSY2AeBcaoJ9UtJ4xa6k8_=-SugvMwmZg@mail.gmail.com>

Hey folks (mostly Thomas, I'm afraid),

On two different ubuntu 12.04 boxes (both 64 bit), I keep getting the
python3 test phase silently stuck.  No activity, no output, just this:

Installed /home/fperez/.ipy_pr_tests/venv-python3.2/lib/python3.2/site-packages/ipython-0.13.dev-py3.2.egg
Processing dependencies for ipython==0.13.dev
Finished processing dependencies for ipython==0.13.dev

Running tests, this typically takes a few minutes...

Eventually I Control-C it and get this:

^CTraceback (most recent call last):
  File "./test_pr.py", line 259, in <module>
    test_pr(args.number, post_results=args.publish)
  File "./test_pr.py", line 228, in test_pr
    passed, log = run_tests(venv)
  File "./test_pr.py", line 124, in run_tests
    return True, check_output([iptest], stderr=STDOUT).decode('utf-8')
  File "/usr/lib/python2.7/subprocess.py", line 538, in check_output
    output, unused_err = process.communicate()
  File "/usr/lib/python2.7/subprocess.py", line 746, in communicate
    stdout = _eintr_retry_call(self.stdout.read)
  File "/usr/lib/python2.7/subprocess.py", line 478, in _eintr_retry_call
    return func(*args)
KeyboardInterrupt


Is test_pr working OK for others on python3?  It used to be fine for
me too up until recently, I have no idea what may have changed.

But test_pr has really been a boon to the process, so I'd like to have
it working as well as possible: it really helps us ensure the quality
of the merged code (multiple problems have already been caught
preemptively by it before they hit master).

Cheers,

f


From benjaminrk at gmail.com  Mon Jun 11 03:53:22 2012
From: benjaminrk at gmail.com (MinRK)
Date: Mon, 11 Jun 2012 00:53:22 -0700
Subject: [IPython-dev] Persistent test_pr problems on python3
In-Reply-To: <CAHAreOo0TZctDWqB5OSY2AeBcaoJ9UtJ4xa6k8_=-SugvMwmZg@mail.gmail.com>
References: <CAHAreOo0TZctDWqB5OSY2AeBcaoJ9UtJ4xa6k8_=-SugvMwmZg@mail.gmail.com>
Message-ID: <CAHNn8BXxdA4+9JTAhPrCKX6tCmrX3Aik7PF3pE8n7HkyiUAONw@mail.gmail.com>

It's been a few days since I ran it, but in testing PRs this evening, I am
seeing this as well.  Seems to be stuck testing core.

On Mon, Jun 11, 2012 at 12:28 AM, Fernando Perez <fperez.net at gmail.com>wrote:

> Hey folks (mostly Thomas, I'm afraid),
>
> On two different ubuntu 12.04 boxes (both 64 bit), I keep getting the
> python3 test phase silently stuck.  No activity, no output, just this:
>
> Installed
> /home/fperez/.ipy_pr_tests/venv-python3.2/lib/python3.2/site-packages/ipython-0.13.dev-py3.2.egg
> Processing dependencies for ipython==0.13.dev
> Finished processing dependencies for ipython==0.13.dev
>
> Running tests, this typically takes a few minutes...
>
> Eventually I Control-C it and get this:
>
> ^CTraceback (most recent call last):
>  File "./test_pr.py", line 259, in <module>
>    test_pr(args.number, post_results=args.publish)
>  File "./test_pr.py", line 228, in test_pr
>    passed, log = run_tests(venv)
>  File "./test_pr.py", line 124, in run_tests
>    return True, check_output([iptest], stderr=STDOUT).decode('utf-8')
>  File "/usr/lib/python2.7/subprocess.py", line 538, in check_output
>    output, unused_err = process.communicate()
>  File "/usr/lib/python2.7/subprocess.py", line 746, in communicate
>    stdout = _eintr_retry_call(self.stdout.read)
>  File "/usr/lib/python2.7/subprocess.py", line 478, in _eintr_retry_call
>    return func(*args)
> KeyboardInterrupt
>
>
> Is test_pr working OK for others on python3?  It used to be fine for
> me too up until recently, I have no idea what may have changed.
>
> But test_pr has really been a boon to the process, so I'd like to have
> it working as well as possible: it really helps us ensure the quality
> of the merged code (multiple problems have already been caught
> preemptively by it before they hit master).
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120611/e6d4e4bf/attachment.html>

From fperez.net at gmail.com  Mon Jun 11 03:53:25 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Jun 2012 00:53:25 -0700
Subject: [IPython-dev] Let's get 0.13 released...
In-Reply-To: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
References: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
Message-ID: <CAHAreOpR4cx2wH0wYAigwOYhkwkrCVJkux3wGPeUhVBmgbwhXQ@mail.gmail.com>

On Sun, Jun 10, 2012 at 11:54 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> I will also try to fix #1904, which is a
> serious usability problem right now for some magics and shouldn't be
> hard to do (but if anyone beats me with a fix, even better!).

Scratch that, Min jumped on it and we just went through the PR to completion:

https://github.com/ipython/ipython/pull/1906

So that's one less one to worry about now.

f


From fperez.net at gmail.com  Mon Jun 11 03:54:45 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Jun 2012 00:54:45 -0700
Subject: [IPython-dev] Persistent test_pr problems on python3
In-Reply-To: <CAHNn8BXxdA4+9JTAhPrCKX6tCmrX3Aik7PF3pE8n7HkyiUAONw@mail.gmail.com>
References: <CAHAreOo0TZctDWqB5OSY2AeBcaoJ9UtJ4xa6k8_=-SugvMwmZg@mail.gmail.com>
	<CAHNn8BXxdA4+9JTAhPrCKX6tCmrX3Aik7PF3pE8n7HkyiUAONw@mail.gmail.com>
Message-ID: <CAHAreOquUM0pxWFqUzViO8OToUumzM-FXkaJvL2jhyuJuOxN6w@mail.gmail.com>

On Mon, Jun 11, 2012 at 12:53 AM, MinRK <benjaminrk at gmail.com> wrote:
> It's been a few days since I ran it, but in testing PRs this evening, I am
> seeing this as well. ?Seems to be stuck testing core.

Do you see it on your mac or on your linux boxes only?


From benjaminrk at gmail.com  Mon Jun 11 03:59:31 2012
From: benjaminrk at gmail.com (MinRK)
Date: Mon, 11 Jun 2012 00:59:31 -0700
Subject: [IPython-dev] Persistent test_pr problems on python3
In-Reply-To: <CAHAreOquUM0pxWFqUzViO8OToUumzM-FXkaJvL2jhyuJuOxN6w@mail.gmail.com>
References: <CAHAreOo0TZctDWqB5OSY2AeBcaoJ9UtJ4xa6k8_=-SugvMwmZg@mail.gmail.com>
	<CAHNn8BXxdA4+9JTAhPrCKX6tCmrX3Aik7PF3pE8n7HkyiUAONw@mail.gmail.com>
	<CAHAreOquUM0pxWFqUzViO8OToUumzM-FXkaJvL2jhyuJuOxN6w@mail.gmail.com>
Message-ID: <CAHNn8BVUZQYkj6OOAc6qVSc0Qm8jCVEm=xaH-EbsMmB=gkT6gg@mail.gmail.com>

On Mon, Jun 11, 2012 at 12:54 AM, Fernando Perez <fperez.net at gmail.com>wrote:

> On Mon, Jun 11, 2012 at 12:53 AM, MinRK <benjaminrk at gmail.com> wrote:
> > It's been a few days since I ran it, but in testing PRs this evening, I
> am
> > seeing this as well.  Seems to be stuck testing core.
>
> Do you see it on your mac or on your linux boxes only?
>

mac as well, debugging now...


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

From fperez.net at gmail.com  Mon Jun 11 04:00:17 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Jun 2012 01:00:17 -0700
Subject: [IPython-dev] Persistent test_pr problems on python3
In-Reply-To: <CAHNn8BVUZQYkj6OOAc6qVSc0Qm8jCVEm=xaH-EbsMmB=gkT6gg@mail.gmail.com>
References: <CAHAreOo0TZctDWqB5OSY2AeBcaoJ9UtJ4xa6k8_=-SugvMwmZg@mail.gmail.com>
	<CAHNn8BXxdA4+9JTAhPrCKX6tCmrX3Aik7PF3pE8n7HkyiUAONw@mail.gmail.com>
	<CAHAreOquUM0pxWFqUzViO8OToUumzM-FXkaJvL2jhyuJuOxN6w@mail.gmail.com>
	<CAHNn8BVUZQYkj6OOAc6qVSc0Qm8jCVEm=xaH-EbsMmB=gkT6gg@mail.gmail.com>
Message-ID: <CAHAreOqfMuoGzvVNhaycnH7NHfEszf0iECy7AN--mGUW5GLDmA@mail.gmail.com>

On Mon, Jun 11, 2012 at 12:59 AM, MinRK <benjaminrk at gmail.com> wrote:
> mac as well, debugging now...

OK, great.  At least it's not just me... Thanks.


From benjaminrk at gmail.com  Mon Jun 11 04:00:56 2012
From: benjaminrk at gmail.com (MinRK)
Date: Mon, 11 Jun 2012 01:00:56 -0700
Subject: [IPython-dev] Persistent test_pr problems on python3
In-Reply-To: <CAHNn8BVUZQYkj6OOAc6qVSc0Qm8jCVEm=xaH-EbsMmB=gkT6gg@mail.gmail.com>
References: <CAHAreOo0TZctDWqB5OSY2AeBcaoJ9UtJ4xa6k8_=-SugvMwmZg@mail.gmail.com>
	<CAHNn8BXxdA4+9JTAhPrCKX6tCmrX3Aik7PF3pE8n7HkyiUAONw@mail.gmail.com>
	<CAHAreOquUM0pxWFqUzViO8OToUumzM-FXkaJvL2jhyuJuOxN6w@mail.gmail.com>
	<CAHNn8BVUZQYkj6OOAc6qVSc0Qm8jCVEm=xaH-EbsMmB=gkT6gg@mail.gmail.com>
Message-ID: <CAHNn8BVVOvcb=9G46KLQqmfSt9t=vSMOOJHZ_tk9knCx=gyRfQ@mail.gmail.com>

On Mon, Jun 11, 2012 at 12:59 AM, MinRK <benjaminrk at gmail.com> wrote:

>
>
> On Mon, Jun 11, 2012 at 12:54 AM, Fernando Perez <fperez.net at gmail.com>wrote:
>
>> On Mon, Jun 11, 2012 at 12:53 AM, MinRK <benjaminrk at gmail.com> wrote:
>> > It's been a few days since I ran it, but in testing PRs this evening, I
>> am
>> > seeing this as well.  Seems to be stuck testing core.
>>
>> Do you see it on your mac or on your linux boxes only?
>>
>
> mac as well, debugging now...
>

Ha - we should have been using test_pr!  It's the script-magics tests.
 Should be an easy py3compat fix.


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

From fperez.net at gmail.com  Mon Jun 11 04:02:17 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Jun 2012 01:02:17 -0700
Subject: [IPython-dev] Persistent test_pr problems on python3
In-Reply-To: <CAHNn8BVVOvcb=9G46KLQqmfSt9t=vSMOOJHZ_tk9knCx=gyRfQ@mail.gmail.com>
References: <CAHAreOo0TZctDWqB5OSY2AeBcaoJ9UtJ4xa6k8_=-SugvMwmZg@mail.gmail.com>
	<CAHNn8BXxdA4+9JTAhPrCKX6tCmrX3Aik7PF3pE8n7HkyiUAONw@mail.gmail.com>
	<CAHAreOquUM0pxWFqUzViO8OToUumzM-FXkaJvL2jhyuJuOxN6w@mail.gmail.com>
	<CAHNn8BVUZQYkj6OOAc6qVSc0Qm8jCVEm=xaH-EbsMmB=gkT6gg@mail.gmail.com>
	<CAHNn8BVVOvcb=9G46KLQqmfSt9t=vSMOOJHZ_tk9knCx=gyRfQ@mail.gmail.com>
Message-ID: <CAHAreOqZ5hTRNYCdNR7i2N7uXQONmRztSQN+ftfqDAgsEyd6FQ@mail.gmail.com>

On Mon, Jun 11, 2012 at 1:00 AM, MinRK <benjaminrk at gmail.com> wrote:
> Ha - we should have been using test_pr! ?It's the script-magics tests.
> ?Should be an easy py3compat fix.

Glad to hear that.  That's an arrow I want in our quiver as we get
closer to actual release time...


From fperez.net at gmail.com  Mon Jun 11 04:36:44 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Jun 2012 01:36:44 -0700
Subject: [IPython-dev] Persistent test_pr problems on python3
In-Reply-To: <CAHAreOqZ5hTRNYCdNR7i2N7uXQONmRztSQN+ftfqDAgsEyd6FQ@mail.gmail.com>
References: <CAHAreOo0TZctDWqB5OSY2AeBcaoJ9UtJ4xa6k8_=-SugvMwmZg@mail.gmail.com>
	<CAHNn8BXxdA4+9JTAhPrCKX6tCmrX3Aik7PF3pE8n7HkyiUAONw@mail.gmail.com>
	<CAHAreOquUM0pxWFqUzViO8OToUumzM-FXkaJvL2jhyuJuOxN6w@mail.gmail.com>
	<CAHNn8BVUZQYkj6OOAc6qVSc0Qm8jCVEm=xaH-EbsMmB=gkT6gg@mail.gmail.com>
	<CAHNn8BVVOvcb=9G46KLQqmfSt9t=vSMOOJHZ_tk9knCx=gyRfQ@mail.gmail.com>
	<CAHAreOqZ5hTRNYCdNR7i2N7uXQONmRztSQN+ftfqDAgsEyd6FQ@mail.gmail.com>
Message-ID: <CAHAreOp1HtEsbCV1XRVrV3mQE4kZDk-v4y=cQKS_7wTajoaeAQ@mail.gmail.com>

On Mon, Jun 11, 2012 at 1:02 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> Glad to hear that. ?That's an arrow I want in our quiver as we get
> closer to actual release time...

Just so Thomas doesn't have to worry, fixed and merged in #1907.


From takowl at gmail.com  Mon Jun 11 06:13:45 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 11 Jun 2012 11:13:45 +0100
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAP-uhDcMnCaM=47=qQFmO+LoxMACOsECEU=_HETvPmJGBcdEFQ@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
	<CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
	<CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>
	<CAHAreOryjSpoJpwwTwq6EeE7b1wwHQndoRTGD3R+0tYCF+CsWg@mail.gmail.com>
	<4FD17889.50800@creativetrax.com>
	<CAP-uhDdeY0KKSdGuH_X6rFxeKC=JH60OeUrkXqcSH-vm_bh6qQ@mail.gmail.com>
	<CAP-uhDct7nOmjoGZXPmD-UGuhQtAMsVARUn7Jvd=ENOgxCYHMQ@mail.gmail.com>
	<CAOvn4qgF-CQMvOTv5WdMDZRt+BgZ5npG9ZtFMD+7-hmvsrkAjg@mail.gmail.com>
	<CAP-uhDeas4=xNYE39KBm0JKg0fMDLuAK5ZidqdMqmnRij7Ma3Q@mail.gmail.com>
	<CAP-uhDewWs-JdREQdEVmopEyVZH9UJd7NpsPTv0W-m7=yKQfXg@mail.gmail.com>
	<CAOvn4qjAZRYwvKTSKytSgR8UtDmXFy=vguaHZmRCoHBrspJ5wQ@mail.gmail.com>
	<CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
	<CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>
	<CAOvn4qjs5ifL_HKj1qJWkmNdQ+4KUSQtgCE37QbLX3Yy_y6DcA@mail.gmail.com>
	<CAHAreOp_+joxdeZTQ1ZEOOU4w=euqtESMTisVSDA8oRx=RdCHg@mail.gmail.com>
	<CAOvn4qhKg9QM8u-BQvrk+PazfRBpAYtF_7Vh7-YHGYAWmHiABw@mail.gmail.com>
	<CAHAreOr+c3CS_NWOMPwUuCXN=-t5vPswzEvS6QUtX+sUKq=yrw@mail.gmail.com>
	<CAOvn4qgF+am8ScvsCtC7pXxxmtfEsY6EixnbHdYwsWLO+HQ31g@mail.gmail.com>
	<CAHAreOpqk=KuSLJdDS1n7w_DYjGhjtA_RJdxAfur_iQ2Lq_iig@mail.gmail.com>
	<CAP-uhDcMnCaM=47=qQFmO+LoxMACOsECEU=_HETvPmJGBcdEFQ@mail.gmail.com>
Message-ID: <CAOvn4qhT5uW-VTJrQzikvh=QV5A+mb8Htt37rk-Vu0iwepwOSA@mail.gmail.com>

On 11 June 2012 03:11, Carl Smith <carl.input at gmail.com> wrote:
> I'd
> suggest a simple magic for doing an upgrade from a standard IPython,
> got from a distro's repo, to a recent version, with all the cool bits.

I think the best way to do this is to push towards a new release, and
then get that into distro repositories. At present a lot of people are
running from master, but hopefully once things settle down the latest
stable release will have enough goodies for most users.

In the meantime, Julian's ipython-dev PPA is a simple way to go from
the stable version to a recent development version - just add the PPA
& let the normal update procedure do it.

Another obstacle is that it often takes a while before releases get to
a distro's regular users. But Ubuntu in particular is making
encouraging noises about speeding that process up where upstreams have
a good QA setup, which I think we do.

Thanks,
Thomas


From bussonniermatthias at gmail.com  Mon Jun 11 06:43:22 2012
From: bussonniermatthias at gmail.com (Matthias BUSSONNIER)
Date: Mon, 11 Jun 2012 12:43:22 +0200
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAP-uhDeMkQux3mxiB1mmDLhHmQND1hoJ21xB0i9wVkAQUgsiMQ@mail.gmail.com>
References: <CAP-uhDcgbvm6_JxCA2-QqAVwst5wE8fY6PR0bdFRSejyH9k3tA@mail.gmail.com>
	<CAOvn4qgsNattYwoG5WVPLebXFRgNsMGFbzQEqLRvG3Phn4ezkw@mail.gmail.com>
	<CAHAreOoLLqQtOSkHuG1mMY6kR_8-tUsTrn2aMCBNROv9f_SkZQ@mail.gmail.com>
	<CAP-uhDd=sF-UxMuHTRn4MVxBXu_hs-+0ige_+Kyrqb_s5cKZWg@mail.gmail.com>
	<CAHAreOryjSpoJpwwTwq6EeE7b1wwHQndoRTGD3R+0tYCF+CsWg@mail.gmail.com>
	<4FD17889.50800@creativetrax.com>
	<CAP-uhDdeY0KKSdGuH_X6rFxeKC=JH60OeUrkXqcSH-vm_bh6qQ@mail.gmail.com>
	<CAP-uhDct7nOmjoGZXPmD-UGuhQtAMsVARUn7Jvd=ENOgxCYHMQ@mail.gmail.com>
	<CAOvn4qgF-CQMvOTv5WdMDZRt+BgZ5npG9ZtFMD+7-hmvsrkAjg@mail.gmail.com>
	<CAP-uhDeas4=xNYE39KBm0JKg0fMDLuAK5ZidqdMqmnRij7Ma3Q@mail.gmail.com>
	<CAP-uhDewWs-JdREQdEVmopEyVZH9UJd7NpsPTv0W-m7=yKQfXg@mail.gmail.com>
	<CAOvn4qjAZRYwvKTSKytSgR8UtDmXFy=vguaHZmRCoHBrspJ5wQ@mail.gmail.com>
	<CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
	<CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>
	<CAP-uhDeMkQux3mxiB1mmDLhHmQND1hoJ21xB0i9wVkAQUgsiMQ@mail.gmail.com>
Message-ID: <1E296D68-1883-4F96-8819-6F584DA4B68C@gmail.com>

> 
> I did try this, but it racks up a lot of requests if you leave it open
> for a while and you do pay for them if there's loads. I think you get
> 10,000 a month on the Free Tier, but that isn't that many at one every
> 10 seconds. As you suggested, it needs to just do it when there's
> something pending, then settle down when all is quiet. The problem is
> that refreshing the page refreshes the namespace, so you can't modify
> the time between each refresh easily. I'm thinking about how to solve
> that??
To add to what have been said on the list later, 
the current notebook dashboard have a 10s timer that pauses when the page lost focus, and resume when the page get it back.
So you don't have to worry about user leaving the page open.
-- 
Matthias



From takowl at gmail.com  Mon Jun 11 06:41:35 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 11 Jun 2012 11:41:35 +0100
Subject: [IPython-dev] Let's get 0.13 released...
In-Reply-To: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
References: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
Message-ID: <CAOvn4qg=Y6GG4=jCG=ohhGTmRXwiigoDh6B28QwK8RPuOOZ2vA@mail.gmail.com>

On 11 June 2012 07:54, Fernando Perez <fperez.net at gmail.com> wrote:
> I think it's high time we start getting things in gear for a 0.13
> release. ?We've had a *massive* amount of new work since 0.12, to give
> you a quick idea:

Excellent, I'm looking forward to delivering the improvements to more
users. I'll do my best to pitch in with reviewing PRs and updating
docs.

Thanks,
Thomas


From takowl at gmail.com  Mon Jun 11 06:58:54 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 11 Jun 2012 11:58:54 +0100
Subject: [IPython-dev] Persistent test_pr problems on python3
In-Reply-To: <CAHAreOp1HtEsbCV1XRVrV3mQE4kZDk-v4y=cQKS_7wTajoaeAQ@mail.gmail.com>
References: <CAHAreOo0TZctDWqB5OSY2AeBcaoJ9UtJ4xa6k8_=-SugvMwmZg@mail.gmail.com>
	<CAHNn8BXxdA4+9JTAhPrCKX6tCmrX3Aik7PF3pE8n7HkyiUAONw@mail.gmail.com>
	<CAHAreOquUM0pxWFqUzViO8OToUumzM-FXkaJvL2jhyuJuOxN6w@mail.gmail.com>
	<CAHNn8BVUZQYkj6OOAc6qVSc0Qm8jCVEm=xaH-EbsMmB=gkT6gg@mail.gmail.com>
	<CAHNn8BVVOvcb=9G46KLQqmfSt9t=vSMOOJHZ_tk9knCx=gyRfQ@mail.gmail.com>
	<CAHAreOqZ5hTRNYCdNR7i2N7uXQONmRztSQN+ftfqDAgsEyd6FQ@mail.gmail.com>
	<CAHAreOp1HtEsbCV1XRVrV3mQE4kZDk-v4y=cQKS_7wTajoaeAQ@mail.gmail.com>
Message-ID: <CAOvn4qjrQG5xHe9oYUvk+AE2xR_om8yKW6jWycVWqk8-XSnOsw@mail.gmail.com>

On 11 June 2012 09:36, Fernando Perez <fperez.net at gmail.com> wrote:
> Just so Thomas doesn't have to worry, fixed and merged in #1907.

I love it when time zones mean my work is done before I even see it ;-)

Thanks,
Thomas


From nicolas.chauvat at logilab.fr  Mon Jun 11 08:11:45 2012
From: nicolas.chauvat at logilab.fr (Nicolas Chauvat)
Date: Mon, 11 Jun 2012 14:11:45 +0200
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAOvn4qhT5uW-VTJrQzikvh=QV5A+mb8Htt37rk-Vu0iwepwOSA@mail.gmail.com>
References: <CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
	<CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>
	<CAOvn4qjs5ifL_HKj1qJWkmNdQ+4KUSQtgCE37QbLX3Yy_y6DcA@mail.gmail.com>
	<CAHAreOp_+joxdeZTQ1ZEOOU4w=euqtESMTisVSDA8oRx=RdCHg@mail.gmail.com>
	<CAOvn4qhKg9QM8u-BQvrk+PazfRBpAYtF_7Vh7-YHGYAWmHiABw@mail.gmail.com>
	<CAHAreOr+c3CS_NWOMPwUuCXN=-t5vPswzEvS6QUtX+sUKq=yrw@mail.gmail.com>
	<CAOvn4qgF+am8ScvsCtC7pXxxmtfEsY6EixnbHdYwsWLO+HQ31g@mail.gmail.com>
	<CAHAreOpqk=KuSLJdDS1n7w_DYjGhjtA_RJdxAfur_iQ2Lq_iig@mail.gmail.com>
	<CAP-uhDcMnCaM=47=qQFmO+LoxMACOsECEU=_HETvPmJGBcdEFQ@mail.gmail.com>
	<CAOvn4qhT5uW-VTJrQzikvh=QV5A+mb8Htt37rk-Vu0iwepwOSA@mail.gmail.com>
Message-ID: <20120611121145.GA3470@volans.logilab.fr>

On Mon, Jun 11, 2012 at 11:13:45AM +0100, Thomas Kluyver wrote:
> > suggest a simple magic for doing an upgrade from a standard IPython,
> > got from a distro's repo, to a recent version, with all the cool bits.
> 
> I think the best way to do this is to push towards a new release, and
> then get that into distro repositories.

+1

Software Development and System/Distribution Development have a lot in
common, but are two different jobs. Please let us not make the mistake
to believe that everything is done once the software is written and
tested.

If you have time in your hands, take a look at
http://www.debian.org/doc/debian-policy/ and you will be surprised by
the amount of work and tools that is needed in order to get "a system
that just works for end-users and installs/upgrades packages when
asked to". Once you understand this, it becomes clear that unless you
want to limit yourself to a very restricted scope, there is no cheap
way to get it done.

Note: the keyword is "system" as in "an assemblage or combination of
things or parts forming a complex or unitary whole" meaning "lots of
(inter)dependencies" meaning "lots of difficult problems".

HTH,

-- 
Nicolas Chauvat

logilab.fr - services en informatique scientifique et gestion de connaissances  


From takowl at gmail.com  Mon Jun 11 09:28:24 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 11 Jun 2012 14:28:24 +0100
Subject: [IPython-dev] Let's get 0.13 released...
In-Reply-To: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
References: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
Message-ID: <CAOvn4qijZNGTsxdbKzPuykYo_W0V6-4daGfEpVdFKFOR14M4kQ@mail.gmail.com>

On 11 June 2012 07:54, Fernando Perez <fperez.net at gmail.com> wrote:
> I'd like to know if we have some hands on deck that can volunteer to
> help start writing *now* a nice set of release notes/what's new
> document.

I've made a start on this with a description of cell magics. Other key
things that we need described are:

- The multitude of UI changes to the notebook. Brian, I think you're
best placed to write this?
- The new completer in the Qt console. Matthias, if you could write
something for this & make a small screenshot, I'm happy to check the
English.

I have a notoriously bad memory, so everyone who's added features
since 0.12, please go and check the what's new document. If you don't
see your feature, change it directly, make a pull request, or remind
us about it on this list.

https://github.com/ipython/ipython/blob/master/docs/source/whatsnew/development.txt

Thanks,
Thomas


From carl.input at gmail.com  Mon Jun 11 09:43:54 2012
From: carl.input at gmail.com (Carl Smith)
Date: Mon, 11 Jun 2012 14:43:54 +0100
Subject: [IPython-dev] Let's get 0.13 released...
In-Reply-To: <CAOvn4qijZNGTsxdbKzPuykYo_W0V6-4daGfEpVdFKFOR14M4kQ@mail.gmail.com>
References: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
	<CAOvn4qijZNGTsxdbKzPuykYo_W0V6-4daGfEpVdFKFOR14M4kQ@mail.gmail.com>
Message-ID: <CAP-uhDfK-9tuJqB-X61P0sbur_sfLuKwdvt6p8eV1et_f1H8AQ@mail.gmail.com>

I love to see stdin in the notebook. I don't know how important it is for
most users, but I'm promoting the notebook as an alternative to ssh, which
it isn't at the moment.

Thanks all
On Jun 11, 2012 2:28 PM, "Thomas Kluyver" <takowl at gmail.com> wrote:

> On 11 June 2012 07:54, Fernando Perez <fperez.net at gmail.com> wrote:
> > I'd like to know if we have some hands on deck that can volunteer to
> > help start writing *now* a nice set of release notes/what's new
> > document.
>
> I've made a start on this with a description of cell magics. Other key
> things that we need described are:
>
> - The multitude of UI changes to the notebook. Brian, I think you're
> best placed to write this?
> - The new completer in the Qt console. Matthias, if you could write
> something for this & make a small screenshot, I'm happy to check the
> English.
>
> I have a notoriously bad memory, so everyone who's added features
> since 0.12, please go and check the what's new document. If you don't
> see your feature, change it directly, make a pull request, or remind
> us about it on this list.
>
>
> https://github.com/ipython/ipython/blob/master/docs/source/whatsnew/development.txt
>
> Thanks,
> Thomas
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120611/879a0eea/attachment.html>

From takowl at gmail.com  Mon Jun 11 10:38:56 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 11 Jun 2012 15:38:56 +0100
Subject: [IPython-dev] Let's get 0.13 released...
In-Reply-To: <CAP-uhDfK-9tuJqB-X61P0sbur_sfLuKwdvt6p8eV1et_f1H8AQ@mail.gmail.com>
References: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
	<CAOvn4qijZNGTsxdbKzPuykYo_W0V6-4daGfEpVdFKFOR14M4kQ@mail.gmail.com>
	<CAP-uhDfK-9tuJqB-X61P0sbur_sfLuKwdvt6p8eV1et_f1H8AQ@mail.gmail.com>
Message-ID: <CAOvn4qgb0tOb9f_wMb=rJddjwoU-K-jxJBE-Agk7KiNqajkWmA@mail.gmail.com>

On 11 June 2012 14:43, Carl Smith <carl.input at gmail.com> wrote:
> I love to see stdin in the notebook. I don't know how important it is for
> most users, but I'm promoting the notebook as an alternative to ssh, which
> it isn't at the moment.

This would be great to see, but I don't think we have a clear idea how
to make it happen yet. Our architecture for Python code that calls
input() involves the kernel requesting input from the frontend. AFAIK,
that won't work for external processes, so we'd need some sort of
'forward all input' mechanism.

I can't see this being implemented in time for 0.13, but you're
welcome to start experimenting with what we could do.

In the meantime, if you want a web interface that removes the need for
SSH, I know pythonanywhere uses Shell In A Box:
http://code.google.com/p/shellinabox/

Thanks,
Thomas


From carl.input at gmail.com  Mon Jun 11 10:52:22 2012
From: carl.input at gmail.com (Carl Smith)
Date: Mon, 11 Jun 2012 15:52:22 +0100
Subject: [IPython-dev] Let's get 0.13 released...
In-Reply-To: <CAOvn4qgb0tOb9f_wMb=rJddjwoU-K-jxJBE-Agk7KiNqajkWmA@mail.gmail.com>
References: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
	<CAOvn4qijZNGTsxdbKzPuykYo_W0V6-4daGfEpVdFKFOR14M4kQ@mail.gmail.com>
	<CAP-uhDfK-9tuJqB-X61P0sbur_sfLuKwdvt6p8eV1et_f1H8AQ@mail.gmail.com>
	<CAOvn4qgb0tOb9f_wMb=rJddjwoU-K-jxJBE-Agk7KiNqajkWmA@mail.gmail.com>
Message-ID: <CAP-uhDdSwS2ZVKCsRyQ9RJrhijGUO1Nce0x7uwA6qp5baYpYmg@mail.gmail.com>

I think Fernando has something in mind for getting stdin in the notebook,
but it isn't straight forwards. I don't know much about IPython's
internals, but I guess there's no better time to start learning.

That shell server looks interesting. Nice one for pointing us to it. It's a
handy resource. PA do some really cool stuff with it.
On Jun 11, 2012 3:39 PM, "Thomas Kluyver" <takowl at gmail.com> wrote:

> On 11 June 2012 14:43, Carl Smith <carl.input at gmail.com> wrote:
> > I love to see stdin in the notebook. I don't know how important it is for
> > most users, but I'm promoting the notebook as an alternative to ssh,
> which
> > it isn't at the moment.
>
> This would be great to see, but I don't think we have a clear idea how
> to make it happen yet. Our architecture for Python code that calls
> input() involves the kernel requesting input from the frontend. AFAIK,
> that won't work for external processes, so we'd need some sort of
> 'forward all input' mechanism.
>
> I can't see this being implemented in time for 0.13, but you're
> welcome to start experimenting with what we could do.
>
> In the meantime, if you want a web interface that removes the need for
> SSH, I know pythonanywhere uses Shell In A Box:
> http://code.google.com/p/shellinabox/
>
> Thanks,
> Thomas
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120611/df65a79a/attachment.html>

From jtaylor.debian at googlemail.com  Mon Jun 11 12:40:12 2012
From: jtaylor.debian at googlemail.com (Julian Taylor)
Date: Mon, 11 Jun 2012 18:40:12 +0200
Subject: [IPython-dev] Let's get 0.13 released...
In-Reply-To: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
References: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
Message-ID: <4FD61F6C.3080709@googlemail.com>

On 06/11/2012 08:54 AM, Fernando Perez wrote:
> Hi all,
> 
> I think it's high time we start getting things in gear for a 0.13
> release.

This is great.
I was fearing the current feature creep would delay 0.13 forever.

I'd still like the minified javascript situation cleaned up a bit.
I'm ok with accepting the same state as 0.12.1, unminify the stuff that
not in Debian which was only prettify.js last release. I'll remove the
rest myself.
Any new stuff that has been added since then?

Does the notebook still need development snapshots of jquery & co or
will it work with official releases (debian has 1.7.2, -ui 1.8.20)?

Unfortunately unless you release really soon or the Debian release team
delays the freeze (currently 15. July) 0.13 is going to be too late for
Debian wheezy.
But everything should be in place for a smooth backport.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120611/93daf2d8/attachment.sig>

From takowl at gmail.com  Mon Jun 11 12:58:24 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 11 Jun 2012 17:58:24 +0100
Subject: [IPython-dev] Let's get 0.13 released...
In-Reply-To: <4FD61F6C.3080709@googlemail.com>
References: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
	<4FD61F6C.3080709@googlemail.com>
Message-ID: <CAOvn4qh_taY1sG_4NZUeueV7Pid8NeD3nq5-B8anqAC2b53v0g@mail.gmail.com>

On 11 June 2012 17:40, Julian Taylor <jtaylor.debian at googlemail.com> wrote:
> Unfortunately unless you release really soon or the Debian release team
> delays the freeze (currently 15. July) 0.13 is going to be too late for
> Debian wheezy.

That reminds me, target dates for Ubuntu:
- 5 July for automatic sync from Debian. After this, someone will have
to manually update the package.
- 23 August for feature freeze.

Thomas


From jorgen.stenarson at kroywen.se  Mon Jun 11 13:29:55 2012
From: jorgen.stenarson at kroywen.se (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Mon, 11 Jun 2012 19:29:55 +0200
Subject: [IPython-dev] Warnings in testsuite
Message-ID: <4FD62B13.3040001@kroywen.se>

Hi,

with a current master 83b6d25 I get these warnings in all testgroups (on 
64-bit windows 7 python2.7):

WARNING: Excluding nonexistent file: 'IPython\\\\quarantine'
WARNING: Excluding nonexistent file: 'IPython\\\\deathrow'
WARNING: Excluding nonexistent file: 
'IPython\\\\testing\\\\plugin\\\\test_exampleip'
WARNING: Excluding nonexistent file: 'IPython\\\\scripts\\\\irunner'

Is this something anyone else sees?


From takowl at gmail.com  Mon Jun 11 13:58:29 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 11 Jun 2012 18:58:29 +0100
Subject: [IPython-dev] Warnings in testsuite
In-Reply-To: <4FD62B13.3040001@kroywen.se>
References: <4FD62B13.3040001@kroywen.se>
Message-ID: <CAOvn4qimz7LwYF2RvxieOJN-XGrTdzzH56pByKOBkN+g1FULdw@mail.gmail.com>

I see the first two routinely, because I test against installed
versions, and the quarantine & deathrow subpackages don't get
installed. I guess the other bits are also not installed on Windows.

Thomas

On 11 June 2012 18:29, J?rgen Stenarson <jorgen.stenarson at kroywen.se> wrote:
> Hi,
>
> with a current master 83b6d25 I get these warnings in all testgroups (on
> 64-bit windows 7 python2.7):
>
> WARNING: Excluding nonexistent file: 'IPython\\\\quarantine'
> WARNING: Excluding nonexistent file: 'IPython\\\\deathrow'
> WARNING: Excluding nonexistent file:
> 'IPython\\\\testing\\\\plugin\\\\test_exampleip'
> WARNING: Excluding nonexistent file: 'IPython\\\\scripts\\\\irunner'
>
> Is this something anyone else sees?
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev


From fperez.net at gmail.com  Mon Jun 11 15:39:21 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Jun 2012 12:39:21 -0700
Subject: [IPython-dev] Help with python3 Windows testing for PR #1715
Message-ID: <CAHAreOpE0gk4nDJgO58aGxsb9K0c-001+GQTt3oU3xeG9n=Hrw@mail.gmail.com>

Hi all,

Jorgen and Thomas have been doing some great, grungy work on #1715 to
fix a bunch of obscure and unpleasant unicode issues, but we're short
on hands that can test a Python 3 Windows installation.  Anyone on the
list who could give us a hand with that?

https://github.com/ipython/ipython/pull/1715

Note that we are currently trying to get persistent access for the
core team to good Windows testing infrastructure, but that may still
take a few weeks to sort out, so for now manual help from the list
would be greatly appreciated.

Best,

f


From fperez.net at gmail.com  Mon Jun 11 15:53:49 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Jun 2012 12:53:49 -0700
Subject: [IPython-dev] Persistent test_pr problems on python3
In-Reply-To: <CAOvn4qjrQG5xHe9oYUvk+AE2xR_om8yKW6jWycVWqk8-XSnOsw@mail.gmail.com>
References: <CAHAreOo0TZctDWqB5OSY2AeBcaoJ9UtJ4xa6k8_=-SugvMwmZg@mail.gmail.com>
	<CAHNn8BXxdA4+9JTAhPrCKX6tCmrX3Aik7PF3pE8n7HkyiUAONw@mail.gmail.com>
	<CAHAreOquUM0pxWFqUzViO8OToUumzM-FXkaJvL2jhyuJuOxN6w@mail.gmail.com>
	<CAHNn8BVUZQYkj6OOAc6qVSc0Qm8jCVEm=xaH-EbsMmB=gkT6gg@mail.gmail.com>
	<CAHNn8BVVOvcb=9G46KLQqmfSt9t=vSMOOJHZ_tk9knCx=gyRfQ@mail.gmail.com>
	<CAHAreOqZ5hTRNYCdNR7i2N7uXQONmRztSQN+ftfqDAgsEyd6FQ@mail.gmail.com>
	<CAHAreOp1HtEsbCV1XRVrV3mQE4kZDk-v4y=cQKS_7wTajoaeAQ@mail.gmail.com>
	<CAOvn4qjrQG5xHe9oYUvk+AE2xR_om8yKW6jWycVWqk8-XSnOsw@mail.gmail.com>
Message-ID: <CAHAreOo2mzschuKU3Z9MLxPuOxDQVhVcntpk4OLdh=y0AEMX_w@mail.gmail.com>

On Mon, Jun 11, 2012 at 3:58 AM, Thomas Kluyver <takowl at gmail.com> wrote:
>
> I love it when time zones mean my work is done before I even see it ;-)

Don't get too smug then, here's some work for you ;)

Why is it that when I run it on my screen it prints:

**Test results for commit 199aa71 merged into master**
Platform: linux2
python2.7 : OK
    Libraries not available: oct2py
python3.2 : OK
    Libraries not available: cython matplotlib oct2py pymongo rpy2 wx wx.aui
Not available for testing: python2.6, python3.1
To post the results to Github, run ./post_pr_test.py

But when uploading with post_pr, it shows:

(stefanv-octavemagic)longs[tools]> ./post_pr_test.py


**Test results for commit 199aa71 merged into master**
Platform: linux2
python2.7 : OK
    Libraries not available: oct2py
python3.2 : OK
    Libraries not available: cython matplotlib oct2py pymongo rpy2 wx wx.aui
Not available for testing:
()
Posted test results to pull request
  https://github.com/ipython/ipython/pull/1849

The difference I want to highlight is that in post_pr, the 'not
available' list appears always empty and therefore the uploaded
reports look funky:

https://github.com/ipython/ipython/pull/1849#issuecomment-6254108

It would be nice to polish that...

Cheers,

f


From fperez.net at gmail.com  Mon Jun 11 16:20:55 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Jun 2012 13:20:55 -0700
Subject: [IPython-dev] Easy Installation
In-Reply-To: <20120611121145.GA3470@volans.logilab.fr>
References: <CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
	<CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>
	<CAOvn4qjs5ifL_HKj1qJWkmNdQ+4KUSQtgCE37QbLX3Yy_y6DcA@mail.gmail.com>
	<CAHAreOp_+joxdeZTQ1ZEOOU4w=euqtESMTisVSDA8oRx=RdCHg@mail.gmail.com>
	<CAOvn4qhKg9QM8u-BQvrk+PazfRBpAYtF_7Vh7-YHGYAWmHiABw@mail.gmail.com>
	<CAHAreOr+c3CS_NWOMPwUuCXN=-t5vPswzEvS6QUtX+sUKq=yrw@mail.gmail.com>
	<CAOvn4qgF+am8ScvsCtC7pXxxmtfEsY6EixnbHdYwsWLO+HQ31g@mail.gmail.com>
	<CAHAreOpqk=KuSLJdDS1n7w_DYjGhjtA_RJdxAfur_iQ2Lq_iig@mail.gmail.com>
	<CAP-uhDcMnCaM=47=qQFmO+LoxMACOsECEU=_HETvPmJGBcdEFQ@mail.gmail.com>
	<CAOvn4qhT5uW-VTJrQzikvh=QV5A+mb8Htt37rk-Vu0iwepwOSA@mail.gmail.com>
	<20120611121145.GA3470@volans.logilab.fr>
Message-ID: <CAHAreOrTZ9Wo8o1n+VjRd-_U1LAwxiXPPx7vYjOzrtsqyuN_OQ@mail.gmail.com>

On Mon, Jun 11, 2012 at 5:11 AM, Nicolas Chauvat
<nicolas.chauvat at logilab.fr> wrote:
>
> If you have time in your hands, take a look at
> http://www.debian.org/doc/debian-policy/ and you will be surprised by
> the amount of work and tools that is needed in order to get "a system
> that just works for end-users and installs/upgrades packages when
> asked to". Once you understand this, it becomes clear that unless you
> want to limit yourself to a very restricted scope, there is no cheap
> way to get it done.

Absolutely.  I'm actually hopeful we might get 0.13 out before the
next Debian cutoff date, it's not looking impossible...


From fperez.net at gmail.com  Mon Jun 11 16:26:09 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Jun 2012 13:26:09 -0700
Subject: [IPython-dev] Let's get 0.13 released...
In-Reply-To: <4FD61F6C.3080709@googlemail.com>
References: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
	<4FD61F6C.3080709@googlemail.com>
Message-ID: <CAHAreOprJ9qwqJcrw1mesHu2kXYYw_x_dEod91DA4mYTYXDsHA@mail.gmail.com>

On Mon, Jun 11, 2012 at 9:40 AM, Julian Taylor
<jtaylor.debian at googlemail.com> wrote:
> This is great.
> I was fearing the current feature creep would delay 0.13 forever.

Certainly not!  It's really been an issue of manpower and time: the
'three monsters' we landed recently were extremely important, but they
took full-time commitment from Brian, Min and I to get done (JS
refactoring, full kernel merge, magics/cell).  And right after we
finished the work, we had to write a long and detailed report as this
work was done under a grant with the US Department of Defense.

And the *same day* the DoD report was due was the day that Microsoft
was announcing the new Azure platform with IPython.

So our plates have been just a little bit full ;)

But we understand that normal users get code from stable
distributions, not from last night's git master, so making a release
has always been in our minds.  It was just a matter of landing this
hugely important work first, so we'd have something really good to
push out to people.  Now I think we do.

> I'd still like the minified javascript situation cleaned up a bit.
> I'm ok with accepting the same state as 0.12.1, unminify the stuff that
> not in Debian which was only prettify.js last release. I'll remove the
> rest myself.
> Any new stuff that has been added since then?

Not to my knowledge.

> Does the notebook still need development snapshots of jquery & co or
> will it work with official releases (debian has 1.7.2, -ui 1.8.20)?

Honestly I'm not sure, others (Brian, Min, Matthias) might know better
the answer to that...

> Unfortunately unless you release really soon or the Debian release team
> delays the freeze (currently 15. July) 0.13 is going to be too late for
> Debian wheezy.

Well, I don't think July 15 is out of the question.  I'd like to cut
the beta tomorrow or Wednesday, with an RC soon thereafter.

The point is that we want to release *what's there now*, not start a
process of writing a bunch of new code :)

Cheers,

f


From takowl at gmail.com  Mon Jun 11 16:51:13 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 11 Jun 2012 21:51:13 +0100
Subject: [IPython-dev] Persistent test_pr problems on python3
In-Reply-To: <CAHAreOo2mzschuKU3Z9MLxPuOxDQVhVcntpk4OLdh=y0AEMX_w@mail.gmail.com>
References: <CAHAreOo0TZctDWqB5OSY2AeBcaoJ9UtJ4xa6k8_=-SugvMwmZg@mail.gmail.com>
	<CAHNn8BXxdA4+9JTAhPrCKX6tCmrX3Aik7PF3pE8n7HkyiUAONw@mail.gmail.com>
	<CAHAreOquUM0pxWFqUzViO8OToUumzM-FXkaJvL2jhyuJuOxN6w@mail.gmail.com>
	<CAHNn8BVUZQYkj6OOAc6qVSc0Qm8jCVEm=xaH-EbsMmB=gkT6gg@mail.gmail.com>
	<CAHNn8BVVOvcb=9G46KLQqmfSt9t=vSMOOJHZ_tk9knCx=gyRfQ@mail.gmail.com>
	<CAHAreOqZ5hTRNYCdNR7i2N7uXQONmRztSQN+ftfqDAgsEyd6FQ@mail.gmail.com>
	<CAHAreOp1HtEsbCV1XRVrV3mQE4kZDk-v4y=cQKS_7wTajoaeAQ@mail.gmail.com>
	<CAOvn4qjrQG5xHe9oYUvk+AE2xR_om8yKW6jWycVWqk8-XSnOsw@mail.gmail.com>
	<CAHAreOo2mzschuKU3Z9MLxPuOxDQVhVcntpk4OLdh=y0AEMX_w@mail.gmail.com>
Message-ID: <CAOvn4qgjzNfo12LoDiyTAJOiAQrQ4jRRpmuAFJLdGPwpGePisw@mail.gmail.com>

On 11 June 2012 20:53, Fernando Perez <fperez.net at gmail.com> wrote:
> The difference I want to highlight is that in post_pr, the 'not
> available' list appears always empty and therefore the uploaded
> reports look funky:

I think I've noticed that before. The pickle that saves the results
doesn't store the list of unavailable Python versions. It should be an
easy enough fix.

Thomas


From fperez.net at gmail.com  Mon Jun 11 16:54:19 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Jun 2012 13:54:19 -0700
Subject: [IPython-dev] Persistent test_pr problems on python3
In-Reply-To: <CAOvn4qgjzNfo12LoDiyTAJOiAQrQ4jRRpmuAFJLdGPwpGePisw@mail.gmail.com>
References: <CAHAreOo0TZctDWqB5OSY2AeBcaoJ9UtJ4xa6k8_=-SugvMwmZg@mail.gmail.com>
	<CAHNn8BXxdA4+9JTAhPrCKX6tCmrX3Aik7PF3pE8n7HkyiUAONw@mail.gmail.com>
	<CAHAreOquUM0pxWFqUzViO8OToUumzM-FXkaJvL2jhyuJuOxN6w@mail.gmail.com>
	<CAHNn8BVUZQYkj6OOAc6qVSc0Qm8jCVEm=xaH-EbsMmB=gkT6gg@mail.gmail.com>
	<CAHNn8BVVOvcb=9G46KLQqmfSt9t=vSMOOJHZ_tk9knCx=gyRfQ@mail.gmail.com>
	<CAHAreOqZ5hTRNYCdNR7i2N7uXQONmRztSQN+ftfqDAgsEyd6FQ@mail.gmail.com>
	<CAHAreOp1HtEsbCV1XRVrV3mQE4kZDk-v4y=cQKS_7wTajoaeAQ@mail.gmail.com>
	<CAOvn4qjrQG5xHe9oYUvk+AE2xR_om8yKW6jWycVWqk8-XSnOsw@mail.gmail.com>
	<CAHAreOo2mzschuKU3Z9MLxPuOxDQVhVcntpk4OLdh=y0AEMX_w@mail.gmail.com>
	<CAOvn4qgjzNfo12LoDiyTAJOiAQrQ4jRRpmuAFJLdGPwpGePisw@mail.gmail.com>
Message-ID: <CAHAreOqkXkSHa0GR6DnG4ZofK_6rNG5Vgbpp08W0EpBUyQtMWg@mail.gmail.com>

On Mon, Jun 11, 2012 at 1:51 PM, Thomas Kluyver <takowl at gmail.com> wrote:
> I think I've noticed that before. The pickle that saves the results
> doesn't store the list of unavailable Python versions. It should be an
> easy enough fix.

Great, glad to hear that.


From benjaminrk at gmail.com  Mon Jun 11 17:03:59 2012
From: benjaminrk at gmail.com (MinRK)
Date: Mon, 11 Jun 2012 14:03:59 -0700
Subject: [IPython-dev] Persistent test_pr problems on python3
In-Reply-To: <CAHAreOqkXkSHa0GR6DnG4ZofK_6rNG5Vgbpp08W0EpBUyQtMWg@mail.gmail.com>
References: <CAHAreOo0TZctDWqB5OSY2AeBcaoJ9UtJ4xa6k8_=-SugvMwmZg@mail.gmail.com>
	<CAHNn8BXxdA4+9JTAhPrCKX6tCmrX3Aik7PF3pE8n7HkyiUAONw@mail.gmail.com>
	<CAHAreOquUM0pxWFqUzViO8OToUumzM-FXkaJvL2jhyuJuOxN6w@mail.gmail.com>
	<CAHNn8BVUZQYkj6OOAc6qVSc0Qm8jCVEm=xaH-EbsMmB=gkT6gg@mail.gmail.com>
	<CAHNn8BVVOvcb=9G46KLQqmfSt9t=vSMOOJHZ_tk9knCx=gyRfQ@mail.gmail.com>
	<CAHAreOqZ5hTRNYCdNR7i2N7uXQONmRztSQN+ftfqDAgsEyd6FQ@mail.gmail.com>
	<CAHAreOp1HtEsbCV1XRVrV3mQE4kZDk-v4y=cQKS_7wTajoaeAQ@mail.gmail.com>
	<CAOvn4qjrQG5xHe9oYUvk+AE2xR_om8yKW6jWycVWqk8-XSnOsw@mail.gmail.com>
	<CAHAreOo2mzschuKU3Z9MLxPuOxDQVhVcntpk4OLdh=y0AEMX_w@mail.gmail.com>
	<CAOvn4qgjzNfo12LoDiyTAJOiAQrQ4jRRpmuAFJLdGPwpGePisw@mail.gmail.com>
	<CAHAreOqkXkSHa0GR6DnG4ZofK_6rNG5Vgbpp08W0EpBUyQtMWg@mail.gmail.com>
Message-ID: <CAHNn8BX3ar3qwkbzJpHQyYa7NWHDzEgGtO=zQKDzMwsNH0VmeA@mail.gmail.com>

On Mon, Jun 11, 2012 at 1:54 PM, Fernando Perez <fperez.net at gmail.com>wrote:

> On Mon, Jun 11, 2012 at 1:51 PM, Thomas Kluyver <takowl at gmail.com> wrote:
> > I think I've noticed that before. The pickle that saves the results
> > doesn't store the list of unavailable Python versions. It should be an
> > easy enough fix.
>
> Great, glad to hear that.
>

Not that it's difficult to deduce the unavailable versions from the above
list, of course.


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

From fperez.net at gmail.com  Mon Jun 11 17:07:09 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Jun 2012 14:07:09 -0700
Subject: [IPython-dev] Persistent test_pr problems on python3
In-Reply-To: <CAHNn8BX3ar3qwkbzJpHQyYa7NWHDzEgGtO=zQKDzMwsNH0VmeA@mail.gmail.com>
References: <CAHAreOo0TZctDWqB5OSY2AeBcaoJ9UtJ4xa6k8_=-SugvMwmZg@mail.gmail.com>
	<CAHNn8BXxdA4+9JTAhPrCKX6tCmrX3Aik7PF3pE8n7HkyiUAONw@mail.gmail.com>
	<CAHAreOquUM0pxWFqUzViO8OToUumzM-FXkaJvL2jhyuJuOxN6w@mail.gmail.com>
	<CAHNn8BVUZQYkj6OOAc6qVSc0Qm8jCVEm=xaH-EbsMmB=gkT6gg@mail.gmail.com>
	<CAHNn8BVVOvcb=9G46KLQqmfSt9t=vSMOOJHZ_tk9knCx=gyRfQ@mail.gmail.com>
	<CAHAreOqZ5hTRNYCdNR7i2N7uXQONmRztSQN+ftfqDAgsEyd6FQ@mail.gmail.com>
	<CAHAreOp1HtEsbCV1XRVrV3mQE4kZDk-v4y=cQKS_7wTajoaeAQ@mail.gmail.com>
	<CAOvn4qjrQG5xHe9oYUvk+AE2xR_om8yKW6jWycVWqk8-XSnOsw@mail.gmail.com>
	<CAHAreOo2mzschuKU3Z9MLxPuOxDQVhVcntpk4OLdh=y0AEMX_w@mail.gmail.com>
	<CAOvn4qgjzNfo12LoDiyTAJOiAQrQ4jRRpmuAFJLdGPwpGePisw@mail.gmail.com>
	<CAHAreOqkXkSHa0GR6DnG4ZofK_6rNG5Vgbpp08W0EpBUyQtMWg@mail.gmail.com>
	<CAHNn8BX3ar3qwkbzJpHQyYa7NWHDzEgGtO=zQKDzMwsNH0VmeA@mail.gmail.com>
Message-ID: <CAHAreOokSwQ2_LEyeZO=b+RM9ZT--F7y_0btBUZXuZVpdRe2_g@mail.gmail.com>

On Mon, Jun 11, 2012 at 2:03 PM, MinRK <benjaminrk at gmail.com> wrote:
> Not that it's difficult to deduce the unavailable versions from the above
> list, of course.

Sure, it's just a minor cosmetic point.  We could also just remove the
'missing' message altogether, it just reads weird right now because
it's truncated.


From jtaylor.debian at googlemail.com  Mon Jun 11 17:10:34 2012
From: jtaylor.debian at googlemail.com (Julian Taylor)
Date: Mon, 11 Jun 2012 23:10:34 +0200
Subject: [IPython-dev] Let's get 0.13 released...
In-Reply-To: <CAHAreOprJ9qwqJcrw1mesHu2kXYYw_x_dEod91DA4mYTYXDsHA@mail.gmail.com>
References: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
	<4FD61F6C.3080709@googlemail.com>
	<CAHAreOprJ9qwqJcrw1mesHu2kXYYw_x_dEod91DA4mYTYXDsHA@mail.gmail.com>
Message-ID: <4FD65ECA.3020207@googlemail.com>

> 
>> Unfortunately unless you release really soon or the Debian release team
>> delays the freeze (currently 15. July) 0.13 is going to be too late for
>> Debian wheezy.
> 
> Well, I don't think July 15 is out of the question.  I'd like to cut
> the beta tomorrow or Wednesday, with an RC soon thereafter.
> 

whoops
I meant 15. of June, so this week.
Though I heard rumors of a delay to end of June.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120611/3ddf0cea/attachment.sig>

From benjaminrk at gmail.com  Mon Jun 11 17:14:02 2012
From: benjaminrk at gmail.com (MinRK)
Date: Mon, 11 Jun 2012 14:14:02 -0700
Subject: [IPython-dev] Let's get 0.13 released...
In-Reply-To: <CAHAreOprJ9qwqJcrw1mesHu2kXYYw_x_dEod91DA4mYTYXDsHA@mail.gmail.com>
References: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
	<4FD61F6C.3080709@googlemail.com>
	<CAHAreOprJ9qwqJcrw1mesHu2kXYYw_x_dEod91DA4mYTYXDsHA@mail.gmail.com>
Message-ID: <CAHNn8BWLU=ggRrwh-U1Tv1VRf1b_2qZfTiP46Jfkr1Z26HpFOQ@mail.gmail.com>

On Mon, Jun 11, 2012 at 1:26 PM, Fernando Perez <fperez.net at gmail.com>wrote:

> On Mon, Jun 11, 2012 at 9:40 AM, Julian Taylor
> <jtaylor.debian at googlemail.com> wrote:
> > This is great.
> > I was fearing the current feature creep would delay 0.13 forever.
>
> Certainly not!  It's really been an issue of manpower and time: the
> 'three monsters' we landed recently were extremely important, but they
> took full-time commitment from Brian, Min and I to get done (JS
> refactoring, full kernel merge, magics/cell).  And right after we
> finished the work, we had to write a long and detailed report as this
> work was done under a grant with the US Department of Defense.
>
> And the *same day* the DoD report was due was the day that Microsoft
> was announcing the new Azure platform with IPython.
>
> So our plates have been just a little bit full ;)
>
> But we understand that normal users get code from stable
> distributions, not from last night's git master, so making a release
> has always been in our minds.  It was just a matter of landing this
> hugely important work first, so we'd have something really good to
> push out to people.  Now I think we do.
>
> > I'd still like the minified javascript situation cleaned up a bit.
> > I'm ok with accepting the same state as 0.12.1, unminify the stuff that
> > not in Debian which was only prettify.js last release. I'll remove the
> > rest myself.
> > Any new stuff that has been added since then?
>
> Not to my knowledge.
>
> > Does the notebook still need development snapshots of jquery & co or
> > will it work with official releases (debian has 1.7.2, -ui 1.8.20)?
>
> Honestly I'm not sure, others (Brian, Min, Matthias) might know better
> the answer to that...
>

jquery is fine (we are shipping 1.7.1, so 1.7.2 should be no problem), but
I think we do need dev jquery-ui.  pagedown now includes a tiny patch:

$> git diff rel-0.12.1 master
IPython/frontend/html/notebook/static/pagedown/

I don't think anything else has changed there.


>
> > Unfortunately unless you release really soon or the Debian release team
> > delays the freeze (currently 15. July) 0.13 is going to be too late for
> > Debian wheezy.
>
> Well, I don't think July 15 is out of the question.  I'd like to cut
> the beta tomorrow or Wednesday, with an RC soon thereafter.
>
> The point is that we want to release *what's there now*, not start a
> process of writing a bunch of new code :)
>

Right - I think if we cut off new features right now, 0.13 is a
satisfactory release.  I already have a few PRs explicitly targeting 0.14.

-MinRK


>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120611/b9b65225/attachment.html>

From fperez.net at gmail.com  Mon Jun 11 17:14:11 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Jun 2012 14:14:11 -0700
Subject: [IPython-dev] Let's get 0.13 released...
In-Reply-To: <4FD65ECA.3020207@googlemail.com>
References: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
	<4FD61F6C.3080709@googlemail.com>
	<CAHAreOprJ9qwqJcrw1mesHu2kXYYw_x_dEod91DA4mYTYXDsHA@mail.gmail.com>
	<4FD65ECA.3020207@googlemail.com>
Message-ID: <CAHAreOp580P-OybxOtoj3547tCCCogi+h1MG16SxNAz+GhZifQ@mail.gmail.com>

On Mon, Jun 11, 2012 at 2:10 PM, Julian Taylor
<jtaylor.debian at googlemail.com> wrote:
> whoops
> I meant 15. of June, so this week.
> Though I heard rumors of a delay to end of June.

Ah, that's a completely different story.  This week is most certainly
NOT going to happen.

We might even make the July 5 Ubuntu auto-sync date, but there's no
way we're releasing this week, sorry.

f


From jtaylor.debian at googlemail.com  Mon Jun 11 17:19:53 2012
From: jtaylor.debian at googlemail.com (Julian Taylor)
Date: Mon, 11 Jun 2012 23:19:53 +0200
Subject: [IPython-dev] Let's get 0.13 released...
In-Reply-To: <CAHAreOp580P-OybxOtoj3547tCCCogi+h1MG16SxNAz+GhZifQ@mail.gmail.com>
References: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
	<4FD61F6C.3080709@googlemail.com>
	<CAHAreOprJ9qwqJcrw1mesHu2kXYYw_x_dEod91DA4mYTYXDsHA@mail.gmail.com>
	<4FD65ECA.3020207@googlemail.com>
	<CAHAreOp580P-OybxOtoj3547tCCCogi+h1MG16SxNAz+GhZifQ@mail.gmail.com>
Message-ID: <4FD660F9.60207@googlemail.com>

On 06/11/2012 11:14 PM, Fernando Perez wrote:
> On Mon, Jun 11, 2012 at 2:10 PM, Julian Taylor
> <jtaylor.debian at googlemail.com> wrote:
>> whoops
>> I meant 15. of June, so this week.
>> Though I heard rumors of a delay to end of June.
> 
> Ah, that's a completely different story.  This week is most certainly
> NOT going to happen.
> 
> We might even make the July 5 Ubuntu auto-sync date, but there's no
> way we're releasing this week, sorry.
> 

the Ubuntu auto sync date is just a technicality, it does not prevent
new stuff from going into the archive
It only needs to be manually requested instead of being automatic (see
requestsync from the ubuntu-dev-tools package)

So there is no need to rush something out before that date.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120611/d4c2393d/attachment.sig>

From warren.weckesser at enthought.com  Mon Jun 11 17:22:55 2012
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Mon, 11 Jun 2012 16:22:55 -0500
Subject: [IPython-dev] Let's get 0.13 released...
In-Reply-To: <CAHAreOp580P-OybxOtoj3547tCCCogi+h1MG16SxNAz+GhZifQ@mail.gmail.com>
References: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
	<4FD61F6C.3080709@googlemail.com>
	<CAHAreOprJ9qwqJcrw1mesHu2kXYYw_x_dEod91DA4mYTYXDsHA@mail.gmail.com>
	<4FD65ECA.3020207@googlemail.com>
	<CAHAreOp580P-OybxOtoj3547tCCCogi+h1MG16SxNAz+GhZifQ@mail.gmail.com>
Message-ID: <CAM-+wY97d69p9zq+R=Sq3nVdvWdq2GkVARVbzrL6k=r9npfUCA@mail.gmail.com>

On Mon, Jun 11, 2012 at 4:14 PM, Fernando Perez <fperez.net at gmail.com>wrote:

> On Mon, Jun 11, 2012 at 2:10 PM, Julian Taylor
> <jtaylor.debian at googlemail.com> wrote:
> > whoops
> > I meant 15. of June, so this week.
> > Though I heard rumors of a delay to end of June.
>
> Ah, that's a completely different story.  This week is most certainly
> NOT going to happen.
>
> We might even make the July 5 Ubuntu auto-sync date, but there's no
> way we're releasing this week, sorry.
>
>

It will be great to have a shiny new IPython for the SciPy conference in
July, especially since Fernando and Min will be giving tutorials and talks
about it.  (That's July 16-21; early registration deadline is a week from
today, so register now if you haven't already.)   See you all there!

Warren


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

From fperez.net at gmail.com  Mon Jun 11 17:22:50 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Jun 2012 14:22:50 -0700
Subject: [IPython-dev] Let's get 0.13 released...
In-Reply-To: <4FD660F9.60207@googlemail.com>
References: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
	<4FD61F6C.3080709@googlemail.com>
	<CAHAreOprJ9qwqJcrw1mesHu2kXYYw_x_dEod91DA4mYTYXDsHA@mail.gmail.com>
	<4FD65ECA.3020207@googlemail.com>
	<CAHAreOp580P-OybxOtoj3547tCCCogi+h1MG16SxNAz+GhZifQ@mail.gmail.com>
	<4FD660F9.60207@googlemail.com>
Message-ID: <CAHAreOpsu0EP19hsgwaXLxJndgPMN8QG2_hrBhBsTb1nwSQRtg@mail.gmail.com>

On Mon, Jun 11, 2012 at 2:19 PM, Julian Taylor
<jtaylor.debian at googlemail.com> wrote:
> the Ubuntu auto sync date is just a technicality, it does not prevent
> new stuff from going into the archive
> It only needs to be manually requested instead of being automatic (see
> requestsync from the ubuntu-dev-tools package)
>
> So there is no need to rush something out before that date.

OK, thanks for clarifying that.

Still, we're going to try to keep this release semi-freeze to be as
short as possible, so that everyone can go back to writing new fun
code quickly :)

f


From fperez.net at gmail.com  Mon Jun 11 17:24:26 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Jun 2012 14:24:26 -0700
Subject: [IPython-dev] Let's get 0.13 released...
In-Reply-To: <CAM-+wY97d69p9zq+R=Sq3nVdvWdq2GkVARVbzrL6k=r9npfUCA@mail.gmail.com>
References: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
	<4FD61F6C.3080709@googlemail.com>
	<CAHAreOprJ9qwqJcrw1mesHu2kXYYw_x_dEod91DA4mYTYXDsHA@mail.gmail.com>
	<4FD65ECA.3020207@googlemail.com>
	<CAHAreOp580P-OybxOtoj3547tCCCogi+h1MG16SxNAz+GhZifQ@mail.gmail.com>
	<CAM-+wY97d69p9zq+R=Sq3nVdvWdq2GkVARVbzrL6k=r9npfUCA@mail.gmail.com>
Message-ID: <CAHAreOoHMiREtjyCUB__s37_bu9MMvmZjvdGN4AKaSKoYdg+7A@mail.gmail.com>

On Mon, Jun 11, 2012 at 2:22 PM, Warren Weckesser
<warren.weckesser at enthought.com> wrote:
> It will be great to have a shiny new IPython for the SciPy conference in
> July, especially since Fernando and Min will be giving tutorials and talks
> about it.? (That's July 16-21; early registration deadline is a week from
> today, so register now if you haven't already.) ? See you all there!

Yup, that's a *strongly* motivating factor for us right now!


From benjaminrk at gmail.com  Mon Jun 11 17:25:53 2012
From: benjaminrk at gmail.com (MinRK)
Date: Mon, 11 Jun 2012 14:25:53 -0700
Subject: [IPython-dev] Let's get 0.13 released...
In-Reply-To: <CAHAreOoHMiREtjyCUB__s37_bu9MMvmZjvdGN4AKaSKoYdg+7A@mail.gmail.com>
References: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
	<4FD61F6C.3080709@googlemail.com>
	<CAHAreOprJ9qwqJcrw1mesHu2kXYYw_x_dEod91DA4mYTYXDsHA@mail.gmail.com>
	<4FD65ECA.3020207@googlemail.com>
	<CAHAreOp580P-OybxOtoj3547tCCCogi+h1MG16SxNAz+GhZifQ@mail.gmail.com>
	<CAM-+wY97d69p9zq+R=Sq3nVdvWdq2GkVARVbzrL6k=r9npfUCA@mail.gmail.com>
	<CAHAreOoHMiREtjyCUB__s37_bu9MMvmZjvdGN4AKaSKoYdg+7A@mail.gmail.com>
Message-ID: <CAHNn8BUzTegys879Ja7eeWvurpwh7JPpPX393XMP=HFZBCJLcQ@mail.gmail.com>

On Mon, Jun 11, 2012 at 2:24 PM, Fernando Perez <fperez.net at gmail.com>wrote:

> On Mon, Jun 11, 2012 at 2:22 PM, Warren Weckesser
> <warren.weckesser at enthought.com> wrote:
> > It will be great to have a shiny new IPython for the SciPy conference in
> > July, especially since Fernando and Min will be giving tutorials and
> talks
> > about it.  (That's July 16-21; early registration deadline is a week from
> > today, so register now if you haven't already.)   See you all there!
>
> Yup, that's a *strongly* motivating factor for us right now!
>

Yeah, we are not about to demo with 0.12 - that's so 2011!


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

From fperez.net at gmail.com  Mon Jun 11 17:36:34 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Jun 2012 14:36:34 -0700
Subject: [IPython-dev] 43 PRs merged in a week, not bad
Message-ID: <CAHAreOp9NVZ_0MHSMkTHiRW44Or3X3hNHqyJb3Cf3kAbJUeXrg@mail.gmail.com>

(master)longs[tools]> git log --oneline --since=2012-06-03 | grep
"Merge pull request" | wc -l
43

Thanks and congrats everyone!

(master)longs[tools]> git log --oneline --since=2012-06-03 | grep
"Merge pull request"
dc7323f Merge pull request #1919 from tkf/better_find_edit_target2
09141ff Merge pull request #1918 from minrk/nowarnquarantine
01d7b93 Merge pull request #1917 from takluyver/i1914
967ce49 Merge pull request #1913 from jstenar/fix-1428
2287b38 Merge pull request #1911 from minrk/skipreload
4af3a6a Merge pull request #1909 from jstenar/fixfor-1908
8f74c17 Merge pull request #1907 from minrk/py3script
a7d33e6 Merge pull request #1906 from minrk/magic_info
44b8121 Merge pull request #1845 from fperez/magic_inspect
6f61cb0 Merge pull request #1902 from jdmarch/win32-shell-revert
1df7d98 Merge pull request #1900 from fperez/cython-libs
23ead87 Merge pull request #1899 from minrk/scriptcfg
b43efbb Merge pull request #1898 from minrk/badman
1e110af Merge pull request #1897 from minrk/exclude_glob
18f728c Merge pull request #1855 from minrk/moremagics
024e384 Merge pull request #1870 from minrk/captureio
7cd55e5 Merge pull request #1861 from tkf/dvipng
9b25003 Merge pull request #1867 from mcelrath/menu_borders
41f79e7 Merge pull request #1889 from invisibleroads/patch-3
68a629f Merge pull request #1886 from tkf/fix-notebook-rename
610e90f Merge pull request #1895 from takluyver/testing-ip.system-depth
0d0d208 Merge pull request #1762 from minrk/locate
8325d15 Merge pull request #1883 from mcelrath/mono_cursor_offset
45d28c5 Merge pull request #1851 from Carreau/newcomp_rebase
825a832 Merge pull request #1892 from tkf/suspicious-quotes
4c940c8 Merge pull request #1864 from takluyver/rmagic-exception
ba4b54a Merge pull request #1829 from Carreau/notebook_cellmagic_completion
2097353 Merge pull request #1832 from ellisonbg/imageresize
0b92c4e Merge pull request #1674 from mdboom/notebook-carriage-return
7a50de9 Merge pull request #1882 from bfroehle/_1874_import_module
93e6672 Merge pull request #1879 from takluyver/i1878
09ae0f3 Merge pull request #1841 from Carreau/deduplicate_completion
d7c7a8f Merge pull request #1850 from bfroehle/_1736_try_next
0956514 Merge pull request #1663 from minrk/splitlines
66a567b Merge pull request #1815 from ellisonbg/nbsavebug
9f36bf5 Merge pull request #1819 from thisch/psums_cleanup
e9dcd18 Merge pull request #1839 from juliantaylor/external-cleanup
8b00a30 Merge pull request #1782 from Carreau/magiclistinfo
7e71399 Merge pull request #1862 from minrk/bindkernel
1170c58 Merge pull request #1856 from mcelrath/master
344e543 Merge pull request #1852 from minrk/resubmitbufs
b108835 Merge pull request #1780 from jonathan-taylor/rmagic_extension
426ba31 Merge pull request #1847 from minrk/inlinecfg


From benjaminrk at gmail.com  Mon Jun 11 17:46:31 2012
From: benjaminrk at gmail.com (MinRK)
Date: Mon, 11 Jun 2012 14:46:31 -0700
Subject: [IPython-dev] 43 PRs merged in a week, not bad
In-Reply-To: <CAHAreOp9NVZ_0MHSMkTHiRW44Or3X3hNHqyJb3Cf3kAbJUeXrg@mail.gmail.com>
References: <CAHAreOp9NVZ_0MHSMkTHiRW44Or3X3hNHqyJb3Cf3kAbJUeXrg@mail.gmail.com>
Message-ID: <CAHNn8BUQ4V5DQTVsBHPKT+aZNT1avBUX-1SoFAbGzg6CdUdxzw@mail.gmail.com>

On Mon, Jun 11, 2012 at 2:36 PM, Fernando Perez <fperez.net at gmail.com>wrote:

> (master)longs[tools]> git log --oneline --since=2012-06-03 | grep
> "Merge pull request" | wc -l
> 43
>
> Thanks and congrats everyone!
>
> (master)longs[tools]> git log --oneline --since=2012-06-03 | grep
> "Merge pull request"
> dc7323f Merge pull request #1919 from tkf/better_find_edit_target2
> 09141ff Merge pull request #1918 from minrk/nowarnquarantine
> 01d7b93 Merge pull request #1917 from takluyver/i1914
> 967ce49 Merge pull request #1913 from jstenar/fix-1428
> 2287b38 Merge pull request #1911 from minrk/skipreload
> 4af3a6a Merge pull request #1909 from jstenar/fixfor-1908
> 8f74c17 Merge pull request #1907 from minrk/py3script
> a7d33e6 Merge pull request #1906 from minrk/magic_info
> 44b8121 Merge pull request #1845 from fperez/magic_inspect
> 6f61cb0 Merge pull request #1902 from jdmarch/win32-shell-revert
> 1df7d98 Merge pull request #1900 from fperez/cython-libs
> 23ead87 Merge pull request #1899 from minrk/scriptcfg
> b43efbb Merge pull request #1898 from minrk/badman
> 1e110af Merge pull request #1897 from minrk/exclude_glob
> 18f728c Merge pull request #1855 from minrk/moremagics
> 024e384 Merge pull request #1870 from minrk/captureio
> 7cd55e5 Merge pull request #1861 from tkf/dvipng
> 9b25003 Merge pull request #1867 from mcelrath/menu_borders
> 41f79e7 Merge pull request #1889 from invisibleroads/patch-3
> 68a629f Merge pull request #1886 from tkf/fix-notebook-rename
> 610e90f Merge pull request #1895 from takluyver/testing-ip.system-depth
> 0d0d208 Merge pull request #1762 from minrk/locate
> 8325d15 Merge pull request #1883 from mcelrath/mono_cursor_offset
> 45d28c5 Merge pull request #1851 from Carreau/newcomp_rebase
> 825a832 Merge pull request #1892 from tkf/suspicious-quotes
> 4c940c8 Merge pull request #1864 from takluyver/rmagic-exception
> ba4b54a Merge pull request #1829 from Carreau/notebook_cellmagic_completion
> 2097353 Merge pull request #1832 from ellisonbg/imageresize
> 0b92c4e Merge pull request #1674 from mdboom/notebook-carriage-return
> 7a50de9 Merge pull request #1882 from bfroehle/_1874_import_module
> 93e6672 Merge pull request #1879 from takluyver/i1878
> 09ae0f3 Merge pull request #1841 from Carreau/deduplicate_completion
> d7c7a8f Merge pull request #1850 from bfroehle/_1736_try_next
> 0956514 Merge pull request #1663 from minrk/splitlines
> 66a567b Merge pull request #1815 from ellisonbg/nbsavebug
> 9f36bf5 Merge pull request #1819 from thisch/psums_cleanup
> e9dcd18 Merge pull request #1839 from juliantaylor/external-cleanup
> 8b00a30 Merge pull request #1782 from Carreau/magiclistinfo
> 7e71399 Merge pull request #1862 from minrk/bindkernel
> 1170c58 Merge pull request #1856 from mcelrath/master
> 344e543 Merge pull request #1852 from minrk/resubmitbufs
> b108835 Merge pull request #1780 from jonathan-taylor/rmagic_extension
> 426ba31 Merge pull request #1847 from minrk/inlinecfg
>

And open Issues just dropped under 300 (should last for a few minutes, at
least).

Well done, all!

I have a feeling that a pandas notebook visualizing IPython contributions
is in order for the SciPy tutorial.

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

From fperez.net at gmail.com  Mon Jun 11 17:48:30 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Jun 2012 14:48:30 -0700
Subject: [IPython-dev] 43 PRs merged in a week, not bad
In-Reply-To: <CAHNn8BUQ4V5DQTVsBHPKT+aZNT1avBUX-1SoFAbGzg6CdUdxzw@mail.gmail.com>
References: <CAHAreOp9NVZ_0MHSMkTHiRW44Or3X3hNHqyJb3Cf3kAbJUeXrg@mail.gmail.com>
	<CAHNn8BUQ4V5DQTVsBHPKT+aZNT1avBUX-1SoFAbGzg6CdUdxzw@mail.gmail.com>
Message-ID: <CAHAreOp1eTgRN89ub_Z-1e8=aP+BMeiS5NdjDzu4CNV5KWoftg@mail.gmail.com>

On Mon, Jun 11, 2012 at 2:46 PM, MinRK <benjaminrk at gmail.com> wrote:
> And open Issues just dropped under 300 (should last for a few minutes, at
> least).

I wish we had the manpower for a 'bug blitz' to bring that under 150
again, like we used to have...

> I have a feeling that a pandas notebook visualizing IPython contributions is
> in order for the SciPy tutorial.

+1


From jtaylor.debian at googlemail.com  Mon Jun 11 18:02:55 2012
From: jtaylor.debian at googlemail.com (Julian Taylor)
Date: Tue, 12 Jun 2012 00:02:55 +0200
Subject: [IPython-dev] Let's get 0.13 released...
In-Reply-To: <CAHNn8BWLU=ggRrwh-U1Tv1VRf1b_2qZfTiP46Jfkr1Z26HpFOQ@mail.gmail.com>
References: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
	<4FD61F6C.3080709@googlemail.com>
	<CAHAreOprJ9qwqJcrw1mesHu2kXYYw_x_dEod91DA4mYTYXDsHA@mail.gmail.com>
	<CAHNn8BWLU=ggRrwh-U1Tv1VRf1b_2qZfTiP46Jfkr1Z26HpFOQ@mail.gmail.com>
Message-ID: <4FD66B0F.2060405@googlemail.com>

>     > Does the notebook still need development snapshots of jquery & co or
>     > will it work with official releases (debian has 1.7.2, -ui 1.8.20)?
> 
>     Honestly I'm not sure, others (Brian, Min, Matthias) might know better
>     the answer to that...
> 
> 
> jquery is fine (we are shipping 1.7.1, so 1.7.2 should be no problem),
> but I think we do need dev jquery-ui.  

what features of the dev version are required?
wasn't there supposed to be some file that should give that information?
IPython/frontend/html/notebook/static/unminified/README does not mention
a dev release.
the commit log gives no clue and the obfuscated file itself just
contains @VERSION, not very helpful.

> pagedown now includes a tiny patch:

pagedown is not obfuscated so its is fine.
I only have issues with the binary blobs you have in your source.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120612/acc7f48c/attachment.sig>

From jorgen.stenarson at kroywen.se  Mon Jun 11 18:07:34 2012
From: jorgen.stenarson at kroywen.se (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Tue, 12 Jun 2012 00:07:34 +0200
Subject: [IPython-dev] All tests pass on windows!
Message-ID: <4FD66C26.9070902@kroywen.se>

Hi,

I'm happy to report that we now have no failing tests on windows:

https://jenkins.shiningpanda.com/ipython/job/ipython-windows-py27/


/J?rgen


From benjaminrk at gmail.com  Mon Jun 11 18:09:11 2012
From: benjaminrk at gmail.com (MinRK)
Date: Mon, 11 Jun 2012 15:09:11 -0700
Subject: [IPython-dev] All tests pass on windows!
In-Reply-To: <4FD66C26.9070902@kroywen.se>
References: <4FD66C26.9070902@kroywen.se>
Message-ID: <CAHNn8BU=RJRpuakcgFRYL-pUeDTv0tRY6NWz12zCn6YZbmX0qw@mail.gmail.com>

On Mon, Jun 11, 2012 at 3:07 PM, J?rgen Stenarson <
jorgen.stenarson at kroywen.se> wrote:

> Hi,
>
> I'm happy to report that we now have no failing tests on windows:
>
> https://jenkins.shiningpanda.com/ipython/job/ipython-windows-py27/


Hooray!  Thanks for all your help!  This is always a big hurdle as we
prepare a release.


>
>
>
> /J?rgen
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120611/66ee1594/attachment.html>

From benjaminrk at gmail.com  Mon Jun 11 18:18:11 2012
From: benjaminrk at gmail.com (MinRK)
Date: Mon, 11 Jun 2012 15:18:11 -0700
Subject: [IPython-dev] Let's get 0.13 released...
In-Reply-To: <4FD66B0F.2060405@googlemail.com>
References: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
	<4FD61F6C.3080709@googlemail.com>
	<CAHAreOprJ9qwqJcrw1mesHu2kXYYw_x_dEod91DA4mYTYXDsHA@mail.gmail.com>
	<CAHNn8BWLU=ggRrwh-U1Tv1VRf1b_2qZfTiP46Jfkr1Z26HpFOQ@mail.gmail.com>
	<4FD66B0F.2060405@googlemail.com>
Message-ID: <CAHNn8BWAQwwjCt=DoO8exczW4z-aN3PAEU=gx4aU8kbSENXq5Q@mail.gmail.com>

On Mon, Jun 11, 2012 at 3:02 PM, Julian Taylor <
jtaylor.debian at googlemail.com> wrote:

> >     > Does the notebook still need development snapshots of jquery & co
> or
> >     > will it work with official releases (debian has 1.7.2, -ui 1.8.20)?
> >
> >     Honestly I'm not sure, others (Brian, Min, Matthias) might know
> better
> >     the answer to that...
> >
> >
> > jquery is fine (we are shipping 1.7.1, so 1.7.2 should be no problem),
> > but I think we do need dev jquery-ui.
>
> what features of the dev version are required?
>

Menus, to be introduced in jQuery 1.9:
http://wiki.jqueryui.com/w/page/12137997/Menu



> wasn't there supposed to be some file that should give that information?
> IPython/frontend/html/notebook/static/unminified/README does not mention
> a dev release.
>

Yes, it should mention it.


> the commit log gives no clue and the obfuscated file itself just
> contains @VERSION, not very helpful.
>

It certainly is not, is it?  It's probably 1.9 milestone 5.  We need Brian
to make a note of that, and possibly consider updating to 1.9m8.


>
> > pagedown now includes a tiny patch:
>
> pagedown is not obfuscated so its is fine.
> I only have issues with the binary blobs you have in your source.
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120611/adb35405/attachment.html>

From fperez.net at gmail.com  Mon Jun 11 19:42:43 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Jun 2012 16:42:43 -0700
Subject: [IPython-dev] All tests pass on windows!
In-Reply-To: <CAHNn8BU=RJRpuakcgFRYL-pUeDTv0tRY6NWz12zCn6YZbmX0qw@mail.gmail.com>
References: <4FD66C26.9070902@kroywen.se>
	<CAHNn8BU=RJRpuakcgFRYL-pUeDTv0tRY6NWz12zCn6YZbmX0qw@mail.gmail.com>
Message-ID: <CAHAreOp65TgBp-KMJ6YRS1Y8sut--rQexTNud6NdQ_m84REL0A@mail.gmail.com>

On Mon, Jun 11, 2012 at 3:09 PM, MinRK <benjaminrk at gmail.com> wrote:
> Hooray! ?Thanks for all your help! ?This is always a big hurdle as we
> prepare a release.

Indeed, you've put a ton of work on this and we really appreciate it.
It's especially valuable right now that we're close to a release, but
let's try to keep things that way in the future, so you don't have to
do big cleanup pushes :)

Cheers,

f


From takowl at gmail.com  Mon Jun 11 20:26:00 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Tue, 12 Jun 2012 01:26:00 +0100
Subject: [IPython-dev] Persistent test_pr problems on python3
In-Reply-To: <CAOvn4qgjzNfo12LoDiyTAJOiAQrQ4jRRpmuAFJLdGPwpGePisw@mail.gmail.com>
References: <CAHAreOo0TZctDWqB5OSY2AeBcaoJ9UtJ4xa6k8_=-SugvMwmZg@mail.gmail.com>
	<CAHNn8BXxdA4+9JTAhPrCKX6tCmrX3Aik7PF3pE8n7HkyiUAONw@mail.gmail.com>
	<CAHAreOquUM0pxWFqUzViO8OToUumzM-FXkaJvL2jhyuJuOxN6w@mail.gmail.com>
	<CAHNn8BVUZQYkj6OOAc6qVSc0Qm8jCVEm=xaH-EbsMmB=gkT6gg@mail.gmail.com>
	<CAHNn8BVVOvcb=9G46KLQqmfSt9t=vSMOOJHZ_tk9knCx=gyRfQ@mail.gmail.com>
	<CAHAreOqZ5hTRNYCdNR7i2N7uXQONmRztSQN+ftfqDAgsEyd6FQ@mail.gmail.com>
	<CAHAreOp1HtEsbCV1XRVrV3mQE4kZDk-v4y=cQKS_7wTajoaeAQ@mail.gmail.com>
	<CAOvn4qjrQG5xHe9oYUvk+AE2xR_om8yKW6jWycVWqk8-XSnOsw@mail.gmail.com>
	<CAHAreOo2mzschuKU3Z9MLxPuOxDQVhVcntpk4OLdh=y0AEMX_w@mail.gmail.com>
	<CAOvn4qgjzNfo12LoDiyTAJOiAQrQ4jRRpmuAFJLdGPwpGePisw@mail.gmail.com>
Message-ID: <CAOvn4qiCsuzRmtX87b_+QZWD+tyJ3CDTJe0Ae2mXt1QabGdK2w@mail.gmail.com>

On 11 June 2012 21:51, Thomas Kluyver <takowl at gmail.com> wrote:
> I think I've noticed that before. The pickle that saves the results
> doesn't store the list of unavailable Python versions. It should be an
> easy enough fix.

I've pushed a fix to master. When I have some time, I'll start
refactoring test_pr into something a bit more maintainable - it's got
a bit ugly. Plus it's approaching the point of needing its own
tests...

Thomas


From fperez.net at gmail.com  Mon Jun 11 20:28:01 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Jun 2012 17:28:01 -0700
Subject: [IPython-dev] Persistent test_pr problems on python3
In-Reply-To: <CAOvn4qiCsuzRmtX87b_+QZWD+tyJ3CDTJe0Ae2mXt1QabGdK2w@mail.gmail.com>
References: <CAHAreOo0TZctDWqB5OSY2AeBcaoJ9UtJ4xa6k8_=-SugvMwmZg@mail.gmail.com>
	<CAHNn8BXxdA4+9JTAhPrCKX6tCmrX3Aik7PF3pE8n7HkyiUAONw@mail.gmail.com>
	<CAHAreOquUM0pxWFqUzViO8OToUumzM-FXkaJvL2jhyuJuOxN6w@mail.gmail.com>
	<CAHNn8BVUZQYkj6OOAc6qVSc0Qm8jCVEm=xaH-EbsMmB=gkT6gg@mail.gmail.com>
	<CAHNn8BVVOvcb=9G46KLQqmfSt9t=vSMOOJHZ_tk9knCx=gyRfQ@mail.gmail.com>
	<CAHAreOqZ5hTRNYCdNR7i2N7uXQONmRztSQN+ftfqDAgsEyd6FQ@mail.gmail.com>
	<CAHAreOp1HtEsbCV1XRVrV3mQE4kZDk-v4y=cQKS_7wTajoaeAQ@mail.gmail.com>
	<CAOvn4qjrQG5xHe9oYUvk+AE2xR_om8yKW6jWycVWqk8-XSnOsw@mail.gmail.com>
	<CAHAreOo2mzschuKU3Z9MLxPuOxDQVhVcntpk4OLdh=y0AEMX_w@mail.gmail.com>
	<CAOvn4qgjzNfo12LoDiyTAJOiAQrQ4jRRpmuAFJLdGPwpGePisw@mail.gmail.com>
	<CAOvn4qiCsuzRmtX87b_+QZWD+tyJ3CDTJe0Ae2mXt1QabGdK2w@mail.gmail.com>
Message-ID: <CAHAreOpcdwaFHyu3f=_WiGAY1fgPszWXuwdTy5KMSxPTxfqUnQ@mail.gmail.com>

On Mon, Jun 11, 2012 at 5:26 PM, Thomas Kluyver <takowl at gmail.com> wrote:
> I've pushed a fix to master. When I have some time, I'll start
> refactoring test_pr into something a bit more maintainable - it's got
> a bit ugly. Plus it's approaching the point of needing its own
> tests...

Sounds good, thanks for the quick response.

You did the right thing: get a useful tool out first, beat on it until
we know it has value, and then you can return more calmly to a
refactor and cleanup.  This has become an essential part of the
development process.

Cheers,

f


From carl.input at gmail.com  Mon Jun 11 20:58:28 2012
From: carl.input at gmail.com (Carl Smith)
Date: Tue, 12 Jun 2012 01:58:28 +0100
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAHAreOrTZ9Wo8o1n+VjRd-_U1LAwxiXPPx7vYjOzrtsqyuN_OQ@mail.gmail.com>
References: <CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
	<CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>
	<CAOvn4qjs5ifL_HKj1qJWkmNdQ+4KUSQtgCE37QbLX3Yy_y6DcA@mail.gmail.com>
	<CAHAreOp_+joxdeZTQ1ZEOOU4w=euqtESMTisVSDA8oRx=RdCHg@mail.gmail.com>
	<CAOvn4qhKg9QM8u-BQvrk+PazfRBpAYtF_7Vh7-YHGYAWmHiABw@mail.gmail.com>
	<CAHAreOr+c3CS_NWOMPwUuCXN=-t5vPswzEvS6QUtX+sUKq=yrw@mail.gmail.com>
	<CAOvn4qgF+am8ScvsCtC7pXxxmtfEsY6EixnbHdYwsWLO+HQ31g@mail.gmail.com>
	<CAHAreOpqk=KuSLJdDS1n7w_DYjGhjtA_RJdxAfur_iQ2Lq_iig@mail.gmail.com>
	<CAP-uhDcMnCaM=47=qQFmO+LoxMACOsECEU=_HETvPmJGBcdEFQ@mail.gmail.com>
	<CAOvn4qhT5uW-VTJrQzikvh=QV5A+mb8Htt37rk-Vu0iwepwOSA@mail.gmail.com>
	<20120611121145.GA3470@volans.logilab.fr>
	<CAHAreOrTZ9Wo8o1n+VjRd-_U1LAwxiXPPx7vYjOzrtsqyuN_OQ@mail.gmail.com>
Message-ID: <CAP-uhDcJ6ckhv6wQRgfPmr_EDy4_FSG+U6G=pN4tiQ=5dN3C9Q@mail.gmail.com>

I got the Launcher on NotebookCloud refreshing now. It'll refresh
every 8 seconds for so long as any instance is in a transitional
state, then stop altogether when they're all stable. Seems to work
fine.

On 11 June 2012 21:20, Fernando Perez <fperez.net at gmail.com> wrote:
> On Mon, Jun 11, 2012 at 5:11 AM, Nicolas Chauvat
> <nicolas.chauvat at logilab.fr> wrote:
>>
>> If you have time in your hands, take a look at
>> http://www.debian.org/doc/debian-policy/ and you will be surprised by
>> the amount of work and tools that is needed in order to get "a system
>> that just works for end-users and installs/upgrades packages when
>> asked to". Once you understand this, it becomes clear that unless you
>> want to limit yourself to a very restricted scope, there is no cheap
>> way to get it done.
>
> Absolutely. ?I'm actually hopeful we might get 0.13 out before the
> next Debian cutoff date, it's not looking impossible...
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev


From jason-sage at creativetrax.com  Mon Jun 11 22:19:48 2012
From: jason-sage at creativetrax.com (Jason Grout)
Date: Mon, 11 Jun 2012 19:19:48 -0700
Subject: [IPython-dev] 43 PRs merged in a week, not bad
In-Reply-To: <CAHAreOp1eTgRN89ub_Z-1e8=aP+BMeiS5NdjDzu4CNV5KWoftg@mail.gmail.com>
References: <CAHAreOp9NVZ_0MHSMkTHiRW44Or3X3hNHqyJb3Cf3kAbJUeXrg@mail.gmail.com>
	<CAHNn8BUQ4V5DQTVsBHPKT+aZNT1avBUX-1SoFAbGzg6CdUdxzw@mail.gmail.com>
	<CAHAreOp1eTgRN89ub_Z-1e8=aP+BMeiS5NdjDzu4CNV5KWoftg@mail.gmail.com>
Message-ID: <4FD6A744.6000805@creativetrax.com>

On 6/11/12 2:48 PM, Fernando Perez wrote:
> I wish we had the manpower for a 'bug blitz' to bring that under 150
> again, like we used to have...

We used to think that was a high number in the Sage project too.  But 
despite being on Sage Days *41* right now, we still have 1503 open 
tickets right now.  And we just closed hundreds in the last release...

Jason


From fperez.net at gmail.com  Mon Jun 11 22:52:13 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Jun 2012 19:52:13 -0700
Subject: [IPython-dev] should we make nodb the default hub backend?
Message-ID: <CAHAreOpDd9ZniC7JfB0wxpDD4G5V1nsGMPQhvq8URs89h=Em3Q@mail.gmail.com>

Hey guys,

I'm wondering if we shouldn't make nodb the default... The new cell
magics and the ability to combiine cython with parallel stuff make it
so blindingly easy to parallelize existing codes (for certain
patterns, of course!) that I bet people are *quickly* going to run
into the problems with memory introduced by the persistent backends.
I was just now parallelizing some Gibbs sampling code in Cython
written by Chris Fonnesbeck for a panel at the R conference later this
week, and all of a sudden noticed my machine grind to a halt.  I had
only run the code a few times, and I was overwriting the same
variables over and over, so I wasn't really thinking I'd be in memory
trouble, but it was the hub's persistence that bit me.

The DB backends are really useful only in more advanced circumstances,
so I'm thinking that perhaps they should be activated knowingly by
users who need their features, leaving the 'naive' patterns to behave
a bit better.  What I'm worried is that right now, a fairly natural
use pattern degrades badly and somewhat mysteriously (unless you
really know what's under the hood).

Thoughts?

f


From fperez.net at gmail.com  Mon Jun 11 22:54:01 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Jun 2012 19:54:01 -0700
Subject: [IPython-dev] 43 PRs merged in a week, not bad
In-Reply-To: <4FD6A744.6000805@creativetrax.com>
References: <CAHAreOp9NVZ_0MHSMkTHiRW44Or3X3hNHqyJb3Cf3kAbJUeXrg@mail.gmail.com>
	<CAHNn8BUQ4V5DQTVsBHPKT+aZNT1avBUX-1SoFAbGzg6CdUdxzw@mail.gmail.com>
	<CAHAreOp1eTgRN89ub_Z-1e8=aP+BMeiS5NdjDzu4CNV5KWoftg@mail.gmail.com>
	<4FD6A744.6000805@creativetrax.com>
Message-ID: <CAHAreOrZo7k922G6yELFzbJVc6k0ziOHkqW851BSn4eBjoX7Cg@mail.gmail.com>

On Mon, Jun 11, 2012 at 7:19 PM, Jason Grout
<jason-sage at creativetrax.com> wrote:
> We used to think that was a high number in the Sage project too. ?But
> despite being on Sage Days *41* right now, we still have 1503 open
> tickets right now. ?And we just closed hundreds in the last release...

Well, keep in mind that we're a *tiny* project in terms of resources
and manpower compared to Sage, so a much smaller debt is already a
burden for us, I'm afraid.

If one day we get to 1500 open bugs, I go into witness protection...

f


From asmeurer at gmail.com  Mon Jun 11 22:55:01 2012
From: asmeurer at gmail.com (Aaron Meurer)
Date: Mon, 11 Jun 2012 20:55:01 -0600
Subject: [IPython-dev] 43 PRs merged in a week, not bad
In-Reply-To: <4FD6A744.6000805@creativetrax.com>
References: <CAHAreOp9NVZ_0MHSMkTHiRW44Or3X3hNHqyJb3Cf3kAbJUeXrg@mail.gmail.com>
	<CAHNn8BUQ4V5DQTVsBHPKT+aZNT1avBUX-1SoFAbGzg6CdUdxzw@mail.gmail.com>
	<CAHAreOp1eTgRN89ub_Z-1e8=aP+BMeiS5NdjDzu4CNV5KWoftg@mail.gmail.com>
	<4FD6A744.6000805@creativetrax.com>
Message-ID: <-4526613830129720063@unknownmsgid>

I've found an interesting metric to be the ratio of all issues that
are open. That probably will be hard to compute for you guys since
you've switched issue trackers and since GitHub makes it hard to
distinguish between issues and pull requests.

Aaron Meurer

On Jun 11, 2012, at 8:19 PM, Jason Grout <jason-sage at creativetrax.com> wrote:

> On 6/11/12 2:48 PM, Fernando Perez wrote:
>> I wish we had the manpower for a 'bug blitz' to bring that under 150
>> again, like we used to have...
>
> We used to think that was a high number in the Sage project too.  But
> despite being on Sage Days *41* right now, we still have 1503 open
> tickets right now.  And we just closed hundreds in the last release...
>
> Jason
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev


From fperez.net at gmail.com  Mon Jun 11 23:53:44 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Jun 2012 20:53:44 -0700
Subject: [IPython-dev] Should we silence the 'Parallel execution on
	engine(s): [0, 1, 2, 3]' messages?
Message-ID: <CAHAreOq=aryvhPxX4GHpeLSf1LUX5ttNNUW_sUbEjH72Qum5Eg@mail.gmail.com>

or at least provide a way to quiet parallel execution?  I'm adding
support to %%timeit to make it easy to time parallel codes more
intuitively (the async result has great low-level tools for this, but
for quick demos nothing beats slapping %%timeit atop a cell).  But
cells with %px in them will flood the console with the output, as
timeit runs the code many many times.

Thoughts?

f


From ellisonbg at gmail.com  Tue Jun 12 00:21:27 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Mon, 11 Jun 2012 21:21:27 -0700
Subject: [IPython-dev] Should we silence the 'Parallel execution on
 engine(s): [0, 1, 2, 3]' messages?
In-Reply-To: <CAHAreOq=aryvhPxX4GHpeLSf1LUX5ttNNUW_sUbEjH72Qum5Eg@mail.gmail.com>
References: <CAHAreOq=aryvhPxX4GHpeLSf1LUX5ttNNUW_sUbEjH72Qum5Eg@mail.gmail.com>
Message-ID: <CAH4pYpQS1uFF6tr3ygz_aZH1=bCeZNzwL5ZZRUMgZVt=qbd4eg@mail.gmail.com>

+1

It becomes especially annoying when there are many engines.

On Mon, Jun 11, 2012 at 8:53 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> or at least provide a way to quiet parallel execution? ?I'm adding
> support to %%timeit to make it easy to time parallel codes more
> intuitively (the async result has great low-level tools for this, but
> for quick demos nothing beats slapping %%timeit atop a cell). ?But
> cells with %px in them will flood the console with the output, as
> timeit runs the code many many times.
>
> Thoughts?
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



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


From fperez.net at gmail.com  Tue Jun 12 00:27:16 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Jun 2012 21:27:16 -0700
Subject: [IPython-dev] Should we silence the 'Parallel execution on
 engine(s): [0, 1, 2, 3]' messages?
In-Reply-To: <CAH4pYpQS1uFF6tr3ygz_aZH1=bCeZNzwL5ZZRUMgZVt=qbd4eg@mail.gmail.com>
References: <CAHAreOq=aryvhPxX4GHpeLSf1LUX5ttNNUW_sUbEjH72Qum5Eg@mail.gmail.com>
	<CAH4pYpQS1uFF6tr3ygz_aZH1=bCeZNzwL5ZZRUMgZVt=qbd4eg@mail.gmail.com>
Message-ID: <CAHAreOpUvDYGHisqJdn-sKYKf=7zfsXLC7q6h5xdpAZ1Us5+Zw@mail.gmail.com>

On Mon, Jun 11, 2012 at 9:21 PM, Brian Granger <ellisonbg at gmail.com> wrote:
> It becomes especially annoying when there are many engines.

OK, glad I'm not the only one :)  My vote would be to silence it by
default, offering a way to turn it on for demos or debugging.


From benjaminrk at gmail.com  Tue Jun 12 00:54:51 2012
From: benjaminrk at gmail.com (MinRK)
Date: Mon, 11 Jun 2012 21:54:51 -0700
Subject: [IPython-dev] should we make nodb the default hub backend?
In-Reply-To: <CAHAreOpDd9ZniC7JfB0wxpDD4G5V1nsGMPQhvq8URs89h=Em3Q@mail.gmail.com>
References: <CAHAreOpDd9ZniC7JfB0wxpDD4G5V1nsGMPQhvq8URs89h=Em3Q@mail.gmail.com>
Message-ID: <CAHNn8BUaPjASD5cK1uKoTMgMiLvyk2+wfBDB0icL8u=G495sNA@mail.gmail.com>

On Mon, Jun 11, 2012 at 7:52 PM, Fernando Perez <fperez.net at gmail.com>wrote:

> Hey guys,
>
> I'm wondering if we shouldn't make nodb the default... The new cell
> magics and the ability to combiine cython with parallel stuff make it
> so blindingly easy to parallelize existing codes (for certain
> patterns, of course!) that I bet people are *quickly* going to run
> into the problems with memory introduced by the persistent backends.
> I was just now parallelizing some Gibbs sampling code in Cython
> written by Chris Fonnesbeck for a panel at the R conference later this
> week, and all of a sudden noticed my machine grind to a halt.  I had
> only run the code a few times, and I was overwriting the same
> variables over and over, so I wasn't really thinking I'd be in memory
> trouble, but it was the hub's persistence that bit me.
>
> The DB backends are really useful only in more advanced circumstances,
> so I'm thinking that perhaps they should be activated knowingly by
> users who need their features, leaving the 'naive' patterns to behave
> a bit better.  What I'm worried is that right now, a fairly natural
> use pattern degrades badly and somewhat mysteriously (unless you
> really know what's under the hood).
>
> Thoughts?
>

I'm 50-50.  I generally think of NoDB as an optimization, which would
suggest that *it* should be the optional case for people in the know,
rather than the other way around.

I don't view delayed result retrieval as "advanced", but I think has turned
out to be rare, so I would be okay with this.  The one thing it changes is
adding big warnings to the docs, because a huge swath of features would be
totally unavailable by default.

In fact, with NoDB the Hub does very nearly nothing, and can be killed
entirely after engines and clients are connected with ~no consequences.

-MinRK


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

From fperez.net at gmail.com  Tue Jun 12 01:01:01 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Jun 2012 22:01:01 -0700
Subject: [IPython-dev] should we make nodb the default hub backend?
In-Reply-To: <CAHNn8BUaPjASD5cK1uKoTMgMiLvyk2+wfBDB0icL8u=G495sNA@mail.gmail.com>
References: <CAHAreOpDd9ZniC7JfB0wxpDD4G5V1nsGMPQhvq8URs89h=Em3Q@mail.gmail.com>
	<CAHNn8BUaPjASD5cK1uKoTMgMiLvyk2+wfBDB0icL8u=G495sNA@mail.gmail.com>
Message-ID: <CAHAreOpaKJ51nSn1fHh1Tsm6Cki8_L8+wXP_bC8CZsnL3=VO6Q@mail.gmail.com>

On Mon, Jun 11, 2012 at 9:54 PM, MinRK <benjaminrk at gmail.com> wrote:
> I'm 50-50. ?I generally think of NoDB as an optimization, which would
> suggest that *it* should be the optional case for people in the know, rather
> than the other way around.


I guess what we're finding is that it can cause a pretty nasty failure
mode with fairly naive and natural use patterns.  Alternatively, would
it be possible for the dictdb to (at least by default) drop every
result that gets retrieved?  That would keep the ability to do delayed
retrieval while perhaps lowering the memory pressure under common use
patterns.

> I don't view delayed result retrieval as "advanced", but I think has turned
> out to be rare, so I would be okay with this. ?The one thing it changes is
> adding big warnings to the docs, because a huge swath of features would be
> totally unavailable by default.

I'm not saying I'm too happy with the idea, but my experience today
has made me lean towards it more, thinking of 'regular' users...

f


From benjaminrk at gmail.com  Tue Jun 12 01:16:30 2012
From: benjaminrk at gmail.com (MinRK)
Date: Mon, 11 Jun 2012 22:16:30 -0700
Subject: [IPython-dev] Should we silence the 'Parallel execution on
 engine(s): [0, 1, 2, 3]' messages?
In-Reply-To: <CAHAreOpUvDYGHisqJdn-sKYKf=7zfsXLC7q6h5xdpAZ1Us5+Zw@mail.gmail.com>
References: <CAHAreOq=aryvhPxX4GHpeLSf1LUX5ttNNUW_sUbEjH72Qum5Eg@mail.gmail.com>
	<CAH4pYpQS1uFF6tr3ygz_aZH1=bCeZNzwL5ZZRUMgZVt=qbd4eg@mail.gmail.com>
	<CAHAreOpUvDYGHisqJdn-sKYKf=7zfsXLC7q6h5xdpAZ1Us5+Zw@mail.gmail.com>
Message-ID: <CAHNn8BWmb+x-DpyMngfqhxKKMy-u7ZR6mWzNsM=1o6hc7VqGtg@mail.gmail.com>

On Mon, Jun 11, 2012 at 9:27 PM, Fernando Perez <fperez.net at gmail.com>wrote:

> On Mon, Jun 11, 2012 at 9:21 PM, Brian Granger <ellisonbg at gmail.com>
> wrote:
>


>  > It becomes especially annoying when there are many engines.
>

PR #1893 makes this particular note irrelevant as it elides long lists of
engines, but I will add `%pxconfig --[no-]verbose` there.


>
> OK, glad I'm not the only one :)  My vote would be to silence it by
> default, offering a way to turn it on for demos or debugging.
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120611/4fd51fd3/attachment.html>

From benjaminrk at gmail.com  Tue Jun 12 01:30:17 2012
From: benjaminrk at gmail.com (MinRK)
Date: Mon, 11 Jun 2012 22:30:17 -0700
Subject: [IPython-dev] should we make nodb the default hub backend?
In-Reply-To: <CAHAreOpaKJ51nSn1fHh1Tsm6Cki8_L8+wXP_bC8CZsnL3=VO6Q@mail.gmail.com>
References: <CAHAreOpDd9ZniC7JfB0wxpDD4G5V1nsGMPQhvq8URs89h=Em3Q@mail.gmail.com>
	<CAHNn8BUaPjASD5cK1uKoTMgMiLvyk2+wfBDB0icL8u=G495sNA@mail.gmail.com>
	<CAHAreOpaKJ51nSn1fHh1Tsm6Cki8_L8+wXP_bC8CZsnL3=VO6Q@mail.gmail.com>
Message-ID: <CAHNn8BU5vHm_a62FMix-en4PWDFgzJTHPr5Jf32wBwoiCSfbqA@mail.gmail.com>

On Mon, Jun 11, 2012 at 10:01 PM, Fernando Perez <fperez.net at gmail.com>wrote:

> On Mon, Jun 11, 2012 at 9:54 PM, MinRK <benjaminrk at gmail.com> wrote:
> > I'm 50-50.  I generally think of NoDB as an optimization, which would
> > suggest that *it* should be the optional case for people in the know,
> rather
> > than the other way around.
>
>
> I guess what we're finding is that it can cause a pretty nasty failure
> mode with fairly naive and natural use patterns.


Yes, there is cost to storing large amounts of data.


> Alternatively, would
> it be possible for the dictdb to (at least by default) drop every
> result that gets retrieved?

 That would keep the ability to do delayed
> retrieval while perhaps lowering the memory pressure under common use
> patterns.
>

What do you mean by retrieved?  Under the normal circumstances you
described, exactly zero results are retrieved from the Hub, so this would
have no effect other than breaking delayed retrievals after the first.

Remember, the Hub is not involved *in any way* in the results of basic
execution/reply, and it can be removed entirely with no effect whatsoever
on simple executions.


>
> > I don't view delayed result retrieval as "advanced", but I think has
> turned
> > out to be rare, so I would be okay with this.  The one thing it changes
> is
> > adding big warnings to the docs, because a huge swath of features would
> be
> > totally unavailable by default.
>
> I'm not saying I'm too happy with the idea, but my experience today
> has made me lean towards it more, thinking of 'regular' users...
>

I know, it makes sense.

Another option could be for DictDB to have a finite history, and just dump
old results if it has too many.


> It's also widely varied - If each task sends/receives 10MB arrays, it only
taks a few hundred to be a problem.  If, on the other hand, it's mostly
simple commands without large data or side effects, it takes millions
before there is an issue.  This makes the above suggestion difficult,
because for some users a history of 100 is huge, while for others it's tiny.


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

From fperez.net at gmail.com  Tue Jun 12 01:47:06 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Jun 2012 22:47:06 -0700
Subject: [IPython-dev] should we make nodb the default hub backend?
In-Reply-To: <CAHNn8BU5vHm_a62FMix-en4PWDFgzJTHPr5Jf32wBwoiCSfbqA@mail.gmail.com>
References: <CAHAreOpDd9ZniC7JfB0wxpDD4G5V1nsGMPQhvq8URs89h=Em3Q@mail.gmail.com>
	<CAHNn8BUaPjASD5cK1uKoTMgMiLvyk2+wfBDB0icL8u=G495sNA@mail.gmail.com>
	<CAHAreOpaKJ51nSn1fHh1Tsm6Cki8_L8+wXP_bC8CZsnL3=VO6Q@mail.gmail.com>
	<CAHNn8BU5vHm_a62FMix-en4PWDFgzJTHPr5Jf32wBwoiCSfbqA@mail.gmail.com>
Message-ID: <CAHAreOpdzPi+dodHri+_T8hNmo3gfW1dXVB-g3gi1y+Qg_mq8Q@mail.gmail.com>

On Mon, Jun 11, 2012 at 10:30 PM, MinRK <benjaminrk at gmail.com> wrote:
> What do you mean by retrieved? ?Under the normal circumstances you
> described, exactly zero results are retrieved from the Hub, so this would
> have no effect other than breaking delayed retrievals after the first.
>
> Remember, the Hub is not involved *in any way* in the results of basic
> execution/reply, and it can be removed entirely with no effect whatsoever on
> simple executions.

Ah, I was making a mistaken assumption here; never mind then.

> Another option could be for DictDB to have a finite history, and just dump
> old results if it has too many.
>
>
> It's also widely varied - If each task sends/receives 10MB arrays, it only
> taks a few hundred to be a problem. ?If, on the other hand, it's mostly
> simple commands without large data or side effects, it takes millions before
> there is an issue. ?This makes the above suggestion difficult, because for
> some users a history of 100 is huge, while for others it's tiny.

Yes, that's really the problem: it's memory size, not length of the
history.  And detecting memory pressure in Python isn't too easy, it
would require separate codepaths for pickled results and numpy arrays,
which appear small to most normal python introspection tools (which
don't see their buffers).

I don't know if we want to fiddle with code of that nature this close
to a release, or just go to nodb for now, and think about this issue
with the calm of the 0.14 period.  I'm leaning towards that...

f


From fperez.net at gmail.com  Tue Jun 12 01:53:39 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Jun 2012 22:53:39 -0700
Subject: [IPython-dev] I'm on the doctest failures...
Message-ID: <CAHAreOr9EeaV0tMOVyjWRqKUdRD=jPcJUfEdPxH1UPdjdmEueA@mail.gmail.com>

will commit straight to master in a minute


From benjaminrk at gmail.com  Tue Jun 12 02:01:12 2012
From: benjaminrk at gmail.com (Min RK)
Date: Mon, 11 Jun 2012 23:01:12 -0700
Subject: [IPython-dev] should we make nodb the default hub backend?
In-Reply-To: <CAHAreOpdzPi+dodHri+_T8hNmo3gfW1dXVB-g3gi1y+Qg_mq8Q@mail.gmail.com>
References: <CAHAreOpDd9ZniC7JfB0wxpDD4G5V1nsGMPQhvq8URs89h=Em3Q@mail.gmail.com>
	<CAHNn8BUaPjASD5cK1uKoTMgMiLvyk2+wfBDB0icL8u=G495sNA@mail.gmail.com>
	<CAHAreOpaKJ51nSn1fHh1Tsm6Cki8_L8+wXP_bC8CZsnL3=VO6Q@mail.gmail.com>
	<CAHNn8BU5vHm_a62FMix-en4PWDFgzJTHPr5Jf32wBwoiCSfbqA@mail.gmail.com>
	<CAHAreOpdzPi+dodHri+_T8hNmo3gfW1dXVB-g3gi1y+Qg_mq8Q@mail.gmail.com>
Message-ID: <CDF21EF5-6D75-4A9C-A726-50AC2CD0A3D5@gmail.com>



On Jun 11, 2012, at 22:47, Fernando Perez <fperez.net at gmail.com> wrote:

> On Mon, Jun 11, 2012 at 10:30 PM, MinRK <benjaminrk at gmail.com> wrote:
>> What do you mean by retrieved?  Under the normal circumstances you
>> described, exactly zero results are retrieved from the Hub, so this would
>> have no effect other than breaking delayed retrievals after the first.
>> 
>> Remember, the Hub is not involved *in any way* in the results of basic
>> execution/reply, and it can be removed entirely with no effect whatsoever on
>> simple executions.
> 
> Ah, I was making a mistaken assumption here; never mind then.
> 
>> Another option could be for DictDB to have a finite history, and just dump
>> old results if it has too many.
>> 
>> 
>> It's also widely varied - If each task sends/receives 10MB arrays, it only
>> taks a few hundred to be a problem.  If, on the other hand, it's mostly
>> simple commands without large data or side effects, it takes millions before
>> there is an issue.  This makes the above suggestion difficult, because for
>> some users a history of 100 is huge, while for others it's tiny.
> 
> Yes, that's really the problem: it's memory size, not length of the
> history.  And detecting memory pressure in Python isn't too easy, it
> would require separate codepaths for pickled results and numpy arrays,
> which appear small to most normal python introspection tools (which
> don't see their buffers).
> 
> I don't know if we want to fiddle with code of that nature this close
> to a release, or just go to nodb for now, and think about this issue
> with the calm of the 0.14 period.  I'm leaning towards that...

I agree, switching to nodb for 0.13 is fine, but I wouldn't try to get a clever self-limiting dictdb into this release.

The Parallel code, and Hub in particular, are due for a pretty big pass (two parts of which are already PRs), which I want to get into 0.14, but not this month.


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


From fperez.net at gmail.com  Tue Jun 12 02:09:20 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Jun 2012 23:09:20 -0700
Subject: [IPython-dev] should we make nodb the default hub backend?
In-Reply-To: <CDF21EF5-6D75-4A9C-A726-50AC2CD0A3D5@gmail.com>
References: <CAHAreOpDd9ZniC7JfB0wxpDD4G5V1nsGMPQhvq8URs89h=Em3Q@mail.gmail.com>
	<CAHNn8BUaPjASD5cK1uKoTMgMiLvyk2+wfBDB0icL8u=G495sNA@mail.gmail.com>
	<CAHAreOpaKJ51nSn1fHh1Tsm6Cki8_L8+wXP_bC8CZsnL3=VO6Q@mail.gmail.com>
	<CAHNn8BU5vHm_a62FMix-en4PWDFgzJTHPr5Jf32wBwoiCSfbqA@mail.gmail.com>
	<CAHAreOpdzPi+dodHri+_T8hNmo3gfW1dXVB-g3gi1y+Qg_mq8Q@mail.gmail.com>
	<CDF21EF5-6D75-4A9C-A726-50AC2CD0A3D5@gmail.com>
Message-ID: <CAHAreOqqWhuG-H6PUYV5fJPc-bzudZ5kqad1YPfjp62ZS2Ttcw@mail.gmail.com>

On Mon, Jun 11, 2012 at 11:01 PM, Min RK <benjaminrk at gmail.com> wrote:
> I agree, switching to nodb for 0.13 is fine, but I wouldn't try to get a clever self-limiting dictdb into this release.
>
> The Parallel code, and Hub in particular, are due for a pretty big pass (two parts of which are already PRs), which I want to get into 0.14, but not this month.

OK, that sounds like a good plan.  We get 0.13 just with nodb, and
then we rework the internals early in the 0.14 cycle so we have a
chance to let it stabilize.

Cheers,

f


From benjaminrk at gmail.com  Tue Jun 12 02:38:01 2012
From: benjaminrk at gmail.com (Min RK)
Date: Mon, 11 Jun 2012 23:38:01 -0700
Subject: [IPython-dev] should we make nodb the default hub backend?
In-Reply-To: <CAHAreOqqWhuG-H6PUYV5fJPc-bzudZ5kqad1YPfjp62ZS2Ttcw@mail.gmail.com>
References: <CAHAreOpDd9ZniC7JfB0wxpDD4G5V1nsGMPQhvq8URs89h=Em3Q@mail.gmail.com>
	<CAHNn8BUaPjASD5cK1uKoTMgMiLvyk2+wfBDB0icL8u=G495sNA@mail.gmail.com>
	<CAHAreOpaKJ51nSn1fHh1Tsm6Cki8_L8+wXP_bC8CZsnL3=VO6Q@mail.gmail.com>
	<CAHNn8BU5vHm_a62FMix-en4PWDFgzJTHPr5Jf32wBwoiCSfbqA@mail.gmail.com>
	<CAHAreOpdzPi+dodHri+_T8hNmo3gfW1dXVB-g3gi1y+Qg_mq8Q@mail.gmail.com>
	<CDF21EF5-6D75-4A9C-A726-50AC2CD0A3D5@gmail.com>
	<CAHAreOqqWhuG-H6PUYV5fJPc-bzudZ5kqad1YPfjp62ZS2Ttcw@mail.gmail.com>
Message-ID: <4003840C-1756-46E5-BA1B-F17CACC9F9C4@gmail.com>


On Jun 11, 2012, at 23:09, Fernando Perez <fperez.net at gmail.com> wrote:

> On Mon, Jun 11, 2012 at 11:01 PM, Min RK <benjaminrk at gmail.com> wrote:
>> I agree, switching to nodb for 0.13 is fine, but I wouldn't try to get a clever self-limiting dictdb into this release.
>> 
>> The Parallel code, and Hub in particular, are due for a pretty big pass (two parts of which are already PRs), which I want to get into 0.14, but not this month.
> 
> OK, that sounds like a good plan.  We get 0.13 just with nodb, and
> then we rework the internals early in the 0.14 cycle so we have a
> chance to let it stabilize.
> 

Sounds good to me. I'll give the docs a look, and do a PR with the switch tomorrow.  it's entirely possible that I did a bad job documenting them in the first place, in which case there would not be much to do.

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


From fperez.net at gmail.com  Tue Jun 12 02:42:57 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Jun 2012 23:42:57 -0700
Subject: [IPython-dev] should we make nodb the default hub backend?
In-Reply-To: <4003840C-1756-46E5-BA1B-F17CACC9F9C4@gmail.com>
References: <CAHAreOpDd9ZniC7JfB0wxpDD4G5V1nsGMPQhvq8URs89h=Em3Q@mail.gmail.com>
	<CAHNn8BUaPjASD5cK1uKoTMgMiLvyk2+wfBDB0icL8u=G495sNA@mail.gmail.com>
	<CAHAreOpaKJ51nSn1fHh1Tsm6Cki8_L8+wXP_bC8CZsnL3=VO6Q@mail.gmail.com>
	<CAHNn8BU5vHm_a62FMix-en4PWDFgzJTHPr5Jf32wBwoiCSfbqA@mail.gmail.com>
	<CAHAreOpdzPi+dodHri+_T8hNmo3gfW1dXVB-g3gi1y+Qg_mq8Q@mail.gmail.com>
	<CDF21EF5-6D75-4A9C-A726-50AC2CD0A3D5@gmail.com>
	<CAHAreOqqWhuG-H6PUYV5fJPc-bzudZ5kqad1YPfjp62ZS2Ttcw@mail.gmail.com>
	<4003840C-1756-46E5-BA1B-F17CACC9F9C4@gmail.com>
Message-ID: <CAHAreOoJ8AMrbtg=va+1dFYZCyzp6v8ZxJprfsP2i3xXTqYq7g@mail.gmail.com>

On Mon, Jun 11, 2012 at 11:38 PM, Min RK <benjaminrk at gmail.com> wrote:
> Sounds good to me. I'll give the docs a look, and do a PR with the switch tomorrow. ?it's entirely possible that I did a bad job documenting them in the first place, in which case there would not be much to do.

Perfect, thanks!


From fperez.net at gmail.com  Tue Jun 12 02:50:36 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Jun 2012 23:50:36 -0700
Subject: [IPython-dev] 43 PRs merged in a week, not bad
In-Reply-To: <-4526613830129720063@unknownmsgid>
References: <CAHAreOp9NVZ_0MHSMkTHiRW44Or3X3hNHqyJb3Cf3kAbJUeXrg@mail.gmail.com>
	<CAHNn8BUQ4V5DQTVsBHPKT+aZNT1avBUX-1SoFAbGzg6CdUdxzw@mail.gmail.com>
	<CAHAreOp1eTgRN89ub_Z-1e8=aP+BMeiS5NdjDzu4CNV5KWoftg@mail.gmail.com>
	<4FD6A744.6000805@creativetrax.com> <-4526613830129720063@unknownmsgid>
Message-ID: <CAHAreOqLv4AAYfcCT9-dncrZzHAF2UJp6xQ5P+axnncQKrDh3g@mail.gmail.com>

On Mon, Jun 11, 2012 at 7:55 PM, Aaron Meurer <asmeurer at gmail.com> wrote:
> I've found an interesting metric to be the ratio of all issues that
> are open. That probably will be hard to compute for you guys since
> you've switched issue trackers and since GitHub makes it hard to
> distinguish between issues and pull requests.

Still, it can be useful.  And the launchpad/bzr combination is so
horrificly bad, that in more than two years of using it I think we
just had a couple hundred issues total.  I ended up porting ~130 when
I wrote the code to transfer them.  In comparison, we're now reaching
2000 total in less than two years of being at github.  So the transfer
of trackers doesn't skew the numbers too badly, I think.

The current ones are 298 open/1625 closed ones.  I guess if we ignore
the first 6-12 months of history to let the system 'thermalize', it
would be nice to see the evolution of this metric afterwards.

Cheers,

f


From jorgen.stenarson at kroywen.se  Tue Jun 12 11:41:57 2012
From: jorgen.stenarson at kroywen.se (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Tue, 12 Jun 2012 17:41:57 +0200
Subject: [IPython-dev] All tests pass on windows!
In-Reply-To: <CAHAreOp65TgBp-KMJ6YRS1Y8sut--rQexTNud6NdQ_m84REL0A@mail.gmail.com>
References: <4FD66C26.9070902@kroywen.se>
	<CAHNn8BU=RJRpuakcgFRYL-pUeDTv0tRY6NWz12zCn6YZbmX0qw@mail.gmail.com>
	<CAHAreOp65TgBp-KMJ6YRS1Y8sut--rQexTNud6NdQ_m84REL0A@mail.gmail.com>
Message-ID: <4FD76345.5080700@kroywen.se>

Fernando Perez skrev 2012-06-12 01:42:
> On Mon, Jun 11, 2012 at 3:09 PM, MinRK<benjaminrk at gmail.com>  wrote:
>>  Hooray!  Thanks for all your help!  This is always a big hurdle as we
>>  prepare a release.
>
> Indeed, you've put a ton of work on this and we really appreciate it.
> It's especially valuable right now that we're close to a release, but
> let's try to keep things that way in the future, so you don't have to
> do big cleanup pushes :)
>

Indeed, to that end I will start to run the testscript for
shiningpanda as a schduled job on my home machine. This means it should
run once a day. At least on days I'm at home. I could also add a run on 
python 3.2 but that would require some configuration work for Thomas so 
I get a URL to trigger the upload. Starting friday I will be gone for 
about 10 days (conference in Montreal).

/J?rgen



From takowl at gmail.com  Tue Jun 12 12:24:56 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Tue, 12 Jun 2012 17:24:56 +0100
Subject: [IPython-dev] All tests pass on windows!
In-Reply-To: <4FD76345.5080700@kroywen.se>
References: <4FD66C26.9070902@kroywen.se>
	<CAHNn8BU=RJRpuakcgFRYL-pUeDTv0tRY6NWz12zCn6YZbmX0qw@mail.gmail.com>
	<CAHAreOp65TgBp-KMJ6YRS1Y8sut--rQexTNud6NdQ_m84REL0A@mail.gmail.com>
	<4FD76345.5080700@kroywen.se>
Message-ID: <CAOvn4qhtBnK52P0_yRy0BgmPBgaQa=61km5Y=EZtUuVeCAJbmQ@mail.gmail.com>

On 12 June 2012 16:41, J?rgen Stenarson <jorgen.stenarson at kroywen.se> wrote:
> I could also add a run on
> python 3.2 but that would require some configuration work for Thomas so
> I get a URL to trigger the upload. Starting friday I will be gone for
> about 10 days (conference in Montreal).

That would definitely be useful, and it's pretty simple for me to set
up. I'll send you the URL in a minute.

Thanks,
Thomas


From benjaminrk at gmail.com  Tue Jun 12 12:58:23 2012
From: benjaminrk at gmail.com (MinRK)
Date: Tue, 12 Jun 2012 09:58:23 -0700
Subject: [IPython-dev] should we make nodb the default hub backend?
In-Reply-To: <CAHAreOoJ8AMrbtg=va+1dFYZCyzp6v8ZxJprfsP2i3xXTqYq7g@mail.gmail.com>
References: <CAHAreOpDd9ZniC7JfB0wxpDD4G5V1nsGMPQhvq8URs89h=Em3Q@mail.gmail.com>
	<CAHNn8BUaPjASD5cK1uKoTMgMiLvyk2+wfBDB0icL8u=G495sNA@mail.gmail.com>
	<CAHAreOpaKJ51nSn1fHh1Tsm6Cki8_L8+wXP_bC8CZsnL3=VO6Q@mail.gmail.com>
	<CAHNn8BU5vHm_a62FMix-en4PWDFgzJTHPr5Jf32wBwoiCSfbqA@mail.gmail.com>
	<CAHAreOpdzPi+dodHri+_T8hNmo3gfW1dXVB-g3gi1y+Qg_mq8Q@mail.gmail.com>
	<CDF21EF5-6D75-4A9C-A726-50AC2CD0A3D5@gmail.com>
	<CAHAreOqqWhuG-H6PUYV5fJPc-bzudZ5kqad1YPfjp62ZS2Ttcw@mail.gmail.com>
	<4003840C-1756-46E5-BA1B-F17CACC9F9C4@gmail.com>
	<CAHAreOoJ8AMrbtg=va+1dFYZCyzp6v8ZxJprfsP2i3xXTqYq7g@mail.gmail.com>
Message-ID: <CAHNn8BVZwevZjhWb9LKdR5YSYJLj9tu_6Nv9ttMBjyOgr3kqJA@mail.gmail.com>

PR Issued <https://github.com/ipython/ipython/pull/1928>.

As for the difficulty of measuring size, it shouldn't be a problem in the
Hub, because all the data is just raw buffers, not unserialized Python
objects.  So we can just use `len` as an accurate measure.

-MinRK

On Mon, Jun 11, 2012 at 11:42 PM, Fernando Perez <fperez.net at gmail.com>wrote:

> On Mon, Jun 11, 2012 at 11:38 PM, Min RK <benjaminrk at gmail.com> wrote:
> > Sounds good to me. I'll give the docs a look, and do a PR with the
> switch tomorrow.  it's entirely possible that I did a bad job documenting
> them in the first place, in which case there would not be much to do.
>
> Perfect, thanks!
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120612/b2649145/attachment.html>

From jorgen.stenarson at kroywen.se  Tue Jun 12 13:39:59 2012
From: jorgen.stenarson at kroywen.se (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Tue, 12 Jun 2012 19:39:59 +0200
Subject: [IPython-dev] All tests pass on windows!
In-Reply-To: <CAOvn4qhtBnK52P0_yRy0BgmPBgaQa=61km5Y=EZtUuVeCAJbmQ@mail.gmail.com>
References: <4FD66C26.9070902@kroywen.se>
	<CAHNn8BU=RJRpuakcgFRYL-pUeDTv0tRY6NWz12zCn6YZbmX0qw@mail.gmail.com>
	<CAHAreOp65TgBp-KMJ6YRS1Y8sut--rQexTNud6NdQ_m84REL0A@mail.gmail.com>
	<4FD76345.5080700@kroywen.se>
	<CAOvn4qhtBnK52P0_yRy0BgmPBgaQa=61km5Y=EZtUuVeCAJbmQ@mail.gmail.com>
Message-ID: <4FD77EEF.9010100@kroywen.se>

Thomas Kluyver skrev 2012-06-12 18:24:
> On 12 June 2012 16:41, J?rgen Stenarson<jorgen.stenarson at kroywen.se>  wrote:
>>  I could also add a run on
>>  python 3.2 but that would require some configuration work for Thomas so
>>  I get a URL to trigger the upload. Starting friday I will be gone for
>>  about 10 days (conference in Montreal).
>
> That would definitely be useful, and it's pretty simple for me to set
> up. I'll send you the URL in a minute.
>

I just ran the tests and now we have new failures but only on 3.2

One of the failures is a doctest that looks for a u"..." string. What is 
the recommended way to write robust doctests that work on 3.2?

/J?rgen


From takowl at gmail.com  Tue Jun 12 13:48:01 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Tue, 12 Jun 2012 18:48:01 +0100
Subject: [IPython-dev] All tests pass on windows!
In-Reply-To: <4FD77EEF.9010100@kroywen.se>
References: <4FD66C26.9070902@kroywen.se>
	<CAHNn8BU=RJRpuakcgFRYL-pUeDTv0tRY6NWz12zCn6YZbmX0qw@mail.gmail.com>
	<CAHAreOp65TgBp-KMJ6YRS1Y8sut--rQexTNud6NdQ_m84REL0A@mail.gmail.com>
	<4FD76345.5080700@kroywen.se>
	<CAOvn4qhtBnK52P0_yRy0BgmPBgaQa=61km5Y=EZtUuVeCAJbmQ@mail.gmail.com>
	<4FD77EEF.9010100@kroywen.se>
Message-ID: <CAOvn4qjHjR-v1jf9w+ZP=gzoaZrQ5g_jqL_L+boy19Fgfk26Jw@mail.gmail.com>

On 12 June 2012 18:39, J?rgen Stenarson <jorgen.stenarson at kroywen.se> wrote:
> One of the failures is a doctest that looks for a u"..." string. What is
> the recommended way to write robust doctests that work on 3.2?

If possible, the recommended way is to write regular tests, because
doctests are regularly a headache. For things that do need doctests
with unicode strings in, write the example like '{u}"thestring" ', and
wrap it in py3compat.u_format() - or apply u_format as a decorator to
change a function's docstring.

Thanks,
Thomas


From fperez.net at gmail.com  Tue Jun 12 14:29:21 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 12 Jun 2012 11:29:21 -0700
Subject: [IPython-dev] All tests pass on windows!
In-Reply-To: <CAOvn4qjHjR-v1jf9w+ZP=gzoaZrQ5g_jqL_L+boy19Fgfk26Jw@mail.gmail.com>
References: <4FD66C26.9070902@kroywen.se>
	<CAHNn8BU=RJRpuakcgFRYL-pUeDTv0tRY6NWz12zCn6YZbmX0qw@mail.gmail.com>
	<CAHAreOp65TgBp-KMJ6YRS1Y8sut--rQexTNud6NdQ_m84REL0A@mail.gmail.com>
	<4FD76345.5080700@kroywen.se>
	<CAOvn4qhtBnK52P0_yRy0BgmPBgaQa=61km5Y=EZtUuVeCAJbmQ@mail.gmail.com>
	<4FD77EEF.9010100@kroywen.se>
	<CAOvn4qjHjR-v1jf9w+ZP=gzoaZrQ5g_jqL_L+boy19Fgfk26Jw@mail.gmail.com>
Message-ID: <CAHAreOoVA-X=5JsHOgoK29cPcyDpm+WGehA3Gqyq+=ZERt4FuQ@mail.gmail.com>

On Tue, Jun 12, 2012 at 10:48 AM, Thomas Kluyver <takowl at gmail.com> wrote:
> If possible, the recommended way is to write regular tests, because
> doctests are regularly a headache. For things that do need doctests
> with unicode strings in, write the example like '{u}"thestring" ', and
> wrap it in py3compat.u_format() - or apply u_format as a decorator to
> change a function's docstring.

And as a general note (I'd said this to Thomas somewhere on github
already): it's *totally OK* to remove doctests if we replace what they
test with 'normal tests'.  We used a lot more docetsts early on, when
we were trying to bootstrap IPython's testing support from nearly
zero.  The internals of IPython were so messy and hard to cleanly test
in isolation that the easiest way to get started was to hack a doctest
plugin that would recognize copy-pasted IPython sessions from the
terminal and could reproduce them whole.  But now that we're well past
that point, moving forward it's far cleaner to user regular
programmatic tests, and leave interactive sessions to be only used for
their educational value as examples (it's OK if they are also a simple
and easy doctest, but the main point should be that they serve as
useful documentation, not as tests).

Cheers,

f


From fperez.net at gmail.com  Tue Jun 12 14:32:14 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 12 Jun 2012 11:32:14 -0700
Subject: [IPython-dev] should we make nodb the default hub backend?
In-Reply-To: <CAHNn8BVZwevZjhWb9LKdR5YSYJLj9tu_6Nv9ttMBjyOgr3kqJA@mail.gmail.com>
References: <CAHAreOpDd9ZniC7JfB0wxpDD4G5V1nsGMPQhvq8URs89h=Em3Q@mail.gmail.com>
	<CAHNn8BUaPjASD5cK1uKoTMgMiLvyk2+wfBDB0icL8u=G495sNA@mail.gmail.com>
	<CAHAreOpaKJ51nSn1fHh1Tsm6Cki8_L8+wXP_bC8CZsnL3=VO6Q@mail.gmail.com>
	<CAHNn8BU5vHm_a62FMix-en4PWDFgzJTHPr5Jf32wBwoiCSfbqA@mail.gmail.com>
	<CAHAreOpdzPi+dodHri+_T8hNmo3gfW1dXVB-g3gi1y+Qg_mq8Q@mail.gmail.com>
	<CDF21EF5-6D75-4A9C-A726-50AC2CD0A3D5@gmail.com>
	<CAHAreOqqWhuG-H6PUYV5fJPc-bzudZ5kqad1YPfjp62ZS2Ttcw@mail.gmail.com>
	<4003840C-1756-46E5-BA1B-F17CACC9F9C4@gmail.com>
	<CAHAreOoJ8AMrbtg=va+1dFYZCyzp6v8ZxJprfsP2i3xXTqYq7g@mail.gmail.com>
	<CAHNn8BVZwevZjhWb9LKdR5YSYJLj9tu_6Nv9ttMBjyOgr3kqJA@mail.gmail.com>
Message-ID: <CAHAreOohVqkyV6y2M2qyN5C0hHz822KWSa515YMksBFEafDrLw@mail.gmail.com>

On Tue, Jun 12, 2012 at 9:58 AM, MinRK <benjaminrk at gmail.com> wrote:
> PR Issued.

Great, thanks!  Will review soon.

> As for the difficulty of measuring size, it shouldn't be a problem in the
> Hub, because all the data is just raw buffers, not unserialized Python
> objects. ?So we can just use `len` as an accurate measure.

Ah, that's excellent news.  For 0.14 we could come up with a smarter
cache expiration policy that uses a combination of history age and
memory pressure, then.  But let's not rock the boat too much for now,
I think this is as good as we need for release.

Best,

f


From carl.input at gmail.com  Tue Jun 12 14:52:31 2012
From: carl.input at gmail.com (Carl Smith)
Date: Tue, 12 Jun 2012 19:52:31 +0100
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAP-uhDcJ6ckhv6wQRgfPmr_EDy4_FSG+U6G=pN4tiQ=5dN3C9Q@mail.gmail.com>
References: <CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
	<CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>
	<CAOvn4qjs5ifL_HKj1qJWkmNdQ+4KUSQtgCE37QbLX3Yy_y6DcA@mail.gmail.com>
	<CAHAreOp_+joxdeZTQ1ZEOOU4w=euqtESMTisVSDA8oRx=RdCHg@mail.gmail.com>
	<CAOvn4qhKg9QM8u-BQvrk+PazfRBpAYtF_7Vh7-YHGYAWmHiABw@mail.gmail.com>
	<CAHAreOr+c3CS_NWOMPwUuCXN=-t5vPswzEvS6QUtX+sUKq=yrw@mail.gmail.com>
	<CAOvn4qgF+am8ScvsCtC7pXxxmtfEsY6EixnbHdYwsWLO+HQ31g@mail.gmail.com>
	<CAHAreOpqk=KuSLJdDS1n7w_DYjGhjtA_RJdxAfur_iQ2Lq_iig@mail.gmail.com>
	<CAP-uhDcMnCaM=47=qQFmO+LoxMACOsECEU=_HETvPmJGBcdEFQ@mail.gmail.com>
	<CAOvn4qhT5uW-VTJrQzikvh=QV5A+mb8Htt37rk-Vu0iwepwOSA@mail.gmail.com>
	<20120611121145.GA3470@volans.logilab.fr>
	<CAHAreOrTZ9Wo8o1n+VjRd-_U1LAwxiXPPx7vYjOzrtsqyuN_OQ@mail.gmail.com>
	<CAP-uhDcJ6ckhv6wQRgfPmr_EDy4_FSG+U6G=pN4tiQ=5dN3C9Q@mail.gmail.com>
Message-ID: <CAP-uhDenjmq2eZDL+7wNA9tfy-SbcGTMbhw43E3d00KSArQNUw@mail.gmail.com>

I've done some more on NBCloud. It's looking rubbish in FF at the mo. It's
a ten minute fix, but I'm at work til midnight. I'll add the stuff Thomas
suggested to the docs as well.

I hope to get Stop, Start, Reboot and Terminate in tonight too. Then the
whole thing needs a tidy up. Is there anything else I really need to add
before tidying? I can add all the jewelery later on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120612/14a5366a/attachment.html>

From jorgen.stenarson at kroywen.se  Tue Jun 12 14:54:17 2012
From: jorgen.stenarson at kroywen.se (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Tue, 12 Jun 2012 20:54:17 +0200
Subject: [IPython-dev] All tests pass on windows!
In-Reply-To: <CAHAreOoVA-X=5JsHOgoK29cPcyDpm+WGehA3Gqyq+=ZERt4FuQ@mail.gmail.com>
References: <4FD66C26.9070902@kroywen.se>
	<CAHNn8BU=RJRpuakcgFRYL-pUeDTv0tRY6NWz12zCn6YZbmX0qw@mail.gmail.com>
	<CAHAreOp65TgBp-KMJ6YRS1Y8sut--rQexTNud6NdQ_m84REL0A@mail.gmail.com>
	<4FD76345.5080700@kroywen.se>
	<CAOvn4qhtBnK52P0_yRy0BgmPBgaQa=61km5Y=EZtUuVeCAJbmQ@mail.gmail.com>
	<4FD77EEF.9010100@kroywen.se>
	<CAOvn4qjHjR-v1jf9w+ZP=gzoaZrQ5g_jqL_L+boy19Fgfk26Jw@mail.gmail.com>
	<CAHAreOoVA-X=5JsHOgoK29cPcyDpm+WGehA3Gqyq+=ZERt4FuQ@mail.gmail.com>
Message-ID: <4FD79059.5040501@kroywen.se>

Fernando Perez skrev 2012-06-12 20:29:
> And as a general note (I'd said this to Thomas somewhere on github
> already): it's *totally OK* to remove doctests if we replace what they
> test with 'normal tests'.  We used a lot more docetsts early on, when
> we were trying to bootstrap IPython's testing support from nearly
> zero.  The internals of IPython were so messy and hard to cleanly test
> in isolation that the easiest way to get started was to hack a doctest
> plugin that would recognize copy-pasted IPython sessions from the
> terminal and could reproduce them whole.  But now that we're well past
> that point, moving forward it's far cleaner to user regular
> programmatic tests, and leave interactive sessions to be only used for
> their educational value as examples (it's OK if they are also a simple
> and easy doctest, but the main point should be that they serve as
> useful documentation, not as tests).
>

In this case this case is already tested in a regular test. The doctest
is just an example in the docstring of _get_long_path_name.


/J?rgen


From takowl at gmail.com  Tue Jun 12 14:56:47 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Tue, 12 Jun 2012 19:56:47 +0100
Subject: [IPython-dev] All tests pass on windows!
In-Reply-To: <4FD79059.5040501@kroywen.se>
References: <4FD66C26.9070902@kroywen.se>
	<CAHNn8BU=RJRpuakcgFRYL-pUeDTv0tRY6NWz12zCn6YZbmX0qw@mail.gmail.com>
	<CAHAreOp65TgBp-KMJ6YRS1Y8sut--rQexTNud6NdQ_m84REL0A@mail.gmail.com>
	<4FD76345.5080700@kroywen.se>
	<CAOvn4qhtBnK52P0_yRy0BgmPBgaQa=61km5Y=EZtUuVeCAJbmQ@mail.gmail.com>
	<4FD77EEF.9010100@kroywen.se>
	<CAOvn4qjHjR-v1jf9w+ZP=gzoaZrQ5g_jqL_L+boy19Fgfk26Jw@mail.gmail.com>
	<CAHAreOoVA-X=5JsHOgoK29cPcyDpm+WGehA3Gqyq+=ZERt4FuQ@mail.gmail.com>
	<4FD79059.5040501@kroywen.se>
Message-ID: <CAOvn4qhocsSYo0OAX-PGeXa5p6DMjqKVhhfs4D7u5mWswavvdg@mail.gmail.com>

On 12 June 2012 19:54, J?rgen Stenarson <jorgen.stenarson at kroywen.se> wrote:
> In this case this case is already tested in a regular test. The doctest
> is just an example in the docstring of _get_long_path_name.

In that case, I think it's fine to use the skip_doctest decorator from
IPython.testing.skipdoctest

Thomas


From fperez.net at gmail.com  Tue Jun 12 15:00:11 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 12 Jun 2012 12:00:11 -0700
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAP-uhDenjmq2eZDL+7wNA9tfy-SbcGTMbhw43E3d00KSArQNUw@mail.gmail.com>
References: <CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
	<CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>
	<CAOvn4qjs5ifL_HKj1qJWkmNdQ+4KUSQtgCE37QbLX3Yy_y6DcA@mail.gmail.com>
	<CAHAreOp_+joxdeZTQ1ZEOOU4w=euqtESMTisVSDA8oRx=RdCHg@mail.gmail.com>
	<CAOvn4qhKg9QM8u-BQvrk+PazfRBpAYtF_7Vh7-YHGYAWmHiABw@mail.gmail.com>
	<CAHAreOr+c3CS_NWOMPwUuCXN=-t5vPswzEvS6QUtX+sUKq=yrw@mail.gmail.com>
	<CAOvn4qgF+am8ScvsCtC7pXxxmtfEsY6EixnbHdYwsWLO+HQ31g@mail.gmail.com>
	<CAHAreOpqk=KuSLJdDS1n7w_DYjGhjtA_RJdxAfur_iQ2Lq_iig@mail.gmail.com>
	<CAP-uhDcMnCaM=47=qQFmO+LoxMACOsECEU=_HETvPmJGBcdEFQ@mail.gmail.com>
	<CAOvn4qhT5uW-VTJrQzikvh=QV5A+mb8Htt37rk-Vu0iwepwOSA@mail.gmail.com>
	<20120611121145.GA3470@volans.logilab.fr>
	<CAHAreOrTZ9Wo8o1n+VjRd-_U1LAwxiXPPx7vYjOzrtsqyuN_OQ@mail.gmail.com>
	<CAP-uhDcJ6ckhv6wQRgfPmr_EDy4_FSG+U6G=pN4tiQ=5dN3C9Q@mail.gmail.com>
	<CAP-uhDenjmq2eZDL+7wNA9tfy-SbcGTMbhw43E3d00KSArQNUw@mail.gmail.com>
Message-ID: <CAHAreOpVo0EZ6sRRVxkdAGRrb7Ya6SZHngjMjM4Gt7s8nWb51Q@mail.gmail.com>

On Tue, Jun 12, 2012 at 11:52 AM, Carl Smith <carl.input at gmail.com> wrote:
> I hope to get Stop, Start, Reboot and Terminate in tonight too. Then the
> whole thing needs a tidy up. Is there anything else I really need to add
> before tidying? I can add all the jewelery later on.

I think those are the biggest ones.  Persistent EBS attachment will be
a killer feature but is more work, so you can do it later.


From benjaminrk at gmail.com  Tue Jun 12 15:06:27 2012
From: benjaminrk at gmail.com (MinRK)
Date: Tue, 12 Jun 2012 12:06:27 -0700
Subject: [IPython-dev] should we make nodb the default hub backend?
In-Reply-To: <CAHAreOohVqkyV6y2M2qyN5C0hHz822KWSa515YMksBFEafDrLw@mail.gmail.com>
References: <CAHAreOpDd9ZniC7JfB0wxpDD4G5V1nsGMPQhvq8URs89h=Em3Q@mail.gmail.com>
	<CAHNn8BUaPjASD5cK1uKoTMgMiLvyk2+wfBDB0icL8u=G495sNA@mail.gmail.com>
	<CAHAreOpaKJ51nSn1fHh1Tsm6Cki8_L8+wXP_bC8CZsnL3=VO6Q@mail.gmail.com>
	<CAHNn8BU5vHm_a62FMix-en4PWDFgzJTHPr5Jf32wBwoiCSfbqA@mail.gmail.com>
	<CAHAreOpdzPi+dodHri+_T8hNmo3gfW1dXVB-g3gi1y+Qg_mq8Q@mail.gmail.com>
	<CDF21EF5-6D75-4A9C-A726-50AC2CD0A3D5@gmail.com>
	<CAHAreOqqWhuG-H6PUYV5fJPc-bzudZ5kqad1YPfjp62ZS2Ttcw@mail.gmail.com>
	<4003840C-1756-46E5-BA1B-F17CACC9F9C4@gmail.com>
	<CAHAreOoJ8AMrbtg=va+1dFYZCyzp6v8ZxJprfsP2i3xXTqYq7g@mail.gmail.com>
	<CAHNn8BVZwevZjhWb9LKdR5YSYJLj9tu_6Nv9ttMBjyOgr3kqJA@mail.gmail.com>
	<CAHAreOohVqkyV6y2M2qyN5C0hHz822KWSa515YMksBFEafDrLw@mail.gmail.com>
Message-ID: <CAHNn8BUdRe3=_=9a6=RJnQMA5dxZ1E=J-YTwGbQ_x23UQBx4SA@mail.gmail.com>

On Tue, Jun 12, 2012 at 11:32 AM, Fernando Perez <fperez.net at gmail.com>wrote:

> On Tue, Jun 12, 2012 at 9:58 AM, MinRK <benjaminrk at gmail.com> wrote:
> > PR Issued.
>
> Great, thanks!  Will review soon.
>
> > As for the difficulty of measuring size, it shouldn't be a problem in the
> > Hub, because all the data is just raw buffers, not unserialized Python
> > objects.  So we can just use `len` as an accurate measure.
>
> Ah, that's excellent news.  For 0.14 we could come up with a smarter
> cache expiration policy that uses a combination of history age and
> memory pressure, then.  But let's not rock the boat too much for now,
> I think this is as good as we need for release.
>

Indeed, and here's a PR to get started:
https://github.com/ipython/ipython/pull/1930

Which should not be merged until after 0.13 is done.


>
> Best,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120612/79ff7691/attachment.html>

From fperez.net at gmail.com  Tue Jun 12 15:07:35 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 12 Jun 2012 12:07:35 -0700
Subject: [IPython-dev] should we make nodb the default hub backend?
In-Reply-To: <CAHNn8BUdRe3=_=9a6=RJnQMA5dxZ1E=J-YTwGbQ_x23UQBx4SA@mail.gmail.com>
References: <CAHAreOpDd9ZniC7JfB0wxpDD4G5V1nsGMPQhvq8URs89h=Em3Q@mail.gmail.com>
	<CAHNn8BUaPjASD5cK1uKoTMgMiLvyk2+wfBDB0icL8u=G495sNA@mail.gmail.com>
	<CAHAreOpaKJ51nSn1fHh1Tsm6Cki8_L8+wXP_bC8CZsnL3=VO6Q@mail.gmail.com>
	<CAHNn8BU5vHm_a62FMix-en4PWDFgzJTHPr5Jf32wBwoiCSfbqA@mail.gmail.com>
	<CAHAreOpdzPi+dodHri+_T8hNmo3gfW1dXVB-g3gi1y+Qg_mq8Q@mail.gmail.com>
	<CDF21EF5-6D75-4A9C-A726-50AC2CD0A3D5@gmail.com>
	<CAHAreOqqWhuG-H6PUYV5fJPc-bzudZ5kqad1YPfjp62ZS2Ttcw@mail.gmail.com>
	<4003840C-1756-46E5-BA1B-F17CACC9F9C4@gmail.com>
	<CAHAreOoJ8AMrbtg=va+1dFYZCyzp6v8ZxJprfsP2i3xXTqYq7g@mail.gmail.com>
	<CAHNn8BVZwevZjhWb9LKdR5YSYJLj9tu_6Nv9ttMBjyOgr3kqJA@mail.gmail.com>
	<CAHAreOohVqkyV6y2M2qyN5C0hHz822KWSa515YMksBFEafDrLw@mail.gmail.com>
	<CAHNn8BUdRe3=_=9a6=RJnQMA5dxZ1E=J-YTwGbQ_x23UQBx4SA@mail.gmail.com>
Message-ID: <CAHAreOrU1cxqcwW2vrs6OZj+47=Yif9ZZVA27-e4c=CCYApL9g@mail.gmail.com>

On Tue, Jun 12, 2012 at 12:06 PM, MinRK <benjaminrk at gmail.com> wrote:
> Indeed, and here's a PR to get
> started:?https://github.com/ipython/ipython/pull/1930
>
> Which should not be merged until after 0.13 is done.

Great, already tagged it for the 0.14 milestone.  Awesome job, as always.


From jorgen.stenarson at kroywen.se  Tue Jun 12 15:15:11 2012
From: jorgen.stenarson at kroywen.se (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Tue, 12 Jun 2012 21:15:11 +0200
Subject: [IPython-dev] !commands on python3 version
Message-ID: <4FD7953F.2090108@kroywen.se>

What is the result of a !command call on linux? On windows I get binary 
data and not strings.

/J?rgen


From jorgen.stenarson at kroywen.se  Tue Jun 12 15:23:45 2012
From: jorgen.stenarson at kroywen.se (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Tue, 12 Jun 2012 21:23:45 +0200
Subject: [IPython-dev] How to organize test code
Message-ID: <4FD79741.2090406@kroywen.se>

Hi,

I'm working on the python3 failures on windows and have a general 
question regarding test code.

One of the failing tests is test_history. This is a very long test 
function with many asserts. All these asserts are surrounded with a try 
finally block. I believe this is causing some problems when debugging a 
failure. When running iptest --pdb I get into the traceback but the 
stack is messed up and I end up in the finally clause instead of the 
actual failure point. The many asserts makes it difficult to guess which 
one was responsible for the failure.

What do you think about rewriting this using a class and proper 
setUp/tearDown methods instead?



From fperez.net at gmail.com  Tue Jun 12 15:31:33 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 12 Jun 2012 12:31:33 -0700
Subject: [IPython-dev] !commands on python3 version
In-Reply-To: <4FD7953F.2090108@kroywen.se>
References: <4FD7953F.2090108@kroywen.se>
Message-ID: <CAHAreOpjt1aT4XOLf0BS4f7OE0L7fjAODTRdxPZvHx3UNjVo5w@mail.gmail.com>

On Tue, Jun 12, 2012 at 12:15 PM, J?rgen Stenarson
<jorgen.stenarson at kroywen.se> wrote:
> What is the result of a !command call on linux? On windows I get binary
> data and not strings.

Should just print the output to the screen, as if you had run it at a
terminal.  If that's not the case, that's a problem.


From fperez.net at gmail.com  Tue Jun 12 15:32:04 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 12 Jun 2012 12:32:04 -0700
Subject: [IPython-dev] All tests pass on windows!
In-Reply-To: <CAOvn4qhocsSYo0OAX-PGeXa5p6DMjqKVhhfs4D7u5mWswavvdg@mail.gmail.com>
References: <4FD66C26.9070902@kroywen.se>
	<CAHNn8BU=RJRpuakcgFRYL-pUeDTv0tRY6NWz12zCn6YZbmX0qw@mail.gmail.com>
	<CAHAreOp65TgBp-KMJ6YRS1Y8sut--rQexTNud6NdQ_m84REL0A@mail.gmail.com>
	<4FD76345.5080700@kroywen.se>
	<CAOvn4qhtBnK52P0_yRy0BgmPBgaQa=61km5Y=EZtUuVeCAJbmQ@mail.gmail.com>
	<4FD77EEF.9010100@kroywen.se>
	<CAOvn4qjHjR-v1jf9w+ZP=gzoaZrQ5g_jqL_L+boy19Fgfk26Jw@mail.gmail.com>
	<CAHAreOoVA-X=5JsHOgoK29cPcyDpm+WGehA3Gqyq+=ZERt4FuQ@mail.gmail.com>
	<4FD79059.5040501@kroywen.se>
	<CAOvn4qhocsSYo0OAX-PGeXa5p6DMjqKVhhfs4D7u5mWswavvdg@mail.gmail.com>
Message-ID: <CAHAreOoSo2i=mf_1Pf4=Jx=MN=1bGgDcySyyMyWDVq9BHX_TNg@mail.gmail.com>

On Tue, Jun 12, 2012 at 11:56 AM, Thomas Kluyver <takowl at gmail.com> wrote:
> In that case, I think it's fine to use the skip_doctest decorator from
> IPython.testing.skipdoctest

+1


From fperez.net at gmail.com  Tue Jun 12 15:34:18 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 12 Jun 2012 12:34:18 -0700
Subject: [IPython-dev] How to organize test code
In-Reply-To: <4FD79741.2090406@kroywen.se>
References: <4FD79741.2090406@kroywen.se>
Message-ID: <CAHAreOp6TZvEXYLr17hor8qkcNcGeVefXC7k4HGE3LW+GRzubA@mail.gmail.com>

On Tue, Jun 12, 2012 at 12:23 PM, J?rgen Stenarson
<jorgen.stenarson at kroywen.se> wrote:
> What do you think about rewriting this using a class and proper
> setUp/tearDown methods instead?

Sure!  To reiterate: a lot of our testing machinery is messy because
it was written in a desperate effort early on to get *some* testing
going, and IPython isn't the easiest beast to test (because you
basically are bootstrapping a 'vm inside a vm' for many practical
purposes).  So we cut quite a few corners just so that we'd have any
testing at all.

Any and all testing simplifications and cleanups are now welcome and a
good idea, even if they include completely shedding some of the old
stuff.  We're not emotionally attached to any of that code, as long as
we get solid test coverage, all punches are fair to throw :)

Cheers,

f


From jorgen.stenarson at kroywen.se  Tue Jun 12 15:34:49 2012
From: jorgen.stenarson at kroywen.se (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Tue, 12 Jun 2012 21:34:49 +0200
Subject: [IPython-dev] !commands on python3 version
In-Reply-To: <CAHAreOpjt1aT4XOLf0BS4f7OE0L7fjAODTRdxPZvHx3UNjVo5w@mail.gmail.com>
References: <4FD7953F.2090108@kroywen.se>
	<CAHAreOpjt1aT4XOLf0BS4f7OE0L7fjAODTRdxPZvHx3UNjVo5w@mail.gmail.com>
Message-ID: <4FD799D9.9060106@kroywen.se>

Fernando Perez skrev 2012-06-12 21:31:
> On Tue, Jun 12, 2012 at 12:15 PM, J?rgen Stenarson
> <jorgen.stenarson at kroywen.se>  wrote:
>>  What is the result of a !command call on linux? On windows I get binary
>>  data and not strings.
>
> Should just print the output to the screen, as if you had run it at a
> terminal.  If that's not the case, that's a problem.

I should have given a complete example

In [8]: a=!ls *.py

In [9]: a
Out[9]:
[b'_process_win32.py',
  b'argsplit.py',
  b'debugerror.py',
  b'embedkernel.py',
  b'error-utf8.py',
  b'error.py',
  b'slask.py']

/J?rgen


From fperez.net at gmail.com  Tue Jun 12 15:39:54 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 12 Jun 2012 12:39:54 -0700
Subject: [IPython-dev] !commands on python3 version
In-Reply-To: <4FD799D9.9060106@kroywen.se>
References: <4FD7953F.2090108@kroywen.se>
	<CAHAreOpjt1aT4XOLf0BS4f7OE0L7fjAODTRdxPZvHx3UNjVo5w@mail.gmail.com>
	<4FD799D9.9060106@kroywen.se>
Message-ID: <CAHAreOrKnio8uWOMwVYB+pS9FYRma=t3MDxrpbDwZHakTg+=qg@mail.gmail.com>

On Tue, Jun 12, 2012 at 12:34 PM, J?rgen Stenarson
<jorgen.stenarson at kroywen.se> wrote:
> I should have given a complete example
>
> In [8]: a=!ls *.py
>
> In [9]: a
> Out[9]:
> [b'_process_win32.py',
> ?b'argsplit.py',
> ?b'debugerror.py',
> ?b'embedkernel.py',
> ?b'error-utf8.py',
> ?b'error.py',
> ?b'slask.py']

Ah, that's OK.  When capturing, we deliberately grab the output  by
effectively doing splitlines, so it's more convenient to manage as a
python data structure.

But if you type

!ls *.py

alone, you should just see the printout.


From benjaminrk at gmail.com  Tue Jun 12 15:45:59 2012
From: benjaminrk at gmail.com (MinRK)
Date: Tue, 12 Jun 2012 12:45:59 -0700
Subject: [IPython-dev] !commands on python3 version
In-Reply-To: <CAHAreOrKnio8uWOMwVYB+pS9FYRma=t3MDxrpbDwZHakTg+=qg@mail.gmail.com>
References: <4FD7953F.2090108@kroywen.se>
	<CAHAreOpjt1aT4XOLf0BS4f7OE0L7fjAODTRdxPZvHx3UNjVo5w@mail.gmail.com>
	<4FD799D9.9060106@kroywen.se>
	<CAHAreOrKnio8uWOMwVYB+pS9FYRma=t3MDxrpbDwZHakTg+=qg@mail.gmail.com>
Message-ID: <CAHNn8BUomxJy5TQp5tM3a-En29AfkWb47bzoxTNzMwVR1A0cvg@mail.gmail.com>

But I think he's asking specifically about whether it should be bytes or
text.

On Python 3 on OSX it is text, and I presume the same on Linux.  This
should be a bug in Shell.getoutput on Windows.

-MinRK

On Tue, Jun 12, 2012 at 12:39 PM, Fernando Perez <fperez.net at gmail.com>wrote:

> On Tue, Jun 12, 2012 at 12:34 PM, J?rgen Stenarson
> <jorgen.stenarson at kroywen.se> wrote:
> > I should have given a complete example
> >
> > In [8]: a=!ls *.py
> >
> > In [9]: a
> > Out[9]:
> > [b'_process_win32.py',
> >  b'argsplit.py',
> >  b'debugerror.py',
> >  b'embedkernel.py',
> >  b'error-utf8.py',
> >  b'error.py',
> >  b'slask.py']
>
> Ah, that's OK.  When capturing, we deliberately grab the output  by
> effectively doing splitlines, so it's more convenient to manage as a
> python data structure.
>
> But if you type
>
> !ls *.py
>
> alone, you should just see the printout.
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120612/16031e3f/attachment.html>

From jorgen.stenarson at kroywen.se  Tue Jun 12 15:47:33 2012
From: jorgen.stenarson at kroywen.se (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Tue, 12 Jun 2012 21:47:33 +0200
Subject: [IPython-dev] !commands on python3 version
In-Reply-To: <CAHNn8BUomxJy5TQp5tM3a-En29AfkWb47bzoxTNzMwVR1A0cvg@mail.gmail.com>
References: <4FD7953F.2090108@kroywen.se>
	<CAHAreOpjt1aT4XOLf0BS4f7OE0L7fjAODTRdxPZvHx3UNjVo5w@mail.gmail.com>
	<4FD799D9.9060106@kroywen.se>
	<CAHAreOrKnio8uWOMwVYB+pS9FYRma=t3MDxrpbDwZHakTg+=qg@mail.gmail.com>
	<CAHNn8BUomxJy5TQp5tM3a-En29AfkWb47bzoxTNzMwVR1A0cvg@mail.gmail.com>
Message-ID: <4FD79CD5.9030602@kroywen.se>

MinRK skrev 2012-06-12 21:45:
> But I think he's asking specifically about whether it should be bytes or
> text.
>
> On Python 3 on OSX it is text, and I presume the same on Linux.  This
> should be a bug in Shell.getoutput on Windows.
>
Great that's what I need.

/J?rgen


From takowl at gmail.com  Tue Jun 12 15:48:18 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Tue, 12 Jun 2012 20:48:18 +0100
Subject: [IPython-dev] How to organize test code
In-Reply-To: <4FD79741.2090406@kroywen.se>
References: <4FD79741.2090406@kroywen.se>
Message-ID: <CAOvn4qizR4eWp7eA34hg2ZeZRCgsUjAQ6L-HBa07PJoEzYX-6A@mail.gmail.com>

On 12 June 2012 20:23, J?rgen Stenarson <jorgen.stenarson at kroywen.se> wrote:
> What do you think about rewriting this using a class and proper
> setUp/tearDown methods instead?

In general, as Fernando says, go for it. I think the nature of the
history tests is that the later steps depend on the earlier ones
having already been done, so in this case the content of the tests may
have to be rejigged a bit to make them into independent parts.

Thanks,
Thomas


From takowl at gmail.com  Tue Jun 12 15:49:19 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Tue, 12 Jun 2012 20:49:19 +0100
Subject: [IPython-dev] !commands on python3 version
In-Reply-To: <CAHNn8BUomxJy5TQp5tM3a-En29AfkWb47bzoxTNzMwVR1A0cvg@mail.gmail.com>
References: <4FD7953F.2090108@kroywen.se>
	<CAHAreOpjt1aT4XOLf0BS4f7OE0L7fjAODTRdxPZvHx3UNjVo5w@mail.gmail.com>
	<4FD799D9.9060106@kroywen.se>
	<CAHAreOrKnio8uWOMwVYB+pS9FYRma=t3MDxrpbDwZHakTg+=qg@mail.gmail.com>
	<CAHNn8BUomxJy5TQp5tM3a-En29AfkWb47bzoxTNzMwVR1A0cvg@mail.gmail.com>
Message-ID: <CAOvn4qi4rpMaL7znKfNMPQUFpU74jSjDwvKC3tXcjVdEFws_dQ@mail.gmail.com>

On 12 June 2012 20:45, MinRK <benjaminrk at gmail.com> wrote:
> On Python 3 on OSX it is text, and I presume the same on Linux.

Confirmed.

Thomas


From carl.input at gmail.com  Tue Jun 12 18:12:37 2012
From: carl.input at gmail.com (Carl Smith)
Date: Tue, 12 Jun 2012 23:12:37 +0100
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAHAreOpVo0EZ6sRRVxkdAGRrb7Ya6SZHngjMjM4Gt7s8nWb51Q@mail.gmail.com>
References: <CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
	<CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>
	<CAOvn4qjs5ifL_HKj1qJWkmNdQ+4KUSQtgCE37QbLX3Yy_y6DcA@mail.gmail.com>
	<CAHAreOp_+joxdeZTQ1ZEOOU4w=euqtESMTisVSDA8oRx=RdCHg@mail.gmail.com>
	<CAOvn4qhKg9QM8u-BQvrk+PazfRBpAYtF_7Vh7-YHGYAWmHiABw@mail.gmail.com>
	<CAHAreOr+c3CS_NWOMPwUuCXN=-t5vPswzEvS6QUtX+sUKq=yrw@mail.gmail.com>
	<CAOvn4qgF+am8ScvsCtC7pXxxmtfEsY6EixnbHdYwsWLO+HQ31g@mail.gmail.com>
	<CAHAreOpqk=KuSLJdDS1n7w_DYjGhjtA_RJdxAfur_iQ2Lq_iig@mail.gmail.com>
	<CAP-uhDcMnCaM=47=qQFmO+LoxMACOsECEU=_HETvPmJGBcdEFQ@mail.gmail.com>
	<CAOvn4qhT5uW-VTJrQzikvh=QV5A+mb8Htt37rk-Vu0iwepwOSA@mail.gmail.com>
	<20120611121145.GA3470@volans.logilab.fr>
	<CAHAreOrTZ9Wo8o1n+VjRd-_U1LAwxiXPPx7vYjOzrtsqyuN_OQ@mail.gmail.com>
	<CAP-uhDcJ6ckhv6wQRgfPmr_EDy4_FSG+U6G=pN4tiQ=5dN3C9Q@mail.gmail.com>
	<CAP-uhDenjmq2eZDL+7wNA9tfy-SbcGTMbhw43E3d00KSArQNUw@mail.gmail.com>
	<CAHAreOpVo0EZ6sRRVxkdAGRrb7Ya6SZHngjMjM4Gt7s8nWb51Q@mail.gmail.com>
Message-ID: <CAP-uhDcqWcy0QfjnohgxsDEemruJREay3awPpqDxUYxPrO5z3w@mail.gmail.com>

OK. Thanks for you're time Fernando. And Thomas of course. I've only been
programming a few years so input from other developers is really valuable
to me. I'm off work tomorrow so I'll make a start tonight.

Thanks again.
On Jun 12, 2012 8:00 PM, "Fernando Perez" <fperez.net at gmail.com> wrote:

> On Tue, Jun 12, 2012 at 11:52 AM, Carl Smith <carl.input at gmail.com> wrote:
> > I hope to get Stop, Start, Reboot and Terminate in tonight too. Then the
> > whole thing needs a tidy up. Is there anything else I really need to add
> > before tidying? I can add all the jewelery later on.
>
> I think those are the biggest ones.  Persistent EBS attachment will be
> a killer feature but is more work, so you can do it later.
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120612/116f081d/attachment.html>

From fperez.net at gmail.com  Tue Jun 12 18:14:26 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 12 Jun 2012 15:14:26 -0700
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAP-uhDcqWcy0QfjnohgxsDEemruJREay3awPpqDxUYxPrO5z3w@mail.gmail.com>
References: <CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
	<CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>
	<CAOvn4qjs5ifL_HKj1qJWkmNdQ+4KUSQtgCE37QbLX3Yy_y6DcA@mail.gmail.com>
	<CAHAreOp_+joxdeZTQ1ZEOOU4w=euqtESMTisVSDA8oRx=RdCHg@mail.gmail.com>
	<CAOvn4qhKg9QM8u-BQvrk+PazfRBpAYtF_7Vh7-YHGYAWmHiABw@mail.gmail.com>
	<CAHAreOr+c3CS_NWOMPwUuCXN=-t5vPswzEvS6QUtX+sUKq=yrw@mail.gmail.com>
	<CAOvn4qgF+am8ScvsCtC7pXxxmtfEsY6EixnbHdYwsWLO+HQ31g@mail.gmail.com>
	<CAHAreOpqk=KuSLJdDS1n7w_DYjGhjtA_RJdxAfur_iQ2Lq_iig@mail.gmail.com>
	<CAP-uhDcMnCaM=47=qQFmO+LoxMACOsECEU=_HETvPmJGBcdEFQ@mail.gmail.com>
	<CAOvn4qhT5uW-VTJrQzikvh=QV5A+mb8Htt37rk-Vu0iwepwOSA@mail.gmail.com>
	<20120611121145.GA3470@volans.logilab.fr>
	<CAHAreOrTZ9Wo8o1n+VjRd-_U1LAwxiXPPx7vYjOzrtsqyuN_OQ@mail.gmail.com>
	<CAP-uhDcJ6ckhv6wQRgfPmr_EDy4_FSG+U6G=pN4tiQ=5dN3C9Q@mail.gmail.com>
	<CAP-uhDenjmq2eZDL+7wNA9tfy-SbcGTMbhw43E3d00KSArQNUw@mail.gmail.com>
	<CAHAreOpVo0EZ6sRRVxkdAGRrb7Ya6SZHngjMjM4Gt7s8nWb51Q@mail.gmail.com>
	<CAP-uhDcqWcy0QfjnohgxsDEemruJREay3awPpqDxUYxPrO5z3w@mail.gmail.com>
Message-ID: <CAHAreOpuSBSx+kKRt8kpO3giXcaA=Tv9wEObUcy1hXCpsVVskw@mail.gmail.com>

On Tue, Jun 12, 2012 at 3:12 PM, Carl Smith <carl.input at gmail.com> wrote:
> OK. Thanks for you're time Fernando. And Thomas of course. I've only been
> programming a few years so input from other developers is really valuable to
> me. I'm off work tomorrow so I'll make a start tonight.

Our pleasure, it's always great to have new contributors on the project.

BTW, one more thing that I think would be great and easy: instance
type selection.  You may want to pop up a message indicating that the
ones bigger than micro are never free and can rack up real costs
quick, but it will make it much more useful in practice to have the
option to choose a larger instance.

Cheers,

f


From carl.input at gmail.com  Wed Jun 13 12:32:38 2012
From: carl.input at gmail.com (Carl Smith)
Date: Wed, 13 Jun 2012 17:32:38 +0100
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAHAreOpuSBSx+kKRt8kpO3giXcaA=Tv9wEObUcy1hXCpsVVskw@mail.gmail.com>
References: <CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
	<CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>
	<CAOvn4qjs5ifL_HKj1qJWkmNdQ+4KUSQtgCE37QbLX3Yy_y6DcA@mail.gmail.com>
	<CAHAreOp_+joxdeZTQ1ZEOOU4w=euqtESMTisVSDA8oRx=RdCHg@mail.gmail.com>
	<CAOvn4qhKg9QM8u-BQvrk+PazfRBpAYtF_7Vh7-YHGYAWmHiABw@mail.gmail.com>
	<CAHAreOr+c3CS_NWOMPwUuCXN=-t5vPswzEvS6QUtX+sUKq=yrw@mail.gmail.com>
	<CAOvn4qgF+am8ScvsCtC7pXxxmtfEsY6EixnbHdYwsWLO+HQ31g@mail.gmail.com>
	<CAHAreOpqk=KuSLJdDS1n7w_DYjGhjtA_RJdxAfur_iQ2Lq_iig@mail.gmail.com>
	<CAP-uhDcMnCaM=47=qQFmO+LoxMACOsECEU=_HETvPmJGBcdEFQ@mail.gmail.com>
	<CAOvn4qhT5uW-VTJrQzikvh=QV5A+mb8Htt37rk-Vu0iwepwOSA@mail.gmail.com>
	<20120611121145.GA3470@volans.logilab.fr>
	<CAHAreOrTZ9Wo8o1n+VjRd-_U1LAwxiXPPx7vYjOzrtsqyuN_OQ@mail.gmail.com>
	<CAP-uhDcJ6ckhv6wQRgfPmr_EDy4_FSG+U6G=pN4tiQ=5dN3C9Q@mail.gmail.com>
	<CAP-uhDenjmq2eZDL+7wNA9tfy-SbcGTMbhw43E3d00KSArQNUw@mail.gmail.com>
	<CAHAreOpVo0EZ6sRRVxkdAGRrb7Ya6SZHngjMjM4Gt7s8nWb51Q@mail.gmail.com>
	<CAP-uhDcqWcy0QfjnohgxsDEemruJREay3awPpqDxUYxPrO5z3w@mail.gmail.com>
	<CAHAreOpuSBSx+kKRt8kpO3giXcaA=Tv9wEObUcy1hXCpsVVskw@mail.gmail.com>
Message-ID: <CAP-uhDe=ogMOsWdPmkRNK0Q43wwTuE-WVAptK+Vw9ahyXshegQ@mail.gmail.com>

I'm looking to make the launch button open a little form, that'll expand
the space between the buttons and the instances list. It'll be pre-filled
with the user's defaults so you can launch your regular setup in two clicks.

I like this approach because I can reuse it to have the other buttons open
their own little panels if I want to add stuff later.

Cheers

Carl
On Jun 12, 2012 11:15 PM, "Fernando Perez" <fperez.net at gmail.com> wrote:

> On Tue, Jun 12, 2012 at 3:12 PM, Carl Smith <carl.input at gmail.com> wrote:
> > OK. Thanks for you're time Fernando. And Thomas of course. I've only been
> > programming a few years so input from other developers is really
> valuable to
> > me. I'm off work tomorrow so I'll make a start tonight.
>
> Our pleasure, it's always great to have new contributors on the project.
>
> BTW, one more thing that I think would be great and easy: instance
> type selection.  You may want to pop up a message indicating that the
> ones bigger than micro are never free and can rack up real costs
> quick, but it will make it much more useful in practice to have the
> option to choose a larger instance.
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120613/3064026f/attachment.html>

From jonathan.taylor at stanford.edu  Wed Jun 13 18:52:31 2012
From: jonathan.taylor at stanford.edu (Jonathan Taylor)
Date: Wed, 13 Jun 2012 15:52:31 -0700
Subject: [IPython-dev] problem with publish_display_data?
Message-ID: <CANmCCuQyK7Uo6SZKVZC6CHhjEttPJnWyYsXY5E+etWwZ6vGSjg@mail.gmail.com>

On the master branch, I am getting some unexpected behaviour when I try the
following

import numpy as np
from IPython.core.displaypub import publish_display_data

class NormalMean(object):
    """
    Sample from N(mean, sd) independently n times
    """
    tol = 5.e-2
    checkable = True

    def __init__(self, mean, sd, n, identifier):
        self.mean = mean
        self.identifier = identifier
        self.sd = sd
        self.n = n
        self.sequence = self.generate()
        self.correct_answer = np.mean(self.sequence)

    def generate(self):
        return np.round(np.random.standard_normal(self.n), 1) * self.sd +
self.mean

    @property
    def answer(self):
        return np.mean(self.sequence)

    def publish(self, return_data=False):

        data = {'text/latex': r"What is the sample mean, $\bar{X}$ of this
sequence: %s ?" % `["%0.1f" % s for s in self.sequence]`,
                'text/html': ''}

        data['text/html'] += '<form method="post" name=%s ><p><input
type="text" ></p></form>' % self.identifier
        data['application/json'] = {'constructor_info': ('normal_mean',
[self.mean, self.sd, self.n], {})}
        publish_display_data("NormalMean", data)
        if return_data:
            return data

    def check_answer(self, answer):
        if np.fabs(answer - self.correct_answer) / np.std(self.sequence) <
self.tol:
            data = self.publish(return_data=True)
            data['text/html'] += '\n<p><h2>Good job!</h2></p>\n'
        else:
            self.sequence = self.generate()
            data = self.publish(return_data=True)
            data['text/html'] += '\n<p><h2>Try Again!</h2></p>\n'


NormalMean(10, 3, 6, 'mean_10_sd_3_n_6').publish()


I expect to see a latex rendering of the question with a textbox below it
but I am only getting a text box.

By the way, if I want to see these things in order, I suppose it is best to
use several calls to publish_display_data? Is that right, if so the outputs
are in the order I want them to be rather than
the order of the dict keys (which I cannot control).

Thanks,

Jonathan


-- 
Jonathan Taylor
Dept. of Statistics
Sequoia Hall, 137
390 Serra Mall
Stanford, CA 94305
Tel:   650.723.9230
Fax:   650.725.8977
Web: http://www-stat.stanford.edu/~jtaylo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120613/056ca176/attachment.html>

From benjaminrk at gmail.com  Wed Jun 13 19:08:27 2012
From: benjaminrk at gmail.com (MinRK)
Date: Wed, 13 Jun 2012 16:08:27 -0700
Subject: [IPython-dev] problem with publish_display_data?
In-Reply-To: <CANmCCuQyK7Uo6SZKVZC6CHhjEttPJnWyYsXY5E+etWwZ6vGSjg@mail.gmail.com>
References: <CANmCCuQyK7Uo6SZKVZC6CHhjEttPJnWyYsXY5E+etWwZ6vGSjg@mail.gmail.com>
Message-ID: <CAHNn8BVG57cVy7g0mewcN4y-pmU=ZKWiY3zybatnnm9ngwr9BQ@mail.gmail.com>

On Wed, Jun 13, 2012 at 3:52 PM, Jonathan Taylor <
jonathan.taylor at stanford.edu> wrote:

> On the master branch, I am getting some unexpected behaviour when I try
> the following
>
> import numpy as np
> from IPython.core.displaypub import publish_display_data
>
> class NormalMean(object):
>     """
>     Sample from N(mean, sd) independently n times
>     """
>     tol = 5.e-2
>     checkable = True
>
>     def __init__(self, mean, sd, n, identifier):
>         self.mean = mean
>         self.identifier = identifier
>         self.sd = sd
>         self.n = n
>         self.sequence = self.generate()
>         self.correct_answer = np.mean(self.sequence)
>
>     def generate(self):
>         return np.round(np.random.standard_normal(self.n), 1) * self.sd +
> self.mean
>
>     @property
>     def answer(self):
>         return np.mean(self.sequence)
>
>     def publish(self, return_data=False):
>
>         data = {'text/latex': r"What is the sample mean, $\bar{X}$ of this
> sequence: %s ?" % `["%0.1f" % s for s in self.sequence]`,
>                 'text/html': ''}
>
>         data['text/html'] += '<form method="post" name=%s ><p><input
> type="text" ></p></form>' % self.identifier
>         data['application/json'] = {'constructor_info': ('normal_mean',
> [self.mean, self.sd, self.n], {})}
>         publish_display_data("NormalMean", data)
>         if return_data:
>             return data
>
>     def check_answer(self, answer):
>         if np.fabs(answer - self.correct_answer) / np.std(self.sequence) <
> self.tol:
>             data = self.publish(return_data=True)
>             data['text/html'] += '\n<p><h2>Good job!</h2></p>\n'
>         else:
>             self.sequence = self.generate()
>             data = self.publish(return_data=True)
>             data['text/html'] += '\n<p><h2>Try Again!</h2></p>\n'
>
>
> NormalMean(10, 3, 6, 'mean_10_sd_3_n_6').publish()
>
>
> I expect to see a latex rendering of the question with a textbox below it
> but I am only getting a text box.
>
> By the way, if I want to see these things in order, I suppose it is best
> to use several calls to publish_display_data? Is that right, if so the
> outputs are in the order I want them to be rather than
> the order of the dict keys (which I cannot control).
>

Right - one call to "publish_display_data" should always result in exactly
one thing being displayed.  The idea being "I have a thing I want to
display, and I can display in all these different ways". It is up to the
frontends to pick their favorite (HTML in the notebook).  If you want to
display multiple things, then you should use multiple calls.

-MinRK


>
> Thanks,
>
> Jonathan
>
>
> --
> Jonathan Taylor
> Dept. of Statistics
> Sequoia Hall, 137
> 390 Serra Mall
> Stanford, CA 94305
> Tel:   650.723.9230
> Fax:   650.725.8977
> Web: http://www-stat.stanford.edu/~jtaylo
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120613/2a3056d8/attachment.html>

From carl.input at gmail.com  Wed Jun 13 20:37:48 2012
From: carl.input at gmail.com (Carl Smith)
Date: Thu, 14 Jun 2012 01:37:48 +0100
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAP-uhDe=ogMOsWdPmkRNK0Q43wwTuE-WVAptK+Vw9ahyXshegQ@mail.gmail.com>
References: <CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
	<CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>
	<CAOvn4qjs5ifL_HKj1qJWkmNdQ+4KUSQtgCE37QbLX3Yy_y6DcA@mail.gmail.com>
	<CAHAreOp_+joxdeZTQ1ZEOOU4w=euqtESMTisVSDA8oRx=RdCHg@mail.gmail.com>
	<CAOvn4qhKg9QM8u-BQvrk+PazfRBpAYtF_7Vh7-YHGYAWmHiABw@mail.gmail.com>
	<CAHAreOr+c3CS_NWOMPwUuCXN=-t5vPswzEvS6QUtX+sUKq=yrw@mail.gmail.com>
	<CAOvn4qgF+am8ScvsCtC7pXxxmtfEsY6EixnbHdYwsWLO+HQ31g@mail.gmail.com>
	<CAHAreOpqk=KuSLJdDS1n7w_DYjGhjtA_RJdxAfur_iQ2Lq_iig@mail.gmail.com>
	<CAP-uhDcMnCaM=47=qQFmO+LoxMACOsECEU=_HETvPmJGBcdEFQ@mail.gmail.com>
	<CAOvn4qhT5uW-VTJrQzikvh=QV5A+mb8Htt37rk-Vu0iwepwOSA@mail.gmail.com>
	<20120611121145.GA3470@volans.logilab.fr>
	<CAHAreOrTZ9Wo8o1n+VjRd-_U1LAwxiXPPx7vYjOzrtsqyuN_OQ@mail.gmail.com>
	<CAP-uhDcJ6ckhv6wQRgfPmr_EDy4_FSG+U6G=pN4tiQ=5dN3C9Q@mail.gmail.com>
	<CAP-uhDenjmq2eZDL+7wNA9tfy-SbcGTMbhw43E3d00KSArQNUw@mail.gmail.com>
	<CAHAreOpVo0EZ6sRRVxkdAGRrb7Ya6SZHngjMjM4Gt7s8nWb51Q@mail.gmail.com>
	<CAP-uhDcqWcy0QfjnohgxsDEemruJREay3awPpqDxUYxPrO5z3w@mail.gmail.com>
	<CAHAreOpuSBSx+kKRt8kpO3giXcaA=Tv9wEObUcy1hXCpsVVskw@mail.gmail.com>
	<CAP-uhDe=ogMOsWdPmkRNK0Q43wwTuE-WVAptK+Vw9ahyXshegQ@mail.gmail.com>
Message-ID: <CAP-uhDezt-esACujasuZeWMBHdGmAF6qWRLZuAXnRcv9k5Xa9g@mail.gmail.com>

I've added Stop, Start, Reboot and Terminate as well as tidied up the HTML.
On Jun 13, 2012 5:32 PM, "Carl Smith" <carl.input at gmail.com> wrote:

> I'm looking to make the launch button open a little form, that'll expand
> the space between the buttons and the instances list. It'll be pre-filled
> with the user's defaults so you can launch your regular setup in two clicks.
>
> I like this approach because I can reuse it to have the other buttons open
> their own little panels if I want to add stuff later.
>
> Cheers
>
> Carl
> On Jun 12, 2012 11:15 PM, "Fernando Perez" <fperez.net at gmail.com> wrote:
>
>> On Tue, Jun 12, 2012 at 3:12 PM, Carl Smith <carl.input at gmail.com> wrote:
>> > OK. Thanks for you're time Fernando. And Thomas of course. I've only
>> been
>> > programming a few years so input from other developers is really
>> valuable to
>> > me. I'm off work tomorrow so I'll make a start tonight.
>>
>> Our pleasure, it's always great to have new contributors on the project.
>>
>> BTW, one more thing that I think would be great and easy: instance
>> type selection.  You may want to pop up a message indicating that the
>> ones bigger than micro are never free and can rack up real costs
>> quick, but it will make it much more useful in practice to have the
>> option to choose a larger instance.
>>
>> Cheers,
>>
>> f
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120614/c27fc98c/attachment.html>

From carl.input at gmail.com  Wed Jun 13 20:48:06 2012
From: carl.input at gmail.com (Carl Smith)
Date: Thu, 14 Jun 2012 01:48:06 +0100
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAP-uhDezt-esACujasuZeWMBHdGmAF6qWRLZuAXnRcv9k5Xa9g@mail.gmail.com>
References: <CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
	<CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>
	<CAOvn4qjs5ifL_HKj1qJWkmNdQ+4KUSQtgCE37QbLX3Yy_y6DcA@mail.gmail.com>
	<CAHAreOp_+joxdeZTQ1ZEOOU4w=euqtESMTisVSDA8oRx=RdCHg@mail.gmail.com>
	<CAOvn4qhKg9QM8u-BQvrk+PazfRBpAYtF_7Vh7-YHGYAWmHiABw@mail.gmail.com>
	<CAHAreOr+c3CS_NWOMPwUuCXN=-t5vPswzEvS6QUtX+sUKq=yrw@mail.gmail.com>
	<CAOvn4qgF+am8ScvsCtC7pXxxmtfEsY6EixnbHdYwsWLO+HQ31g@mail.gmail.com>
	<CAHAreOpqk=KuSLJdDS1n7w_DYjGhjtA_RJdxAfur_iQ2Lq_iig@mail.gmail.com>
	<CAP-uhDcMnCaM=47=qQFmO+LoxMACOsECEU=_HETvPmJGBcdEFQ@mail.gmail.com>
	<CAOvn4qhT5uW-VTJrQzikvh=QV5A+mb8Htt37rk-Vu0iwepwOSA@mail.gmail.com>
	<20120611121145.GA3470@volans.logilab.fr>
	<CAHAreOrTZ9Wo8o1n+VjRd-_U1LAwxiXPPx7vYjOzrtsqyuN_OQ@mail.gmail.com>
	<CAP-uhDcJ6ckhv6wQRgfPmr_EDy4_FSG+U6G=pN4tiQ=5dN3C9Q@mail.gmail.com>
	<CAP-uhDenjmq2eZDL+7wNA9tfy-SbcGTMbhw43E3d00KSArQNUw@mail.gmail.com>
	<CAHAreOpVo0EZ6sRRVxkdAGRrb7Ya6SZHngjMjM4Gt7s8nWb51Q@mail.gmail.com>
	<CAP-uhDcqWcy0QfjnohgxsDEemruJREay3awPpqDxUYxPrO5z3w@mail.gmail.com>
	<CAHAreOpuSBSx+kKRt8kpO3giXcaA=Tv9wEObUcy1hXCpsVVskw@mail.gmail.com>
	<CAP-uhDe=ogMOsWdPmkRNK0Q43wwTuE-WVAptK+Vw9ahyXshegQ@mail.gmail.com>
	<CAP-uhDezt-esACujasuZeWMBHdGmAF6qWRLZuAXnRcv9k5Xa9g@mail.gmail.com>
Message-ID: <CAP-uhDdGPKHgZb=Xx5TXGfn2LXUps8+Sj0ij=hK8MApiT1vXGw@mail.gmail.com>

Here's a screenshot...

On 14 June 2012 01:37, Carl Smith <carl.input at gmail.com> wrote:
> I've added Stop, Start, Reboot and Terminate as well as tidied up the HTML.
>
> On Jun 13, 2012 5:32 PM, "Carl Smith" <carl.input at gmail.com> wrote:
>>
>> I'm looking to make the launch button open a little form, that'll expand
>> the space between the buttons and the instances list. It'll be pre-filled
>> with the user's defaults so you can launch your regular setup in two clicks.
>>
>> I like this approach because I can reuse it to have the other buttons open
>> their own little panels if I want to add stuff later.
>>
>> Cheers
>>
>> Carl
>>
>> On Jun 12, 2012 11:15 PM, "Fernando Perez" <fperez.net at gmail.com> wrote:
>>>
>>> On Tue, Jun 12, 2012 at 3:12 PM, Carl Smith <carl.input at gmail.com> wrote:
>>> > OK. Thanks for you're time Fernando. And Thomas of course. I've only
>>> > been
>>> > programming a few years so input from other developers is really
>>> > valuable to
>>> > me. I'm off work tomorrow so I'll make a start tonight.
>>>
>>> Our pleasure, it's always great to have new contributors on the project.
>>>
>>> BTW, one more thing that I think would be great and easy: instance
>>> type selection. ?You may want to pop up a message indicating that the
>>> ones bigger than micro are never free and can rack up real costs
>>> quick, but it will make it much more useful in practice to have the
>>> option to choose a larger instance.
>>>
>>> Cheers,
>>>
>>> f
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: example.png
Type: image/png
Size: 64358 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120614/93840c47/attachment.png>

From matthew.brett at gmail.com  Wed Jun 13 21:13:26 2012
From: matthew.brett at gmail.com (Matthew Brett)
Date: Wed, 13 Jun 2012 18:13:26 -0700
Subject: [IPython-dev] zmq import appearing in all stacktraces
Message-ID: <CAH6Pt5rBHREngGqtD5LS073s8WS1kzjzQAj8VmjnwDtheNVOzw@mail.gmail.com>

Hi,

I just updated to trunk:

In [4]: IPython.sys_info()
Out[4]: "{'commit_hash': '99373b4',\n 'commit_source':
'installation',\n 'ipython_path':
'/home/mb312/.virtualenvs/bare/lib/python2.6/site-packages/IPython',\n
'ipython_version': '0.13.dev',\n 'os_name': 'posix',\n 'platform':
'Linux-2.6.32-5-amd64-x86_64-with-debian-6.0.5',\n 'sys_executable':
'/home/mb312/.virtualenvs/bare/bin/python',\n 'sys_platform':
'linux2',\n 'sys_version': '2.6.6 (r266:84292, Dec 26 2010, 22:31:48)
\\n[GCC 4.4.5]'}"

on a machine without zmq, and noticed:

In [5]: 1/0
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)
/home/mb312/.virtualenvs/bare/lib/python2.6/site-packages/IPython/parallel/__init__.py
in <module>()
     19 import warnings
     20
---> 21 import zmq
     22
     23 from IPython.config.configurable import MultipleInstanceError

ImportError: No module named zmq

Should I try and bisect, or open an issue?  I ask here because of the
impending 0.13 release,

See y'all,

Matthew


From benjaminrk at gmail.com  Wed Jun 13 21:21:13 2012
From: benjaminrk at gmail.com (MinRK)
Date: Wed, 13 Jun 2012 18:21:13 -0700
Subject: [IPython-dev] zmq import appearing in all stacktraces
In-Reply-To: <CAH6Pt5rBHREngGqtD5LS073s8WS1kzjzQAj8VmjnwDtheNVOzw@mail.gmail.com>
References: <CAH6Pt5rBHREngGqtD5LS073s8WS1kzjzQAj8VmjnwDtheNVOzw@mail.gmail.com>
Message-ID: <CAHNn8BUL+9m9HZH_rKhpgdYgG_bBk+CzR4u3jmm8xhMZb13u+Q@mail.gmail.com>

On Wed, Jun 13, 2012 at 6:13 PM, Matthew Brett <matthew.brett at gmail.com>wrote:

> Hi,
>
> I just updated to trunk:
>
> In [4]: IPython.sys_info()
> Out[4]: "{'commit_hash': '99373b4',\n 'commit_source':
> 'installation',\n 'ipython_path':
> '/home/mb312/.virtualenvs/bare/lib/python2.6/site-packages/IPython',\n
> 'ipython_version': '0.13.dev',\n 'os_name': 'posix',\n 'platform':
> 'Linux-2.6.32-5-amd64-x86_64-with-debian-6.0.5',\n 'sys_executable':
> '/home/mb312/.virtualenvs/bare/bin/python',\n 'sys_platform':
> 'linux2',\n 'sys_version': '2.6.6 (r266:84292, Dec 26 2010, 22:31:48)
> \\n[GCC 4.4.5]'}"
>
> on a machine without zmq, and noticed:
>
> In [5]: 1/0
> ---------------------------------------------------------------------------
> ImportError                               Traceback (most recent call last)
>
> /home/mb312/.virtualenvs/bare/lib/python2.6/site-packages/IPython/parallel/__init__.py
> in <module>()
>     19 import warnings
>     20
> ---> 21 import zmq
>     22
>     23 from IPython.config.configurable import MultipleInstanceError
>
> ImportError: No module named zmq
>
> Should I try and bisect, or open an issue?  I ask here because of the
> impending 0.13 release,
>

Try this: https://github.com/ipython/ipython/pull/1956


>
> See y'all,
>
> Matthew
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120613/078d935a/attachment.html>

From matthew.brett at gmail.com  Wed Jun 13 21:34:53 2012
From: matthew.brett at gmail.com (Matthew Brett)
Date: Wed, 13 Jun 2012 18:34:53 -0700
Subject: [IPython-dev] zmq import appearing in all stacktraces
In-Reply-To: <CAHNn8BUL+9m9HZH_rKhpgdYgG_bBk+CzR4u3jmm8xhMZb13u+Q@mail.gmail.com>
References: <CAH6Pt5rBHREngGqtD5LS073s8WS1kzjzQAj8VmjnwDtheNVOzw@mail.gmail.com>
	<CAHNn8BUL+9m9HZH_rKhpgdYgG_bBk+CzR4u3jmm8xhMZb13u+Q@mail.gmail.com>
Message-ID: <CAH6Pt5r2PLA8A=87CMEMbYQX6Jh0F3RPTk8tZVEp+dqNwDpo8Q@mail.gmail.com>

Hi,

On Wed, Jun 13, 2012 at 6:21 PM, MinRK <benjaminrk at gmail.com> wrote:
>
>
> On Wed, Jun 13, 2012 at 6:13 PM, Matthew Brett <matthew.brett at gmail.com>
> wrote:
>>
>> Hi,
>>
>> I just updated to trunk:
>>
>> In [4]: IPython.sys_info()
>> Out[4]: "{'commit_hash': '99373b4',\n 'commit_source':
>> 'installation',\n 'ipython_path':
>> '/home/mb312/.virtualenvs/bare/lib/python2.6/site-packages/IPython',\n
>> 'ipython_version': '0.13.dev',\n 'os_name': 'posix',\n 'platform':
>> 'Linux-2.6.32-5-amd64-x86_64-with-debian-6.0.5',\n 'sys_executable':
>> '/home/mb312/.virtualenvs/bare/bin/python',\n 'sys_platform':
>> 'linux2',\n 'sys_version': '2.6.6 (r266:84292, Dec 26 2010, 22:31:48)
>> \\n[GCC 4.4.5]'}"
>>
>> on a machine without zmq, and noticed:
>>
>> In [5]: 1/0
>>
>> ---------------------------------------------------------------------------
>> ImportError ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Traceback (most recent call
>> last)
>>
>> /home/mb312/.virtualenvs/bare/lib/python2.6/site-packages/IPython/parallel/__init__.py
>> in <module>()
>> ? ? 19 import warnings
>> ? ? 20
>> ---> 21 import zmq
>> ? ? 22
>> ? ? 23 from IPython.config.configurable import MultipleInstanceError
>>
>> ImportError: No module named zmq
>>
>> Should I try and bisect, or open an issue? ?I ask here because of the
>> impending 0.13 release,
>
>
> Try this: https://github.com/ipython/ipython/pull/1956

Yup, works for me, thanks,

Matthew


From jonathan.taylor at stanford.edu  Wed Jun 13 21:51:12 2012
From: jonathan.taylor at stanford.edu (Jonathan Taylor)
Date: Wed, 13 Jun 2012 18:51:12 -0700
Subject: [IPython-dev] problem with publish_display_data?
In-Reply-To: <CAHNn8BVG57cVy7g0mewcN4y-pmU=ZKWiY3zybatnnm9ngwr9BQ@mail.gmail.com>
References: <CANmCCuQyK7Uo6SZKVZC6CHhjEttPJnWyYsXY5E+etWwZ6vGSjg@mail.gmail.com>
	<CAHNn8BVG57cVy7g0mewcN4y-pmU=ZKWiY3zybatnnm9ngwr9BQ@mail.gmail.com>
Message-ID: <CANmCCuSxqLNRRh4xLgdWY5nBq1kciPXAXbUG1F=t26ZsH82sig@mail.gmail.com>

I was a little confused because sometimes it displays several things. The
idea with having several values in the dict is that they might be different
representations of the same output?

On Wed, Jun 13, 2012 at 4:08 PM, MinRK <benjaminrk at gmail.com> wrote:

>
>
> On Wed, Jun 13, 2012 at 3:52 PM, Jonathan Taylor <
> jonathan.taylor at stanford.edu> wrote:
>
>> On the master branch, I am getting some unexpected behaviour when I try
>> the following
>>
>> import numpy as np
>> from IPython.core.displaypub import publish_display_data
>>
>> class NormalMean(object):
>>     """
>>     Sample from N(mean, sd) independently n times
>>     """
>>     tol = 5.e-2
>>     checkable = True
>>
>>     def __init__(self, mean, sd, n, identifier):
>>         self.mean = mean
>>         self.identifier = identifier
>>         self.sd = sd
>>         self.n = n
>>         self.sequence = self.generate()
>>         self.correct_answer = np.mean(self.sequence)
>>
>>     def generate(self):
>>         return np.round(np.random.standard_normal(self.n), 1) * self.sd+ self.mean
>>
>>     @property
>>     def answer(self):
>>         return np.mean(self.sequence)
>>
>>     def publish(self, return_data=False):
>>
>>         data = {'text/latex': r"What is the sample mean, $\bar{X}$ of
>> this sequence: %s ?" % `["%0.1f" % s for s in self.sequence]`,
>>                 'text/html': ''}
>>
>>         data['text/html'] += '<form method="post" name=%s ><p><input
>> type="text" ></p></form>' % self.identifier
>>         data['application/json'] = {'constructor_info': ('normal_mean',
>> [self.mean, self.sd, self.n], {})}
>>         publish_display_data("NormalMean", data)
>>         if return_data:
>>             return data
>>
>>     def check_answer(self, answer):
>>         if np.fabs(answer - self.correct_answer) / np.std(self.sequence)
>> < self.tol:
>>             data = self.publish(return_data=True)
>>             data['text/html'] += '\n<p><h2>Good job!</h2></p>\n'
>>         else:
>>             self.sequence = self.generate()
>>             data = self.publish(return_data=True)
>>             data['text/html'] += '\n<p><h2>Try Again!</h2></p>\n'
>>
>>
>> NormalMean(10, 3, 6, 'mean_10_sd_3_n_6').publish()
>>
>>
>> I expect to see a latex rendering of the question with a textbox below it
>> but I am only getting a text box.
>>
>> By the way, if I want to see these things in order, I suppose it is best
>> to use several calls to publish_display_data? Is that right, if so the
>> outputs are in the order I want them to be rather than
>> the order of the dict keys (which I cannot control).
>>
>
> Right - one call to "publish_display_data" should always result in exactly
> one thing being displayed.  The idea being "I have a thing I want to
> display, and I can display in all these different ways". It is up to the
> frontends to pick their favorite (HTML in the notebook).  If you want to
> display multiple things, then you should use multiple calls.
>
> -MinRK
>
>
>>
>> Thanks,
>>
>> Jonathan
>>
>>
>> --
>> Jonathan Taylor
>> Dept. of Statistics
>> Sequoia Hall, 137
>> 390 Serra Mall
>> Stanford, CA 94305
>> Tel:   650.723.9230
>> Fax:   650.725.8977
>> Web: http://www-stat.stanford.edu/~jtaylo
>>
>> _______________________________________________
>> 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
>
>


-- 
Jonathan Taylor
Dept. of Statistics
Sequoia Hall, 137
390 Serra Mall
Stanford, CA 94305
Tel:   650.723.9230
Fax:   650.725.8977
Web: http://www-stat.stanford.edu/~jtaylo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120613/c096b1a6/attachment.html>

From benjaminrk at gmail.com  Wed Jun 13 21:56:05 2012
From: benjaminrk at gmail.com (MinRK)
Date: Wed, 13 Jun 2012 18:56:05 -0700
Subject: [IPython-dev] problem with publish_display_data?
In-Reply-To: <CANmCCuSxqLNRRh4xLgdWY5nBq1kciPXAXbUG1F=t26ZsH82sig@mail.gmail.com>
References: <CANmCCuQyK7Uo6SZKVZC6CHhjEttPJnWyYsXY5E+etWwZ6vGSjg@mail.gmail.com>
	<CAHNn8BVG57cVy7g0mewcN4y-pmU=ZKWiY3zybatnnm9ngwr9BQ@mail.gmail.com>
	<CANmCCuSxqLNRRh4xLgdWY5nBq1kciPXAXbUG1F=t26ZsH82sig@mail.gmail.com>
Message-ID: <CAHNn8BXiSfrjouta8vcNF7p+3uaLaSSHvxJtUZnVNkjQy4A15w@mail.gmail.com>

On Wed, Jun 13, 2012 at 6:51 PM, Jonathan Taylor <
jonathan.taylor at stanford.edu> wrote:

> I was a little confused because sometimes it displays several things.


When have you seen multiple displays from one display call?  This would be
a bug.


> The idea with having several values in the dict is that they might be
> different representations of the same output?


Precisely. One call == one thing to display.


>
>
> On Wed, Jun 13, 2012 at 4:08 PM, MinRK <benjaminrk at gmail.com> wrote:
>
>>
>>
>> On Wed, Jun 13, 2012 at 3:52 PM, Jonathan Taylor <
>> jonathan.taylor at stanford.edu> wrote:
>>
>>> On the master branch, I am getting some unexpected behaviour when I try
>>> the following
>>>
>>> import numpy as np
>>> from IPython.core.displaypub import publish_display_data
>>>
>>> class NormalMean(object):
>>>     """
>>>     Sample from N(mean, sd) independently n times
>>>     """
>>>     tol = 5.e-2
>>>     checkable = True
>>>
>>>     def __init__(self, mean, sd, n, identifier):
>>>         self.mean = mean
>>>         self.identifier = identifier
>>>         self.sd = sd
>>>         self.n = n
>>>         self.sequence = self.generate()
>>>         self.correct_answer = np.mean(self.sequence)
>>>
>>>     def generate(self):
>>>         return np.round(np.random.standard_normal(self.n), 1) * self.sd+ self.mean
>>>
>>>     @property
>>>     def answer(self):
>>>         return np.mean(self.sequence)
>>>
>>>     def publish(self, return_data=False):
>>>
>>>         data = {'text/latex': r"What is the sample mean, $\bar{X}$ of
>>> this sequence: %s ?" % `["%0.1f" % s for s in self.sequence]`,
>>>                 'text/html': ''}
>>>
>>>         data['text/html'] += '<form method="post" name=%s ><p><input
>>> type="text" ></p></form>' % self.identifier
>>>         data['application/json'] = {'constructor_info': ('normal_mean',
>>> [self.mean, self.sd, self.n], {})}
>>>         publish_display_data("NormalMean", data)
>>>         if return_data:
>>>             return data
>>>
>>>     def check_answer(self, answer):
>>>         if np.fabs(answer - self.correct_answer) / np.std(self.sequence)
>>> < self.tol:
>>>             data = self.publish(return_data=True)
>>>             data['text/html'] += '\n<p><h2>Good job!</h2></p>\n'
>>>         else:
>>>             self.sequence = self.generate()
>>>             data = self.publish(return_data=True)
>>>             data['text/html'] += '\n<p><h2>Try Again!</h2></p>\n'
>>>
>>>
>>> NormalMean(10, 3, 6, 'mean_10_sd_3_n_6').publish()
>>>
>>>
>>> I expect to see a latex rendering of the question with a textbox below
>>> it but I am only getting a text box.
>>>
>>> By the way, if I want to see these things in order, I suppose it is best
>>> to use several calls to publish_display_data? Is that right, if so the
>>> outputs are in the order I want them to be rather than
>>> the order of the dict keys (which I cannot control).
>>>
>>
>> Right - one call to "publish_display_data" should always result in
>> exactly one thing being displayed.  The idea being "I have a thing I want
>> to display, and I can display in all these different ways". It is up to the
>> frontends to pick their favorite (HTML in the notebook).  If you want to
>> display multiple things, then you should use multiple calls.
>>
>> -MinRK
>>
>>
>>>
>>> Thanks,
>>>
>>> Jonathan
>>>
>>>
>>> --
>>> Jonathan Taylor
>>> Dept. of Statistics
>>> Sequoia Hall, 137
>>> 390 Serra Mall
>>> Stanford, CA 94305
>>> Tel:   650.723.9230
>>> Fax:   650.725.8977
>>> Web: http://www-stat.stanford.edu/~jtaylo
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
>
> --
> Jonathan Taylor
> Dept. of Statistics
> Sequoia Hall, 137
> 390 Serra Mall
> Stanford, CA 94305
> Tel:   650.723.9230
> Fax:   650.725.8977
> Web: http://www-stat.stanford.edu/~jtaylo
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120613/fead6c2f/attachment.html>

From jonathan.taylor at stanford.edu  Wed Jun 13 22:18:36 2012
From: jonathan.taylor at stanford.edu (Jonathan Taylor)
Date: Wed, 13 Jun 2012 19:18:36 -0700
Subject: [IPython-dev] problem with publish_display_data?
In-Reply-To: <CAHNn8BXiSfrjouta8vcNF7p+3uaLaSSHvxJtUZnVNkjQy4A15w@mail.gmail.com>
References: <CANmCCuQyK7Uo6SZKVZC6CHhjEttPJnWyYsXY5E+etWwZ6vGSjg@mail.gmail.com>
	<CAHNn8BVG57cVy7g0mewcN4y-pmU=ZKWiY3zybatnnm9ngwr9BQ@mail.gmail.com>
	<CANmCCuSxqLNRRh4xLgdWY5nBq1kciPXAXbUG1F=t26ZsH82sig@mail.gmail.com>
	<CAHNn8BXiSfrjouta8vcNF7p+3uaLaSSHvxJtUZnVNkjQy4A15w@mail.gmail.com>
Message-ID: <CANmCCuQ0pCrDuFN_fQZn3Vi0DUhrB6d7V4+GQ-UgTYokBS8CrA@mail.gmail.com>

Sorry, in looking over my other code I had called publish_display_data
twice but thought it was only once. So, I haven't found a bug.

On Wed, Jun 13, 2012 at 6:56 PM, MinRK <benjaminrk at gmail.com> wrote:

>
>
> On Wed, Jun 13, 2012 at 6:51 PM, Jonathan Taylor <
> jonathan.taylor at stanford.edu> wrote:
>
>> I was a little confused because sometimes it displays several things.
>
>
> When have you seen multiple displays from one display call?  This would be
> a bug.
>
>
>> The idea with having several values in the dict is that they might be
>> different representations of the same output?
>
>
> Precisely. One call == one thing to display.
>
>
>>
>>
>> On Wed, Jun 13, 2012 at 4:08 PM, MinRK <benjaminrk at gmail.com> wrote:
>>
>>>
>>>
>>> On Wed, Jun 13, 2012 at 3:52 PM, Jonathan Taylor <
>>> jonathan.taylor at stanford.edu> wrote:
>>>
>>>> On the master branch, I am getting some unexpected behaviour when I try
>>>> the following
>>>>
>>>> import numpy as np
>>>> from IPython.core.displaypub import publish_display_data
>>>>
>>>> class NormalMean(object):
>>>>     """
>>>>     Sample from N(mean, sd) independently n times
>>>>     """
>>>>     tol = 5.e-2
>>>>     checkable = True
>>>>
>>>>     def __init__(self, mean, sd, n, identifier):
>>>>         self.mean = mean
>>>>         self.identifier = identifier
>>>>         self.sd = sd
>>>>         self.n = n
>>>>         self.sequence = self.generate()
>>>>         self.correct_answer = np.mean(self.sequence)
>>>>
>>>>     def generate(self):
>>>>         return np.round(np.random.standard_normal(self.n), 1) * self.sd+ self.mean
>>>>
>>>>     @property
>>>>     def answer(self):
>>>>         return np.mean(self.sequence)
>>>>
>>>>     def publish(self, return_data=False):
>>>>
>>>>         data = {'text/latex': r"What is the sample mean, $\bar{X}$ of
>>>> this sequence: %s ?" % `["%0.1f" % s for s in self.sequence]`,
>>>>                 'text/html': ''}
>>>>
>>>>         data['text/html'] += '<form method="post" name=%s ><p><input
>>>> type="text" ></p></form>' % self.identifier
>>>>         data['application/json'] = {'constructor_info': ('normal_mean',
>>>> [self.mean, self.sd, self.n], {})}
>>>>         publish_display_data("NormalMean", data)
>>>>         if return_data:
>>>>             return data
>>>>
>>>>     def check_answer(self, answer):
>>>>         if np.fabs(answer - self.correct_answer) /
>>>> np.std(self.sequence) < self.tol:
>>>>             data = self.publish(return_data=True)
>>>>             data['text/html'] += '\n<p><h2>Good job!</h2></p>\n'
>>>>         else:
>>>>             self.sequence = self.generate()
>>>>             data = self.publish(return_data=True)
>>>>             data['text/html'] += '\n<p><h2>Try Again!</h2></p>\n'
>>>>
>>>>
>>>> NormalMean(10, 3, 6, 'mean_10_sd_3_n_6').publish()
>>>>
>>>>
>>>> I expect to see a latex rendering of the question with a textbox below
>>>> it but I am only getting a text box.
>>>>
>>>> By the way, if I want to see these things in order, I suppose it is
>>>> best to use several calls to publish_display_data? Is that right, if so the
>>>> outputs are in the order I want them to be rather than
>>>> the order of the dict keys (which I cannot control).
>>>>
>>>
>>> Right - one call to "publish_display_data" should always result in
>>> exactly one thing being displayed.  The idea being "I have a thing I want
>>> to display, and I can display in all these different ways". It is up to the
>>> frontends to pick their favorite (HTML in the notebook).  If you want to
>>> display multiple things, then you should use multiple calls.
>>>
>>> -MinRK
>>>
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Jonathan
>>>>
>>>>
>>>> --
>>>> Jonathan Taylor
>>>> Dept. of Statistics
>>>> Sequoia Hall, 137
>>>> 390 Serra Mall
>>>> Stanford, CA 94305
>>>> Tel:   650.723.9230
>>>> Fax:   650.725.8977
>>>> Web: http://www-stat.stanford.edu/~jtaylo
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
>>
>> --
>> Jonathan Taylor
>> Dept. of Statistics
>> Sequoia Hall, 137
>> 390 Serra Mall
>> Stanford, CA 94305
>> Tel:   650.723.9230
>> Fax:   650.725.8977
>> Web: http://www-stat.stanford.edu/~jtaylo
>>
>> _______________________________________________
>> 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
>
>


-- 
Jonathan Taylor
Dept. of Statistics
Sequoia Hall, 137
390 Serra Mall
Stanford, CA 94305
Tel:   650.723.9230
Fax:   650.725.8977
Web: http://www-stat.stanford.edu/~jtaylo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120613/0ac71b09/attachment.html>

From takowl at gmail.com  Thu Jun 14 06:24:24 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Thu, 14 Jun 2012 11:24:24 +0100
Subject: [IPython-dev] An idea for `iypthon notebook` server CTRL+C (^C)
In-Reply-To: <1339667422.49193.YahooMailClassic@web162306.mail.bf1.yahoo.com>
References: <1339667422.49193.YahooMailClassic@web162306.mail.bf1.yahoo.com>
Message-ID: <CAOvn4qifCH-btbawQiV9BVJxpw3fmGDiQwTckjER4V9K3wg0yQ@mail.gmail.com>

On 14 June 2012 10:50, Flubber <flubberhk90 at yahoo.com> wrote:

> I am aware of that, I just expressed my opinion regarding the words said
> in the YouTube video that ^C (CTRL+C) in terminal will generate a Keyboard
> Interrupt thus closing the server. The speaker clearly specified that this
> will be handled in the future and at current time (in video at conference)
> isn't fixed. So, I thought to give you guys and idea to try and spawn the
> process similar to "ipython notebook &" and maybe redirect the stdout
> output to a log or similarly.
>

I think you're confused about this - we *want* Ctrl+C in the terminal to
shut the server down. It's not a bug. At present it's the simplest way to
stop the server.

If we didn't want that, it would be easy to catch the exception and keep
the server running.

Thanks,
Thomas

P.S. If you want to reply, please send it to the mailing list, rather than
me personally: ipython-dev at scipy.org



>
> All the best and,
> Keep up the good work
>
> --- On Tue, 5/15/12, Thomas Kluyver <takowl at gmail.com<http://mc/compose?to=takowl at gmail.com>>
> wrote:
>
> > From: Thomas Kluyver <takowl at gmail.com<http://mc/compose?to=takowl at gmail.com>
> >
> > Subject: Re: [IPython-dev] An idea for `iypthon notebook` server CTRL+C
> (^C)
> > To: "IPython developers list" <ipython-dev at scipy.org<http://mc/compose?to=ipython-dev at scipy.org>>,
> flubberhk90 at yahoo.com <http://mc/compose?to=flubberhk90 at yahoo.com>
> > Date: Tuesday, May 15, 2012, 10:42 AM
> > Hi,
> >
> > Flubber:
> > but
> > if the server crashes upon CTRL+C (the `ipython notebook`),
> > then, couldn't
> >  you spawn the server in a mirror
> > shell/terminal/console/whatever similar to the QT
> > one?
> > I'm not quite clear about what you're suggesting.
> > It's not a crash - pressing Ctrl+C in the terminal where
> > you started the notebook is the way to shut it down. Ctrl+C
> > within a notebook doesn't affect the server - the
> > browser will handle it, generally as a copy command.
> >
> >
> >
> > Thanks,
> > Thomas
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120614/e22dd867/attachment.html>

From takowl at gmail.com  Thu Jun 14 10:37:25 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Thu, 14 Jun 2012 15:37:25 +0100
Subject: [IPython-dev] Tests passing on Python 3.3
Message-ID: <CAOvn4qiGPGq5cQHRmdYaEKhHP3o59Yb6B45GXQo6jukj-rUJsw@mail.gmail.com>

I'm pleased to say that, hot on the heels of fixing our windows tests,
the Python 3.3 tests on ShiningPanda are now passing.

Shiningpanda upgraded to 3.3a4, and I've fixed some teething troubles
(pyzmq needed to be re-cythoned).

Best wishes,
Thomas


From jonathan.taylor at stanford.edu  Thu Jun 14 18:23:34 2012
From: jonathan.taylor at stanford.edu (Jonathan Taylor)
Date: Thu, 14 Jun 2012 15:23:34 -0700
Subject: [IPython-dev] use of InteractiveShell and R magic
Message-ID: <CANmCCuQdxOOLgrW_+7Z3Jv7afqn+_fnF0JWOfxQCQM21Yqmqcw@mail.gmail.com>

I'm trying to run some cells through InteractiveShell and am getting an
unexpected error message which is that my shell
can't find the %R line magic:


In [1]: import IPython.frontend.terminal.interactiveshell as IS

In [2]: shell = IS.InteractiveShell()

In [3]: shell.run_cell('%load_ext rmagic')

In [4]: shell.run_cell('%R X=rnorm(20)')
ERROR: Line magic function `%R` not found.
In [5]:

In [5]: load_ext rmagic

In [6]: %R X=rnorm(20)
Out[6]:
array([ 0.08724969,  2.03344439, -0.82111458, -2.07136391, -0.11913743,
        0.19598438,  0.58574042, -0.33684877, -0.9659225 , -0.68404775,
       -0.0278716 ,  1.34169008, -0.6034878 ,  1.76146422, -0.19225874,
       -1.15088263, -1.10644146, -1.27298014, -1.18212805,  1.60194601])

Is this expected? I can't tell.



-- 
Jonathan Taylor
Dept. of Statistics
Sequoia Hall, 137
390 Serra Mall
Stanford, CA 94305
Tel:   650.723.9230
Fax:   650.725.8977
Web: http://www-stat.stanford.edu/~jtaylo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120614/a10bc333/attachment.html>

From benjaminrk at gmail.com  Thu Jun 14 18:35:04 2012
From: benjaminrk at gmail.com (MinRK)
Date: Thu, 14 Jun 2012 15:35:04 -0700
Subject: [IPython-dev] use of InteractiveShell and R magic
In-Reply-To: <CANmCCuQdxOOLgrW_+7Z3Jv7afqn+_fnF0JWOfxQCQM21Yqmqcw@mail.gmail.com>
References: <CANmCCuQdxOOLgrW_+7Z3Jv7afqn+_fnF0JWOfxQCQM21Yqmqcw@mail.gmail.com>
Message-ID: <CAHNn8BVpzzm56ZQ518okzE+hOsbUkbo+xnyKwY7Qmov_v0pPhA@mail.gmail.com>

On Thu, Jun 14, 2012 at 3:23 PM, Jonathan Taylor <
jonathan.taylor at stanford.edu> wrote:

> I'm trying to run some cells through InteractiveShell and am getting an
> unexpected error message which is that my shell
> can't find the %R line magic:
>
>
> In [1]: import IPython.frontend.terminal.interactiveshell as IS
>
> In [2]: shell = IS.InteractiveShell()
>
> In [3]: shell.run_cell('%load_ext rmagic')
>
> In [4]: shell.run_cell('%R X=rnorm(20)')
> ERROR: Line magic function `%R` not found.
> In [5]:
>
> In [5]: load_ext rmagic
>
> In [6]: %R X=rnorm(20)
> Out[6]:
> array([ 0.08724969,  2.03344439, -0.82111458, -2.07136391, -0.11913743,
>         0.19598438,  0.58574042, -0.33684877, -0.9659225 , -0.68404775,
>        -0.0278716 ,  1.34169008, -0.6034878 ,  1.76146422, -0.19225874,
>        -1.15088263, -1.10644146, -1.27298014, -1.18212805,  1.60194601])
>
> Is this expected? I can't tell.
>

One thing that's not at all expected is creating a new InteractiveShell
inside an InteractiveShell.  Do you mean to be creating a whole new
InteractiveShell object in which to run these commands?

If you want a handle on the*existing* shell, you can use: shell =
get_ipython().

If you do that, your run_cell calls above seem to behave as you are
expecting.

-MinRK


>
>
> --
> Jonathan Taylor
> Dept. of Statistics
> Sequoia Hall, 137
> 390 Serra Mall
> Stanford, CA 94305
> Tel:   650.723.9230
> Fax:   650.725.8977
> Web: http://www-stat.stanford.edu/~jtaylo
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120614/855986ba/attachment.html>

From jonathan.taylor at stanford.edu  Thu Jun 14 18:44:00 2012
From: jonathan.taylor at stanford.edu (Jonathan Taylor)
Date: Thu, 14 Jun 2012 15:44:00 -0700
Subject: [IPython-dev] use of InteractiveShell and R magic
In-Reply-To: <CAHNn8BVpzzm56ZQ518okzE+hOsbUkbo+xnyKwY7Qmov_v0pPhA@mail.gmail.com>
References: <CANmCCuQdxOOLgrW_+7Z3Jv7afqn+_fnF0JWOfxQCQM21Yqmqcw@mail.gmail.com>
	<CAHNn8BVpzzm56ZQ518okzE+hOsbUkbo+xnyKwY7Qmov_v0pPhA@mail.gmail.com>
Message-ID: <CANmCCuQExen2BdqaLU12NZAGXWjON0o3xXbCzv5R+oc-uBkUNQ@mail.gmail.com>

Actually, I want to create an InteractiveShell inside another python
process. Maybe I should use embed?

Inside ipython this doesn't work, but maybe it would inside another python
process?

In [12]: import IPython.frontend.terminal as IT

In [13]: shell = IT.embed.InteractiveShellEmbed()

In [14]: shell.run_cell('%R X=rnorm(20)')
ERROR: Line magic function `%R` not found.

On Thu, Jun 14, 2012 at 3:35 PM, MinRK <benjaminrk at gmail.com> wrote:

>
>
> On Thu, Jun 14, 2012 at 3:23 PM, Jonathan Taylor <
> jonathan.taylor at stanford.edu> wrote:
>
>> I'm trying to run some cells through InteractiveShell and am getting an
>> unexpected error message which is that my shell
>> can't find the %R line magic:
>>
>>
>> In [1]: import IPython.frontend.terminal.interactiveshell as IS
>>
>> In [2]: shell = IS.InteractiveShell()
>>
>> In [3]: shell.run_cell('%load_ext rmagic')
>>
>> In [4]: shell.run_cell('%R X=rnorm(20)')
>> ERROR: Line magic function `%R` not found.
>> In [5]:
>>
>> In [5]: load_ext rmagic
>>
>> In [6]: %R X=rnorm(20)
>> Out[6]:
>> array([ 0.08724969,  2.03344439, -0.82111458, -2.07136391, -0.11913743,
>>         0.19598438,  0.58574042, -0.33684877, -0.9659225 , -0.68404775,
>>        -0.0278716 ,  1.34169008, -0.6034878 ,  1.76146422, -0.19225874,
>>        -1.15088263, -1.10644146, -1.27298014, -1.18212805,  1.60194601])
>>
>> Is this expected? I can't tell.
>>
>
> One thing that's not at all expected is creating a new InteractiveShell
> inside an InteractiveShell.  Do you mean to be creating a whole new
> InteractiveShell object in which to run these commands?
>
> If you want a handle on the*existing* shell, you can use: shell =
> get_ipython().
>
> If you do that, your run_cell calls above seem to behave as you are
> expecting.
>
> -MinRK
>
>
>>
>>
>> --
>> Jonathan Taylor
>> Dept. of Statistics
>> Sequoia Hall, 137
>> 390 Serra Mall
>> Stanford, CA 94305
>> Tel:   650.723.9230
>> Fax:   650.725.8977
>> Web: http://www-stat.stanford.edu/~jtaylo
>>
>> _______________________________________________
>> 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
>
>


-- 
Jonathan Taylor
Dept. of Statistics
Sequoia Hall, 137
390 Serra Mall
Stanford, CA 94305
Tel:   650.723.9230
Fax:   650.725.8977
Web: http://www-stat.stanford.edu/~jtaylo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120614/d34b5f81/attachment.html>

From jonathan.taylor at stanford.edu  Thu Jun 14 18:48:13 2012
From: jonathan.taylor at stanford.edu (Jonathan Taylor)
Date: Thu, 14 Jun 2012 15:48:13 -0700
Subject: [IPython-dev] use of InteractiveShell and R magic
In-Reply-To: <CANmCCuQExen2BdqaLU12NZAGXWjON0o3xXbCzv5R+oc-uBkUNQ@mail.gmail.com>
References: <CANmCCuQdxOOLgrW_+7Z3Jv7afqn+_fnF0JWOfxQCQM21Yqmqcw@mail.gmail.com>
	<CAHNn8BVpzzm56ZQ518okzE+hOsbUkbo+xnyKwY7Qmov_v0pPhA@mail.gmail.com>
	<CANmCCuQExen2BdqaLU12NZAGXWjON0o3xXbCzv5R+oc-uBkUNQ@mail.gmail.com>
Message-ID: <CANmCCuRzXHUzfKnBxKPrkOpXO8p=D-kysw2CwccCRwU8q-7Wog@mail.gmail.com>

I should say that what I really want to do is to take an .ipynb file and
execute it in such a way that I can take some things from its namespace into
the namespace of the python process. For example, I might have a function
or a class defined in the .ipynb file that I want to pull into the python
process.

Using InteractiveShell or TerminalInteractiveShell seems to work for this,
except for raising errors about not finding the %R magic.

On Thu, Jun 14, 2012 at 3:44 PM, Jonathan Taylor <
jonathan.taylor at stanford.edu> wrote:

> Actually, I want to create an InteractiveShell inside another python
> process. Maybe I should use embed?
>
> Inside ipython this doesn't work, but maybe it would inside another python
> process?
>
> In [12]: import IPython.frontend.terminal as IT
>
> In [13]: shell = IT.embed.InteractiveShellEmbed()
>
> In [14]: shell.run_cell('%R X=rnorm(20)')
> ERROR: Line magic function `%R` not found.
>
> On Thu, Jun 14, 2012 at 3:35 PM, MinRK <benjaminrk at gmail.com> wrote:
>
>>
>>
>> On Thu, Jun 14, 2012 at 3:23 PM, Jonathan Taylor <
>> jonathan.taylor at stanford.edu> wrote:
>>
>>> I'm trying to run some cells through InteractiveShell and am getting an
>>> unexpected error message which is that my shell
>>> can't find the %R line magic:
>>>
>>>
>>> In [1]: import IPython.frontend.terminal.interactiveshell as IS
>>>
>>> In [2]: shell = IS.InteractiveShell()
>>>
>>> In [3]: shell.run_cell('%load_ext rmagic')
>>>
>>> In [4]: shell.run_cell('%R X=rnorm(20)')
>>> ERROR: Line magic function `%R` not found.
>>> In [5]:
>>>
>>> In [5]: load_ext rmagic
>>>
>>> In [6]: %R X=rnorm(20)
>>> Out[6]:
>>> array([ 0.08724969,  2.03344439, -0.82111458, -2.07136391, -0.11913743,
>>>         0.19598438,  0.58574042, -0.33684877, -0.9659225 , -0.68404775,
>>>        -0.0278716 ,  1.34169008, -0.6034878 ,  1.76146422, -0.19225874,
>>>        -1.15088263, -1.10644146, -1.27298014, -1.18212805,  1.60194601])
>>>
>>> Is this expected? I can't tell.
>>>
>>
>> One thing that's not at all expected is creating a new InteractiveShell
>> inside an InteractiveShell.  Do you mean to be creating a whole new
>> InteractiveShell object in which to run these commands?
>>
>> If you want a handle on the*existing* shell, you can use: shell =
>> get_ipython().
>>
>> If you do that, your run_cell calls above seem to behave as you are
>> expecting.
>>
>> -MinRK
>>
>>
>>>
>>>
>>> --
>>> Jonathan Taylor
>>> Dept. of Statistics
>>> Sequoia Hall, 137
>>> 390 Serra Mall
>>> Stanford, CA 94305
>>> Tel:   650.723.9230
>>> Fax:   650.725.8977
>>> Web: http://www-stat.stanford.edu/~jtaylo
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
>
> --
> Jonathan Taylor
> Dept. of Statistics
> Sequoia Hall, 137
> 390 Serra Mall
> Stanford, CA 94305
> Tel:   650.723.9230
> Fax:   650.725.8977
> Web: http://www-stat.stanford.edu/~jtaylo
>



-- 
Jonathan Taylor
Dept. of Statistics
Sequoia Hall, 137
390 Serra Mall
Stanford, CA 94305
Tel:   650.723.9230
Fax:   650.725.8977
Web: http://www-stat.stanford.edu/~jtaylo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120614/aa2c3999/attachment.html>

From takowl at gmail.com  Thu Jun 14 18:48:48 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Thu, 14 Jun 2012 23:48:48 +0100
Subject: [IPython-dev] use of InteractiveShell and R magic
In-Reply-To: <CANmCCuQExen2BdqaLU12NZAGXWjON0o3xXbCzv5R+oc-uBkUNQ@mail.gmail.com>
References: <CANmCCuQdxOOLgrW_+7Z3Jv7afqn+_fnF0JWOfxQCQM21Yqmqcw@mail.gmail.com>
	<CAHNn8BVpzzm56ZQ518okzE+hOsbUkbo+xnyKwY7Qmov_v0pPhA@mail.gmail.com>
	<CANmCCuQExen2BdqaLU12NZAGXWjON0o3xXbCzv5R+oc-uBkUNQ@mail.gmail.com>
Message-ID: <CAOvn4qjvZ5Muyfrn0UqktjiKxxwjHHFgwHZAn7soGAqyDSqO2A@mail.gmail.com>

On 14 June 2012 23:44, Jonathan Taylor <jonathan.taylor at stanford.edu> wrote:
> Actually, I want to create an InteractiveShell inside another python
> process. Maybe I should use embed?

Embed's not terribly relevant here - that creates an InteractiveShell,
but attempts to use the namespace from which it's called.

Try it in a separate Python process. Don't forget to %load_ext rmagic first.

Thomas


From jonathan.taylor at stanford.edu  Thu Jun 14 18:57:00 2012
From: jonathan.taylor at stanford.edu (Jonathan Taylor)
Date: Thu, 14 Jun 2012 15:57:00 -0700
Subject: [IPython-dev] use of InteractiveShell and R magic
In-Reply-To: <CAOvn4qjvZ5Muyfrn0UqktjiKxxwjHHFgwHZAn7soGAqyDSqO2A@mail.gmail.com>
References: <CANmCCuQdxOOLgrW_+7Z3Jv7afqn+_fnF0JWOfxQCQM21Yqmqcw@mail.gmail.com>
	<CAHNn8BVpzzm56ZQ518okzE+hOsbUkbo+xnyKwY7Qmov_v0pPhA@mail.gmail.com>
	<CANmCCuQExen2BdqaLU12NZAGXWjON0o3xXbCzv5R+oc-uBkUNQ@mail.gmail.com>
	<CAOvn4qjvZ5Muyfrn0UqktjiKxxwjHHFgwHZAn7soGAqyDSqO2A@mail.gmail.com>
Message-ID: <CANmCCuRK7hkr306n3Yt+Apb2sFmdgHGzwNCmiCcbh8pnBncHFQ@mail.gmail.com>

Thanks, that seems to work in a separate python process rather than the
ipython process:

~/workbook (metadata*) $ python -c "import
IPython.frontend.terminal.interactiveshell as IS; shell =
IS.TerminalInteractiveShell(); shell.run_cell('%load_ext rmagic');
shell.run_cell('%R X=rnorm(20); print(X)')"
 [1]  0.2125483  0.1030451 -1.4036373 -0.5617847 -0.7571675 -0.3985085
 [7] -0.4386932  0.7164915 -0.4794236 -0.1373804  0.2831013 -0.7248862
[13]  0.5260675 -0.3789804  0.1535592  1.5569203  1.0225972  0.8149846
[19] -0.9629060 -0.4161373

~/workbook (metadata*) $ python -c "import
IPython.frontend.terminal.interactiveshell as IS; shell =
IS.InteractiveShell(); shell.run_cell('%load_ext rmagic');
shell.run_cell('%R X=rnorm(20); print(X)')"
 [1]  0.44037484  1.31372601 -0.37253955  2.21955270 -0.07886852 -0.09022193
 [7]  0.38464850 -0.41004855  1.62648041 -0.13687832  0.91537699 -2.70125217
[13]  1.49125226  0.11580012 -0.64993087  2.49367657  0.01447792  0.57408249
[19] -0.80559871 -0.76346964

So, for interactively running this in ipython I should expect to see this
load_ext failure?

Thanks,

Jonathan

On Thu, Jun 14, 2012 at 3:48 PM, Thomas Kluyver <takowl at gmail.com> wrote:

> On 14 June 2012 23:44, Jonathan Taylor <jonathan.taylor at stanford.edu>
> wrote:
> > Actually, I want to create an InteractiveShell inside another python
> > process. Maybe I should use embed?
>
> Embed's not terribly relevant here - that creates an InteractiveShell,
> but attempts to use the namespace from which it's called.
>
> Try it in a separate Python process. Don't forget to %load_ext rmagic
> first.
>
> Thomas
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Jonathan Taylor
Dept. of Statistics
Sequoia Hall, 137
390 Serra Mall
Stanford, CA 94305
Tel:   650.723.9230
Fax:   650.725.8977
Web: http://www-stat.stanford.edu/~jtaylo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120614/d20f3096/attachment.html>

From dlsun at stanford.edu  Thu Jun 14 19:13:21 2012
From: dlsun at stanford.edu (Dennis Sun)
Date: Thu, 14 Jun 2012 16:13:21 -0700
Subject: [IPython-dev] Adding attributes to .ipynb files
Message-ID: <CADLczKD+gbS+VQkzH5+brhpYq-RjWkOAUXBpyA5mX37rPsFunw@mail.gmail.com>

Hi all,

We're working on a project where we need notebook files that have some
extra data attached to each cell. Because we would like to make sure that
the files are still compatible with the iPython Notebook, what we're doing
right now is including this metadata in the "json" attribute of the output
of each cell and then "promoting" these attributes to the cell level at
runtime. Thus, the notebook file is still a valid .ipynb file, but the
metadata doesn't show up when the user loads the page.

However, it seems right now that we can get away with adding the metadata
directly at the cell level in the .ipynb file, since iPython Notebook
simply passes over any keys that it doesn't know to look for. We would like
to do this instead, since it is conceptually much cleaner, but we are
worried about compatibility with future versions of iPython, which might
enforce .ipynb files to follow a certain format.

We were hoping that someone more knowledgeable about the state of iPython
development could advise on whether or not it's safe to add our own
attributes directly to the .ipynb files. It seems that this shouldn't be a
problem as long as .ipynb remains a JSON key-value store, but we wanted to
check with the community to make sure.

Thanks,
Dennis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120614/0042bd27/attachment.html>

From benjaminrk at gmail.com  Thu Jun 14 19:26:01 2012
From: benjaminrk at gmail.com (MinRK)
Date: Thu, 14 Jun 2012 16:26:01 -0700
Subject: [IPython-dev] use of InteractiveShell and R magic
In-Reply-To: <CANmCCuRK7hkr306n3Yt+Apb2sFmdgHGzwNCmiCcbh8pnBncHFQ@mail.gmail.com>
References: <CANmCCuQdxOOLgrW_+7Z3Jv7afqn+_fnF0JWOfxQCQM21Yqmqcw@mail.gmail.com>
	<CAHNn8BVpzzm56ZQ518okzE+hOsbUkbo+xnyKwY7Qmov_v0pPhA@mail.gmail.com>
	<CANmCCuQExen2BdqaLU12NZAGXWjON0o3xXbCzv5R+oc-uBkUNQ@mail.gmail.com>
	<CAOvn4qjvZ5Muyfrn0UqktjiKxxwjHHFgwHZAn7soGAqyDSqO2A@mail.gmail.com>
	<CANmCCuRK7hkr306n3Yt+Apb2sFmdgHGzwNCmiCcbh8pnBncHFQ@mail.gmail.com>
Message-ID: <CAHNn8BWb-5WWDfU-z6ZL4shsVGmEEJJ2LaHE53LN+qHU3+Vu4A@mail.gmail.com>

On Thu, Jun 14, 2012 at 3:57 PM, Jonathan Taylor <
jonathan.taylor at stanford.edu> wrote:

> Thanks, that seems to work in a separate python process rather than the
> ipython process:
>
> ~/workbook (metadata*) $ python -c "import
> IPython.frontend.terminal.interactiveshell as IS; shell =
> IS.TerminalInteractiveShell(); shell.run_cell('%load_ext rmagic');
> shell.run_cell('%R X=rnorm(20); print(X)')"
>  [1]  0.2125483  0.1030451 -1.4036373 -0.5617847 -0.7571675 -0.3985085
>  [7] -0.4386932  0.7164915 -0.4794236 -0.1373804  0.2831013 -0.7248862
> [13]  0.5260675 -0.3789804  0.1535592  1.5569203  1.0225972  0.8149846
> [19] -0.9629060 -0.4161373
>
> ~/workbook (metadata*) $ python -c "import
> IPython.frontend.terminal.interactiveshell as IS; shell =
> IS.InteractiveShell(); shell.run_cell('%load_ext rmagic');
> shell.run_cell('%R X=rnorm(20); print(X)')"
>  [1]  0.44037484  1.31372601 -0.37253955  2.21955270 -0.07886852
> -0.09022193
>  [7]  0.38464850 -0.41004855  1.62648041 -0.13687832  0.91537699
> -2.70125217
> [13]  1.49125226  0.11580012 -0.64993087  2.49367657  0.01447792
>  0.57408249
> [19] -0.80559871 -0.76346964
>
> So, for interactively running this in ipython I should expect to see this
> load_ext failure?
>
>
You are running into some singleton assumptions in the new magics system -
each Magics class methods are only registered once, and thus bound to the
first Shell that load the magic.

So what you are seeing is that shell.magic("load_ext rmagic") is actually
triggering the load_ext magic on the *original* IPython instance.  I think
this should be considered a bug.


> Thanks,
>
> Jonathan
>
> On Thu, Jun 14, 2012 at 3:48 PM, Thomas Kluyver <takowl at gmail.com> wrote:
>
>> On 14 June 2012 23:44, Jonathan Taylor <jonathan.taylor at stanford.edu>
>> wrote:
>> > Actually, I want to create an InteractiveShell inside another python
>> > process. Maybe I should use embed?
>>
>> Embed's not terribly relevant here - that creates an InteractiveShell,
>> but attempts to use the namespace from which it's called.
>>
>> Try it in a separate Python process. Don't forget to %load_ext rmagic
>> first.
>>
>> Thomas
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>
>
>
> --
> Jonathan Taylor
> Dept. of Statistics
> Sequoia Hall, 137
> 390 Serra Mall
> Stanford, CA 94305
> Tel:   650.723.9230
> Fax:   650.725.8977
> Web: http://www-stat.stanford.edu/~jtaylo
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120614/77d1b0f6/attachment.html>

From ellisonbg at gmail.com  Thu Jun 14 19:30:51 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Thu, 14 Jun 2012 16:30:51 -0700
Subject: [IPython-dev] use of InteractiveShell and R magic
In-Reply-To: <CAHNn8BWb-5WWDfU-z6ZL4shsVGmEEJJ2LaHE53LN+qHU3+Vu4A@mail.gmail.com>
References: <CANmCCuQdxOOLgrW_+7Z3Jv7afqn+_fnF0JWOfxQCQM21Yqmqcw@mail.gmail.com>
	<CAHNn8BVpzzm56ZQ518okzE+hOsbUkbo+xnyKwY7Qmov_v0pPhA@mail.gmail.com>
	<CANmCCuQExen2BdqaLU12NZAGXWjON0o3xXbCzv5R+oc-uBkUNQ@mail.gmail.com>
	<CAOvn4qjvZ5Muyfrn0UqktjiKxxwjHHFgwHZAn7soGAqyDSqO2A@mail.gmail.com>
	<CANmCCuRK7hkr306n3Yt+Apb2sFmdgHGzwNCmiCcbh8pnBncHFQ@mail.gmail.com>
	<CAHNn8BWb-5WWDfU-z6ZL4shsVGmEEJJ2LaHE53LN+qHU3+Vu4A@mail.gmail.com>
Message-ID: <CAH4pYpSVn7gkR4kV96=5pb0vRW5JFsPem2p1wtKuxW0e4Z10ZA@mail.gmail.com>

But don't we have similar assumptions about InteractiveShell being a
singleton throughout the code base.  The patterns used by the magic
system are by no means unique.  I am not sure I would call this a bug.

Brian

On Thu, Jun 14, 2012 at 4:26 PM, MinRK <benjaminrk at gmail.com> wrote:
>
>
> On Thu, Jun 14, 2012 at 3:57 PM, Jonathan Taylor
> <jonathan.taylor at stanford.edu> wrote:
>>
>> Thanks, that seems to work in a separate python process rather than the
>> ipython process:
>>
>> ~/workbook (metadata*) $ python -c "import
>> IPython.frontend.terminal.interactiveshell as IS; shell =
>> IS.TerminalInteractiveShell(); shell.run_cell('%load_ext rmagic');
>> shell.run_cell('%R X=rnorm(20); print(X)')"
>> ?[1] ?0.2125483 ?0.1030451 -1.4036373 -0.5617847 -0.7571675 -0.3985085
>> ?[7] -0.4386932 ?0.7164915 -0.4794236 -0.1373804 ?0.2831013 -0.7248862
>> [13] ?0.5260675 -0.3789804 ?0.1535592 ?1.5569203 ?1.0225972 ?0.8149846
>> [19] -0.9629060 -0.4161373
>>
>> ~/workbook (metadata*) $ python -c "import
>> IPython.frontend.terminal.interactiveshell as IS; shell =
>> IS.InteractiveShell(); shell.run_cell('%load_ext rmagic');
>> shell.run_cell('%R X=rnorm(20); print(X)')"
>> ?[1] ?0.44037484 ?1.31372601 -0.37253955 ?2.21955270 -0.07886852
>> -0.09022193
>> ?[7] ?0.38464850 -0.41004855 ?1.62648041 -0.13687832 ?0.91537699
>> -2.70125217
>> [13] ?1.49125226 ?0.11580012 -0.64993087 ?2.49367657 ?0.01447792
>> ?0.57408249
>> [19] -0.80559871 -0.76346964
>>
>> So, for interactively running this in ipython I should expect to see this
>> load_ext failure?
>>
>
> You are running into some singleton assumptions in the new magics system -
> each Magics class methods are only registered once, and thus bound to the
> first Shell that load the magic.
>
> So what you are seeing is that shell.magic("load_ext rmagic") is actually
> triggering the load_ext magic on the *original* IPython instance. ?I think
> this should be considered a bug.
>
>>
>> Thanks,
>>
>> Jonathan
>>
>> On Thu, Jun 14, 2012 at 3:48 PM, Thomas Kluyver <takowl at gmail.com> wrote:
>>>
>>> On 14 June 2012 23:44, Jonathan Taylor <jonathan.taylor at stanford.edu>
>>> wrote:
>>> > Actually, I want to create an InteractiveShell inside another python
>>> > process. Maybe I should use embed?
>>>
>>> Embed's not terribly relevant here - that creates an InteractiveShell,
>>> but attempts to use the namespace from which it's called.
>>>
>>> Try it in a separate Python process. Don't forget to %load_ext rmagic
>>> first.
>>>
>>> Thomas
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>>
>>
>>
>> --
>> Jonathan Taylor
>> Dept. of Statistics
>> Sequoia Hall, 137
>> 390 Serra Mall
>> Stanford, CA 94305
>> Tel:?? 650.723.9230
>> Fax:?? 650.725.8977
>> Web: http://www-stat.stanford.edu/~jtaylo
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



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


From ellisonbg at gmail.com  Thu Jun 14 19:51:53 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Thu, 14 Jun 2012 16:51:53 -0700
Subject: [IPython-dev] IPython notebook on Windows Azure
In-Reply-To: <loom.20120610T141014-629@post.gmane.org>
References: <CAOvn4qgqT578_fU5t-YXQCw7FqwAWuT5XOxfrJ3S4hOULx=J-Q@mail.gmail.com>
	<loom.20120610T141014-629@post.gmane.org>
Message-ID: <CAH4pYpQJjLiV5E0wq4F3kBQuDUZARULBDKhnOVPWf-yrfN6rSw@mail.gmail.com>

Dave,

Ha, yes, you are uncovering the not so pleasant details of getting the
notebook running on Azure...

On Sun, Jun 10, 2012 at 6:39 AM, Dave Hirschfeld
<dave.hirschfeld at gmail.com> wrote:
> Thomas Kluyver <takowl <at> gmail.com> writes:
>
>>
>> Just scanning through the documentation for Windows Azure, I notice
>> that they have instructions for setting up the IPython notebook both
>> on Linux and Windows (it's not clear why you'd want the extra hassle
>> of setting everything up on Windows, but I guess someone will want
>> to).
>>
>> http://www.windowsazure.com/en-us/develop/python/tutorials/ipython-notebook/
>>
>
> Thanks Brian & Fernando for the great tutorial - I've been meaning to try out
> Azure for a while so this gave me the perfect excuse to finally give it a go!
>
> For anyone else going through the hassle of setting it up on Windows, here's a
> few things I learnt along the way:
>
> After setting up a Windows Server VM you start out with Internet Explorer having
> security settings which prevent you for visiting any website without a security
> alert popping up. More importantly, you also can't download anything. To fix
> this you need to got to Security tab in the Tools -> Internet Options dialog. In
> the "Internet Zone" you can't change the level from High so you have to click
> the Custom Level button and enable the required functionality. At this point I
> enabled everything, downloaded Chrome and proceeded from there.

I think this is the lamest security default I have ever seen.
Everytime I get on Windows, I download Chrome as fast as I possibly
can.

> Having got the notebook server up & running I then tried to view it locally on
> "http://localhost:9999". This didn't work and in the terminal where the notebook
> server was running I got the following error message:
>
> _ssl.c:503: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request
>
> A little bit of googling seemed to suggest this had something to do with trying
> to access a https site using the http protocol and sure enough
> "https://localhost:9999" took me to the notebook login page.
>
> Finally, despite confirming it was running locally I couldn't access it via
> "https://ipython-demo.cloudapp.net". I confirmed this was a firewall issue by
> turning off the firewall entirely. With a bit of trial and error I found that it
> was only necessary to open port 9999 in the firewall to have external access.
>
> This can be done from the firewall gui: go to Start -> Run, enter wf.msc then
> create a new Inbound rule to open port 9999 on the Public Profile.

Yes, when we update the tutorial next we will add a note about opening
the firewall port.  Good catch.

> Alternatively, entering the following command in a terminal will also do the
> job:
>
> netsh firewall set portopening protocol = TCP port = 9999 name = nbserver mode =
> ENABLE scope = ALL profile = CURRENT
>
>
> AFAICS you get charged for your VM whether or not it's running? Is the only way
> to stop being charged is to delete all your VMs and recreate them when you want
> to use them again? If that is the case, you'll probably want to create an image
> so when you create a new VM you can pick up from where you left off. Following
> the instructions below it was fairly easy to do:
>
> https://www.windowsazure.com/en-us/manage/windows/how-to-guides/capture-an-
> image/
>
> I'll have to look into setting up an ipython cluster on Azure next!

I actually don't know if they charge while the VM is not running.

Cheers,

Brian

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



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


From ellisonbg at gmail.com  Thu Jun 14 19:51:53 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Thu, 14 Jun 2012 16:51:53 -0700
Subject: [IPython-dev] IPython notebook on Windows Azure
In-Reply-To: <loom.20120610T141014-629@post.gmane.org>
References: <CAOvn4qgqT578_fU5t-YXQCw7FqwAWuT5XOxfrJ3S4hOULx=J-Q@mail.gmail.com>
	<loom.20120610T141014-629@post.gmane.org>
Message-ID: <CAH4pYpQJjLiV5E0wq4F3kBQuDUZARULBDKhnOVPWf-yrfN6rSw@mail.gmail.com>

Dave,

Ha, yes, you are uncovering the not so pleasant details of getting the
notebook running on Azure...

On Sun, Jun 10, 2012 at 6:39 AM, Dave Hirschfeld
<dave.hirschfeld at gmail.com> wrote:
> Thomas Kluyver <takowl <at> gmail.com> writes:
>
>>
>> Just scanning through the documentation for Windows Azure, I notice
>> that they have instructions for setting up the IPython notebook both
>> on Linux and Windows (it's not clear why you'd want the extra hassle
>> of setting everything up on Windows, but I guess someone will want
>> to).
>>
>> http://www.windowsazure.com/en-us/develop/python/tutorials/ipython-notebook/
>>
>
> Thanks Brian & Fernando for the great tutorial - I've been meaning to try out
> Azure for a while so this gave me the perfect excuse to finally give it a go!
>
> For anyone else going through the hassle of setting it up on Windows, here's a
> few things I learnt along the way:
>
> After setting up a Windows Server VM you start out with Internet Explorer having
> security settings which prevent you for visiting any website without a security
> alert popping up. More importantly, you also can't download anything. To fix
> this you need to got to Security tab in the Tools -> Internet Options dialog. In
> the "Internet Zone" you can't change the level from High so you have to click
> the Custom Level button and enable the required functionality. At this point I
> enabled everything, downloaded Chrome and proceeded from there.

I think this is the lamest security default I have ever seen.
Everytime I get on Windows, I download Chrome as fast as I possibly
can.

> Having got the notebook server up & running I then tried to view it locally on
> "http://localhost:9999". This didn't work and in the terminal where the notebook
> server was running I got the following error message:
>
> _ssl.c:503: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request
>
> A little bit of googling seemed to suggest this had something to do with trying
> to access a https site using the http protocol and sure enough
> "https://localhost:9999" took me to the notebook login page.
>
> Finally, despite confirming it was running locally I couldn't access it via
> "https://ipython-demo.cloudapp.net". I confirmed this was a firewall issue by
> turning off the firewall entirely. With a bit of trial and error I found that it
> was only necessary to open port 9999 in the firewall to have external access.
>
> This can be done from the firewall gui: go to Start -> Run, enter wf.msc then
> create a new Inbound rule to open port 9999 on the Public Profile.

Yes, when we update the tutorial next we will add a note about opening
the firewall port.  Good catch.

> Alternatively, entering the following command in a terminal will also do the
> job:
>
> netsh firewall set portopening protocol = TCP port = 9999 name = nbserver mode =
> ENABLE scope = ALL profile = CURRENT
>
>
> AFAICS you get charged for your VM whether or not it's running? Is the only way
> to stop being charged is to delete all your VMs and recreate them when you want
> to use them again? If that is the case, you'll probably want to create an image
> so when you create a new VM you can pick up from where you left off. Following
> the instructions below it was fairly easy to do:
>
> https://www.windowsazure.com/en-us/manage/windows/how-to-guides/capture-an-
> image/
>
> I'll have to look into setting up an ipython cluster on Azure next!

I actually don't know if they charge while the VM is not running.

Cheers,

Brian

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



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


From ellisonbg at gmail.com  Thu Jun 14 19:55:15 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Thu, 14 Jun 2012 16:55:15 -0700
Subject: [IPython-dev] A 'static demo' mode for the notebook,
 so we could keep a more visible version of the examples up?
In-Reply-To: <20120610064817.GR6159@mcelrath.org>
References: <CAHAreOo5QvKDD1PGcWZ6qRCum7n+xH5Z0A_sQ0003-_TL2CfDQ@mail.gmail.com>
	<CA+A4wO=MhGeNJqWZS-SKwPsdCmuwhPJpMoX87CiuABAqrhB3CQ@mail.gmail.com>
	<20120610064817.GR6159@mcelrath.org>
Message-ID: <CAH4pYpTzfCOAioDau3huiVokLRHEogc9vsBp3XUkrRaY0mD=Tg@mail.gmail.com>

Some (late) comments:

* I agree that the read-only mode covers this usage case.
* Read-only is currently broken (by myself) and that breakage was deliberate.
* We are working on a proper replacement that will serve static HTML
pages for each notebook.

Cheers,

Brian

On Sat, Jun 9, 2012 at 11:48 PM, Bob McElrath <bob+ipython at mcelrath.org> wrote:
> +1!!!
>
> Satrajit Ghosh [satra at mit.edu] wrote:
>> it would be cool if this could be done with a client side javascript viewer? so
>> no server to instantiate at all.
>
> Is anyone familiar with TiddlyWiki (tiddlywiki.org)? ?It's a single-html file
> application for personal note-taking. ?People have written server-side
> implementations (including me) but the single-file html paradigm is very
> powerful. ?It's easily thrown on the web, and easily passed around. ?I've been
> using it as a "scientific notebook" for years (I wrote a tex plugin for it).
>
> Anyway, I think the single-html-file could be a very powerful paradigm for an
> IPython notebook. ?All necessary javascript, json worksheet, css, etc can be
> embedded in the file. ?The "worksheet" part (json) could be programatically
> extracted to upgrade. ?(TiddlyWiki does all that) ?Plugins could interface
> python, sage, maple, mathematica, or start remote server (ec2) instances.
>
> Some years ago I built an interface in TiddlyWiki that communicated with the
> computer algebra software Axiom, it was extremely similar to the IPython
> notebook (though, less developed).
>
> Currently I'm already interfacing TW and IPython, in that I've embedded the
> dashboard in a tiddler (iframe). ?("tiddler" = single, titled note in the wiki)
> I can't embed worksheets currently because IPython does not produce stable URL's
> -- the URL hash changes when the server is restarted. ?For me, it's important to
> link an idea/note in my wiki with a corresponding calculation in a worksheet.
> Notes are always idea->discussion->literature search->calculation->graph->more
> discussion->(repeat).
>
> I think the concept of a "unit" of code as a tiddler may also be a very powerful
> paradigm. ?It aligns with the "light table" idea that has gotten a lot of press
> recently. ?Something I've been thinking about a lot...
>
> Any takers? ?It would be fairly straightforward to write a TiddlyWiki plugin
> containing the existing IPython notebook javascript and CSS. ?It would have to
> be served from the IPython HTTP server, due to cross-origin restrictions.
>
> I do have some concerns about how to make a consistent "state" of the kernel
> when the code can be spread around in multiple "tiddler", that's a challenge
> shared with the light table idea. ?But one worksheet per tiddler is an easy way
> to start.
>
> --
> Cheers, Bob McElrath
>
> "The individual has always had to struggle to keep from being overwhelmed by
> the tribe. ?If you try it, you will be lonely often, and sometimes frightened.
> But no price is too high to pay for the privilege of owning yourself."
> ? ?-- Friedrich Nietzsche
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



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


From ellisonbg at gmail.com  Thu Jun 14 19:56:08 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Thu, 14 Jun 2012 16:56:08 -0700
Subject: [IPython-dev] ipython notebook installation instructions
In-Reply-To: <CAHAreOrjD9VPr79v1waF4d+T92DC_ju2qD8_3KPjBBeGj4y8gw@mail.gmail.com>
References: <CAHAreOrozM5LTbsrTd3Hc4CLwEvUhfu+azXZePGGuGHuyfMPkw@mail.gmail.com>
	<4FC74053.5060509@gmail.com>
	<CAHAreOo5acS26fr8ktWhyfA8KbwfepvkX7xyOM9-7srs-MhyXQ@mail.gmail.com>
	<CAH4pYpQA4_mGfuYZXS2hSjxGm7TUD9yjtisDCTzicZYHSNrhiQ@mail.gmail.com>
	<4FC7AA82.4030103@creativetrax.com>
	<CAH4pYpQ4PFzeokbjaDoteKb75K+U1wn7+LTAf3EOeZhCexhkaA@mail.gmail.com>
	<CAHAreOrZyEwURwu++rskq2irpy_t1TYrqGJg_4LUr7Zjk5ZE0g@mail.gmail.com>
	<CAH4pYpR40kjAW3sfhJsE_K6QnNpLar-jdGPPM2hd-YSYEoYYFg@mail.gmail.com>
	<CAHAreOr3PgSqzcmWwDB1fEzNzPTEyTjsaH60ohtxqwAU+RR98w@mail.gmail.com>
	<CAH4pYpREwokDri5PWq5q7Pp2+xnVyzvUdb=SBjeDpZqAAN=n6g@mail.gmail.com>
	<CAHAreOrjD9VPr79v1waF4d+T92DC_ju2qD8_3KPjBBeGj4y8gw@mail.gmail.com>
Message-ID: <CAH4pYpQTZWHzEz_3_rEEO+Xv7S--Cnpcp4eEJtr8y63jY5kP6Q@mail.gmail.com>

On Sat, Jun 9, 2012 at 2:52 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Thu, May 31, 2012 at 12:12 PM, Brian Granger <ellisonbg at gmail.com> wrote:
>> This requires a separate notebook server or kernel manager for each
>> such type of notebook. ?What happens when I have users that have R
>> notebooks, Matlab notebooks, etc., etc. ?You end up with an incredibly
>> difficult situation to manage, both for users, the person running the
>> notebook server and the developers of the notebook. ?I think the
>> reality is that most users will want to switch back and forth between
>> different syntaxes. ?We need to make that simple, easy and lightweight
>> and I don't see how to do that with a kernel-side approach.
>
> I'm not convinced that doing it client-side works completely either,
> but honestly, this problem is so tricky and full of branching logic to
> worry about, that I suggest we just punt on it for now. ?We just don't
> have the time or mental bandwidth right now to deal with it well, I'm
> afraid (at least I don't). ?Hopefully in a few months when the base
> architecture is more stable we can return to it with a clear head...

Yes, I think this strategy makes sense.

> I also think that after a few months of using the cell magics system
> extensively we'll also have a better understanding and intuition on
> some of these questions.

Yep.

Brian

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



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


From ellisonbg at gmail.com  Thu Jun 14 20:05:35 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Thu, 14 Jun 2012 17:05:35 -0700
Subject: [IPython-dev] Let's get 0.13 released...
In-Reply-To: <CAHNn8BWAQwwjCt=DoO8exczW4z-aN3PAEU=gx4aU8kbSENXq5Q@mail.gmail.com>
References: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
	<4FD61F6C.3080709@googlemail.com>
	<CAHAreOprJ9qwqJcrw1mesHu2kXYYw_x_dEod91DA4mYTYXDsHA@mail.gmail.com>
	<CAHNn8BWLU=ggRrwh-U1Tv1VRf1b_2qZfTiP46Jfkr1Z26HpFOQ@mail.gmail.com>
	<4FD66B0F.2060405@googlemail.com>
	<CAHNn8BWAQwwjCt=DoO8exczW4z-aN3PAEU=gx4aU8kbSENXq5Q@mail.gmail.com>
Message-ID: <CAH4pYpSFKz3g9mkQLRgOaF8zcXkEsxpMkqXjhOYkmtHrFaYYnQ@mail.gmail.com>

On Mon, Jun 11, 2012 at 3:18 PM, MinRK <benjaminrk at gmail.com> wrote:
>
>
> On Mon, Jun 11, 2012 at 3:02 PM, Julian Taylor
> <jtaylor.debian at googlemail.com> wrote:
>>
>> > ? ? > Does the notebook still need development snapshots of jquery & co
>> > or
>> > ? ? > will it work with official releases (debian has 1.7.2, -ui
>> > 1.8.20)?
>> >
>> > ? ? Honestly I'm not sure, others (Brian, Min, Matthias) might know
>> > better
>> > ? ? the answer to that...
>> >
>> >
>> > jquery is fine (we are shipping 1.7.1, so 1.7.2 should be no problem),
>> > but I think we do need dev jquery-ui.
>>
>> what features of the dev version are required?
>
>
> Menus, to be introduced in jQuery
> 1.9:?http://wiki.jqueryui.com/w/page/12137997/Menu

It is worse than this.  At the last minute jQuery devs removed the
menubar from the master (1.9) branch.  They distinguish between a menu
and menubar, but we need both.  The menubar work was moved into this
branch:

https://github.com/jquery/jquery-ui/tree/menubar

The current version of jquery ui that we include in base on this (I
don't know which commit though - it was right after the branch was
created).

>
>>
>> wasn't there supposed to be some file that should give that information?
>> IPython/frontend/html/notebook/static/unminified/README does not mention
>> a dev release.
>
>
> Yes, it should mention it.
>
>>
>> the commit log gives no clue and the obfuscated file itself just
>> contains @VERSION, not very helpful.
>
>
> It certainly is not, is it? ?It's probably 1.9 milestone 5. ?We need Brian
> to make a note of that, and possibly consider updating to 1.9m8.

We are in a horrible position right now.  We can't live without the
menubar implementation, but this means we are tracking a very-dev
branch.  We could update the the latest of that, but that is risky.  I
would probably prefer to just keep the version we are using as we know
it works.  Once 1.9 is released, I think the plan is the merge the
menubar branch back in.  Then we will be in the clear.  1.9 was
supposed to come out "within a few months" of last summer.  In the
meantime, we can all flog me for not tracking which commit of that
branch we are actually using...

Brian

>>
>>
>> > pagedown now includes a tiny patch:
>>
>> pagedown is not obfuscated so its is fine.
>> I only have issues with the binary blobs you have in your source.
>>
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



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


From benjaminrk at gmail.com  Thu Jun 14 20:07:00 2012
From: benjaminrk at gmail.com (MinRK)
Date: Thu, 14 Jun 2012 17:07:00 -0700
Subject: [IPython-dev] use of InteractiveShell and R magic
In-Reply-To: <CAH4pYpSVn7gkR4kV96=5pb0vRW5JFsPem2p1wtKuxW0e4Z10ZA@mail.gmail.com>
References: <CANmCCuQdxOOLgrW_+7Z3Jv7afqn+_fnF0JWOfxQCQM21Yqmqcw@mail.gmail.com>
	<CAHNn8BVpzzm56ZQ518okzE+hOsbUkbo+xnyKwY7Qmov_v0pPhA@mail.gmail.com>
	<CANmCCuQExen2BdqaLU12NZAGXWjON0o3xXbCzv5R+oc-uBkUNQ@mail.gmail.com>
	<CAOvn4qjvZ5Muyfrn0UqktjiKxxwjHHFgwHZAn7soGAqyDSqO2A@mail.gmail.com>
	<CANmCCuRK7hkr306n3Yt+Apb2sFmdgHGzwNCmiCcbh8pnBncHFQ@mail.gmail.com>
	<CAHNn8BWb-5WWDfU-z6ZL4shsVGmEEJJ2LaHE53LN+qHU3+Vu4A@mail.gmail.com>
	<CAH4pYpSVn7gkR4kV96=5pb0vRW5JFsPem2p1wtKuxW0e4Z10ZA@mail.gmail.com>
Message-ID: <CAHNn8BUTie8-uvU7PhLBZiZP2R5uN=18i3pVxbP1P==3WYd4EQ@mail.gmail.com>

On Thu, Jun 14, 2012 at 4:30 PM, Brian Granger <ellisonbg at gmail.com> wrote:

> But don't we have similar assumptions about InteractiveShell being a
> singleton throughout the code base.  The patterns used by the magic
> system are by no means unique.  I am not sure I would call this a bug.
>

The relevant assumption is that the Magics object itself is a singleton.
 The magics table is *per class*, but on initialization of the first
instance, the class mapping clobbered with the methods of the first
instance.  Simply copying the magics dict before altering it so that it is
an instance attribute rather than a class attribute edited by the instance
fixes the issue. I think this is inappropriate for a class that doesn't
have any singleton-like instance() api like the InteractiveShell does.

For instance:

from IPython.core.magic import magics_class, Magics, line_magic
@magics_class
class MyMagic(Magics):

    @line_magic
    def foo(self, line):
        print 'hi'

magic = MyMagic(None)
magic2 = MyMagic(None)

assert magic2.magics['line']['foo'].im_self is not magic # fails


>
> Brian
>
> On Thu, Jun 14, 2012 at 4:26 PM, MinRK <benjaminrk at gmail.com> wrote:
> >
> >
> > On Thu, Jun 14, 2012 at 3:57 PM, Jonathan Taylor
> > <jonathan.taylor at stanford.edu> wrote:
> >>
> >> Thanks, that seems to work in a separate python process rather than the
> >> ipython process:
> >>
> >> ~/workbook (metadata*) $ python -c "import
> >> IPython.frontend.terminal.interactiveshell as IS; shell =
> >> IS.TerminalInteractiveShell(); shell.run_cell('%load_ext rmagic');
> >> shell.run_cell('%R X=rnorm(20); print(X)')"
> >>  [1]  0.2125483  0.1030451 -1.4036373 -0.5617847 -0.7571675 -0.3985085
> >>  [7] -0.4386932  0.7164915 -0.4794236 -0.1373804  0.2831013 -0.7248862
> >> [13]  0.5260675 -0.3789804  0.1535592  1.5569203  1.0225972  0.8149846
> >> [19] -0.9629060 -0.4161373
> >>
> >> ~/workbook (metadata*) $ python -c "import
> >> IPython.frontend.terminal.interactiveshell as IS; shell =
> >> IS.InteractiveShell(); shell.run_cell('%load_ext rmagic');
> >> shell.run_cell('%R X=rnorm(20); print(X)')"
> >>  [1]  0.44037484  1.31372601 -0.37253955  2.21955270 -0.07886852
> >> -0.09022193
> >>  [7]  0.38464850 -0.41004855  1.62648041 -0.13687832  0.91537699
> >> -2.70125217
> >> [13]  1.49125226  0.11580012 -0.64993087  2.49367657  0.01447792
> >>  0.57408249
> >> [19] -0.80559871 -0.76346964
> >>
> >> So, for interactively running this in ipython I should expect to see
> this
> >> load_ext failure?
> >>
> >
> > You are running into some singleton assumptions in the new magics system
> -
> > each Magics class methods are only registered once, and thus bound to the
> > first Shell that load the magic.
> >
> > So what you are seeing is that shell.magic("load_ext rmagic") is actually
> > triggering the load_ext magic on the *original* IPython instance.  I
> think
> > this should be considered a bug.
> >
> >>
> >> Thanks,
> >>
> >> Jonathan
> >>
> >> On Thu, Jun 14, 2012 at 3:48 PM, Thomas Kluyver <takowl at gmail.com>
> wrote:
> >>>
> >>> On 14 June 2012 23:44, Jonathan Taylor <jonathan.taylor at stanford.edu>
> >>> wrote:
> >>> > Actually, I want to create an InteractiveShell inside another python
> >>> > process. Maybe I should use embed?
> >>>
> >>> Embed's not terribly relevant here - that creates an InteractiveShell,
> >>> but attempts to use the namespace from which it's called.
> >>>
> >>> Try it in a separate Python process. Don't forget to %load_ext rmagic
> >>> first.
> >>>
> >>> Thomas
> >>> _______________________________________________
> >>> IPython-dev mailing list
> >>> IPython-dev at scipy.org
> >>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >>
> >>
> >>
> >>
> >> --
> >> Jonathan Taylor
> >> Dept. of Statistics
> >> Sequoia Hall, 137
> >> 390 Serra Mall
> >> Stanford, CA 94305
> >> Tel:   650.723.9230
> >> Fax:   650.725.8977
> >> Web: http://www-stat.stanford.edu/~jtaylo
> >>
> >> _______________________________________________
> >> IPython-dev mailing list
> >> IPython-dev at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >>
> >
> >
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> >
>
>
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu and ellisonbg at gmail.com
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120614/2596b181/attachment.html>

From benjaminrk at gmail.com  Thu Jun 14 20:09:23 2012
From: benjaminrk at gmail.com (MinRK)
Date: Thu, 14 Jun 2012 17:09:23 -0700
Subject: [IPython-dev] Adding attributes to .ipynb files
In-Reply-To: <CADLczKD+gbS+VQkzH5+brhpYq-RjWkOAUXBpyA5mX37rPsFunw@mail.gmail.com>
References: <CADLczKD+gbS+VQkzH5+brhpYq-RjWkOAUXBpyA5mX37rPsFunw@mail.gmail.com>
Message-ID: <CAHNn8BXDtt1oYWjepp=ruBSbpRi1cNpu7BWH_3Zs8Veu+WB4Cg@mail.gmail.com>

You mean something like this <https://github.com/ipython/ipython/pull/1934>?

Adding your own (jsonable) data into those metadata dicts should be safe.
 I would recommend using your own prefix or subdict to avoid potential
collisions down the road.

On Thu, Jun 14, 2012 at 4:13 PM, Dennis Sun <dlsun at stanford.edu> wrote:

> Hi all,
>
> We're working on a project where we need notebook files that have some
> extra data attached to each cell. Because we would like to make sure that
> the files are still compatible with the iPython Notebook, what we're doing
> right now is including this metadata in the "json" attribute of the output
> of each cell and then "promoting" these attributes to the cell level at
> runtime. Thus, the notebook file is still a valid .ipynb file, but the
> metadata doesn't show up when the user loads the page.
>
> However, it seems right now that we can get away with adding the metadata
> directly at the cell level in the .ipynb file, since iPython Notebook
> simply passes over any keys that it doesn't know to look for. We would like
> to do this instead, since it is conceptually much cleaner, but we are
> worried about compatibility with future versions of iPython, which might
> enforce .ipynb files to follow a certain format.
>
> We were hoping that someone more knowledgeable about the state of iPython
> development could advise on whether or not it's safe to add our own
> attributes directly to the .ipynb files. It seems that this shouldn't be a
> problem as long as .ipynb remains a JSON key-value store, but we wanted to
> check with the community to make sure.
>
> Thanks,
> Dennis
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120614/3fbfcecd/attachment.html>

From jason-sage at creativetrax.com  Thu Jun 14 20:13:18 2012
From: jason-sage at creativetrax.com (Jason Grout)
Date: Thu, 14 Jun 2012 17:13:18 -0700
Subject: [IPython-dev] Let's get 0.13 released...
In-Reply-To: <CAH4pYpSFKz3g9mkQLRgOaF8zcXkEsxpMkqXjhOYkmtHrFaYYnQ@mail.gmail.com>
References: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
	<4FD61F6C.3080709@googlemail.com>
	<CAHAreOprJ9qwqJcrw1mesHu2kXYYw_x_dEod91DA4mYTYXDsHA@mail.gmail.com>
	<CAHNn8BWLU=ggRrwh-U1Tv1VRf1b_2qZfTiP46Jfkr1Z26HpFOQ@mail.gmail.com>
	<4FD66B0F.2060405@googlemail.com>
	<CAHNn8BWAQwwjCt=DoO8exczW4z-aN3PAEU=gx4aU8kbSENXq5Q@mail.gmail.com>
	<CAH4pYpSFKz3g9mkQLRgOaF8zcXkEsxpMkqXjhOYkmtHrFaYYnQ@mail.gmail.com>
Message-ID: <4FDA7E1E.3090602@creativetrax.com>

On 6/14/12 5:05 PM, Brian Granger wrote:

> We are in a horrible position right now.  We can't live without the
> menubar implementation, but this means we are tracking a very-dev
> branch.  We could update the the latest of that, but that is risky.  I
> would probably prefer to just keep the version we are using as we know
> it works.  Once 1.9 is released, I think the plan is the merge the
> menubar branch back in.  Then we will be in the clear.  1.9 was
> supposed to come out "within a few months" of last summer.  In the
> meantime, we can all flog me for not tracking which commit of that
> branch we are actually using...

Have you looked at git submodules?  We use that to track several 
external projects in the sage cell server.  We don't track jquery that 
way (I think you need something special to build jquery?), but we do 
track codemirror and a few other projects using submodules.

Jason






From takowl at gmail.com  Thu Jun 14 20:31:52 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Fri, 15 Jun 2012 01:31:52 +0100
Subject: [IPython-dev] use of InteractiveShell and R magic
In-Reply-To: <CAH4pYpSVn7gkR4kV96=5pb0vRW5JFsPem2p1wtKuxW0e4Z10ZA@mail.gmail.com>
References: <CANmCCuQdxOOLgrW_+7Z3Jv7afqn+_fnF0JWOfxQCQM21Yqmqcw@mail.gmail.com>
	<CAHNn8BVpzzm56ZQ518okzE+hOsbUkbo+xnyKwY7Qmov_v0pPhA@mail.gmail.com>
	<CANmCCuQExen2BdqaLU12NZAGXWjON0o3xXbCzv5R+oc-uBkUNQ@mail.gmail.com>
	<CAOvn4qjvZ5Muyfrn0UqktjiKxxwjHHFgwHZAn7soGAqyDSqO2A@mail.gmail.com>
	<CANmCCuRK7hkr306n3Yt+Apb2sFmdgHGzwNCmiCcbh8pnBncHFQ@mail.gmail.com>
	<CAHNn8BWb-5WWDfU-z6ZL4shsVGmEEJJ2LaHE53LN+qHU3+Vu4A@mail.gmail.com>
	<CAH4pYpSVn7gkR4kV96=5pb0vRW5JFsPem2p1wtKuxW0e4Z10ZA@mail.gmail.com>
Message-ID: <CAOvn4qjZU+q18njam+VyaPcyg5X3C0nuLQQ70MC+h5dPCFmcNw@mail.gmail.com>

On 15 June 2012 00:30, Brian Granger <ellisonbg at gmail.com> wrote:
> But don't we have similar assumptions about InteractiveShell being a
> singleton throughout the code base. ?The patterns used by the magic
> system are by no means unique. ?I am not sure I would call this a bug.

I think, and I've mentioned before, that we should gradually try to
remove this assumption. There are some use cases for having multiple
InteractiveShell objects in one process. It's one reason I like the
extension system - it achieves loose coupling without assuming that
there will only ever be one shell object.

This is a low priority, long term goal, though.

Thomas


From ellisonbg at gmail.com  Thu Jun 14 20:34:29 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Thu, 14 Jun 2012 17:34:29 -0700
Subject: [IPython-dev] use of InteractiveShell and R magic
In-Reply-To: <CAHNn8BUTie8-uvU7PhLBZiZP2R5uN=18i3pVxbP1P==3WYd4EQ@mail.gmail.com>
References: <CANmCCuQdxOOLgrW_+7Z3Jv7afqn+_fnF0JWOfxQCQM21Yqmqcw@mail.gmail.com>
	<CAHNn8BVpzzm56ZQ518okzE+hOsbUkbo+xnyKwY7Qmov_v0pPhA@mail.gmail.com>
	<CANmCCuQExen2BdqaLU12NZAGXWjON0o3xXbCzv5R+oc-uBkUNQ@mail.gmail.com>
	<CAOvn4qjvZ5Muyfrn0UqktjiKxxwjHHFgwHZAn7soGAqyDSqO2A@mail.gmail.com>
	<CANmCCuRK7hkr306n3Yt+Apb2sFmdgHGzwNCmiCcbh8pnBncHFQ@mail.gmail.com>
	<CAHNn8BWb-5WWDfU-z6ZL4shsVGmEEJJ2LaHE53LN+qHU3+Vu4A@mail.gmail.com>
	<CAH4pYpSVn7gkR4kV96=5pb0vRW5JFsPem2p1wtKuxW0e4Z10ZA@mail.gmail.com>
	<CAHNn8BUTie8-uvU7PhLBZiZP2R5uN=18i3pVxbP1P==3WYd4EQ@mail.gmail.com>
Message-ID: <CAH4pYpTGQ53ZUKLX8yfTzYqGTPSCKCxRwkqXmCkyHgiv9MEz5w@mail.gmail.com>

On Thu, Jun 14, 2012 at 5:07 PM, MinRK <benjaminrk at gmail.com> wrote:
>
>
> On Thu, Jun 14, 2012 at 4:30 PM, Brian Granger <ellisonbg at gmail.com> wrote:
>>
>> But don't we have similar assumptions about InteractiveShell being a
>> singleton throughout the code base. ?The patterns used by the magic
>> system are by no means unique. ?I am not sure I would call this a bug.
>
>
> The relevant assumption is that the Magics object itself is a singleton.
> ?The magics table is *per class*, but on initialization of the first
> instance, the class mapping clobbered with the methods of the first
> instance. ?Simply copying the magics dict before altering it so that it is
> an instance attribute rather than a class attribute edited by the instance
> fixes the issue.?I think this is inappropriate for a class that doesn't have
> any singleton-like instance() api like the InteractiveShell does.

Ahh, OK I agree that this is not ideal.  Just saw your PR to fix this.

Cheers,

Brian

> For instance:
>
> from IPython.core.magic import magics_class, Magics, line_magic
> @magics_class
> class MyMagic(Magics):
>
> ? ? @line_magic
> ? ? def foo(self, line):
> ? ? ? ? print 'hi'
>
> magic = MyMagic(None)
> magic2 = MyMagic(None)
>
> assert magic2.magics['line']['foo'].im_self is not magic # fails
>
>>
>>
>> Brian
>>
>> On Thu, Jun 14, 2012 at 4:26 PM, MinRK <benjaminrk at gmail.com> wrote:
>> >
>> >
>> > On Thu, Jun 14, 2012 at 3:57 PM, Jonathan Taylor
>> > <jonathan.taylor at stanford.edu> wrote:
>> >>
>> >> Thanks, that seems to work in a separate python process rather than the
>> >> ipython process:
>> >>
>> >> ~/workbook (metadata*) $ python -c "import
>> >> IPython.frontend.terminal.interactiveshell as IS; shell =
>> >> IS.TerminalInteractiveShell(); shell.run_cell('%load_ext rmagic');
>> >> shell.run_cell('%R X=rnorm(20); print(X)')"
>> >> ?[1] ?0.2125483 ?0.1030451 -1.4036373 -0.5617847 -0.7571675 -0.3985085
>> >> ?[7] -0.4386932 ?0.7164915 -0.4794236 -0.1373804 ?0.2831013 -0.7248862
>> >> [13] ?0.5260675 -0.3789804 ?0.1535592 ?1.5569203 ?1.0225972 ?0.8149846
>> >> [19] -0.9629060 -0.4161373
>> >>
>> >> ~/workbook (metadata*) $ python -c "import
>> >> IPython.frontend.terminal.interactiveshell as IS; shell =
>> >> IS.InteractiveShell(); shell.run_cell('%load_ext rmagic');
>> >> shell.run_cell('%R X=rnorm(20); print(X)')"
>> >> ?[1] ?0.44037484 ?1.31372601 -0.37253955 ?2.21955270 -0.07886852
>> >> -0.09022193
>> >> ?[7] ?0.38464850 -0.41004855 ?1.62648041 -0.13687832 ?0.91537699
>> >> -2.70125217
>> >> [13] ?1.49125226 ?0.11580012 -0.64993087 ?2.49367657 ?0.01447792
>> >> ?0.57408249
>> >> [19] -0.80559871 -0.76346964
>> >>
>> >> So, for interactively running this in ipython I should expect to see
>> >> this
>> >> load_ext failure?
>> >>
>> >
>> > You are running into some singleton assumptions in the new magics system
>> > -
>> > each Magics class methods are only registered once, and thus bound to
>> > the
>> > first Shell that load the magic.
>> >
>> > So what you are seeing is that shell.magic("load_ext rmagic") is
>> > actually
>> > triggering the load_ext magic on the *original* IPython instance. ?I
>> > think
>> > this should be considered a bug.
>> >
>> >>
>> >> Thanks,
>> >>
>> >> Jonathan
>> >>
>> >> On Thu, Jun 14, 2012 at 3:48 PM, Thomas Kluyver <takowl at gmail.com>
>> >> wrote:
>> >>>
>> >>> On 14 June 2012 23:44, Jonathan Taylor <jonathan.taylor at stanford.edu>
>> >>> wrote:
>> >>> > Actually, I want to create an InteractiveShell inside another python
>> >>> > process. Maybe I should use embed?
>> >>>
>> >>> Embed's not terribly relevant here - that creates an InteractiveShell,
>> >>> but attempts to use the namespace from which it's called.
>> >>>
>> >>> Try it in a separate Python process. Don't forget to %load_ext rmagic
>> >>> first.
>> >>>
>> >>> Thomas
>> >>> _______________________________________________
>> >>> IPython-dev mailing list
>> >>> IPython-dev at scipy.org
>> >>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Jonathan Taylor
>> >> Dept. of Statistics
>> >> Sequoia Hall, 137
>> >> 390 Serra Mall
>> >> Stanford, CA 94305
>> >> Tel:?? 650.723.9230
>> >> Fax:?? 650.725.8977
>> >> Web: http://www-stat.stanford.edu/~jtaylo
>> >>
>> >> _______________________________________________
>> >> IPython-dev mailing list
>> >> IPython-dev at scipy.org
>> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >>
>> >
>> >
>> > _______________________________________________
>> > IPython-dev mailing list
>> > IPython-dev at scipy.org
>> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >
>>
>>
>>
>> --
>> Brian E. Granger
>> Cal Poly State University, San Luis Obispo
>> bgranger at calpoly.edu and ellisonbg at gmail.com
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



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


From benjaminrk at gmail.com  Thu Jun 14 20:38:45 2012
From: benjaminrk at gmail.com (MinRK)
Date: Thu, 14 Jun 2012 17:38:45 -0700
Subject: [IPython-dev] use of InteractiveShell and R magic
In-Reply-To: <CAOvn4qjZU+q18njam+VyaPcyg5X3C0nuLQQ70MC+h5dPCFmcNw@mail.gmail.com>
References: <CANmCCuQdxOOLgrW_+7Z3Jv7afqn+_fnF0JWOfxQCQM21Yqmqcw@mail.gmail.com>
	<CAHNn8BVpzzm56ZQ518okzE+hOsbUkbo+xnyKwY7Qmov_v0pPhA@mail.gmail.com>
	<CANmCCuQExen2BdqaLU12NZAGXWjON0o3xXbCzv5R+oc-uBkUNQ@mail.gmail.com>
	<CAOvn4qjvZ5Muyfrn0UqktjiKxxwjHHFgwHZAn7soGAqyDSqO2A@mail.gmail.com>
	<CANmCCuRK7hkr306n3Yt+Apb2sFmdgHGzwNCmiCcbh8pnBncHFQ@mail.gmail.com>
	<CAHNn8BWb-5WWDfU-z6ZL4shsVGmEEJJ2LaHE53LN+qHU3+Vu4A@mail.gmail.com>
	<CAH4pYpSVn7gkR4kV96=5pb0vRW5JFsPem2p1wtKuxW0e4Z10ZA@mail.gmail.com>
	<CAOvn4qjZU+q18njam+VyaPcyg5X3C0nuLQQ70MC+h5dPCFmcNw@mail.gmail.com>
Message-ID: <CAHNn8BWByjmpiMWxv5+k=GUQ64rCO2rPPs7XBcYoM6Wn7-eYiQ@mail.gmail.com>

On Thu, Jun 14, 2012 at 5:31 PM, Thomas Kluyver <takowl at gmail.com> wrote:

> On 15 June 2012 00:30, Brian Granger <ellisonbg at gmail.com> wrote:
> > But don't we have similar assumptions about InteractiveShell being a
> > singleton throughout the code base.  The patterns used by the magic
> > system are by no means unique.  I am not sure I would call this a bug.
>
> I think, and I've mentioned before, that we should gradually try to
> remove this assumption. There are some use cases for having multiple
> InteractiveShell objects in one process. It's one reason I like the
> extension system - it achieves loose coupling without assuming that
> there will only ever be one shell object.
>
> This is a low priority, long term goal, though.
>

Right - the instance() methods are meant as a convenience, not enforcement.
We have a certain amount of functionality that relies on instance() still,
but I think that is appropriately shrinking.

One old singleton-y thing we still really haven't dealt with:
utils.io.stdout/err.


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

From fperez.net at gmail.com  Thu Jun 14 23:35:19 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 14 Jun 2012 20:35:19 -0700
Subject: [IPython-dev] Tests passing on Python 3.3
In-Reply-To: <CAOvn4qiGPGq5cQHRmdYaEKhHP3o59Yb6B45GXQo6jukj-rUJsw@mail.gmail.com>
References: <CAOvn4qiGPGq5cQHRmdYaEKhHP3o59Yb6B45GXQo6jukj-rUJsw@mail.gmail.com>
Message-ID: <CAHAreOpE-oJtF847gcFdW8iT_4D-P6n4-ttAypvG_XjK7XKWsQ@mail.gmail.com>

On Thu, Jun 14, 2012 at 7:37 AM, Thomas Kluyver <takowl at gmail.com> wrote:
> I'm pleased to say that, hot on the heels of fixing our windows tests,
> the Python 3.3 tests on ShiningPanda are now passing.
>
> Shiningpanda upgraded to 3.3a4, and I've fixed some teething troubles
> (pyzmq needed to be re-cythoned).

Awesome, thanks so much for your sustained effort on this front!


From carl.input at gmail.com  Fri Jun 15 11:28:11 2012
From: carl.input at gmail.com (Carl Smith)
Date: Fri, 15 Jun 2012 16:28:11 +0100
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAP-uhDdGPKHgZb=Xx5TXGfn2LXUps8+Sj0ij=hK8MApiT1vXGw@mail.gmail.com>
References: <CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
	<CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>
	<CAOvn4qjs5ifL_HKj1qJWkmNdQ+4KUSQtgCE37QbLX3Yy_y6DcA@mail.gmail.com>
	<CAHAreOp_+joxdeZTQ1ZEOOU4w=euqtESMTisVSDA8oRx=RdCHg@mail.gmail.com>
	<CAOvn4qhKg9QM8u-BQvrk+PazfRBpAYtF_7Vh7-YHGYAWmHiABw@mail.gmail.com>
	<CAHAreOr+c3CS_NWOMPwUuCXN=-t5vPswzEvS6QUtX+sUKq=yrw@mail.gmail.com>
	<CAOvn4qgF+am8ScvsCtC7pXxxmtfEsY6EixnbHdYwsWLO+HQ31g@mail.gmail.com>
	<CAHAreOpqk=KuSLJdDS1n7w_DYjGhjtA_RJdxAfur_iQ2Lq_iig@mail.gmail.com>
	<CAP-uhDcMnCaM=47=qQFmO+LoxMACOsECEU=_HETvPmJGBcdEFQ@mail.gmail.com>
	<CAOvn4qhT5uW-VTJrQzikvh=QV5A+mb8Htt37rk-Vu0iwepwOSA@mail.gmail.com>
	<20120611121145.GA3470@volans.logilab.fr>
	<CAHAreOrTZ9Wo8o1n+VjRd-_U1LAwxiXPPx7vYjOzrtsqyuN_OQ@mail.gmail.com>
	<CAP-uhDcJ6ckhv6wQRgfPmr_EDy4_FSG+U6G=pN4tiQ=5dN3C9Q@mail.gmail.com>
	<CAP-uhDenjmq2eZDL+7wNA9tfy-SbcGTMbhw43E3d00KSArQNUw@mail.gmail.com>
	<CAHAreOpVo0EZ6sRRVxkdAGRrb7Ya6SZHngjMjM4Gt7s8nWb51Q@mail.gmail.com>
	<CAP-uhDcqWcy0QfjnohgxsDEemruJREay3awPpqDxUYxPrO5z3w@mail.gmail.com>
	<CAHAreOpuSBSx+kKRt8kpO3giXcaA=Tv9wEObUcy1hXCpsVVskw@mail.gmail.com>
	<CAP-uhDe=ogMOsWdPmkRNK0Q43wwTuE-WVAptK+Vw9ahyXshegQ@mail.gmail.com>
	<CAP-uhDezt-esACujasuZeWMBHdGmAF6qWRLZuAXnRcv9k5Xa9g@mail.gmail.com>
	<CAP-uhDdGPKHgZb=Xx5TXGfn2LXUps8+Sj0ij=hK8MApiT1vXGw@mail.gmail.com>
Message-ID: <CAP-uhDeBZGCOf5FUZGR4ehKLeXPMEYDi+j7=gE3NR7hbxJuL+w@mail.gmail.com>

I've just published NBCloud to the Chrome Store. It feels strange, but
nice, to have IPython available alongside Angry Birds.

Programming is so much fun.


From takowl at gmail.com  Fri Jun 15 13:05:12 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Fri, 15 Jun 2012 18:05:12 +0100
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAP-uhDeBZGCOf5FUZGR4ehKLeXPMEYDi+j7=gE3NR7hbxJuL+w@mail.gmail.com>
References: <CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
	<CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>
	<CAOvn4qjs5ifL_HKj1qJWkmNdQ+4KUSQtgCE37QbLX3Yy_y6DcA@mail.gmail.com>
	<CAHAreOp_+joxdeZTQ1ZEOOU4w=euqtESMTisVSDA8oRx=RdCHg@mail.gmail.com>
	<CAOvn4qhKg9QM8u-BQvrk+PazfRBpAYtF_7Vh7-YHGYAWmHiABw@mail.gmail.com>
	<CAHAreOr+c3CS_NWOMPwUuCXN=-t5vPswzEvS6QUtX+sUKq=yrw@mail.gmail.com>
	<CAOvn4qgF+am8ScvsCtC7pXxxmtfEsY6EixnbHdYwsWLO+HQ31g@mail.gmail.com>
	<CAHAreOpqk=KuSLJdDS1n7w_DYjGhjtA_RJdxAfur_iQ2Lq_iig@mail.gmail.com>
	<CAP-uhDcMnCaM=47=qQFmO+LoxMACOsECEU=_HETvPmJGBcdEFQ@mail.gmail.com>
	<CAOvn4qhT5uW-VTJrQzikvh=QV5A+mb8Htt37rk-Vu0iwepwOSA@mail.gmail.com>
	<20120611121145.GA3470@volans.logilab.fr>
	<CAHAreOrTZ9Wo8o1n+VjRd-_U1LAwxiXPPx7vYjOzrtsqyuN_OQ@mail.gmail.com>
	<CAP-uhDcJ6ckhv6wQRgfPmr_EDy4_FSG+U6G=pN4tiQ=5dN3C9Q@mail.gmail.com>
	<CAP-uhDenjmq2eZDL+7wNA9tfy-SbcGTMbhw43E3d00KSArQNUw@mail.gmail.com>
	<CAHAreOpVo0EZ6sRRVxkdAGRrb7Ya6SZHngjMjM4Gt7s8nWb51Q@mail.gmail.com>
	<CAP-uhDcqWcy0QfjnohgxsDEemruJREay3awPpqDxUYxPrO5z3w@mail.gmail.com>
	<CAHAreOpuSBSx+kKRt8kpO3giXcaA=Tv9wEObUcy1hXCpsVVskw@mail.gmail.com>
	<CAP-uhDe=ogMOsWdPmkRNK0Q43wwTuE-WVAptK+Vw9ahyXshegQ@mail.gmail.com>
	<CAP-uhDezt-esACujasuZeWMBHdGmAF6qWRLZuAXnRcv9k5Xa9g@mail.gmail.com>
	<CAP-uhDdGPKHgZb=Xx5TXGfn2LXUps8+Sj0ij=hK8MApiT1vXGw@mail.gmail.com>
	<CAP-uhDeBZGCOf5FUZGR4ehKLeXPMEYDi+j7=gE3NR7hbxJuL+w@mail.gmail.com>
Message-ID: <CAOvn4qjApqgVwEi-57RYxf3_DGzzkiWj=nNp1C3jf-WpeiTzUA@mail.gmail.com>

On 15 June 2012 16:28, Carl Smith <carl.input at gmail.com> wrote:
> I've just published NBCloud to the Chrome Store. It feels strange, but
> nice, to have IPython available alongside Angry Birds.

I propose an easter egg mode where you get Angry Birds sound effects
for running a cell (launch) and seeing an uncaught error (crash). ;-)

Thomas


From bussonniermatthias at gmail.com  Fri Jun 15 15:10:31 2012
From: bussonniermatthias at gmail.com (Matthias BUSSONNIER)
Date: Fri, 15 Jun 2012 21:10:31 +0200
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAOvn4qjApqgVwEi-57RYxf3_DGzzkiWj=nNp1C3jf-WpeiTzUA@mail.gmail.com>
References: <CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
	<CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>
	<CAOvn4qjs5ifL_HKj1qJWkmNdQ+4KUSQtgCE37QbLX3Yy_y6DcA@mail.gmail.com>
	<CAHAreOp_+joxdeZTQ1ZEOOU4w=euqtESMTisVSDA8oRx=RdCHg@mail.gmail.com>
	<CAOvn4qhKg9QM8u-BQvrk+PazfRBpAYtF_7Vh7-YHGYAWmHiABw@mail.gmail.com>
	<CAHAreOr+c3CS_NWOMPwUuCXN=-t5vPswzEvS6QUtX+sUKq=yrw@mail.gmail.com>
	<CAOvn4qgF+am8ScvsCtC7pXxxmtfEsY6EixnbHdYwsWLO+HQ31g@mail.gmail.com>
	<CAHAreOpqk=KuSLJdDS1n7w_DYjGhjtA_RJdxAfur_iQ2Lq_iig@mail.gmail.com>
	<CAP-uhDcMnCaM=47=qQFmO+LoxMACOsECEU=_HETvPmJGBcdEFQ@mail.gmail.com>
	<CAOvn4qhT5uW-VTJrQzikvh=QV5A+mb8Htt37rk-Vu0iwepwOSA@mail.gmail.com>
	<20120611121145.GA3470@volans.logilab.fr>
	<CAHAreOrTZ9Wo8o1n+VjRd-_U1LAwxiXPPx7vYjOzrtsqyuN_OQ@mail.gmail.com>
	<CAP-uhDcJ6ckhv6wQRgfPmr_EDy4_FSG+U6G=pN4tiQ=5dN3C9Q@mail.gmail.com>
	<CAP-uhDenjmq2eZDL+7wNA9tfy-SbcGTMbhw43E3d00KSArQNUw@mail.gmail.com>
	<CAHAreOpVo0EZ6sRRVxkdAGRrb7Ya6SZHngjMjM4Gt7s8nWb51Q@mail.gmail.com>
	<CAP-uhDcqWcy0QfjnohgxsDEemruJREay3awPpqDxUYxPrO5z3w@mail.gmail.com>
	<CAHAreOpuSBSx+kKRt8kpO3giXcaA=Tv9wEObUcy1hXCpsVVskw@mail.gmail.com>
	<CAP-uhDe=ogMOsWdPmkRNK0Q43wwTuE-WVAptK+Vw9ahyXshegQ@mail.gmail.com>
	<CAP-uhDezt-esACujasuZeWMBHdGmAF6qWRLZuAXnRcv9k5Xa9g@mail.gmail.com>
	<CAP-uhDdGPKHgZb=Xx5TXGfn2LXUps8+Sj0ij=hK8MApiT1vXGw@mail.gmail.com>
	<CAP-uhDeBZGCOf5FUZGR4ehKLeXPMEYDi+j7=gE3NR7hbxJuL+w@mail.gmail.com>
	<CAOvn4qjApqgVwEi-57RYxf3_DGzzkiWj=nNp1C3jf-WpeiTzUA@mail.gmail.com>
Message-ID: <FA297FEE-3054-479F-8272-CAF6C63AEE02@gmail.com>


Le 15 juin 2012 ? 19:05, Thomas Kluyver a ?crit :

> On 15 June 2012 16:28, Carl Smith <carl.input at gmail.com> wrote:
>> I've just published NBCloud to the Chrome Store. It feels strange, but
>> nice, to have IPython available alongside Angry Birds.
> 
> I propose an easter egg mode where you get Angry Birds sound effects
> for running a cell (launch) and seeing an uncaught error (crash). ;-)

Waiting for a PR, as usual....

I'll just add that you have to search for NotebookCloud not NBCloud : 
https://chrome.google.com/webstore/detail/afepkpkdjhebipfagcfkeganflaannla

-- 
Matthias

From jonathan.taylor at stanford.edu  Fri Jun 15 16:24:14 2012
From: jonathan.taylor at stanford.edu (Jonathan Taylor)
Date: Fri, 15 Jun 2012 13:24:14 -0700
Subject: [IPython-dev] Easy Installation
In-Reply-To: <CAP-uhDeBZGCOf5FUZGR4ehKLeXPMEYDi+j7=gE3NR7hbxJuL+w@mail.gmail.com>
References: <CAP-uhDfZxPZwbz+fsWbcyqP0wfAgE=kT_TR93D1g=LLoD9CnTQ@mail.gmail.com>
	<CAHAreOq6e_Pm4WHfF2W7-2LMxFWmcoJSckpFjfNciB+seNyB2g@mail.gmail.com>
	<CAOvn4qjs5ifL_HKj1qJWkmNdQ+4KUSQtgCE37QbLX3Yy_y6DcA@mail.gmail.com>
	<CAHAreOp_+joxdeZTQ1ZEOOU4w=euqtESMTisVSDA8oRx=RdCHg@mail.gmail.com>
	<CAOvn4qhKg9QM8u-BQvrk+PazfRBpAYtF_7Vh7-YHGYAWmHiABw@mail.gmail.com>
	<CAHAreOr+c3CS_NWOMPwUuCXN=-t5vPswzEvS6QUtX+sUKq=yrw@mail.gmail.com>
	<CAOvn4qgF+am8ScvsCtC7pXxxmtfEsY6EixnbHdYwsWLO+HQ31g@mail.gmail.com>
	<CAHAreOpqk=KuSLJdDS1n7w_DYjGhjtA_RJdxAfur_iQ2Lq_iig@mail.gmail.com>
	<CAP-uhDcMnCaM=47=qQFmO+LoxMACOsECEU=_HETvPmJGBcdEFQ@mail.gmail.com>
	<CAOvn4qhT5uW-VTJrQzikvh=QV5A+mb8Htt37rk-Vu0iwepwOSA@mail.gmail.com>
	<20120611121145.GA3470@volans.logilab.fr>
	<CAHAreOrTZ9Wo8o1n+VjRd-_U1LAwxiXPPx7vYjOzrtsqyuN_OQ@mail.gmail.com>
	<CAP-uhDcJ6ckhv6wQRgfPmr_EDy4_FSG+U6G=pN4tiQ=5dN3C9Q@mail.gmail.com>
	<CAP-uhDenjmq2eZDL+7wNA9tfy-SbcGTMbhw43E3d00KSArQNUw@mail.gmail.com>
	<CAHAreOpVo0EZ6sRRVxkdAGRrb7Ya6SZHngjMjM4Gt7s8nWb51Q@mail.gmail.com>
	<CAP-uhDcqWcy0QfjnohgxsDEemruJREay3awPpqDxUYxPrO5z3w@mail.gmail.com>
	<CAHAreOpuSBSx+kKRt8kpO3giXcaA=Tv9wEObUcy1hXCpsVVskw@mail.gmail.com>
	<CAP-uhDe=ogMOsWdPmkRNK0Q43wwTuE-WVAptK+Vw9ahyXshegQ@mail.gmail.com>
	<CAP-uhDezt-esACujasuZeWMBHdGmAF6qWRLZuAXnRcv9k5Xa9g@mail.gmail.com>
	<CAP-uhDdGPKHgZb=Xx5TXGfn2LXUps8+Sj0ij=hK8MApiT1vXGw@mail.gmail.com>
	<CAP-uhDeBZGCOf5FUZGR4ehKLeXPMEYDi+j7=gE3NR7hbxJuL+w@mail.gmail.com>
Message-ID: <CANmCCuQrABFZ2XNVZEzUufJeMWaFL29gbP-6YMVbZmYfm+m=vg@mail.gmail.com>

.

On Fri, Jun 15, 2012 at 8:28 AM, Carl Smith <carl.input at gmail.com> wrote:

> It feels strange, but
> nice, to have IPython available alongside Angry Birds.
>
>
Agreed.

-- 
Jonathan Taylor
Dept. of Statistics
Sequoia Hall, 137
390 Serra Mall
Stanford, CA 94305
Tel:   650.723.9230
Fax:   650.725.8977
Web: http://www-stat.stanford.edu/~jtaylo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120615/a0f80405/attachment.html>

From bob+ipython at mcelrath.org  Fri Jun 15 16:31:35 2012
From: bob+ipython at mcelrath.org (Bob McElrath)
Date: Fri, 15 Jun 2012 20:31:35 +0000
Subject: [IPython-dev] Namespace pollution and a kernel panel
Message-ID: <20120615203135.GA6159@mcelrath.org>

One of my long-standing complaints about notebook-style worksheets (Maple,
Mathematica) is the large and hidden namespace of defined symbols.  If one is
not careful, it's easy to end up with some element of worksheet-state that is
not what you think it is, and end up with garbage results.  This can be very
difficult to track down.  And because worksheets are generally not executed top
to bottom, it often results in difficult-to-reproduce errors.

I discovered this today with IPython's notebook and gamma(), which turns out to
be numpy.random.gamma() rather than the Euler Gamma function math.gamma() or
scipy.special.gamma().  

This is because I ran ipython --pylab, but it highlights a bigger problem: how
does the user know which symbols are defined?  I have been thinking lately of an
addition to the notebook interface: a side-panel showing everything
defined/imported in the kernel.  This would further allow the user to inspect
the output of commands by clicking on kernel data structures, rather than
wasting a cell just to print some output.  Personally I always end up with very
messy worksheets, because I insert a lot of print or plot commands, just to
explore a data structure or function.

Another possible use of such a thing would be a non-modifying cell: a cell that
refuses to change the state of the kernel by modifying variables, but could be
used to print/plot/explore existing data structures.  Then when one has found
the most desirable representation, that could be copied/moved to the worksheet.

Perhaps there are other creative ways to avoid the user having to manage an
approximation of the kernel state in their head.

--
Cheers, Bob McElrath

"The individual has always had to struggle to keep from being overwhelmed by
the tribe.  If you try it, you will be lonely often, and sometimes frightened.
But no price is too high to pay for the privilege of owning yourself." 
    -- Friedrich Nietzsche


From jonathan.taylor at stanford.edu  Fri Jun 15 16:30:00 2012
From: jonathan.taylor at stanford.edu (Jonathan Taylor)
Date: Fri, 15 Jun 2012 13:30:00 -0700
Subject: [IPython-dev] Adding attributes to .ipynb files
In-Reply-To: <CAHNn8BXDtt1oYWjepp=ruBSbpRi1cNpu7BWH_3Zs8Veu+WB4Cg@mail.gmail.com>
References: <CADLczKD+gbS+VQkzH5+brhpYq-RjWkOAUXBpyA5mX37rPsFunw@mail.gmail.com>
	<CAHNn8BXDtt1oYWjepp=ruBSbpRi1cNpu7BWH_3Zs8Veu+WB4Cg@mail.gmail.com>
Message-ID: <CANmCCuSO80L4Zj8=sc_YLyeWEwyyyv6ABN7GtiC0Sye55hGLJw@mail.gmail.com>

Yes, that sounds exactly like what we want. As always, the ipython team is
one step ahead. I guess this PR will happen sometime soon as there don't
seem to be many issues on github?

On Thu, Jun 14, 2012 at 5:09 PM, MinRK <benjaminrk at gmail.com> wrote:

> You mean something like this<https://github.com/ipython/ipython/pull/1934>
> ?
>
> Adding your own (jsonable) data into those metadata dicts should be safe.
>  I would recommend using your own prefix or subdict to avoid potential
> collisions down the road.
>
> On Thu, Jun 14, 2012 at 4:13 PM, Dennis Sun <dlsun at stanford.edu> wrote:
>
>> Hi all,
>>
>> We're working on a project where we need notebook files that have some
>> extra data attached to each cell. Because we would like to make sure that
>> the files are still compatible with the iPython Notebook, what we're doing
>> right now is including this metadata in the "json" attribute of the output
>> of each cell and then "promoting" these attributes to the cell level at
>> runtime. Thus, the notebook file is still a valid .ipynb file, but the
>> metadata doesn't show up when the user loads the page.
>>
>> However, it seems right now that we can get away with adding the metadata
>> directly at the cell level in the .ipynb file, since iPython Notebook
>> simply passes over any keys that it doesn't know to look for. We would like
>> to do this instead, since it is conceptually much cleaner, but we are
>> worried about compatibility with future versions of iPython, which might
>> enforce .ipynb files to follow a certain format.
>>
>> We were hoping that someone more knowledgeable about the state of iPython
>> development could advise on whether or not it's safe to add our own
>> attributes directly to the .ipynb files. It seems that this shouldn't be a
>> problem as long as .ipynb remains a JSON key-value store, but we wanted to
>> check with the community to make sure.
>>
>> Thanks,
>> Dennis
>>
>> _______________________________________________
>> 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
>
>


-- 
Jonathan Taylor
Dept. of Statistics
Sequoia Hall, 137
390 Serra Mall
Stanford, CA 94305
Tel:   650.723.9230
Fax:   650.725.8977
Web: http://www-stat.stanford.edu/~jtaylo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120615/01b19eca/attachment.html>

From benjaminrk at gmail.com  Fri Jun 15 16:31:39 2012
From: benjaminrk at gmail.com (MinRK)
Date: Fri, 15 Jun 2012 13:31:39 -0700
Subject: [IPython-dev] Adding attributes to .ipynb files
In-Reply-To: <CANmCCuSO80L4Zj8=sc_YLyeWEwyyyv6ABN7GtiC0Sye55hGLJw@mail.gmail.com>
References: <CADLczKD+gbS+VQkzH5+brhpYq-RjWkOAUXBpyA5mX37rPsFunw@mail.gmail.com>
	<CAHNn8BXDtt1oYWjepp=ruBSbpRi1cNpu7BWH_3Zs8Veu+WB4Cg@mail.gmail.com>
	<CANmCCuSO80L4Zj8=sc_YLyeWEwyyyv6ABN7GtiC0Sye55hGLJw@mail.gmail.com>
Message-ID: <CAHNn8BXFvoQHgr=TJOJcLojt63NE6E5VHrx9S1+ifT12cZDJbQ@mail.gmail.com>

On Fri, Jun 15, 2012 at 1:30 PM, Jonathan Taylor <
jonathan.taylor at stanford.edu> wrote:

> Yes, that sounds exactly like what we want. As always, the ipython team is
> one step ahead. I guess this PR will happen sometime soon as there don't
> seem to be many issues on github?


Yes, finishing the review on this one is one of the last things to do
before cutting the beta.


>
>
> On Thu, Jun 14, 2012 at 5:09 PM, MinRK <benjaminrk at gmail.com> wrote:
>
>> You mean something like this<https://github.com/ipython/ipython/pull/1934>
>> ?
>>
>> Adding your own (jsonable) data into those metadata dicts should be safe.
>>  I would recommend using your own prefix or subdict to avoid potential
>> collisions down the road.
>>
>> On Thu, Jun 14, 2012 at 4:13 PM, Dennis Sun <dlsun at stanford.edu> wrote:
>>
>>> Hi all,
>>>
>>> We're working on a project where we need notebook files that have some
>>> extra data attached to each cell. Because we would like to make sure that
>>> the files are still compatible with the iPython Notebook, what we're doing
>>> right now is including this metadata in the "json" attribute of the output
>>> of each cell and then "promoting" these attributes to the cell level at
>>> runtime. Thus, the notebook file is still a valid .ipynb file, but the
>>> metadata doesn't show up when the user loads the page.
>>>
>>> However, it seems right now that we can get away with adding the
>>> metadata directly at the cell level in the .ipynb file, since iPython
>>> Notebook simply passes over any keys that it doesn't know to look for. We
>>> would like to do this instead, since it is conceptually much cleaner, but
>>> we are worried about compatibility with future versions of iPython, which
>>> might enforce .ipynb files to follow a certain format.
>>>
>>> We were hoping that someone more knowledgeable about the state of
>>> iPython development could advise on whether or not it's safe to add our own
>>> attributes directly to the .ipynb files. It seems that this shouldn't be a
>>> problem as long as .ipynb remains a JSON key-value store, but we wanted to
>>> check with the community to make sure.
>>>
>>> Thanks,
>>> Dennis
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
>
> --
> Jonathan Taylor
> Dept. of Statistics
> Sequoia Hall, 137
> 390 Serra Mall
> Stanford, CA 94305
> Tel:   650.723.9230
> Fax:   650.725.8977
> Web: http://www-stat.stanford.edu/~jtaylo
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120615/cbcdd65a/attachment.html>

From benjaminrk at gmail.com  Fri Jun 15 16:42:21 2012
From: benjaminrk at gmail.com (MinRK)
Date: Fri, 15 Jun 2012 13:42:21 -0700
Subject: [IPython-dev] Namespace pollution and a kernel panel
In-Reply-To: <20120615203135.GA6159@mcelrath.org>
References: <20120615203135.GA6159@mcelrath.org>
Message-ID: <CAHNn8BUQs_ax0YUh89r_88U4nh0ixT748GC_axoQwi9PUtxCvw@mail.gmail.com>

On Fri, Jun 15, 2012 at 1:31 PM, Bob McElrath <bob+ipython at mcelrath.org>wrote:

> One of my long-standing complaints about notebook-style worksheets (Maple,
> Mathematica) is the large and hidden namespace of defined symbols.  If one
> is
> not careful, it's easy to end up with some element of worksheet-state that
> is
> not what you think it is, and end up with garbage results.  This can be
> very
> difficult to track down.  And because worksheets are generally not
> executed top
> to bottom, it often results in difficult-to-reproduce errors.
>
> I discovered this today with IPython's notebook and gamma(), which turns
> out to
> be numpy.random.gamma() rather than the Euler Gamma function math.gamma()
> or
> scipy.special.gamma().
>
> This is because I ran ipython --pylab, but it highlights a bigger problem:
> how
> does the user know which symbols are defined?  I have been thinking lately
> of an
> addition to the notebook interface: a side-panel showing everything
> defined/imported in the kernel.  This would further allow the user to
> inspect
> the output of commands by clicking on kernel data structures, rather than
> wasting a cell just to print some output.  Personally I always end up with
> very
> messy worksheets, because I insert a lot of print or plot commands, just to
> explore a data structure or function.
>

This is a popular idea - a namespace view, sidebar, etc. a la matlab or
what have you.  I've even implemented a simple one myself (purely with
javascript in a markdown cell) as a test of the recently reorganized
javascript that allows decoupling of execution from cells, based on %whos.

It's not difficult, and should probably be done as a widget-style thing.


>
> Another possible use of such a thing would be a non-modifying cell: a cell
> that
> refuses to change the state of the kernel by modifying variables, but
> could be
> used to print/plot/explore existing data structures.  Then when one has
> found
> the most desirable representation, that could be copied/moved to the
> worksheet.
>

If you want to execute without editing the document,
this is what the 'run-in-place' (ctrl-Enter) is for - running a few
commands in place,
always overwriting the same cell,
because you don't actually want to keep the effects in your document.


>
> Perhaps there are other creative ways to avoid the user having to manage an
> approximation of the kernel state in their head.
>
> --
> Cheers, Bob McElrath
>
> "The individual has always had to struggle to keep from being overwhelmed
> by
> the tribe.  If you try it, you will be lonely often, and sometimes
> frightened.
> But no price is too high to pay for the privilege of owning yourself."
>    -- Friedrich Nietzsche
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120615/60bd6d8c/attachment.html>

From jtaylor.debian at googlemail.com  Fri Jun 15 17:06:45 2012
From: jtaylor.debian at googlemail.com (Julian Taylor)
Date: Fri, 15 Jun 2012 23:06:45 +0200
Subject: [IPython-dev] Let's get 0.13 released...
In-Reply-To: <CAH4pYpSFKz3g9mkQLRgOaF8zcXkEsxpMkqXjhOYkmtHrFaYYnQ@mail.gmail.com>
References: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
	<4FD61F6C.3080709@googlemail.com>
	<CAHAreOprJ9qwqJcrw1mesHu2kXYYw_x_dEod91DA4mYTYXDsHA@mail.gmail.com>
	<CAHNn8BWLU=ggRrwh-U1Tv1VRf1b_2qZfTiP46Jfkr1Z26HpFOQ@mail.gmail.com>
	<4FD66B0F.2060405@googlemail.com>
	<CAHNn8BWAQwwjCt=DoO8exczW4z-aN3PAEU=gx4aU8kbSENXq5Q@mail.gmail.com>
	<CAH4pYpSFKz3g9mkQLRgOaF8zcXkEsxpMkqXjhOYkmtHrFaYYnQ@mail.gmail.com>
Message-ID: <CAK5FAtFYFLMdHVfQ6Xy66kBxZg5Fgv+UQsgycjQNqzfRPkJc_w@mail.gmail.com>

>
> We are in a horrible position right now. ?We can't live without the
> menubar implementation, but this means we are tracking a very-dev
> branch. ?We could update the the latest of that, but that is risky. ?I
> would probably prefer to just keep the version we are using as we know
> it works. ?Once 1.9 is released, I think the plan is the merge the
> menubar branch back in. ?Then we will be in the clear. ?1.9 was
> supposed to come out "within a few months" of last summer. ?In the
> meantime, we can all flog me for not tracking which commit of that
> branch we are actually using...
>

sorting this out should be a critical blocker for 0.13.
It can't be packaged in debian, ubuntu, fedora and likely most other
distributions following free software guidelines in the current state.
A binary blob and no mean to determine where to get the correct
un-obfuscated source from is a no-go.


From bob+ipython at mcelrath.org  Fri Jun 15 17:16:01 2012
From: bob+ipython at mcelrath.org (Bob McElrath)
Date: Fri, 15 Jun 2012 21:16:01 +0000
Subject: [IPython-dev] Namespace pollution and a kernel panel
In-Reply-To: <CAHNn8BUQs_ax0YUh89r_88U4nh0ixT748GC_axoQwi9PUtxCvw@mail.gmail.com>
References: <20120615203135.GA6159@mcelrath.org>
	<CAHNn8BUQs_ax0YUh89r_88U4nh0ixT748GC_axoQwi9PUtxCvw@mail.gmail.com>
Message-ID: <20120615211601.GB6159@mcelrath.org>

MinRK [benjaminrk at gmail.com] wrote:
> 
> This is a popular idea - a namespace view, sidebar, etc. a la matlab or what
> have you. ?I've even implemented a simple one myself (purely with javascript in
> a markdown cell) as a test of the recently reorganized javascript that allows
> decoupling of execution from cells, based on %whos.

Is it available somewhere?

> If you want to execute without editing the document, this is what the
> 'run-in-place' (ctrl-Enter) is for - running a few commands in place, always
> overwriting the same cell, because you don't actually want to keep the effects
> in your document.

Aaah I haven't been doing that with ctrl-enter, good idea.

It still does change the kernel though, which is my concern.  (e.g. "what cell
did I last execute that set $x$?")

--
Cheers, Bob McElrath

"The individual has always had to struggle to keep from being overwhelmed by
the tribe.  If you try it, you will be lonely often, and sometimes frightened.
But no price is too high to pay for the privilege of owning yourself." 
    -- Friedrich Nietzsche


From benjaminrk at gmail.com  Fri Jun 15 17:16:57 2012
From: benjaminrk at gmail.com (MinRK)
Date: Fri, 15 Jun 2012 14:16:57 -0700
Subject: [IPython-dev] Namespace pollution and a kernel panel
In-Reply-To: <20120615211601.GB6159@mcelrath.org>
References: <20120615203135.GA6159@mcelrath.org>
	<CAHNn8BUQs_ax0YUh89r_88U4nh0ixT748GC_axoQwi9PUtxCvw@mail.gmail.com>
	<20120615211601.GB6159@mcelrath.org>
Message-ID: <CAHNn8BWK61wAGeuJiWFOS_7ayM7Zh_BbLdmYMzMub_chttFOuw@mail.gmail.com>

On Fri, Jun 15, 2012 at 2:16 PM, Bob McElrath <bob+ipython at mcelrath.org>wrote:

> MinRK [benjaminrk at gmail.com] wrote:
> >
> > This is a popular idea - a namespace view, sidebar, etc. a la matlab or
> what
> > have you.  I've even implemented a simple one myself (purely with
> javascript in
> > a markdown cell) as a test of the recently reorganized javascript that
> allows
> > decoupling of execution from cells, based on %whos.
>
> Is it available somewhere?
>

I have no idea where I put it - I'll post it somewhere if I find it (and it
still works).


>
> > If you want to execute without editing the document, this is what the
> > 'run-in-place' (ctrl-Enter) is for - running a few commands in place,
> always
> > overwriting the same cell, because you don't actually want to keep the
> effects
> > in your document.
>
> Aaah I haven't been doing that with ctrl-enter, good idea.
>
> It still does change the kernel though, which is my concern.  (e.g. "what
> cell
> did I last execute that set $x$?")
>

But I think that's not feasible to actually enforce in Python, since
arbitrary code can cause arbitrary effects anywhere in the Python runtime.


>
> --
> Cheers, Bob McElrath
>
> "The individual has always had to struggle to keep from being overwhelmed
> by
> the tribe.  If you try it, you will be lonely often, and sometimes
> frightened.
> But no price is too high to pay for the privilege of owning yourself."
>    -- Friedrich Nietzsche
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120615/f13d86e5/attachment.html>

From bob+ipython at mcelrath.org  Fri Jun 15 17:22:01 2012
From: bob+ipython at mcelrath.org (Bob McElrath)
Date: Fri, 15 Jun 2012 21:22:01 +0000
Subject: [IPython-dev] Namespace pollution and a kernel panel
In-Reply-To: <CAHNn8BWK61wAGeuJiWFOS_7ayM7Zh_BbLdmYMzMub_chttFOuw@mail.gmail.com>
References: <20120615203135.GA6159@mcelrath.org>
	<CAHNn8BUQs_ax0YUh89r_88U4nh0ixT748GC_axoQwi9PUtxCvw@mail.gmail.com>
	<20120615211601.GB6159@mcelrath.org>
	<CAHNn8BWK61wAGeuJiWFOS_7ayM7Zh_BbLdmYMzMub_chttFOuw@mail.gmail.com>
Message-ID: <20120615212201.GC6159@mcelrath.org>

MinRK [benjaminrk at gmail.com] wrote:
> 
> But I think that's not feasible to actually enforce in Python, since arbitrary
> code can cause arbitrary effects anywhere in the Python runtime.

Just fork().

--
Cheers, Bob McElrath

"The individual has always had to struggle to keep from being overwhelmed by
the tribe.  If you try it, you will be lonely often, and sometimes frightened.
But no price is too high to pay for the privilege of owning yourself." 
    -- Friedrich Nietzsche


From benjaminrk at gmail.com  Fri Jun 15 17:26:30 2012
From: benjaminrk at gmail.com (MinRK)
Date: Fri, 15 Jun 2012 14:26:30 -0700
Subject: [IPython-dev] Namespace pollution and a kernel panel
In-Reply-To: <20120615212201.GC6159@mcelrath.org>
References: <20120615203135.GA6159@mcelrath.org>
	<CAHNn8BUQs_ax0YUh89r_88U4nh0ixT748GC_axoQwi9PUtxCvw@mail.gmail.com>
	<20120615211601.GB6159@mcelrath.org>
	<CAHNn8BWK61wAGeuJiWFOS_7ayM7Zh_BbLdmYMzMub_chttFOuw@mail.gmail.com>
	<20120615212201.GC6159@mcelrath.org>
Message-ID: <CAHNn8BXiYUjWdwEK8md4mkbcsn_7=WVz+Pbt-HXmeWE9ij=AAA@mail.gmail.com>

On Fri, Jun 15, 2012 at 2:22 PM, Bob McElrath <bob+ipython at mcelrath.org>wrote:

> MinRK [benjaminrk at gmail.com] wrote:
> >
> > But I think that's not feasible to actually enforce in Python, since
> arbitrary
> > code can cause arbitrary effects anywhere in the Python runtime.
>
> Just fork().
>

Not all code is not fork-safe. Most pertinent would be the zmq
context/sockets used  by the kernel to communicate.

So this might work, as long as you don't need to actually see any outputs :)


> --
> Cheers, Bob McElrath
>
> "The individual has always had to struggle to keep from being overwhelmed
> by
> the tribe.  If you try it, you will be lonely often, and sometimes
> frightened.
> But no price is too high to pay for the privilege of owning yourself."
>    -- Friedrich Nietzsche
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120615/c72c2e31/attachment.html>

From fperez.net at gmail.com  Fri Jun 15 18:13:29 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 15 Jun 2012 15:13:29 -0700
Subject: [IPython-dev] Let's get 0.13 released...
In-Reply-To: <CAK5FAtFYFLMdHVfQ6Xy66kBxZg5Fgv+UQsgycjQNqzfRPkJc_w@mail.gmail.com>
References: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
	<4FD61F6C.3080709@googlemail.com>
	<CAHAreOprJ9qwqJcrw1mesHu2kXYYw_x_dEod91DA4mYTYXDsHA@mail.gmail.com>
	<CAHNn8BWLU=ggRrwh-U1Tv1VRf1b_2qZfTiP46Jfkr1Z26HpFOQ@mail.gmail.com>
	<4FD66B0F.2060405@googlemail.com>
	<CAHNn8BWAQwwjCt=DoO8exczW4z-aN3PAEU=gx4aU8kbSENXq5Q@mail.gmail.com>
	<CAH4pYpSFKz3g9mkQLRgOaF8zcXkEsxpMkqXjhOYkmtHrFaYYnQ@mail.gmail.com>
	<CAK5FAtFYFLMdHVfQ6Xy66kBxZg5Fgv+UQsgycjQNqzfRPkJc_w@mail.gmail.com>
Message-ID: <CAHAreOoRwdXkW=vmxqZ71zEGbfdgS6GR6WKKsNEP9onZajyUAw@mail.gmail.com>

On Fri, Jun 15, 2012 at 2:06 PM, Julian Taylor
<jtaylor.debian at googlemail.com> wrote:
> sorting this out should be a critical blocker for 0.13.
> It can't be packaged in debian, ubuntu, fedora and likely most other
> distributions following free software guidelines in the current state.
> A binary blob and no mean to determine where to get the correct
> un-obfuscated source from is a no-go.

Ouch.  OK, let's have a blocker issue opened on this then.  Obviously
not much point in releasing 0.13 if we can't make it into any distro.

It shouldn't be too hard to determine which version we're using by
comparing against a git tree.

f


From benjaminrk at gmail.com  Fri Jun 15 18:16:28 2012
From: benjaminrk at gmail.com (MinRK)
Date: Fri, 15 Jun 2012 15:16:28 -0700
Subject: [IPython-dev] Let's get 0.13 released...
In-Reply-To: <CAHAreOoRwdXkW=vmxqZ71zEGbfdgS6GR6WKKsNEP9onZajyUAw@mail.gmail.com>
References: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
	<4FD61F6C.3080709@googlemail.com>
	<CAHAreOprJ9qwqJcrw1mesHu2kXYYw_x_dEod91DA4mYTYXDsHA@mail.gmail.com>
	<CAHNn8BWLU=ggRrwh-U1Tv1VRf1b_2qZfTiP46Jfkr1Z26HpFOQ@mail.gmail.com>
	<4FD66B0F.2060405@googlemail.com>
	<CAHNn8BWAQwwjCt=DoO8exczW4z-aN3PAEU=gx4aU8kbSENXq5Q@mail.gmail.com>
	<CAH4pYpSFKz3g9mkQLRgOaF8zcXkEsxpMkqXjhOYkmtHrFaYYnQ@mail.gmail.com>
	<CAK5FAtFYFLMdHVfQ6Xy66kBxZg5Fgv+UQsgycjQNqzfRPkJc_w@mail.gmail.com>
	<CAHAreOoRwdXkW=vmxqZ71zEGbfdgS6GR6WKKsNEP9onZajyUAw@mail.gmail.com>
Message-ID: <CAHNn8BURt7QiUFSJ8gdOUpYqJzhH3GJso5cfOcLLjHooz-qaWA@mail.gmail.com>

On Fri, Jun 15, 2012 at 3:13 PM, Fernando Perez <fperez.net at gmail.com>wrote:

> On Fri, Jun 15, 2012 at 2:06 PM, Julian Taylor
> <jtaylor.debian at googlemail.com> wrote:
> > sorting this out should be a critical blocker for 0.13.
> > It can't be packaged in debian, ubuntu, fedora and likely most other
> > distributions following free software guidelines in the current state.
> > A binary blob and no mean to determine where to get the correct
> > un-obfuscated source from is a no-go.
>
> Ouch.  OK, let's have a blocker issue opened on this then.  Obviously
> not much point in releasing 0.13 if we can't make it into any distro.
>
> It shouldn't be too hard to determine which version we're using by
> comparing against a git tree.
>

Except that we would have to *build* for every commit to check, and hope
that the build tools also didn't change the output.  This is the whole
source of the problem - shipping minified js is equivalent to shipping a
dll.

I think the first sensible approach would be to test a current checkout,
and see if it works.


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

From fperez.net at gmail.com  Fri Jun 15 18:25:40 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 15 Jun 2012 15:25:40 -0700
Subject: [IPython-dev] Let's get 0.13 released...
In-Reply-To: <CAHNn8BURt7QiUFSJ8gdOUpYqJzhH3GJso5cfOcLLjHooz-qaWA@mail.gmail.com>
References: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
	<4FD61F6C.3080709@googlemail.com>
	<CAHAreOprJ9qwqJcrw1mesHu2kXYYw_x_dEod91DA4mYTYXDsHA@mail.gmail.com>
	<CAHNn8BWLU=ggRrwh-U1Tv1VRf1b_2qZfTiP46Jfkr1Z26HpFOQ@mail.gmail.com>
	<4FD66B0F.2060405@googlemail.com>
	<CAHNn8BWAQwwjCt=DoO8exczW4z-aN3PAEU=gx4aU8kbSENXq5Q@mail.gmail.com>
	<CAH4pYpSFKz3g9mkQLRgOaF8zcXkEsxpMkqXjhOYkmtHrFaYYnQ@mail.gmail.com>
	<CAK5FAtFYFLMdHVfQ6Xy66kBxZg5Fgv+UQsgycjQNqzfRPkJc_w@mail.gmail.com>
	<CAHAreOoRwdXkW=vmxqZ71zEGbfdgS6GR6WKKsNEP9onZajyUAw@mail.gmail.com>
	<CAHNn8BURt7QiUFSJ8gdOUpYqJzhH3GJso5cfOcLLjHooz-qaWA@mail.gmail.com>
Message-ID: <CAHAreOpaJ8JdXZQn8RavF7z880c6CSGSZ9kSVqQjr_zehBj2uQ@mail.gmail.com>

i, Jun 15, 2012 at 3:16 PM, MinRK <benjaminrk at gmail.com> wrote:
> Except that we would have to *build* for every commit to check, and hope
> that the build tools also didn't change the output. ?This is the whole
> source of the problem - shipping minified js is equivalent to shipping a
> dll.
>
> I think the first sensible approach would be to test a current checkout, and
> see if it works.

Argh. Getting bumped off the distros doesn't sound great either...  What a drag.


From benjaminrk at gmail.com  Fri Jun 15 19:14:49 2012
From: benjaminrk at gmail.com (MinRK)
Date: Fri, 15 Jun 2012 16:14:49 -0700
Subject: [IPython-dev] Let's get 0.13 released...
In-Reply-To: <CAHAreOpaJ8JdXZQn8RavF7z880c6CSGSZ9kSVqQjr_zehBj2uQ@mail.gmail.com>
References: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
	<4FD61F6C.3080709@googlemail.com>
	<CAHAreOprJ9qwqJcrw1mesHu2kXYYw_x_dEod91DA4mYTYXDsHA@mail.gmail.com>
	<CAHNn8BWLU=ggRrwh-U1Tv1VRf1b_2qZfTiP46Jfkr1Z26HpFOQ@mail.gmail.com>
	<4FD66B0F.2060405@googlemail.com>
	<CAHNn8BWAQwwjCt=DoO8exczW4z-aN3PAEU=gx4aU8kbSENXq5Q@mail.gmail.com>
	<CAH4pYpSFKz3g9mkQLRgOaF8zcXkEsxpMkqXjhOYkmtHrFaYYnQ@mail.gmail.com>
	<CAK5FAtFYFLMdHVfQ6Xy66kBxZg5Fgv+UQsgycjQNqzfRPkJc_w@mail.gmail.com>
	<CAHAreOoRwdXkW=vmxqZ71zEGbfdgS6GR6WKKsNEP9onZajyUAw@mail.gmail.com>
	<CAHNn8BURt7QiUFSJ8gdOUpYqJzhH3GJso5cfOcLLjHooz-qaWA@mail.gmail.com>
	<CAHAreOpaJ8JdXZQn8RavF7z880c6CSGSZ9kSVqQjr_zehBj2uQ@mail.gmail.com>
Message-ID: <CAHNn8BVXU2wx4an6vgeaOZSmwPKyxj5M_cmYyOJ2kObo+aBgQg@mail.gmail.com>

On Fri, Jun 15, 2012 at 3:25 PM, Fernando Perez <fperez.net at gmail.com>wrote:

> i, Jun 15, 2012 at 3:16 PM, MinRK <benjaminrk at gmail.com> wrote:
> > Except that we would have to *build* for every commit to check, and hope
> > that the build tools also didn't change the output.  This is the whole
> > source of the problem - shipping minified js is equivalent to shipping a
> > dll.
> >
> > I think the first sensible approach would be to test a current checkout,
> and
> > see if it works.
>

I checked out master, and it's pretty borked (just had a huge merge from
upstream).

So I did a git log on ui/jquery.ui.menubar.js, and lucky for us, there has
only been one commit on *that file* since Brian brought in dev jquery-ui.

I did a build, and lo and behold, md5 checksums on jquery-ui.min.{js|css}
match.

We are using ba8f147<https://github.com/jquery/jquery-ui/tree/ba8f147e4d69948aff4e956333098fb9360e3865>.
 I will add a note to the minified readme so we don't have to do this again.

-MinRK




>
> Argh. Getting bumped off the distros doesn't sound great either...  What a
> drag.
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120615/7f3e7ba3/attachment.html>

From benjaminrk at gmail.com  Fri Jun 15 19:26:43 2012
From: benjaminrk at gmail.com (MinRK)
Date: Fri, 15 Jun 2012 16:26:43 -0700
Subject: [IPython-dev] Let's get 0.13 released...
In-Reply-To: <CAHNn8BVXU2wx4an6vgeaOZSmwPKyxj5M_cmYyOJ2kObo+aBgQg@mail.gmail.com>
References: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
	<4FD61F6C.3080709@googlemail.com>
	<CAHAreOprJ9qwqJcrw1mesHu2kXYYw_x_dEod91DA4mYTYXDsHA@mail.gmail.com>
	<CAHNn8BWLU=ggRrwh-U1Tv1VRf1b_2qZfTiP46Jfkr1Z26HpFOQ@mail.gmail.com>
	<4FD66B0F.2060405@googlemail.com>
	<CAHNn8BWAQwwjCt=DoO8exczW4z-aN3PAEU=gx4aU8kbSENXq5Q@mail.gmail.com>
	<CAH4pYpSFKz3g9mkQLRgOaF8zcXkEsxpMkqXjhOYkmtHrFaYYnQ@mail.gmail.com>
	<CAK5FAtFYFLMdHVfQ6Xy66kBxZg5Fgv+UQsgycjQNqzfRPkJc_w@mail.gmail.com>
	<CAHAreOoRwdXkW=vmxqZ71zEGbfdgS6GR6WKKsNEP9onZajyUAw@mail.gmail.com>
	<CAHNn8BURt7QiUFSJ8gdOUpYqJzhH3GJso5cfOcLLjHooz-qaWA@mail.gmail.com>
	<CAHAreOpaJ8JdXZQn8RavF7z880c6CSGSZ9kSVqQjr_zehBj2uQ@mail.gmail.com>
	<CAHNn8BVXU2wx4an6vgeaOZSmwPKyxj5M_cmYyOJ2kObo+aBgQg@mail.gmail.com>
Message-ID: <CAHNn8BV96Zt423y82JPDaDATA4ZS3QfCSsydD0GLQZ=ZqokSRA@mail.gmail.com>

On Fri, Jun 15, 2012 at 4:14 PM, MinRK <benjaminrk at gmail.com> wrote:

>
>
> On Fri, Jun 15, 2012 at 3:25 PM, Fernando Perez <fperez.net at gmail.com>wrote:
>
>> i, Jun 15, 2012 at 3:16 PM, MinRK <benjaminrk at gmail.com> wrote:
>> > Except that we would have to *build* for every commit to check, and hope
>> > that the build tools also didn't change the output.  This is the whole
>> > source of the problem - shipping minified js is equivalent to shipping a
>> > dll.
>> >
>> > I think the first sensible approach would be to test a current
>> checkout, and
>> > see if it works.
>>
>
> I checked out master, and it's pretty borked (just had a huge merge from
> upstream).
>
> So I did a git log on ui/jquery.ui.menubar.js, and lucky for us, there has
> only been one commit on *that file* since Brian brought in dev jquery-ui.
>
> I did a build, and lo and behold, md5 checksums on jquery-ui.min.{js|css}
> match.
>
> We are using ba8f147<https://github.com/jquery/jquery-ui/tree/ba8f147e4d69948aff4e956333098fb9360e3865>.
>  I will add a note to the minified readme so we don't have to do this again.
>

crisis averted<https://github.com/ipython/ipython/commit/38cb32de5fe807fd1e2a3581f9e80e4e6192b7d7>

Hopefully they will release someday, and we can go back to using a stable
version.

-MinRK


>
> -MinRK
>
>
>
>
>>
>> Argh. Getting bumped off the distros doesn't sound great either...  What
>> a drag.
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120615/2b8a7346/attachment.html>

From fperez.net at gmail.com  Fri Jun 15 19:40:17 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 15 Jun 2012 16:40:17 -0700
Subject: [IPython-dev] Let's get 0.13 released...
In-Reply-To: <CAHNn8BV96Zt423y82JPDaDATA4ZS3QfCSsydD0GLQZ=ZqokSRA@mail.gmail.com>
References: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
	<4FD61F6C.3080709@googlemail.com>
	<CAHAreOprJ9qwqJcrw1mesHu2kXYYw_x_dEod91DA4mYTYXDsHA@mail.gmail.com>
	<CAHNn8BWLU=ggRrwh-U1Tv1VRf1b_2qZfTiP46Jfkr1Z26HpFOQ@mail.gmail.com>
	<4FD66B0F.2060405@googlemail.com>
	<CAHNn8BWAQwwjCt=DoO8exczW4z-aN3PAEU=gx4aU8kbSENXq5Q@mail.gmail.com>
	<CAH4pYpSFKz3g9mkQLRgOaF8zcXkEsxpMkqXjhOYkmtHrFaYYnQ@mail.gmail.com>
	<CAK5FAtFYFLMdHVfQ6Xy66kBxZg5Fgv+UQsgycjQNqzfRPkJc_w@mail.gmail.com>
	<CAHAreOoRwdXkW=vmxqZ71zEGbfdgS6GR6WKKsNEP9onZajyUAw@mail.gmail.com>
	<CAHNn8BURt7QiUFSJ8gdOUpYqJzhH3GJso5cfOcLLjHooz-qaWA@mail.gmail.com>
	<CAHAreOpaJ8JdXZQn8RavF7z880c6CSGSZ9kSVqQjr_zehBj2uQ@mail.gmail.com>
	<CAHNn8BVXU2wx4an6vgeaOZSmwPKyxj5M_cmYyOJ2kObo+aBgQg@mail.gmail.com>
	<CAHNn8BV96Zt423y82JPDaDATA4ZS3QfCSsydD0GLQZ=ZqokSRA@mail.gmail.com>
Message-ID: <CAHAreOp1F5bJ72cyC6fLFMNRuidEbCfPu1oHyRz=oJq5LxYd2w@mail.gmail.com>

On Fri, Jun 15, 2012 at 4:26 PM, MinRK <benjaminrk at gmail.com> wrote:
> crisis averted
>
> Hopefully they will release someday, and we can go back to using a stable
> version.

Fantastic job, thanks so much!!!


From benjaminrk at gmail.com  Fri Jun 15 19:59:50 2012
From: benjaminrk at gmail.com (MinRK)
Date: Fri, 15 Jun 2012 16:59:50 -0700
Subject: [IPython-dev] Let's get 0.13 released...
In-Reply-To: <CAHAreOp1F5bJ72cyC6fLFMNRuidEbCfPu1oHyRz=oJq5LxYd2w@mail.gmail.com>
References: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
	<4FD61F6C.3080709@googlemail.com>
	<CAHAreOprJ9qwqJcrw1mesHu2kXYYw_x_dEod91DA4mYTYXDsHA@mail.gmail.com>
	<CAHNn8BWLU=ggRrwh-U1Tv1VRf1b_2qZfTiP46Jfkr1Z26HpFOQ@mail.gmail.com>
	<4FD66B0F.2060405@googlemail.com>
	<CAHNn8BWAQwwjCt=DoO8exczW4z-aN3PAEU=gx4aU8kbSENXq5Q@mail.gmail.com>
	<CAH4pYpSFKz3g9mkQLRgOaF8zcXkEsxpMkqXjhOYkmtHrFaYYnQ@mail.gmail.com>
	<CAK5FAtFYFLMdHVfQ6Xy66kBxZg5Fgv+UQsgycjQNqzfRPkJc_w@mail.gmail.com>
	<CAHAreOoRwdXkW=vmxqZ71zEGbfdgS6GR6WKKsNEP9onZajyUAw@mail.gmail.com>
	<CAHNn8BURt7QiUFSJ8gdOUpYqJzhH3GJso5cfOcLLjHooz-qaWA@mail.gmail.com>
	<CAHAreOpaJ8JdXZQn8RavF7z880c6CSGSZ9kSVqQjr_zehBj2uQ@mail.gmail.com>
	<CAHNn8BVXU2wx4an6vgeaOZSmwPKyxj5M_cmYyOJ2kObo+aBgQg@mail.gmail.com>
	<CAHNn8BV96Zt423y82JPDaDATA4ZS3QfCSsydD0GLQZ=ZqokSRA@mail.gmail.com>
	<CAHAreOp1F5bJ72cyC6fLFMNRuidEbCfPu1oHyRz=oJq5LxYd2w@mail.gmail.com>
Message-ID: <CAHNn8BVc+PUd=4y+bfcQ8E87JKB5HFtNm3hFtE-jscKVkzVvLw@mail.gmail.com>

So currently outstanding PRs that I think should be criteria for a beta:

Cell metadata (1934) - ready I think, awaiting sign-off from Brian,
nbformat overlord.
Scrolled output (1825) - similarly pending review from notebook aesthetics
authorities.
Whichever QtConsole completion fix we choose (1972 or 1944)

So if those can be reviewed or officially postponed, I think we can go
ahead with cutting the beta.

Little fixes I would like to see, but I don't think need to block the beta:

1970 - dblclick to restore zero-resize on images
1951 - minor changes to notebook/kernel startup
1964 - remove class-singleton assumption on Magics

More:

1715 (unicode tracebacks) seems important, but I don't have a great grasp
on its status
1891 (virtualenv cell magic) has not yet addressed review comments.


On Fri, Jun 15, 2012 at 4:40 PM, Fernando Perez <fperez.net at gmail.com>wrote:

> On Fri, Jun 15, 2012 at 4:26 PM, MinRK <benjaminrk at gmail.com> wrote:
> > crisis averted
> >
> > Hopefully they will release someday, and we can go back to using a stable
> > version.
>
> Fantastic job, thanks so much!!!
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120615/b5f76d08/attachment.html>

From fperez.net at gmail.com  Fri Jun 15 20:02:12 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 15 Jun 2012 17:02:12 -0700
Subject: [IPython-dev] Namespace pollution and a kernel panel
In-Reply-To: <20120615203135.GA6159@mcelrath.org>
References: <20120615203135.GA6159@mcelrath.org>
Message-ID: <CAHAreOpDCThE41Zw5CVEKSiM6JPxJUB1rahbO6s6jEtFY+LaNg@mail.gmail.com>

On Fri, Jun 15, 2012 at 1:31 PM, Bob McElrath <bob+ipython at mcelrath.org> wrote:
> This is because I ran ipython --pylab, but it highlights a bigger problem: how
> does the user know which symbols are defined?

This is slightly orthogonal to the rest of the discussion, but you can
configure ipython to *not* do 'from numpy import *' when --pylab is
given, and to only provide the names 'numpy, matplotlib, pyplot, np,
plt' in your namespace and nothing else.  That gives you the plotting
support (including backend integration and gui/inline support),
without any further pollution of the namespace.


From fperez.net at gmail.com  Fri Jun 15 20:05:11 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 15 Jun 2012 17:05:11 -0700
Subject: [IPython-dev] Let's get 0.13 released...
In-Reply-To: <CAHNn8BVc+PUd=4y+bfcQ8E87JKB5HFtNm3hFtE-jscKVkzVvLw@mail.gmail.com>
References: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
	<4FD61F6C.3080709@googlemail.com>
	<CAHAreOprJ9qwqJcrw1mesHu2kXYYw_x_dEod91DA4mYTYXDsHA@mail.gmail.com>
	<CAHNn8BWLU=ggRrwh-U1Tv1VRf1b_2qZfTiP46Jfkr1Z26HpFOQ@mail.gmail.com>
	<4FD66B0F.2060405@googlemail.com>
	<CAHNn8BWAQwwjCt=DoO8exczW4z-aN3PAEU=gx4aU8kbSENXq5Q@mail.gmail.com>
	<CAH4pYpSFKz3g9mkQLRgOaF8zcXkEsxpMkqXjhOYkmtHrFaYYnQ@mail.gmail.com>
	<CAK5FAtFYFLMdHVfQ6Xy66kBxZg5Fgv+UQsgycjQNqzfRPkJc_w@mail.gmail.com>
	<CAHAreOoRwdXkW=vmxqZ71zEGbfdgS6GR6WKKsNEP9onZajyUAw@mail.gmail.com>
	<CAHNn8BURt7QiUFSJ8gdOUpYqJzhH3GJso5cfOcLLjHooz-qaWA@mail.gmail.com>
	<CAHAreOpaJ8JdXZQn8RavF7z880c6CSGSZ9kSVqQjr_zehBj2uQ@mail.gmail.com>
	<CAHNn8BVXU2wx4an6vgeaOZSmwPKyxj5M_cmYyOJ2kObo+aBgQg@mail.gmail.com>
	<CAHNn8BV96Zt423y82JPDaDATA4ZS3QfCSsydD0GLQZ=ZqokSRA@mail.gmail.com>
	<CAHAreOp1F5bJ72cyC6fLFMNRuidEbCfPu1oHyRz=oJq5LxYd2w@mail.gmail.com>
	<CAHNn8BVc+PUd=4y+bfcQ8E87JKB5HFtNm3hFtE-jscKVkzVvLw@mail.gmail.com>
Message-ID: <CAHAreOoOfC=hXAK2_s_yyr6K0VtSzygbKekYYdvCb7BTcHwK1w@mail.gmail.com>

On Fri, Jun 15, 2012 at 4:59 PM, MinRK <benjaminrk at gmail.com> wrote:
> So currently outstanding PRs that I think should be criteria for a beta:
>

Awesome, thanks for the status!  It seems like whenever we say 'beta
coming, no more new stuff' that's actually code for 'quick, everyone
submit PRs' ;)

But truth be told, we've gotten a ton of 'spit and polish' fixes and
improvements that will indeed make 0.13 a much more solid release, so
I'm not complaining.  And thanks everyone for pitching in so much work
to keep the review queue moving...

Cheers,

f


From bob+ipython at mcelrath.org  Fri Jun 15 20:24:09 2012
From: bob+ipython at mcelrath.org (Bob McElrath)
Date: Sat, 16 Jun 2012 00:24:09 +0000
Subject: [IPython-dev] Namespace pollution and a kernel panel
In-Reply-To: <CAHAreOpDCThE41Zw5CVEKSiM6JPxJUB1rahbO6s6jEtFY+LaNg@mail.gmail.com>
References: <20120615203135.GA6159@mcelrath.org>
	<CAHAreOpDCThE41Zw5CVEKSiM6JPxJUB1rahbO6s6jEtFY+LaNg@mail.gmail.com>
Message-ID: <20120616002409.GE6159@mcelrath.org>

Dumb question...but how?

In any case I'm going to stop using --pylab, and use '%pylab inline' instead.
The former makes the notebook not standalone -- it's dependent on whomever I
send it to knowing to start ipython with the --pylab option.

Fernando Perez [fperez.net at gmail.com] wrote:
> On Fri, Jun 15, 2012 at 1:31 PM, Bob McElrath <bob+ipython at mcelrath.org> wrote:
> > This is because I ran ipython --pylab, but it highlights a bigger problem: how
> > does the user know which symbols are defined?
> 
> This is slightly orthogonal to the rest of the discussion, but you can
> configure ipython to *not* do 'from numpy import *' when --pylab is
> given, and to only provide the names 'numpy, matplotlib, pyplot, np,
> plt' in your namespace and nothing else.  That gives you the plotting
> support (including backend integration and gui/inline support),
> without any further pollution of the namespace.
--
Cheers, Bob McElrath

"The individual has always had to struggle to keep from being overwhelmed by
the tribe.  If you try it, you will be lonely often, and sometimes frightened.
But no price is too high to pay for the privilege of owning yourself." 
    -- Friedrich Nietzsche


From fperez.net at gmail.com  Fri Jun 15 20:35:24 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 15 Jun 2012 17:35:24 -0700
Subject: [IPython-dev] Namespace pollution and a kernel panel
In-Reply-To: <20120616002409.GE6159@mcelrath.org>
References: <20120615203135.GA6159@mcelrath.org>
	<CAHAreOpDCThE41Zw5CVEKSiM6JPxJUB1rahbO6s6jEtFY+LaNg@mail.gmail.com>
	<20120616002409.GE6159@mcelrath.org>
Message-ID: <CAHAreOrn5u6iYr2WXB=JVtw3ikJEWwGckFjXw3-M3X+iCix2hQ@mail.gmail.com>

On Fri, Jun 15, 2012 at 5:24 PM, Bob McElrath <bob+ipython at mcelrath.org> wrote:
> Dumb question...but how?

I'm away from a machine I can test on right now, but if I recall
correctly, you can put in your config

c.InteractiveShellApp.pylab_import_all = False

> In any case I'm going to stop using --pylab, and use '%pylab inline' instead.
> The former makes the notebook not standalone -- it's dependent on whomever I
> send it to knowing to start ipython with the --pylab option.

Still, the above flag isn't exposed in the %pylab magic (which could
be considered an issue), so you still may want to set the flag, so
%pylab doesn't do the 'import all' dance.

Cheers,

f


From benjaminrk at gmail.com  Fri Jun 15 21:29:28 2012
From: benjaminrk at gmail.com (MinRK)
Date: Fri, 15 Jun 2012 18:29:28 -0700
Subject: [IPython-dev] Let's get 0.13 released...
In-Reply-To: <CAHAreOoOfC=hXAK2_s_yyr6K0VtSzygbKekYYdvCb7BTcHwK1w@mail.gmail.com>
References: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
	<4FD61F6C.3080709@googlemail.com>
	<CAHAreOprJ9qwqJcrw1mesHu2kXYYw_x_dEod91DA4mYTYXDsHA@mail.gmail.com>
	<CAHNn8BWLU=ggRrwh-U1Tv1VRf1b_2qZfTiP46Jfkr1Z26HpFOQ@mail.gmail.com>
	<4FD66B0F.2060405@googlemail.com>
	<CAHNn8BWAQwwjCt=DoO8exczW4z-aN3PAEU=gx4aU8kbSENXq5Q@mail.gmail.com>
	<CAH4pYpSFKz3g9mkQLRgOaF8zcXkEsxpMkqXjhOYkmtHrFaYYnQ@mail.gmail.com>
	<CAK5FAtFYFLMdHVfQ6Xy66kBxZg5Fgv+UQsgycjQNqzfRPkJc_w@mail.gmail.com>
	<CAHAreOoRwdXkW=vmxqZ71zEGbfdgS6GR6WKKsNEP9onZajyUAw@mail.gmail.com>
	<CAHNn8BURt7QiUFSJ8gdOUpYqJzhH3GJso5cfOcLLjHooz-qaWA@mail.gmail.com>
	<CAHAreOpaJ8JdXZQn8RavF7z880c6CSGSZ9kSVqQjr_zehBj2uQ@mail.gmail.com>
	<CAHNn8BVXU2wx4an6vgeaOZSmwPKyxj5M_cmYyOJ2kObo+aBgQg@mail.gmail.com>
	<CAHNn8BV96Zt423y82JPDaDATA4ZS3QfCSsydD0GLQZ=ZqokSRA@mail.gmail.com>
	<CAHAreOp1F5bJ72cyC6fLFMNRuidEbCfPu1oHyRz=oJq5LxYd2w@mail.gmail.com>
	<CAHNn8BVc+PUd=4y+bfcQ8E87JKB5HFtNm3hFtE-jscKVkzVvLw@mail.gmail.com>
	<CAHAreOoOfC=hXAK2_s_yyr6K0VtSzygbKekYYdvCb7BTcHwK1w@mail.gmail.com>
Message-ID: <CAHNn8BXnjL17JCQ4EHOdw_cq08oiWSq97yBaHnSacxB_zab9dw@mail.gmail.com>

On Fri, Jun 15, 2012 at 5:05 PM, Fernando Perez <fperez.net at gmail.com>wrote:

> On Fri, Jun 15, 2012 at 4:59 PM, MinRK <benjaminrk at gmail.com> wrote:
> > So currently outstanding PRs that I think should be criteria for a beta:
> >
>
> Awesome, thanks for the status!  It seems like whenever we say 'beta
> coming, no more new stuff' that's actually code for 'quick, everyone
> submit PRs' ;)
>

> But truth be told, we've gotten a ton of 'spit and polish' fixes and
> improvements that will indeed make 0.13 a much more solid release, so
> I'm not complaining.  And thanks everyone for pitching in so much work
> to keep the review queue moving...
>

Yes, it especially provides motivation to finally push through all those
little niggles that I don't want to get in a real release, as well as
systematically address the prio-high/blocker issues.


>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120615/ee731253/attachment.html>

From benjaminrk at gmail.com  Fri Jun 15 21:32:18 2012
From: benjaminrk at gmail.com (MinRK)
Date: Fri, 15 Jun 2012 18:32:18 -0700
Subject: [IPython-dev] Namespace pollution and a kernel panel
In-Reply-To: <20120616002409.GE6159@mcelrath.org>
References: <20120615203135.GA6159@mcelrath.org>
	<CAHAreOpDCThE41Zw5CVEKSiM6JPxJUB1rahbO6s6jEtFY+LaNg@mail.gmail.com>
	<20120616002409.GE6159@mcelrath.org>
Message-ID: <CAHNn8BXcBkJNbOZZA1QyhfZWub2yk4FKWVswd+=wCzRza0Hm8A@mail.gmail.com>

On Fri, Jun 15, 2012 at 5:24 PM, Bob McElrath <bob+ipython at mcelrath.org>wrote:

> Dumb question...but how?
>
> In any case I'm going to stop using --pylab, and use '%pylab inline'
> instead.
> The former makes the notebook not standalone -- it's dependent on whomever
> I
> send it to knowing to start ipython with the --pylab option.
>

Yes, this was an artifact of the fact that the %pylab magic didn't
initially work in the kernel, which has since been fixed.

Among other things, PR 1954
<https://github.com/ipython/ipython/pull/1954> removes
any recommendation for starting with `--pylab` from the example notebooks,
because it's really not the best way to do it.


>
> Fernando Perez [fperez.net at gmail.com] wrote:
> > On Fri, Jun 15, 2012 at 1:31 PM, Bob McElrath <bob+ipython at mcelrath.org>
> wrote:
> > > This is because I ran ipython --pylab, but it highlights a bigger
> problem: how
> > > does the user know which symbols are defined?
> >
> > This is slightly orthogonal to the rest of the discussion, but you can
> > configure ipython to *not* do 'from numpy import *' when --pylab is
> > given, and to only provide the names 'numpy, matplotlib, pyplot, np,
> > plt' in your namespace and nothing else.  That gives you the plotting
> > support (including backend integration and gui/inline support),
> > without any further pollution of the namespace.
> --
> Cheers, Bob McElrath
>
> "The individual has always had to struggle to keep from being overwhelmed
> by
> the tribe.  If you try it, you will be lonely often, and sometimes
> frightened.
> But no price is too high to pay for the privilege of owning yourself."
>    -- Friedrich Nietzsche
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120615/ea3f1eae/attachment.html>

From pivanov314 at gmail.com  Sat Jun 16 02:17:30 2012
From: pivanov314 at gmail.com (Paul Ivanov)
Date: Fri, 15 Jun 2012 23:17:30 -0700
Subject: [IPython-dev] Let's get 0.13 released...
In-Reply-To: <CAHNn8BVc+PUd=4y+bfcQ8E87JKB5HFtNm3hFtE-jscKVkzVvLw@mail.gmail.com>
References: <CAHAreOpjERfL03nVJzx313HjJR=VCrgGh-2te4UJ7AmFiccH9Q@mail.gmail.com>
	<4FD61F6C.3080709@googlemail.com>
	<CAHAreOprJ9qwqJcrw1mesHu2kXYYw_x_dEod91DA4mYTYXDsHA@mail.gmail.com>
	<CAHNn8BWLU=ggRrwh-U1Tv1VRf1b_2qZfTiP46Jfkr1Z26HpFOQ@mail.gmail.com>
	<4FD66B0F.2060405@googlemail.com>
	<CAHNn8BWAQwwjCt=DoO8exczW4z-aN3PAEU=gx4aU8kbSENXq5Q@mail.gmail.com>
	<CAH4pYpSFKz3g9mkQLRgOaF8zcXkEsxpMkqXjhOYkmtHrFaYYnQ@mail.gmail.com>
	<CAK5FAtFYFLMdHVfQ6Xy66kBxZg5Fgv+UQsgycjQNqzfRPkJc_w@mail.gmail.com>
	<CAHAreOoRwdXkW=vmxqZ71zEGbfdgS6GR6WKKsNEP9onZajyUAw@mail.gmail.com>
	<CAHNn8BURt7QiUFSJ8gdOUpYqJzhH3GJso5cfOcLLjHooz-qaWA@mail.gmail.com>
	<CAHAreOpaJ8JdXZQn8RavF7z880c6CSGSZ9kSVqQjr_zehBj2uQ@mail.gmail.com>
	<CAHNn8BVXU2wx4an6vgeaOZSmwPKyxj5M_cmYyOJ2kObo+aBgQg@mail.gmail.com>
	<CAHNn8BV96Zt423y82JPDaDATA4ZS3QfCSsydD0GLQZ=ZqokSRA@mail.gmail.com>
	<CAHAreOp1F5bJ72cyC6fLFMNRuidEbCfPu1oHyRz=oJq5LxYd2w@mail.gmail.com>
	<CAHNn8BVc+PUd=4y+bfcQ8E87JKB5HFtNm3hFtE-jscKVkzVvLw@mail.gmail.com>
Message-ID: <CAKCGbV4qXq4qeYWDfpz2kAJttBfHH9XBRBAPfMu4NWKmjNrb+g@mail.gmail.com>

On Fri, Jun 15, 2012 at 4:59 PM, MinRK <benjaminrk at gmail.com> wrote:
> So currently outstanding PRs that I think should be criteria for a beta:

Can I ask for this one to be added to the list?
1746  Confirm restart (configuration option, and checkbox UI)

It's ready and now consistently represents the state of the currently
active tab.


From ellisonbg at gmail.com  Sat Jun 16 03:13:55 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Sat, 16 Jun 2012 00:13:55 -0700
Subject: [IPython-dev] Namespace pollution and a kernel panel
In-Reply-To: <20120615203135.GA6159@mcelrath.org>
References: <20120615203135.GA6159@mcelrath.org>
Message-ID: <CAH4pYpTFVDQGu4541-qXPN7SYPS2y9haJr79X=F0O3z20aAQBA@mail.gmail.com>

I do think we want to think more about a namespace browser.  I can
also imagine that there would also be other "widgets" like this that
we would want to have.  Some questions related to this:

* Do we want these to be welded into the notebook or do we want such
widgets to simply be regular python libraries that 2rd parties can
develop and plug into the notebook?
* Where would be put these.  One obvious choice is to use a left
panel.  I am not thrilled about this, but don't have any better ideas.


On Fri, Jun 15, 2012 at 1:31 PM, Bob McElrath <bob+ipython at mcelrath.org> wrote:
> One of my long-standing complaints about notebook-style worksheets (Maple,
> Mathematica) is the large and hidden namespace of defined symbols. ?If one is
> not careful, it's easy to end up with some element of worksheet-state that is
> not what you think it is, and end up with garbage results. ?This can be very
> difficult to track down. ?And because worksheets are generally not executed top
> to bottom, it often results in difficult-to-reproduce errors.
>
> I discovered this today with IPython's notebook and gamma(), which turns out to
> be numpy.random.gamma() rather than the Euler Gamma function math.gamma() or
> scipy.special.gamma().
>
> This is because I ran ipython --pylab, but it highlights a bigger problem: how
> does the user know which symbols are defined? ?I have been thinking lately of an
> addition to the notebook interface: a side-panel showing everything
> defined/imported in the kernel. ?This would further allow the user to inspect
> the output of commands by clicking on kernel data structures, rather than
> wasting a cell just to print some output. ?Personally I always end up with very
> messy worksheets, because I insert a lot of print or plot commands, just to
> explore a data structure or function.
>
> Another possible use of such a thing would be a non-modifying cell: a cell that
> refuses to change the state of the kernel by modifying variables, but could be
> used to print/plot/explore existing data structures. ?Then when one has found
> the most desirable representation, that could be copied/moved to the worksheet.
>
> Perhaps there are other creative ways to avoid the user having to manage an
> approximation of the kernel state in their head.
>
> --
> Cheers, Bob McElrath
>
> "The individual has always had to struggle to keep from being overwhelmed by
> the tribe. ?If you try it, you will be lonely often, and sometimes frightened.
> But no price is too high to pay for the privilege of owning yourself."
> ? ?-- Friedrich Nietzsche
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



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


From kent.inverarity at adelaide.edu.au  Sun Jun 17 21:39:27 2012
From: kent.inverarity at adelaide.edu.au (Kent Inverarity)
Date: Mon, 18 Jun 2012 11:09:27 +0930
Subject: [IPython-dev] Notebook names truncating at the first period
In-Reply-To: <CAPy5eYzSimUAvJ_=Dc16QRpK2opU1EZCncti0HirNybEP-GvaA@mail.gmail.com>
References: <CAPy5eYzSimUAvJ_=Dc16QRpK2opU1EZCncti0HirNybEP-GvaA@mail.gmail.com>
Message-ID: <CAPy5eYzm0TTA=eD1mPXB-XoV-_L_nmZAATcOgm3Pke+hpsqcTQ@mail.gmail.com>

Hi all

There is a bug in the notebook where the notebook name is truncated at
the first period in the filename when you open it -- and subsequently
renamed when you save it. If you are using a period near the start of
your filenames, this is annoying because you lose whatever the rest of
the filename is as soon as you hit Ctrl+S.

Presumably a better behaviour would be to truncate at the last period
in the filename? I've attached a git patch file which does this.

I didn't open an issue or PR in Github, as I'm not sure which is the
best place to bring this sort of thing up.

Cheers

Kent

--
--
Kent Inverarity


--
--
Kent Inverarity
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-nb-name-truncating-at-first-period-in-filename.patch
Type: application/octet-stream
Size: 1071 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120618/0d35a75b/attachment.obj>

From benjaminrk at gmail.com  Sun Jun 17 22:18:50 2012
From: benjaminrk at gmail.com (MinRK)
Date: Sun, 17 Jun 2012 19:18:50 -0700
Subject: [IPython-dev] Notebook names truncating at the first period
In-Reply-To: <CAPy5eYzm0TTA=eD1mPXB-XoV-_L_nmZAATcOgm3Pke+hpsqcTQ@mail.gmail.com>
References: <CAPy5eYzSimUAvJ_=Dc16QRpK2opU1EZCncti0HirNybEP-GvaA@mail.gmail.com>
	<CAPy5eYzm0TTA=eD1mPXB-XoV-_L_nmZAATcOgm3Pke+hpsqcTQ@mail.gmail.com>
Message-ID: <CAHNn8BXZY-48_sSLSjvivx1mWxsYP-K84Ne9-ocG+keNnOGxjw@mail.gmail.com>

On Sun, Jun 17, 2012 at 6:39 PM, Kent Inverarity <
kent.inverarity at adelaide.edu.au> wrote:

> Hi all
>
> There is a bug in the notebook where the notebook name is truncated at
> the first period in the filename when you open it -- and subsequently
> renamed when you save it. If you are using a period near the start of
> your filenames, this is annoying because you lose whatever the rest of
> the filename is as soon as you hit Ctrl+S.
>
> Presumably a better behaviour would be to truncate at the last period
> in the filename? I've attached a git patch file which does this.
>
> I didn't open an issue or PR in Github, as I'm not sure which is the
> best place to bring this sort of thing up.
>

The best place is a PR if you have a fix.  Though neither the code we have
nor your patch is precisely correct.

It should be:

name = os.path.splitext(os.path.basename(path))[0]

If you want to do a PR with that change, please do, or I can push if you
don't want to.


>
> Cheers
>
> Kent
>
> --
> --
> Kent Inverarity
>
>
> --
> --
> Kent Inverarity
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120617/ac54fed3/attachment.html>

From kent.inverarity at adelaide.edu.au  Sun Jun 17 22:28:50 2012
From: kent.inverarity at adelaide.edu.au (Kent Inverarity)
Date: Mon, 18 Jun 2012 11:58:50 +0930
Subject: [IPython-dev] Notebook names truncating at the first period
In-Reply-To: <CAHNn8BXZY-48_sSLSjvivx1mWxsYP-K84Ne9-ocG+keNnOGxjw@mail.gmail.com>
References: <CAPy5eYzSimUAvJ_=Dc16QRpK2opU1EZCncti0HirNybEP-GvaA@mail.gmail.com>
	<CAPy5eYzm0TTA=eD1mPXB-XoV-_L_nmZAATcOgm3Pke+hpsqcTQ@mail.gmail.com>
	<CAHNn8BXZY-48_sSLSjvivx1mWxsYP-K84Ne9-ocG+keNnOGxjw@mail.gmail.com>
Message-ID: <CAPy5eYxHi=qFEnj6FtcMuP=L2BAzSonbuJv6Eth3v6d8F=sVaw@mail.gmail.com>

OK, thanks for the tip. I'll put it in a PR.

Cheers
On Jun 18, 2012 11:49 AM, "MinRK" <benjaminrk at gmail.com> wrote:

>
>
> On Sun, Jun 17, 2012 at 6:39 PM, Kent Inverarity <
> kent.inverarity at adelaide.edu.au> wrote:
>
>> Hi all
>>
>> There is a bug in the notebook where the notebook name is truncated at
>> the first period in the filename when you open it -- and subsequently
>> renamed when you save it. If you are using a period near the start of
>> your filenames, this is annoying because you lose whatever the rest of
>> the filename is as soon as you hit Ctrl+S.
>>
>> Presumably a better behaviour would be to truncate at the last period
>> in the filename? I've attached a git patch file which does this.
>>
>> I didn't open an issue or PR in Github, as I'm not sure which is the
>> best place to bring this sort of thing up.
>>
>
> The best place is a PR if you have a fix.  Though neither the code we have
> nor your patch is precisely correct.
>
> It should be:
>
> name = os.path.splitext(os.path.basename(path))[0]
>
> If you want to do a PR with that change, please do, or I can push if you
> don't want to.
>
>
>>
>> Cheers
>>
>> Kent
>>
>> --
>> --
>> Kent Inverarity
>>
>>
>> --
>> --
>> Kent Inverarity
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120618/d055afd0/attachment.html>

From fperez.net at gmail.com  Sun Jun 17 23:05:57 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 17 Jun 2012 20:05:57 -0700
Subject: [IPython-dev] Detailed feedback from Titus Brown on the notebook in
	a teaching context
Message-ID: <CAHAreOrSMxVKLCg_ta81BLqjQZu2+dkDOtjtfgTRQ1NxUN1yUw@mail.gmail.com>

Hi all,

Titus wrote up a nice and detailed blog post about his experiences
teaching with the notebook in an intensive course for biologists:

http://ivory.idyll.org/blog/jun-12/teaching-with-ipynb.html

I've already replied, but I think there's useful food for thought
there, so I wanted to share it.

Cheers,

f


From fperez.net at gmail.com  Mon Jun 18 02:43:16 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 17 Jun 2012 23:43:16 -0700
Subject: [IPython-dev] IPython 0.13 first beta is ready!
Message-ID: <CAHAreOrwXz9fSNErD35V+JFzYVR7bUq5QEYhC0rwrFNza+NoSg@mail.gmail.com>

Hi folks,

we've just uploaded the first beta of the upcoming IPython 0.13 release:

http://archive.ipython.org/testing/0.13.beta1/

There are a ton of new features and improvements that we'll detail
later once we have a chance to write up some clean release notes.

For now, we'd appreciate if you let us know of any problems you
encounter with this beta; the best way to report is by filing an issue
in our tracker:

http://github.com/ipython/ipython/issues/

but we welcome feedback in any form.

If things go reasonably smoothly with this beta, we'll try to cut the
first RC by the end of next week.  We'll see how many RCs are required
based on the amount of issue reports we get, so by all means beat up
on this and let us know what breaks.

In the meantime, we'll continue fixing things up and closing open
issues in master.

Many thanks to everyone who has contributed code for this release, and
esp. to several in our core team who jumped and did double-duty over
the last few days as I was somewhat offline.

Cheers,

f

ps - for reference, the beta was cut from commit e382085c (I didn't
bother to push a formal tag to the repo).


From dlsun at stanford.edu  Tue Jun 19 02:01:26 2012
From: dlsun at stanford.edu (Dennis Sun)
Date: Mon, 18 Jun 2012 23:01:26 -0700
Subject: [IPython-dev] Why are notebooks no longer bound to cells?
Message-ID: <CADLczKDc0S0rGojOa1BgztD+XR==X2ZLHpfXGKq1kt3c8WLHRw@mail.gmail.com>

Hi all,

I just pulled the latest development version of iPython, and I noticed that
in the Javascript code, cells no longer contain a reference to the
containing notebook. I had been using this attribute in the Javascript
functions I was writing, so I was wondering: what was the reason for
removing it, and now that it's gone, what is the best way to access the
notebook object given a cell? (I had been using it in some AJAX calls where
the context was the cell rather than the notebook.)

Thanks,
Dennis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120618/9fe7b744/attachment.html>

From benjaminrk at gmail.com  Tue Jun 19 02:07:33 2012
From: benjaminrk at gmail.com (MinRK)
Date: Mon, 18 Jun 2012 23:07:33 -0700
Subject: [IPython-dev] Why are notebooks no longer bound to cells?
In-Reply-To: <CADLczKDc0S0rGojOa1BgztD+XR==X2ZLHpfXGKq1kt3c8WLHRw@mail.gmail.com>
References: <CADLczKDc0S0rGojOa1BgztD+XR==X2ZLHpfXGKq1kt3c8WLHRw@mail.gmail.com>
Message-ID: <CAHNn8BXzLZ6ucDB6BZYnY6NAw1EFiwEo9gDujeeRQLC1FuKnHQ@mail.gmail.com>

On Mon, Jun 18, 2012 at 11:01 PM, Dennis Sun <dlsun at stanford.edu> wrote:

> Hi all,
>
> I just pulled the latest development version of iPython, and I noticed
> that in the Javascript code, cells no longer contain a reference to the
> containing notebook. I had been using this attribute in the Javascript
> functions I was writing, so I was wondering: what was the reason for
> removing it, and now that it's gone, what is the best way to access the
> notebook object given a cell? (I had been using it in some AJAX calls where
> the context was the cell rather than the notebook.)
>

The JS was refactored significantly to decouple kernels/cells/notebooks,
because it should be possible to use them outside the notebook context
(e.g. single cell on an existing webpage).

-MinRK


>
> Thanks,
> Dennis
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120618/954d496b/attachment.html>

From asmeurer at gmail.com  Tue Jun 19 02:16:01 2012
From: asmeurer at gmail.com (Aaron Meurer)
Date: Tue, 19 Jun 2012 00:16:01 -0600
Subject: [IPython-dev] Better handling of older notebook versions
Message-ID: <-6334312716154408239@unknownmsgid>

Hi.

As you may know, we are planning to migrate our SymPy examples to
IPython notebooks, and, indeed, we already have some notebooks that we
intend to ship with the next release.  Currently, we have our
notebooks saved as version 2 (from IPython 0.12), since IPython 0.13
has not been released yet.

I played around with the notebook versions, and I found that a version
3 notebook doesn't work at all in IPython 0.12, regardless if it has a
header cell or not (from what I understand, this is the only new
feature in version 3).  On the other hand, a version 2 notebook is
automatically converted by IPython git master to version 3 with an
onscreen warning.

Is there any way that we could make this more friendly to users who
use our notebooks that we ship.   Currently, we have two options:

- Ship version 3 notebooks.  Previously this was not an option because
version 3 only exists in the development version, but now it is clear
that you guys will release before we do, so it's actually possible.
Even so, this may come up again in the future.  Also, if we do this,
it will obviously alienate any IPython 0.12 users.

- Ship version 2 notebooks.  If we do this, then anyone who opens the
notebook with 0.13 will see a warning that the notebook is converted,
which isn't very friendly since they are not the authors of the
notebook.   If they save the notebook, it will eliminate the warning,
but will change it from the released version.  That may not be such a
bad thing; my main concern is just the initial annoyance/confusion to
anyone who opens the notebook with the newest version of IPython.

Any thoughts on this?  Perhaps the read-only notebooks discussed in
another thread would be the solution to this.  I think something like
that would be ideal for shipped example notebooks, because it would
prevent the user from accidentally overriding them, and it might even
do a "save  as" by default instead (like a template document on the
Mac).

Aaron Meurer


From ellisonbg at gmail.com  Tue Jun 19 02:35:00 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Mon, 18 Jun 2012 23:35:00 -0700
Subject: [IPython-dev] Why are notebooks no longer bound to cells?
In-Reply-To: <CADLczKDc0S0rGojOa1BgztD+XR==X2ZLHpfXGKq1kt3c8WLHRw@mail.gmail.com>
References: <CADLczKDc0S0rGojOa1BgztD+XR==X2ZLHpfXGKq1kt3c8WLHRw@mail.gmail.com>
Message-ID: <CAH4pYpSqyEf6kiTtGdVk1KNJMd8devbck24CipErooYkaUPBmQ@mail.gmail.com>

So Min has outlined the reason for this change.  But to answer your
other part, there is only one notebook instance on a page and you can
always get to it by doing:

IPython.notebook

In your JS.

On Mon, Jun 18, 2012 at 11:01 PM, Dennis Sun <dlsun at stanford.edu> wrote:
> Hi all,
>
> I just pulled the latest development version of iPython, and I noticed that
> in the Javascript code, cells no longer contain a reference to the
> containing notebook. I had been using this attribute in the Javascript
> functions I was writing, so I was wondering: what was the reason for
> removing it, and now that it's gone, what is the best way to access the
> notebook object given a cell? (I had been using it in some AJAX calls where
> the context was the cell rather than the notebook.)
>
> Thanks,
> Dennis
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



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


From jonathan.taylor at stanford.edu  Tue Jun 19 04:18:12 2012
From: jonathan.taylor at stanford.edu (Jonathan Taylor)
Date: Tue, 19 Jun 2012 01:18:12 -0700
Subject: [IPython-dev] magics and metadata
Message-ID: <CANmCCuSwUiDtOxsNdRKDe5jJxwSP7z=r2x8jSxOGFN+ygiB-Zw@mail.gmail.com>

With the addition of cell-level metadata in cells in ipython/master it
would be nice to be able to easily add metadata to cells, say, through
a cell magic? I can't see a way that this is possible in the current
cell_magic api as the cell_magic gives you the input of the cell but not a
cell itself, i.e. not an instance of NotebookNode.

I can see there are some downsides in giving the cell_magics a NotebookNode
as the cell argument over a string:
one obvious problem is that, unconstrained, one could have a magic that
modifies "cell_type" from "code" to "markdown".
Maybe this is a bad thing, but I can imagine a case where I might want to
do that. Another obvious downside
is that users who write cell_magics have to return NotebookNode instances
(which doesn't seem too difficult).

This question might also fit into the discussion of composing or iterating
cell magics. If a cell magic returned a NotebookNode and took
a NotebookNode as its cell argument, then there is a natural way to compose
magics:

%%magic1 line1
%%magic2 line2
cell_text

would return the NotebookNode

magic1(line1, magic2(line2, cell_text))



-- 
Jonathan Taylor
Dept. of Statistics
Sequoia Hall, 137
390 Serra Mall
Stanford, CA 94305
Tel:   650.723.9230
Fax:   650.725.8977
Web: http://www-stat.stanford.edu/~jtaylo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120619/ea2837ac/attachment.html>

From jonathan.taylor at stanford.edu  Tue Jun 19 04:27:54 2012
From: jonathan.taylor at stanford.edu (Jonathan Taylor)
Date: Tue, 19 Jun 2012 01:27:54 -0700
Subject: [IPython-dev] magics and metadata
In-Reply-To: <CANmCCuSwUiDtOxsNdRKDe5jJxwSP7z=r2x8jSxOGFN+ygiB-Zw@mail.gmail.com>
References: <CANmCCuSwUiDtOxsNdRKDe5jJxwSP7z=r2x8jSxOGFN+ygiB-Zw@mail.gmail.com>
Message-ID: <CANmCCuT4kHnWYgK_wUU9mpWw+MF5UzNxaLfAaOCC31KEuxS=xA@mail.gmail.com>

>
>  Another obvious downside
> is that users who write cell_magics have to return NotebookNode instances
> (which doesn't seem too difficult).
>

I guess cell_magics would only have to return NotebookNode instances if
composition were to work.

-- 
Jonathan Taylor
Dept. of Statistics
Sequoia Hall, 137
390 Serra Mall
Stanford, CA 94305
Tel:   650.723.9230
Fax:   650.725.8977
Web: http://www-stat.stanford.edu/~jtaylo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120619/9e31484c/attachment.html>

From takowl at gmail.com  Tue Jun 19 05:48:08 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Tue, 19 Jun 2012 10:48:08 +0100
Subject: [IPython-dev] magics and metadata
In-Reply-To: <CANmCCuSwUiDtOxsNdRKDe5jJxwSP7z=r2x8jSxOGFN+ygiB-Zw@mail.gmail.com>
References: <CANmCCuSwUiDtOxsNdRKDe5jJxwSP7z=r2x8jSxOGFN+ygiB-Zw@mail.gmail.com>
Message-ID: <CAOvn4qhjOcGQJWovO0HnUov80nxEnz=PL8Z8ob6KR0OsXxJ_jg@mail.gmail.com>

On 19 June 2012 09:18, Jonathan Taylor <jonathan.taylor at stanford.edu> wrote:
> With the addition of cell-level metadata in cells in ipython/master it would
> be nice to be able to easily add metadata to cells, say, through a?cell
> magic?

I agree that there are reasons why the user might want to alter the
metadata, but I don't think cell magics are the way to do it. Cell
magics are run in the kernel, which doesn't know about the frontend.
And you can use cell magics in the qt console or the terminal, so
their API can't be notebook specific.

Thomas


From jonathan.taylor at stanford.edu  Tue Jun 19 11:08:51 2012
From: jonathan.taylor at stanford.edu (Jonathan Taylor)
Date: Tue, 19 Jun 2012 08:08:51 -0700
Subject: [IPython-dev] magics and metadata
In-Reply-To: <CAOvn4qhjOcGQJWovO0HnUov80nxEnz=PL8Z8ob6KR0OsXxJ_jg@mail.gmail.com>
References: <CANmCCuSwUiDtOxsNdRKDe5jJxwSP7z=r2x8jSxOGFN+ygiB-Zw@mail.gmail.com>
	<CAOvn4qhjOcGQJWovO0HnUov80nxEnz=PL8Z8ob6KR0OsXxJ_jg@mail.gmail.com>
Message-ID: <CANmCCuT4eb72b-9A+k1m+Qt9zovL32fESsmoE9u_2WZD6WCNTg@mail.gmail.com>

Yes, it would not be good to have the API of cell magics be notebook
specific. What about providing a reference to the current cell metadata in
the Magics class that can be used to update the NotebookNode after
executing cell.input? So, cell_magics would not have access to the metadata
on execution but could pass any metadata it wanted to back to the notebook.

This is already sort of possible if you're willing to go through the
outputs of the cell on the frontend by a hack along the lines of

metadata["type"] = "cell_metadata"
publish_display_data("cell_metadata", {"application/json":metadata)

Followed by (on the front end)

for output in cell.outputs:
    if (output.json is not None and "type" in output.json and
output.json['type'] == "cell_metadata"):
        del(output.json['type'])
        cell.metadata.update(output.json)

This will obviously have a problem if metadata had a key called "type" but
maybe its logic could be encapsulated into an "update_cell_metadata"
function?

On Tue, Jun 19, 2012 at 2:48 AM, Thomas Kluyver <takowl at gmail.com> wrote:

> On 19 June 2012 09:18, Jonathan Taylor <jonathan.taylor at stanford.edu>
> wrote:
> > With the addition of cell-level metadata in cells in ipython/master it
> would
> > be nice to be able to easily add metadata to cells, say, through a cell
> > magic?
>
> I agree that there are reasons why the user might want to alter the
> metadata, but I don't think cell magics are the way to do it. Cell
> magics are run in the kernel, which doesn't know about the frontend.
> And you can use cell magics in the qt console or the terminal, so
> their API can't be notebook specific.
>
> Thomas
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Jonathan Taylor
Dept. of Statistics
Sequoia Hall, 137
390 Serra Mall
Stanford, CA 94305
Tel:   650.723.9230
Fax:   650.725.8977
Web: http://www-stat.stanford.edu/~jtaylo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120619/4e0c2fd8/attachment.html>

From takowl at gmail.com  Tue Jun 19 11:49:03 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Tue, 19 Jun 2012 16:49:03 +0100
Subject: [IPython-dev] magics and metadata
In-Reply-To: <CANmCCuT4eb72b-9A+k1m+Qt9zovL32fESsmoE9u_2WZD6WCNTg@mail.gmail.com>
References: <CANmCCuSwUiDtOxsNdRKDe5jJxwSP7z=r2x8jSxOGFN+ygiB-Zw@mail.gmail.com>
	<CAOvn4qhjOcGQJWovO0HnUov80nxEnz=PL8Z8ob6KR0OsXxJ_jg@mail.gmail.com>
	<CANmCCuT4eb72b-9A+k1m+Qt9zovL32fESsmoE9u_2WZD6WCNTg@mail.gmail.com>
Message-ID: <CAOvn4qj0-ULiBwCHZmC+qJBy1512PRny=df+SQs4xo2DQgKkgw@mail.gmail.com>

On 19 June 2012 16:08, Jonathan Taylor <jonathan.taylor at stanford.edu> wrote:
> Yes, it would not be good to have the API of cell magics be notebook
> specific. What about providing a reference to the current cell metadata in
> the Magics class that can be used to update the NotebookNode after executing
> cell.input? So, cell_magics would not have access to the metadata on
> execution but could pass any metadata it wanted to back to the notebook.

Before we get too far into the mechanism, let's try to think about
actual use cases, so we can figure out how things need to work.

We can also see cell magics themselves as a sort of within-cell
metadata. For example, the frontend might one day be aware that if a
cell starts with %%bash, different syntax highlighting and tab
completion rules apply to it. I think this would need to be within the
frontend, rather than going through the kernel, because we want to use
the new highlighting & completion before the cell is executed.

Thomas


From ellisonbg at gmail.com  Tue Jun 19 11:54:03 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Tue, 19 Jun 2012 08:54:03 -0700
Subject: [IPython-dev] Better handling of older notebook versions
In-Reply-To: <-6334312716154408239@unknownmsgid>
References: <-6334312716154408239@unknownmsgid>
Message-ID: <CAH4pYpTzwX6djptR-UuMXQxgYRr5nOSUH91o7d0dPxCup6+spA@mail.gmail.com>

Aaron,

On Mon, Jun 18, 2012 at 11:16 PM, Aaron Meurer <asmeurer at gmail.com> wrote:
> Hi.
>
> As you may know, we are planning to migrate our SymPy examples to
> IPython notebooks, and, indeed, we already have some notebooks that we
> intend to ship with the next release. ?Currently, we have our
> notebooks saved as version 2 (from IPython 0.12), since IPython 0.13
> has not been released yet.
>
> I played around with the notebook versions, and I found that a version
> 3 notebook doesn't work at all in IPython 0.12, regardless if it has a
> header cell or not (from what I understand, this is the only new
> feature in version 3). ?On the other hand, a version 2 notebook is
> automatically converted by IPython git master to version 3 with an
> onscreen warning.

There are a few other features in the v3 notebooks:

* Raw text cells.
* Cell and worksheet metadata.

If your v3 notebook doesn't use these things, and you change the
version number by had in the notebook file, your notebook should work
with 0.12.

> Is there any way that we could make this more friendly to users who
> use our notebooks that we ship. ? Currently, we have two options:

Overall, this is going to be tough.  The notebook format is still
evolving rather quickly, so this problem is going to keep coming up.
We want to make the format stable as soon as possible though - we are
not there yet though.

> - Ship version 3 notebooks. ?Previously this was not an option because
> version 3 only exists in the development version, but now it is clear
> that you guys will release before we do, so it's actually possible.
> Even so, this may come up again in the future. ?Also, if we do this,
> it will obviously alienate any IPython 0.12 users.

The benefit of this approach is that I think you will find that most
people are using the dev/0.13 version of the notebook. Not everyone,
but most are.

> - Ship version 2 notebooks. ?If we do this, then anyone who opens the
> notebook with 0.13 will see a warning that the notebook is converted,
> which isn't very friendly since they are not the authors of the
> notebook. ? If they save the notebook, it will eliminate the warning,
> but will change it from the released version. ?That may not be such a
> bad thing; my main concern is just the initial annoyance/confusion to
> anyone who opens the notebook with the newest version of IPython.

I think this is the safest approach if you can live with the warning.
But remember, it is likely that 0.14 will have additional changes to
the notebook format so this choice won't go away.

The only other option is to try and keep 2 version of every notebook,
but that is a complete pain.

I think my vote would be to distribute 0.12 notebooks for now.

> Any thoughts on this? ?Perhaps the read-only notebooks discussed in
> another thread would be the solution to this. ?I think something like
> that would be ideal for shipped example notebooks, because it would
> prevent the user from accidentally overriding them, and it might even
> do a "save ?as" by default instead (like a template document on the
> Mac).
>
> Aaron Meurer
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



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


From jonathan.taylor at stanford.edu  Tue Jun 19 15:05:16 2012
From: jonathan.taylor at stanford.edu (Jonathan Taylor)
Date: Tue, 19 Jun 2012 12:05:16 -0700
Subject: [IPython-dev] magics and metadata
In-Reply-To: <CAOvn4qj0-ULiBwCHZmC+qJBy1512PRny=df+SQs4xo2DQgKkgw@mail.gmail.com>
References: <CANmCCuSwUiDtOxsNdRKDe5jJxwSP7z=r2x8jSxOGFN+ygiB-Zw@mail.gmail.com>
	<CAOvn4qhjOcGQJWovO0HnUov80nxEnz=PL8Z8ob6KR0OsXxJ_jg@mail.gmail.com>
	<CANmCCuT4eb72b-9A+k1m+Qt9zovL32fESsmoE9u_2WZD6WCNTg@mail.gmail.com>
	<CAOvn4qj0-ULiBwCHZmC+qJBy1512PRny=df+SQs4xo2DQgKkgw@mail.gmail.com>
Message-ID: <CANmCCuRAdoDEpV4dNHefEPG6uBpc6OzRH-e46cgx6mstm0cczA@mail.gmail.com>

That's the sort of use case I imagine as well, where a cell magic wants
to about something to the frontend a little more information about what
kind of cell it is (in your %%bash example, it would be a code cell for
which the code_mirror might use bash highlighting instead of python). This
seems like it could be accomplished with something parallel to
"publish_display_data" for cell metadata which different frontends can
handle differently.

On Tue, Jun 19, 2012 at 8:49 AM, Thomas Kluyver <takowl at gmail.com> wrote:

> On 19 June 2012 16:08, Jonathan Taylor <jonathan.taylor at stanford.edu>
> wrote:
> > Yes, it would not be good to have the API of cell magics be notebook
> > specific. What about providing a reference to the current cell metadata
> in
> > the Magics class that can be used to update the NotebookNode after
> executing
> > cell.input? So, cell_magics would not have access to the metadata on
> > execution but could pass any metadata it wanted to back to the notebook.
>
> Before we get too far into the mechanism, let's try to think about
> actual use cases, so we can figure out how things need to work.
>
> We can also see cell magics themselves as a sort of within-cell
> metadata. For example, the frontend might one day be aware that if a
> cell starts with %%bash, different syntax highlighting and tab
> completion rules apply to it. I think this would need to be within the
> frontend, rather than going through the kernel, because we want to use
> the new highlighting & completion before the cell is executed.
>
> Thomas
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Jonathan Taylor
Dept. of Statistics
Sequoia Hall, 137
390 Serra Mall
Stanford, CA 94305
Tel:   650.723.9230
Fax:   650.725.8977
Web: http://www-stat.stanford.edu/~jtaylo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120619/13654d77/attachment.html>

From benjaminrk at gmail.com  Tue Jun 19 15:21:49 2012
From: benjaminrk at gmail.com (MinRK)
Date: Tue, 19 Jun 2012 12:21:49 -0700
Subject: [IPython-dev] magics and metadata
In-Reply-To: <CANmCCuRAdoDEpV4dNHefEPG6uBpc6OzRH-e46cgx6mstm0cczA@mail.gmail.com>
References: <CANmCCuSwUiDtOxsNdRKDe5jJxwSP7z=r2x8jSxOGFN+ygiB-Zw@mail.gmail.com>
	<CAOvn4qhjOcGQJWovO0HnUov80nxEnz=PL8Z8ob6KR0OsXxJ_jg@mail.gmail.com>
	<CANmCCuT4eb72b-9A+k1m+Qt9zovL32fESsmoE9u_2WZD6WCNTg@mail.gmail.com>
	<CAOvn4qj0-ULiBwCHZmC+qJBy1512PRny=df+SQs4xo2DQgKkgw@mail.gmail.com>
	<CANmCCuRAdoDEpV4dNHefEPG6uBpc6OzRH-e46cgx6mstm0cczA@mail.gmail.com>
Message-ID: <CAHNn8BUDEGFGspdbabQdKmWfP7xDKd5Sx0qUymjncjc_rbqmEA@mail.gmail.com>

On Tue, Jun 19, 2012 at 12:05 PM, Jonathan Taylor <
jonathan.taylor at stanford.edu> wrote:

> That's the sort of use case I imagine as well, where a cell magic wants
> to about something to the frontend a little more information about what
> kind of cell it is (in your %%bash example, it would be a code cell for
> which the code_mirror might use bash highlighting instead of python). This
> seems like it could be accomplished with something parallel to
> "publish_display_data" for cell metadata which different frontends can
> handle differently.
>

publish_display_data already takes a metadata arg.  This has always been
the case, but so far it's totally unused.

I just noticed, this metadata is *not* included in the added fields
preserved in the notebook, but I will get on that.

-MinRK


>
> On Tue, Jun 19, 2012 at 8:49 AM, Thomas Kluyver <takowl at gmail.com> wrote:
>
>> On 19 June 2012 16:08, Jonathan Taylor <jonathan.taylor at stanford.edu>
>> wrote:
>> > Yes, it would not be good to have the API of cell magics be notebook
>> > specific. What about providing a reference to the current cell metadata
>> in
>> > the Magics class that can be used to update the NotebookNode after
>> executing
>> > cell.input? So, cell_magics would not have access to the metadata on
>> > execution but could pass any metadata it wanted to back to the notebook.
>>
>> Before we get too far into the mechanism, let's try to think about
>> actual use cases, so we can figure out how things need to work.
>>
>> We can also see cell magics themselves as a sort of within-cell
>> metadata. For example, the frontend might one day be aware that if a
>> cell starts with %%bash, different syntax highlighting and tab
>> completion rules apply to it. I think this would need to be within the
>> frontend, rather than going through the kernel, because we want to use
>> the new highlighting & completion before the cell is executed.
>>
>> Thomas
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>
>
>
> --
> Jonathan Taylor
> Dept. of Statistics
> Sequoia Hall, 137
> 390 Serra Mall
> Stanford, CA 94305
> Tel:   650.723.9230
> Fax:   650.725.8977
> Web: http://www-stat.stanford.edu/~jtaylo
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120619/f1263364/attachment.html>

From ellisonbg at gmail.com  Tue Jun 19 16:05:36 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Tue, 19 Jun 2012 13:05:36 -0700
Subject: [IPython-dev] magics and metadata
In-Reply-To: <CAHNn8BUDEGFGspdbabQdKmWfP7xDKd5Sx0qUymjncjc_rbqmEA@mail.gmail.com>
References: <CANmCCuSwUiDtOxsNdRKDe5jJxwSP7z=r2x8jSxOGFN+ygiB-Zw@mail.gmail.com>
	<CAOvn4qhjOcGQJWovO0HnUov80nxEnz=PL8Z8ob6KR0OsXxJ_jg@mail.gmail.com>
	<CANmCCuT4eb72b-9A+k1m+Qt9zovL32fESsmoE9u_2WZD6WCNTg@mail.gmail.com>
	<CAOvn4qj0-ULiBwCHZmC+qJBy1512PRny=df+SQs4xo2DQgKkgw@mail.gmail.com>
	<CANmCCuRAdoDEpV4dNHefEPG6uBpc6OzRH-e46cgx6mstm0cczA@mail.gmail.com>
	<CAHNn8BUDEGFGspdbabQdKmWfP7xDKd5Sx0qUymjncjc_rbqmEA@mail.gmail.com>
Message-ID: <CAH4pYpSno_q1hQpyfrUBxpNVSD+SrLWkBeucGBLuY8=aOJgD3g@mail.gmail.com>

On Tue, Jun 19, 2012 at 12:21 PM, MinRK <benjaminrk at gmail.com> wrote:
>
>
> On Tue, Jun 19, 2012 at 12:05 PM, Jonathan Taylor
> <jonathan.taylor at stanford.edu> wrote:
>>
>> That's the sort of use case I imagine as well, where a cell magic wants
>> to about something to the frontend a little more information about what
>> kind of cell it is (in your %%bash example, it would be a code cell for
>> which the code_mirror might use bash highlighting instead of python). This
>> seems like it could be accomplished?with something parallel to
>> "publish_display_data" for cell metadata which different frontends can
>> handle differently.
>
>
> publish_display_data already takes a metadata arg. ?This has always been the
> case, but so far it's totally unused.
>
> I just noticed, this metadata is *not* included in the added fields
> preserved in the notebook, but I will get on that.

But I think the publish_display_data metadata is separate from the
cell metadata.  Are you thinking we should save another set of
metadata with the display data output?

> -MinRK
>
>>
>>
>> On Tue, Jun 19, 2012 at 8:49 AM, Thomas Kluyver <takowl at gmail.com> wrote:
>>>
>>> On 19 June 2012 16:08, Jonathan Taylor <jonathan.taylor at stanford.edu>
>>> wrote:
>>> > Yes, it would not be good to have the API of cell magics be notebook
>>> > specific. What about providing a reference to the current cell metadata
>>> > in
>>> > the Magics class that can be used to update the NotebookNode after
>>> > executing
>>> > cell.input? So, cell_magics would not have access to the metadata on
>>> > execution but could pass any metadata it wanted to back to the
>>> > notebook.
>>>
>>> Before we get too far into the mechanism, let's try to think about
>>> actual use cases, so we can figure out how things need to work.
>>>
>>> We can also see cell magics themselves as a sort of within-cell
>>> metadata. For example, the frontend might one day be aware that if a
>>> cell starts with %%bash, different syntax highlighting and tab
>>> completion rules apply to it. I think this would need to be within the
>>> frontend, rather than going through the kernel, because we want to use
>>> the new highlighting & completion before the cell is executed.
>>>
>>> Thomas
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>>
>>
>>
>> --
>> Jonathan Taylor
>> Dept. of Statistics
>> Sequoia Hall, 137
>> 390 Serra Mall
>> Stanford, CA 94305
>> Tel:?? 650.723.9230
>> Fax:?? 650.725.8977
>> Web: http://www-stat.stanford.edu/~jtaylo
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



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


From fperez.net at gmail.com  Tue Jun 19 16:10:48 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 19 Jun 2012 13:10:48 -0700
Subject: [IPython-dev] magics and metadata
In-Reply-To: <CANmCCuRAdoDEpV4dNHefEPG6uBpc6OzRH-e46cgx6mstm0cczA@mail.gmail.com>
References: <CANmCCuSwUiDtOxsNdRKDe5jJxwSP7z=r2x8jSxOGFN+ygiB-Zw@mail.gmail.com>
	<CAOvn4qhjOcGQJWovO0HnUov80nxEnz=PL8Z8ob6KR0OsXxJ_jg@mail.gmail.com>
	<CANmCCuT4eb72b-9A+k1m+Qt9zovL32fESsmoE9u_2WZD6WCNTg@mail.gmail.com>
	<CAOvn4qj0-ULiBwCHZmC+qJBy1512PRny=df+SQs4xo2DQgKkgw@mail.gmail.com>
	<CANmCCuRAdoDEpV4dNHefEPG6uBpc6OzRH-e46cgx6mstm0cczA@mail.gmail.com>
Message-ID: <CAHAreOp27cEnt+EGuYHtzmwDFpiLHgAFxfMC1fK1QB8XecE50g@mail.gmail.com>

On Tue, Jun 19, 2012 at 12:05 PM, Jonathan Taylor
<jonathan.taylor at stanford.edu> wrote:
> That's the sort of use case I imagine as well, where a cell magic wants
> to about something to the frontend a little more information about what kind
> of cell it is (in your %%bash example, it would be a code cell for which the
> code_mirror might use bash highlighting instead of python). This seems like
> it could be accomplished?with something parallel to "publish_display_data"
> for cell metadata which different frontends can handle differently.

The trick is to find a clean way of expressing this that happens:

1. before execution of the cell. Highlighting isn't very useful by the
time the cell has been run

2. keeping the separation between kernels and notebooks we currently
have.  Keep in mind that the kernel has *no idea* that it's being
called by a notebook, all it knows is that it was given a chunk of
code to run.

This separation is something that we've made very central to our
design and it does make a few things harder, but it also makes many
others possible (such as the transparent access to a kernel from a qt
console or text console for debugging and other tasks).

We may end up reconsidering that in the future, but if we do so, we'll
do it pretty carefully.  This kind of discussion is for me very useful
evidence to accumulate as we think about the design tradeoffs.

Cheers,

f


From benjaminrk at gmail.com  Tue Jun 19 16:17:56 2012
From: benjaminrk at gmail.com (MinRK)
Date: Tue, 19 Jun 2012 13:17:56 -0700
Subject: [IPython-dev] magics and metadata
In-Reply-To: <CAH4pYpSno_q1hQpyfrUBxpNVSD+SrLWkBeucGBLuY8=aOJgD3g@mail.gmail.com>
References: <CANmCCuSwUiDtOxsNdRKDe5jJxwSP7z=r2x8jSxOGFN+ygiB-Zw@mail.gmail.com>
	<CAOvn4qhjOcGQJWovO0HnUov80nxEnz=PL8Z8ob6KR0OsXxJ_jg@mail.gmail.com>
	<CANmCCuT4eb72b-9A+k1m+Qt9zovL32fESsmoE9u_2WZD6WCNTg@mail.gmail.com>
	<CAOvn4qj0-ULiBwCHZmC+qJBy1512PRny=df+SQs4xo2DQgKkgw@mail.gmail.com>
	<CANmCCuRAdoDEpV4dNHefEPG6uBpc6OzRH-e46cgx6mstm0cczA@mail.gmail.com>
	<CAHNn8BUDEGFGspdbabQdKmWfP7xDKd5Sx0qUymjncjc_rbqmEA@mail.gmail.com>
	<CAH4pYpSno_q1hQpyfrUBxpNVSD+SrLWkBeucGBLuY8=aOJgD3g@mail.gmail.com>
Message-ID: <CAHNn8BVA8YvvJ4bw3epNR7NA=B7XQgGXa5Dh_x9kzwABkv7bPg@mail.gmail.com>

On Tue, Jun 19, 2012 at 1:05 PM, Brian Granger <ellisonbg at gmail.com> wrote:

> On Tue, Jun 19, 2012 at 12:21 PM, MinRK <benjaminrk at gmail.com> wrote:
> >
> >
> > On Tue, Jun 19, 2012 at 12:05 PM, Jonathan Taylor
> > <jonathan.taylor at stanford.edu> wrote:
> >>
> >> That's the sort of use case I imagine as well, where a cell magic wants
> >> to about something to the frontend a little more information about what
> >> kind of cell it is (in your %%bash example, it would be a code cell for
> >> which the code_mirror might use bash highlighting instead of python).
> This
> >> seems like it could be accomplished with something parallel to
> >> "publish_display_data" for cell metadata which different frontends can
> >> handle differently.
> >
> >
> > publish_display_data already takes a metadata arg.  This has always been
> the
> > case, but so far it's totally unused.
> >
> > I just noticed, this metadata is *not* included in the added fields
> > preserved in the notebook, but I will get on that.
>
> But I think the publish_display_data metadata is separate from the
> cell metadata.  Are you thinking we should save another set of
> metadata with the display data output?
>

Yes - we put metadata on outputs for a reason, presumably.  If this
shouldn't be saved, it should probably be removed from the API.


>
> > -MinRK
> >
> >>
> >>
> >> On Tue, Jun 19, 2012 at 8:49 AM, Thomas Kluyver <takowl at gmail.com>
> wrote:
> >>>
> >>> On 19 June 2012 16:08, Jonathan Taylor <jonathan.taylor at stanford.edu>
> >>> wrote:
> >>> > Yes, it would not be good to have the API of cell magics be notebook
> >>> > specific. What about providing a reference to the current cell
> metadata
> >>> > in
> >>> > the Magics class that can be used to update the NotebookNode after
> >>> > executing
> >>> > cell.input? So, cell_magics would not have access to the metadata on
> >>> > execution but could pass any metadata it wanted to back to the
> >>> > notebook.
> >>>
> >>> Before we get too far into the mechanism, let's try to think about
> >>> actual use cases, so we can figure out how things need to work.
> >>>
> >>> We can also see cell magics themselves as a sort of within-cell
> >>> metadata. For example, the frontend might one day be aware that if a
> >>> cell starts with %%bash, different syntax highlighting and tab
> >>> completion rules apply to it. I think this would need to be within the
> >>> frontend, rather than going through the kernel, because we want to use
> >>> the new highlighting & completion before the cell is executed.
> >>>
> >>> Thomas
> >>> _______________________________________________
> >>> IPython-dev mailing list
> >>> IPython-dev at scipy.org
> >>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >>
> >>
> >>
> >>
> >> --
> >> Jonathan Taylor
> >> Dept. of Statistics
> >> Sequoia Hall, 137
> >> 390 Serra Mall
> >> Stanford, CA 94305
> >> Tel:   650.723.9230
> >> Fax:   650.725.8977
> >> Web: http://www-stat.stanford.edu/~jtaylo
> >>
> >> _______________________________________________
> >> IPython-dev mailing list
> >> IPython-dev at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >>
> >
> >
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> >
>
>
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu and ellisonbg at gmail.com
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120619/728ec8dc/attachment.html>

From fperez.net at gmail.com  Tue Jun 19 17:59:23 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 19 Jun 2012 14:59:23 -0700
Subject: [IPython-dev] magics and metadata
In-Reply-To: <CAHNn8BVA8YvvJ4bw3epNR7NA=B7XQgGXa5Dh_x9kzwABkv7bPg@mail.gmail.com>
References: <CANmCCuSwUiDtOxsNdRKDe5jJxwSP7z=r2x8jSxOGFN+ygiB-Zw@mail.gmail.com>
	<CAOvn4qhjOcGQJWovO0HnUov80nxEnz=PL8Z8ob6KR0OsXxJ_jg@mail.gmail.com>
	<CANmCCuT4eb72b-9A+k1m+Qt9zovL32fESsmoE9u_2WZD6WCNTg@mail.gmail.com>
	<CAOvn4qj0-ULiBwCHZmC+qJBy1512PRny=df+SQs4xo2DQgKkgw@mail.gmail.com>
	<CANmCCuRAdoDEpV4dNHefEPG6uBpc6OzRH-e46cgx6mstm0cczA@mail.gmail.com>
	<CAHNn8BUDEGFGspdbabQdKmWfP7xDKd5Sx0qUymjncjc_rbqmEA@mail.gmail.com>
	<CAH4pYpSno_q1hQpyfrUBxpNVSD+SrLWkBeucGBLuY8=aOJgD3g@mail.gmail.com>
	<CAHNn8BVA8YvvJ4bw3epNR7NA=B7XQgGXa5Dh_x9kzwABkv7bPg@mail.gmail.com>
Message-ID: <CAHAreOrFUaf_fP4cnjv4KmHciEK5b60A5uhifu8GH2FbmR3dxQ@mail.gmail.com>

On Tue, Jun 19, 2012 at 1:17 PM, MinRK <benjaminrk at gmail.com> wrote:
> Yes - we put metadata on outputs for a reason, presumably. ?If this
> shouldn't be saved, it should probably be removed from the API.

I can't recall precisely what we had in mind when we put it in, but
something that springs to mind as potentially useful, for example,
would be to specify a desired priority order for the various types of
outputs. Right now when a client can display several kinds of output
it just makes a choice, but we could let objects provide a hint of the
preferred order, based on what they know about the relative quality of
each.

So I'd vote for not removing this, as it may prove useful...

f


From ellisonbg at gmail.com  Tue Jun 19 18:18:03 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Tue, 19 Jun 2012 15:18:03 -0700
Subject: [IPython-dev] magics and metadata
In-Reply-To: <CAHAreOrFUaf_fP4cnjv4KmHciEK5b60A5uhifu8GH2FbmR3dxQ@mail.gmail.com>
References: <CANmCCuSwUiDtOxsNdRKDe5jJxwSP7z=r2x8jSxOGFN+ygiB-Zw@mail.gmail.com>
	<CAOvn4qhjOcGQJWovO0HnUov80nxEnz=PL8Z8ob6KR0OsXxJ_jg@mail.gmail.com>
	<CANmCCuT4eb72b-9A+k1m+Qt9zovL32fESsmoE9u_2WZD6WCNTg@mail.gmail.com>
	<CAOvn4qj0-ULiBwCHZmC+qJBy1512PRny=df+SQs4xo2DQgKkgw@mail.gmail.com>
	<CANmCCuRAdoDEpV4dNHefEPG6uBpc6OzRH-e46cgx6mstm0cczA@mail.gmail.com>
	<CAHNn8BUDEGFGspdbabQdKmWfP7xDKd5Sx0qUymjncjc_rbqmEA@mail.gmail.com>
	<CAH4pYpSno_q1hQpyfrUBxpNVSD+SrLWkBeucGBLuY8=aOJgD3g@mail.gmail.com>
	<CAHNn8BVA8YvvJ4bw3epNR7NA=B7XQgGXa5Dh_x9kzwABkv7bPg@mail.gmail.com>
	<CAHAreOrFUaf_fP4cnjv4KmHciEK5b60A5uhifu8GH2FbmR3dxQ@mail.gmail.com>
Message-ID: <CAH4pYpTTQ=pwFvF+oiSQFd6JDUo6iw3L6DL7+3WzHwSMSmFvug@mail.gmail.com>

On Tue, Jun 19, 2012 at 2:59 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Tue, Jun 19, 2012 at 1:17 PM, MinRK <benjaminrk at gmail.com> wrote:
>> Yes - we put metadata on outputs for a reason, presumably. ?If this
>> shouldn't be saved, it should probably be removed from the API.
>
> I can't recall precisely what we had in mind when we put it in, but
> something that springs to mind as potentially useful, for example,
> would be to specify a desired priority order for the various types of
> outputs. Right now when a client can display several kinds of output
> it just makes a choice, but we could let objects provide a hint of the
> preferred order, based on what they know about the relative quality of
> each.

I originally put it there to allow objects to provide hints to the
frontend on how it should display a representation.  This is similar
to how the payloads can indicate where it came from.

> So I'd vote for not removing this, as it may prove useful...

I also think it could be useful, although it seems a bit excessive to
store metadata for each output.  Here is what I propose.  We simply
leave it alone until we have an actual use case that will help us
figure out exactly what this should look like.  Without a concrete
usage case, it is difficult to know what is needed.

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



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


From benjaminrk at gmail.com  Tue Jun 19 18:19:49 2012
From: benjaminrk at gmail.com (MinRK)
Date: Tue, 19 Jun 2012 15:19:49 -0700
Subject: [IPython-dev] magics and metadata
In-Reply-To: <CAH4pYpTTQ=pwFvF+oiSQFd6JDUo6iw3L6DL7+3WzHwSMSmFvug@mail.gmail.com>
References: <CANmCCuSwUiDtOxsNdRKDe5jJxwSP7z=r2x8jSxOGFN+ygiB-Zw@mail.gmail.com>
	<CAOvn4qhjOcGQJWovO0HnUov80nxEnz=PL8Z8ob6KR0OsXxJ_jg@mail.gmail.com>
	<CANmCCuT4eb72b-9A+k1m+Qt9zovL32fESsmoE9u_2WZD6WCNTg@mail.gmail.com>
	<CAOvn4qj0-ULiBwCHZmC+qJBy1512PRny=df+SQs4xo2DQgKkgw@mail.gmail.com>
	<CANmCCuRAdoDEpV4dNHefEPG6uBpc6OzRH-e46cgx6mstm0cczA@mail.gmail.com>
	<CAHNn8BUDEGFGspdbabQdKmWfP7xDKd5Sx0qUymjncjc_rbqmEA@mail.gmail.com>
	<CAH4pYpSno_q1hQpyfrUBxpNVSD+SrLWkBeucGBLuY8=aOJgD3g@mail.gmail.com>
	<CAHNn8BVA8YvvJ4bw3epNR7NA=B7XQgGXa5Dh_x9kzwABkv7bPg@mail.gmail.com>
	<CAHAreOrFUaf_fP4cnjv4KmHciEK5b60A5uhifu8GH2FbmR3dxQ@mail.gmail.com>
	<CAH4pYpTTQ=pwFvF+oiSQFd6JDUo6iw3L6DL7+3WzHwSMSmFvug@mail.gmail.com>
Message-ID: <CAHNn8BXJRjRYM-i7M2NSfdkfZxS-2WkyqBETOwmGbnCyxvCtEw@mail.gmail.com>

On Tue, Jun 19, 2012 at 3:18 PM, Brian Granger <ellisonbg at gmail.com> wrote:

> On Tue, Jun 19, 2012 at 2:59 PM, Fernando Perez <fperez.net at gmail.com>
> wrote:
> > On Tue, Jun 19, 2012 at 1:17 PM, MinRK <benjaminrk at gmail.com> wrote:
> >> Yes - we put metadata on outputs for a reason, presumably.  If this
> >> shouldn't be saved, it should probably be removed from the API.
> >
> > I can't recall precisely what we had in mind when we put it in, but
> > something that springs to mind as potentially useful, for example,
> > would be to specify a desired priority order for the various types of
> > outputs. Right now when a client can display several kinds of output
> > it just makes a choice, but we could let objects provide a hint of the
> > preferred order, based on what they know about the relative quality of
> > each.
>
> I originally put it there to allow objects to provide hints to the
> frontend on how it should display a representation.  This is similar
> to how the payloads can indicate where it came from.
>
> > So I'd vote for not removing this, as it may prove useful...
>
> I also think it could be useful, although it seems a bit excessive to
> store metadata for each output.  Here is what I propose.  We simply
> leave it alone until we have an actual use case that will help us
> figure out exactly what this should look like.  Without a concrete
> usage case, it is difficult to know what is needed.
>

But this doesn't answer the immediate question: Should this metadata dict
be included in the nbformat


>
> > f
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu and ellisonbg at gmail.com
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120619/596f031a/attachment.html>

From ellisonbg at gmail.com  Tue Jun 19 18:23:16 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Tue, 19 Jun 2012 15:23:16 -0700
Subject: [IPython-dev] magics and metadata
In-Reply-To: <CAHNn8BXJRjRYM-i7M2NSfdkfZxS-2WkyqBETOwmGbnCyxvCtEw@mail.gmail.com>
References: <CANmCCuSwUiDtOxsNdRKDe5jJxwSP7z=r2x8jSxOGFN+ygiB-Zw@mail.gmail.com>
	<CAOvn4qhjOcGQJWovO0HnUov80nxEnz=PL8Z8ob6KR0OsXxJ_jg@mail.gmail.com>
	<CANmCCuT4eb72b-9A+k1m+Qt9zovL32fESsmoE9u_2WZD6WCNTg@mail.gmail.com>
	<CAOvn4qj0-ULiBwCHZmC+qJBy1512PRny=df+SQs4xo2DQgKkgw@mail.gmail.com>
	<CANmCCuRAdoDEpV4dNHefEPG6uBpc6OzRH-e46cgx6mstm0cczA@mail.gmail.com>
	<CAHNn8BUDEGFGspdbabQdKmWfP7xDKd5Sx0qUymjncjc_rbqmEA@mail.gmail.com>
	<CAH4pYpSno_q1hQpyfrUBxpNVSD+SrLWkBeucGBLuY8=aOJgD3g@mail.gmail.com>
	<CAHNn8BVA8YvvJ4bw3epNR7NA=B7XQgGXa5Dh_x9kzwABkv7bPg@mail.gmail.com>
	<CAHAreOrFUaf_fP4cnjv4KmHciEK5b60A5uhifu8GH2FbmR3dxQ@mail.gmail.com>
	<CAH4pYpTTQ=pwFvF+oiSQFd6JDUo6iw3L6DL7+3WzHwSMSmFvug@mail.gmail.com>
	<CAHNn8BXJRjRYM-i7M2NSfdkfZxS-2WkyqBETOwmGbnCyxvCtEw@mail.gmail.com>
Message-ID: <CAH4pYpQgCp2FpnDyM5_+uuZvsM+nNojcW3fn9AAUYji3PMeNAQ@mail.gmail.com>

On Tue, Jun 19, 2012 at 3:19 PM, MinRK <benjaminrk at gmail.com> wrote:
>
>
> On Tue, Jun 19, 2012 at 3:18 PM, Brian Granger <ellisonbg at gmail.com> wrote:
>>
>> On Tue, Jun 19, 2012 at 2:59 PM, Fernando Perez <fperez.net at gmail.com>
>> wrote:
>> > On Tue, Jun 19, 2012 at 1:17 PM, MinRK <benjaminrk at gmail.com> wrote:
>> >> Yes - we put metadata on outputs for a reason, presumably. ?If this
>> >> shouldn't be saved, it should probably be removed from the API.
>> >
>> > I can't recall precisely what we had in mind when we put it in, but
>> > something that springs to mind as potentially useful, for example,
>> > would be to specify a desired priority order for the various types of
>> > outputs. Right now when a client can display several kinds of output
>> > it just makes a choice, but we could let objects provide a hint of the
>> > preferred order, based on what they know about the relative quality of
>> > each.
>>
>> I originally put it there to allow objects to provide hints to the
>> frontend on how it should display a representation. ?This is similar
>> to how the payloads can indicate where it came from.
>>
>> > So I'd vote for not removing this, as it may prove useful...
>>
>> I also think it could be useful, although it seems a bit excessive to
>> store metadata for each output. ?Here is what I propose. ?We simply
>> leave it alone until we have an actual use case that will help us
>> figure out exactly what this should look like. ?Without a concrete
>> usage case, it is difficult to know what is needed.
>
>
> But this doesn't answer the immediate question: Should this metadata dict be
> included in the nbformat

I would vote no - not until we have a real usage case.  I don't like
to add things to the notebook format until we are actually using them.

>>
>>
>> > f
>> > _______________________________________________
>> > IPython-dev mailing list
>> > IPython-dev at scipy.org
>> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>>
>>
>> --
>> Brian E. Granger
>> Cal Poly State University, San Luis Obispo
>> bgranger at calpoly.edu and ellisonbg at gmail.com
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



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


From benjaminrk at gmail.com  Tue Jun 19 18:25:56 2012
From: benjaminrk at gmail.com (MinRK)
Date: Tue, 19 Jun 2012 15:25:56 -0700
Subject: [IPython-dev] magics and metadata
In-Reply-To: <CAH4pYpQgCp2FpnDyM5_+uuZvsM+nNojcW3fn9AAUYji3PMeNAQ@mail.gmail.com>
References: <CANmCCuSwUiDtOxsNdRKDe5jJxwSP7z=r2x8jSxOGFN+ygiB-Zw@mail.gmail.com>
	<CAOvn4qhjOcGQJWovO0HnUov80nxEnz=PL8Z8ob6KR0OsXxJ_jg@mail.gmail.com>
	<CANmCCuT4eb72b-9A+k1m+Qt9zovL32fESsmoE9u_2WZD6WCNTg@mail.gmail.com>
	<CAOvn4qj0-ULiBwCHZmC+qJBy1512PRny=df+SQs4xo2DQgKkgw@mail.gmail.com>
	<CANmCCuRAdoDEpV4dNHefEPG6uBpc6OzRH-e46cgx6mstm0cczA@mail.gmail.com>
	<CAHNn8BUDEGFGspdbabQdKmWfP7xDKd5Sx0qUymjncjc_rbqmEA@mail.gmail.com>
	<CAH4pYpSno_q1hQpyfrUBxpNVSD+SrLWkBeucGBLuY8=aOJgD3g@mail.gmail.com>
	<CAHNn8BVA8YvvJ4bw3epNR7NA=B7XQgGXa5Dh_x9kzwABkv7bPg@mail.gmail.com>
	<CAHAreOrFUaf_fP4cnjv4KmHciEK5b60A5uhifu8GH2FbmR3dxQ@mail.gmail.com>
	<CAH4pYpTTQ=pwFvF+oiSQFd6JDUo6iw3L6DL7+3WzHwSMSmFvug@mail.gmail.com>
	<CAHNn8BXJRjRYM-i7M2NSfdkfZxS-2WkyqBETOwmGbnCyxvCtEw@mail.gmail.com>
	<CAH4pYpQgCp2FpnDyM5_+uuZvsM+nNojcW3fn9AAUYji3PMeNAQ@mail.gmail.com>
Message-ID: <CAHNn8BXbMzFqeAkd6wzDK5=0ZbhtFkbtc0EW_TbM+wKpvjihFA@mail.gmail.com>

On Tue, Jun 19, 2012 at 3:23 PM, Brian Granger <ellisonbg at gmail.com> wrote:

> On Tue, Jun 19, 2012 at 3:19 PM, MinRK <benjaminrk at gmail.com> wrote:
> >
> >
> > On Tue, Jun 19, 2012 at 3:18 PM, Brian Granger <ellisonbg at gmail.com>
> wrote:
> >>
> >> On Tue, Jun 19, 2012 at 2:59 PM, Fernando Perez <fperez.net at gmail.com>
> >> wrote:
> >> > On Tue, Jun 19, 2012 at 1:17 PM, MinRK <benjaminrk at gmail.com> wrote:
> >> >> Yes - we put metadata on outputs for a reason, presumably.  If this
> >> >> shouldn't be saved, it should probably be removed from the API.
> >> >
> >> > I can't recall precisely what we had in mind when we put it in, but
> >> > something that springs to mind as potentially useful, for example,
> >> > would be to specify a desired priority order for the various types of
> >> > outputs. Right now when a client can display several kinds of output
> >> > it just makes a choice, but we could let objects provide a hint of the
> >> > preferred order, based on what they know about the relative quality of
> >> > each.
> >>
> >> I originally put it there to allow objects to provide hints to the
> >> frontend on how it should display a representation.  This is similar
> >> to how the payloads can indicate where it came from.
> >>
> >> > So I'd vote for not removing this, as it may prove useful...
> >>
> >> I also think it could be useful, although it seems a bit excessive to
> >> store metadata for each output.  Here is what I propose.  We simply
> >> leave it alone until we have an actual use case that will help us
> >> figure out exactly what this should look like.  Without a concrete
> >> usage case, it is difficult to know what is needed.
> >
> >
> > But this doesn't answer the immediate question: Should this metadata
> dict be
> > included in the nbformat
>
> I would vote no - not until we have a real usage case.  I don't like
> to add things to the notebook format until we are actually using them.
>

Then should we remove all of the metadata stuff we just added?  The whole
point was to prepare the nbformat for future changes to we don't have to
update the nbformat, which is incredibly painful and should be done as
rarely as possible.

-MinRK


>
> >>
> >>
> >> > f
> >> > _______________________________________________
> >> > IPython-dev mailing list
> >> > IPython-dev at scipy.org
> >> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> >>
> >>
> >>
> >> --
> >> Brian E. Granger
> >> Cal Poly State University, San Luis Obispo
> >> bgranger at calpoly.edu and ellisonbg at gmail.com
> >> _______________________________________________
> >> IPython-dev mailing list
> >> IPython-dev at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >
> >
> >
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> >
>
>
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu and ellisonbg at gmail.com
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120619/be0ce263/attachment.html>

From ellisonbg at gmail.com  Tue Jun 19 19:20:16 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Tue, 19 Jun 2012 16:20:16 -0700
Subject: [IPython-dev] magics and metadata
In-Reply-To: <CAHNn8BXbMzFqeAkd6wzDK5=0ZbhtFkbtc0EW_TbM+wKpvjihFA@mail.gmail.com>
References: <CANmCCuSwUiDtOxsNdRKDe5jJxwSP7z=r2x8jSxOGFN+ygiB-Zw@mail.gmail.com>
	<CAOvn4qhjOcGQJWovO0HnUov80nxEnz=PL8Z8ob6KR0OsXxJ_jg@mail.gmail.com>
	<CANmCCuT4eb72b-9A+k1m+Qt9zovL32fESsmoE9u_2WZD6WCNTg@mail.gmail.com>
	<CAOvn4qj0-ULiBwCHZmC+qJBy1512PRny=df+SQs4xo2DQgKkgw@mail.gmail.com>
	<CANmCCuRAdoDEpV4dNHefEPG6uBpc6OzRH-e46cgx6mstm0cczA@mail.gmail.com>
	<CAHNn8BUDEGFGspdbabQdKmWfP7xDKd5Sx0qUymjncjc_rbqmEA@mail.gmail.com>
	<CAH4pYpSno_q1hQpyfrUBxpNVSD+SrLWkBeucGBLuY8=aOJgD3g@mail.gmail.com>
	<CAHNn8BVA8YvvJ4bw3epNR7NA=B7XQgGXa5Dh_x9kzwABkv7bPg@mail.gmail.com>
	<CAHAreOrFUaf_fP4cnjv4KmHciEK5b60A5uhifu8GH2FbmR3dxQ@mail.gmail.com>
	<CAH4pYpTTQ=pwFvF+oiSQFd6JDUo6iw3L6DL7+3WzHwSMSmFvug@mail.gmail.com>
	<CAHNn8BXJRjRYM-i7M2NSfdkfZxS-2WkyqBETOwmGbnCyxvCtEw@mail.gmail.com>
	<CAH4pYpQgCp2FpnDyM5_+uuZvsM+nNojcW3fn9AAUYji3PMeNAQ@mail.gmail.com>
	<CAHNn8BXbMzFqeAkd6wzDK5=0ZbhtFkbtc0EW_TbM+wKpvjihFA@mail.gmail.com>
Message-ID: <CAH4pYpTSLdQmXKou3x5u9YrYeR1H_w+R6nvQ8YpFmdB1cKWhvw@mail.gmail.com>

When the metadata PR come up, I was originally going to vote -1 on it
because of this issue.  I sat on it for a while and in the end decided
that it was OK because I think the need for metadata is already upon
us even though we don't have an actual usage case in our own code base
(for example, we don't have a metadata UI in the notebook web app).

There is a fine line to walk here.  On one hand, I completely agree
with you that we should try to future-proof the notebook format to
minimize disruptive format changes.  On the other hand, adding things
too soon leads to even more potential disruption for the following
reason.  As I developed the notebook format and notebook UI last
summer, there were multiple situations where I added something to the
notebook format before I actually used it in the UI.  In many of these
cases, when I did get around to developing the UI for it, I realized
that my original thoughts on that element were incomplete.  It wasn't
until I wrote the UI that used the data that I realized exactly what
the format of that data needed to be.  As a result, I had to go back
and modify the notebook format.  After a few iterations of this, I
realized that this approach was broken and started to enforce the
following simple rule on myself: don't add it to the notebook format
until I am ready to write the UI code that uses it.  That rule served
me very well last summer.

This is why for example the notebook and cells do not currently have
any timestamp information (even though I think we will eventually want
it).  The one notebook feature (which I regret adding to the format)
that doesn't have a UI is the multiple worksheets.  We absolutely want
that as a feature, I just wish I had waited to add it to the notebook
format.  When we do implement the mulitple worksheet UI, it is likely
we will want to go back and make changes to the notebook format to
better reflect the UI (for example, we will probably want to persist
which worksheet is active/open).

For the cell and worksheet metadata, I knew we would eventually need
it and I didn't want to hold up the beta release any longer.  But
there are still unanswered questions related to it:

* What types of things go in the metadata?
* Is this an area for us to write data to, or for advanced users to
write data to?
* Is it entirely unstructured, or will we require a discussion for
each new key/value entry into it.

It is not at all clean that the current metadata design will hold up
to our answers of these questions.  But in the end, I sort of wanted
to add the metadata as it is now, so we could being to see how we and
others start to use it.  But just because we added the metadata to the
notebook format definitely doesn't mean that future-proofs this part
of the notebook format.

Hope this clarifies things a bit.

Back to the question of output-level metadata.  When a bit of code
remains unused for almost a year, I start to question whether we
really need it.  I not convinced we don't need it, I am not sure.  In
light of this, I don't think that adding it to the notebook format
makes sense.  When one of us finds a good purpose for this metadata,
let's add it to the nbformat them.

The other philosophical line of reasoning that I am being guided by
here is simplicity.  It would be very easy to over design the notebook
format and add all sorts of feature that we might need.  I think this
is a wrong direction to go.  We want a notebook format that is as
compact and minimal as possible, where each and every bit of data is
there for a well-defined and justified reason.

Cheers,

Brian



On Tue, Jun 19, 2012 at 3:25 PM, MinRK <benjaminrk at gmail.com> wrote:
>
>
> On Tue, Jun 19, 2012 at 3:23 PM, Brian Granger <ellisonbg at gmail.com> wrote:
>>
>> On Tue, Jun 19, 2012 at 3:19 PM, MinRK <benjaminrk at gmail.com> wrote:
>> >
>> >
>> > On Tue, Jun 19, 2012 at 3:18 PM, Brian Granger <ellisonbg at gmail.com>
>> > wrote:
>> >>
>> >> On Tue, Jun 19, 2012 at 2:59 PM, Fernando Perez <fperez.net at gmail.com>
>> >> wrote:
>> >> > On Tue, Jun 19, 2012 at 1:17 PM, MinRK <benjaminrk at gmail.com> wrote:
>> >> >> Yes - we put metadata on outputs for a reason, presumably. ?If this
>> >> >> shouldn't be saved, it should probably be removed from the API.
>> >> >
>> >> > I can't recall precisely what we had in mind when we put it in, but
>> >> > something that springs to mind as potentially useful, for example,
>> >> > would be to specify a desired priority order for the various types of
>> >> > outputs. Right now when a client can display several kinds of output
>> >> > it just makes a choice, but we could let objects provide a hint of
>> >> > the
>> >> > preferred order, based on what they know about the relative quality
>> >> > of
>> >> > each.
>> >>
>> >> I originally put it there to allow objects to provide hints to the
>> >> frontend on how it should display a representation. ?This is similar
>> >> to how the payloads can indicate where it came from.
>> >>
>> >> > So I'd vote for not removing this, as it may prove useful...
>> >>
>> >> I also think it could be useful, although it seems a bit excessive to
>> >> store metadata for each output. ?Here is what I propose. ?We simply
>> >> leave it alone until we have an actual use case that will help us
>> >> figure out exactly what this should look like. ?Without a concrete
>> >> usage case, it is difficult to know what is needed.
>> >
>> >
>> > But this doesn't answer the immediate question: Should this metadata
>> > dict be
>> > included in the nbformat
>>
>> I would vote no - not until we have a real usage case. ?I don't like
>> to add things to the notebook format until we are actually using them.
>
>
> Then should we remove all of the metadata stuff we just added? ?The whole
> point was to prepare the nbformat for future changes to we don't have to
> update the nbformat, which is incredibly painful and should be done as
> rarely as possible.
>
> -MinRK
>
>>
>>
>> >>
>> >>
>> >> > f
>> >> > _______________________________________________
>> >> > IPython-dev mailing list
>> >> > IPython-dev at scipy.org
>> >> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >>
>> >>
>> >>
>> >> --
>> >> Brian E. Granger
>> >> Cal Poly State University, San Luis Obispo
>> >> bgranger at calpoly.edu and ellisonbg at gmail.com
>> >> _______________________________________________
>> >> IPython-dev mailing list
>> >> IPython-dev at scipy.org
>> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >
>> >
>> >
>> > _______________________________________________
>> > IPython-dev mailing list
>> > IPython-dev at scipy.org
>> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >
>>
>>
>>
>> --
>> Brian E. Granger
>> Cal Poly State University, San Luis Obispo
>> bgranger at calpoly.edu and ellisonbg at gmail.com
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



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


From benjaminrk at gmail.com  Tue Jun 19 20:01:10 2012
From: benjaminrk at gmail.com (MinRK)
Date: Tue, 19 Jun 2012 17:01:10 -0700
Subject: [IPython-dev] magics and metadata
In-Reply-To: <CAH4pYpTSLdQmXKou3x5u9YrYeR1H_w+R6nvQ8YpFmdB1cKWhvw@mail.gmail.com>
References: <CANmCCuSwUiDtOxsNdRKDe5jJxwSP7z=r2x8jSxOGFN+ygiB-Zw@mail.gmail.com>
	<CAOvn4qhjOcGQJWovO0HnUov80nxEnz=PL8Z8ob6KR0OsXxJ_jg@mail.gmail.com>
	<CANmCCuT4eb72b-9A+k1m+Qt9zovL32fESsmoE9u_2WZD6WCNTg@mail.gmail.com>
	<CAOvn4qj0-ULiBwCHZmC+qJBy1512PRny=df+SQs4xo2DQgKkgw@mail.gmail.com>
	<CANmCCuRAdoDEpV4dNHefEPG6uBpc6OzRH-e46cgx6mstm0cczA@mail.gmail.com>
	<CAHNn8BUDEGFGspdbabQdKmWfP7xDKd5Sx0qUymjncjc_rbqmEA@mail.gmail.com>
	<CAH4pYpSno_q1hQpyfrUBxpNVSD+SrLWkBeucGBLuY8=aOJgD3g@mail.gmail.com>
	<CAHNn8BVA8YvvJ4bw3epNR7NA=B7XQgGXa5Dh_x9kzwABkv7bPg@mail.gmail.com>
	<CAHAreOrFUaf_fP4cnjv4KmHciEK5b60A5uhifu8GH2FbmR3dxQ@mail.gmail.com>
	<CAH4pYpTTQ=pwFvF+oiSQFd6JDUo6iw3L6DL7+3WzHwSMSmFvug@mail.gmail.com>
	<CAHNn8BXJRjRYM-i7M2NSfdkfZxS-2WkyqBETOwmGbnCyxvCtEw@mail.gmail.com>
	<CAH4pYpQgCp2FpnDyM5_+uuZvsM+nNojcW3fn9AAUYji3PMeNAQ@mail.gmail.com>
	<CAHNn8BXbMzFqeAkd6wzDK5=0ZbhtFkbtc0EW_TbM+wKpvjihFA@mail.gmail.com>
	<CAH4pYpTSLdQmXKou3x5u9YrYeR1H_w+R6nvQ8YpFmdB1cKWhvw@mail.gmail.com>
Message-ID: <CAHNn8BVbpo59MX+3aWs3H200cNZNXM4wCOTS3AowwVwXAuztdQ@mail.gmail.com>

On Tue, Jun 19, 2012 at 4:20 PM, Brian Granger <ellisonbg at gmail.com> wrote:

> When the metadata PR come up, I was originally going to vote -1 on it
> because of this issue.  I sat on it for a while and in the end decided
> that it was OK because I think the need for metadata is already upon
> us even though we don't have an actual usage case in our own code base
> (for example, we don't have a metadata UI in the notebook web app).
>
> There is a fine line to walk here.  On one hand, I completely agree
> with you that we should try to future-proof the notebook format to
> minimize disruptive format changes.  On the other hand, adding things
> too soon leads to even more potential disruption for the following
> reason.  As I developed the notebook format and notebook UI last
> summer, there were multiple situations where I added something to the
> notebook format before I actually used it in the UI.  In many of these
> cases, when I did get around to developing the UI for it, I realized
> that my original thoughts on that element were incomplete.  It wasn't
> until I wrote the UI that used the data that I realized exactly what
> the format of that data needed to be.  As a result, I had to go back
> and modify the notebook format.  After a few iterations of this, I
> realized that this approach was broken and started to enforce the
> following simple rule on myself: don't add it to the notebook format
> until I am ready to write the UI code that uses it.  That rule served
> me very well last summer.
>
> This is why for example the notebook and cells do not currently have
> any timestamp information (even though I think we will eventually want
> it).  The one notebook feature (which I regret adding to the format)
> that doesn't have a UI is the multiple worksheets.  We absolutely want
> that as a feature, I just wish I had waited to add it to the notebook
> format.  When we do implement the mulitple worksheet UI, it is likely
> we will want to go back and make changes to the notebook format to
> better reflect the UI (for example, we will probably want to persist
> which worksheet is active/open).
>

I couldn't agree less.  There is simply no reason that adding support for
multiple worksheets in future versions of IPython should render
single-sheet notebooks unreadable in 0.13, just like adding new metadata
should not make the notebook artificially unreadable.


>
> For the cell and worksheet metadata, I knew we would eventually need
> it and I didn't want to hold up the beta release any longer.  But
> there are still unanswered questions related to it:
>
> * What types of things go in the metadata?
>
* Is this an area for us to write data to, or for advanced users to
> write data to?
> * Is it entirely unstructured, or will we require a discussion for
> each new key/value entry into it.


> It is not at all clean that the current metadata design will hold up
> to our answers of these questions.  But in the end, I sort of wanted
> to add the metadata as it is now, so we could being to see how we and
> others start to use it.  But just because we added the metadata to the
> notebook format definitely doesn't mean that future-proofs this part
> of the notebook format.
>

> Hope this clarifies things a bit.
>

Sure, while it is extremely clear that we need cell metadata, we cannot be
100% certain that
a simple dict will solve 100% of the cases we encounter.  But adding it now
means that we have at least a *chance*
of making a release that is not backwards-incompatible.


>
> Back to the question of output-level metadata.  When a bit of code
> remains unused for almost a year, I start to question whether we
> really need it.  I not convinced we don't need it, I am not sure.  In
> light of this, I don't think that adding it to the notebook format
> makes sense.  When one of us finds a good purpose for this metadata,
> let's add it to the nbformat them.
>

I believe the only current use is in the parallel display republishing,
where the engine ID is added to the display data
so that frontends could theoretically draw display data differently based
on which engine it came from.


>
> The other philosophical line of reasoning that I am being guided by
> here is simplicity.  It would be very easy to over design the notebook
> format and add all sorts of feature that we might need.  I think this
> is a wrong direction to go.  We want a notebook format that is as
> compact and minimal as possible, where each and every bit of data is
> there for a well-defined and justified reason.
>

I think it's simple: We have had ideas over and over and over again for
features requiring metadata attached to cells (hashes, links, timestamps,
etc.), so this is clearly a feature we have a need for right now.  It would
be totally silly for adding timestamps to require updating the nbformat in
a backward-incompatible way.  And the biggest advantage of using json is
that adding keys has no effect on backwards *readability*.  It's only
adding values/types that can cause problems, and should force new versions
(e.g. changing worsheet to worksheets, or adding new cell types).

-MinRK


> Cheers,
>
> Brian
>
>
>
> On Tue, Jun 19, 2012 at 3:25 PM, MinRK <benjaminrk at gmail.com> wrote:
> >
> >
> > On Tue, Jun 19, 2012 at 3:23 PM, Brian Granger <ellisonbg at gmail.com>
> wrote:
> >>
> >> On Tue, Jun 19, 2012 at 3:19 PM, MinRK <benjaminrk at gmail.com> wrote:
> >> >
> >> >
> >> > On Tue, Jun 19, 2012 at 3:18 PM, Brian Granger <ellisonbg at gmail.com>
> >> > wrote:
> >> >>
> >> >> On Tue, Jun 19, 2012 at 2:59 PM, Fernando Perez <
> fperez.net at gmail.com>
> >> >> wrote:
> >> >> > On Tue, Jun 19, 2012 at 1:17 PM, MinRK <benjaminrk at gmail.com>
> wrote:
> >> >> >> Yes - we put metadata on outputs for a reason, presumably.  If
> this
> >> >> >> shouldn't be saved, it should probably be removed from the API.
> >> >> >
> >> >> > I can't recall precisely what we had in mind when we put it in, but
> >> >> > something that springs to mind as potentially useful, for example,
> >> >> > would be to specify a desired priority order for the various types
> of
> >> >> > outputs. Right now when a client can display several kinds of
> output
> >> >> > it just makes a choice, but we could let objects provide a hint of
> >> >> > the
> >> >> > preferred order, based on what they know about the relative quality
> >> >> > of
> >> >> > each.
> >> >>
> >> >> I originally put it there to allow objects to provide hints to the
> >> >> frontend on how it should display a representation.  This is similar
> >> >> to how the payloads can indicate where it came from.
> >> >>
> >> >> > So I'd vote for not removing this, as it may prove useful...
> >> >>
> >> >> I also think it could be useful, although it seems a bit excessive to
> >> >> store metadata for each output.  Here is what I propose.  We simply
> >> >> leave it alone until we have an actual use case that will help us
> >> >> figure out exactly what this should look like.  Without a concrete
> >> >> usage case, it is difficult to know what is needed.
> >> >
> >> >
> >> > But this doesn't answer the immediate question: Should this metadata
> >> > dict be
> >> > included in the nbformat
> >>
> >> I would vote no - not until we have a real usage case.  I don't like
> >> to add things to the notebook format until we are actually using them.
> >
> >
> > Then should we remove all of the metadata stuff we just added?  The whole
> > point was to prepare the nbformat for future changes to we don't have to
> > update the nbformat, which is incredibly painful and should be done as
> > rarely as possible.
> >
> > -MinRK
> >
> >>
> >>
> >> >>
> >> >>
> >> >> > f
> >> >> > _______________________________________________
> >> >> > IPython-dev mailing list
> >> >> > IPython-dev at scipy.org
> >> >> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Brian E. Granger
> >> >> Cal Poly State University, San Luis Obispo
> >> >> bgranger at calpoly.edu and ellisonbg at gmail.com
> >> >> _______________________________________________
> >> >> IPython-dev mailing list
> >> >> IPython-dev at scipy.org
> >> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > IPython-dev mailing list
> >> > IPython-dev at scipy.org
> >> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> >> >
> >>
> >>
> >>
> >> --
> >> Brian E. Granger
> >> Cal Poly State University, San Luis Obispo
> >> bgranger at calpoly.edu and ellisonbg at gmail.com
> >> _______________________________________________
> >> IPython-dev mailing list
> >> IPython-dev at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >
> >
> >
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> >
>
>
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu and ellisonbg at gmail.com
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120619/2adce331/attachment.html>

From ellisonbg at gmail.com  Tue Jun 19 22:25:00 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Tue, 19 Jun 2012 19:25:00 -0700
Subject: [IPython-dev] magics and metadata
In-Reply-To: <CAHNn8BVbpo59MX+3aWs3H200cNZNXM4wCOTS3AowwVwXAuztdQ@mail.gmail.com>
References: <CANmCCuSwUiDtOxsNdRKDe5jJxwSP7z=r2x8jSxOGFN+ygiB-Zw@mail.gmail.com>
	<CAOvn4qhjOcGQJWovO0HnUov80nxEnz=PL8Z8ob6KR0OsXxJ_jg@mail.gmail.com>
	<CANmCCuT4eb72b-9A+k1m+Qt9zovL32fESsmoE9u_2WZD6WCNTg@mail.gmail.com>
	<CAOvn4qj0-ULiBwCHZmC+qJBy1512PRny=df+SQs4xo2DQgKkgw@mail.gmail.com>
	<CANmCCuRAdoDEpV4dNHefEPG6uBpc6OzRH-e46cgx6mstm0cczA@mail.gmail.com>
	<CAHNn8BUDEGFGspdbabQdKmWfP7xDKd5Sx0qUymjncjc_rbqmEA@mail.gmail.com>
	<CAH4pYpSno_q1hQpyfrUBxpNVSD+SrLWkBeucGBLuY8=aOJgD3g@mail.gmail.com>
	<CAHNn8BVA8YvvJ4bw3epNR7NA=B7XQgGXa5Dh_x9kzwABkv7bPg@mail.gmail.com>
	<CAHAreOrFUaf_fP4cnjv4KmHciEK5b60A5uhifu8GH2FbmR3dxQ@mail.gmail.com>
	<CAH4pYpTTQ=pwFvF+oiSQFd6JDUo6iw3L6DL7+3WzHwSMSmFvug@mail.gmail.com>
	<CAHNn8BXJRjRYM-i7M2NSfdkfZxS-2WkyqBETOwmGbnCyxvCtEw@mail.gmail.com>
	<CAH4pYpQgCp2FpnDyM5_+uuZvsM+nNojcW3fn9AAUYji3PMeNAQ@mail.gmail.com>
	<CAHNn8BXbMzFqeAkd6wzDK5=0ZbhtFkbtc0EW_TbM+wKpvjihFA@mail.gmail.com>
	<CAH4pYpTSLdQmXKou3x5u9YrYeR1H_w+R6nvQ8YpFmdB1cKWhvw@mail.gmail.com>
	<CAHNn8BVbpo59MX+3aWs3H200cNZNXM4wCOTS3AowwVwXAuztdQ@mail.gmail.com>
Message-ID: <CAH4pYpQNTZf_ap_vFxs4DeETaebu+rA+z3Z9MFdrH5i68Ahc0A@mail.gmail.com>

On Tue, Jun 19, 2012 at 5:01 PM, MinRK <benjaminrk at gmail.com> wrote:
>
>
> On Tue, Jun 19, 2012 at 4:20 PM, Brian Granger <ellisonbg at gmail.com> wrote:
>>
>> When the metadata PR come up, I was originally going to vote -1 on it
>> because of this issue. ?I sat on it for a while and in the end decided
>> that it was OK because I think the need for metadata is already upon
>> us even though we don't have an actual usage case in our own code base
>> (for example, we don't have a metadata UI in the notebook web app).
>>
>> There is a fine line to walk here. ?On one hand, I completely agree
>> with you that we should try to future-proof the notebook format to
>> minimize disruptive format changes. ?On the other hand, adding things
>> too soon leads to even more potential disruption for the following
>> reason. ?As I developed the notebook format and notebook UI last
>> summer, there were multiple situations where I added something to the
>> notebook format before I actually used it in the UI. ?In many of these
>> cases, when I did get around to developing the UI for it, I realized
>> that my original thoughts on that element were incomplete. ?It wasn't
>> until I wrote the UI that used the data that I realized exactly what
>> the format of that data needed to be. ?As a result, I had to go back
>> and modify the notebook format. ?After a few iterations of this, I
>> realized that this approach was broken and started to enforce the
>> following simple rule on myself: don't add it to the notebook format
>> until I am ready to write the UI code that uses it. ?That rule served
>> me very well last summer.
>>
>> This is why for example the notebook and cells do not currently have
>> any timestamp information (even though I think we will eventually want
>> it). ?The one notebook feature (which I regret adding to the format)
>> that doesn't have a UI is the multiple worksheets. ?We absolutely want
>> that as a feature, I just wish I had waited to add it to the notebook
>> format. ?When we do implement the mulitple worksheet UI, it is likely
>> we will want to go back and make changes to the notebook format to
>> better reflect the UI (for example, we will probably want to persist
>> which worksheet is active/open).
>
>
> I couldn't agree less. ?There is simply no reason that adding support for
> multiple worksheets in future versions of IPython should render single-sheet
> notebooks unreadable in 0.13, just like adding new metadata should not make
> the notebook artificially unreadable.

I am not sure I am following you on this.  Are you suggesting that
0.14 notebooks (let's say we bump to a v4 nbformat with expanded
worksheet support) should be readable in 0.13?

>>
>>
>> For the cell and worksheet metadata, I knew we would eventually need
>> it and I didn't want to hold up the beta release any longer. ?But
>> there are still unanswered questions related to it:
>>
>> * What types of things go in the metadata?
>>
>> * Is this an area for us to write data to, or for advanced users to
>> write data to?
>> * Is it entirely unstructured, or will we require a discussion for
>> each new key/value entry into it.
>>
>>
>> It is not at all clean that the current metadata design will hold up
>> to our answers of these questions. ?But in the end, I sort of wanted
>> to add the metadata as it is now, so we could being to see how we and
>> others start to use it. ?But just because we added the metadata to the
>> notebook format definitely doesn't mean that future-proofs this part
>> of the notebook format.
>>
>>
>> Hope this clarifies things a bit.
>
>
> Sure, while it is extremely clear that we need cell metadata, we cannot be
> 100% certain that
> a simple dict will solve 100% of the cases we encounter. ?But adding it now
> means that we have at least a *chance*
> of making a release that is not backwards-incompatible.

Yes, I agree with this.

>>
>>
>> Back to the question of output-level metadata. ?When a bit of code
>> remains unused for almost a year, I start to question whether we
>> really need it. ?I not convinced we don't need it, I am not sure. ?In
>> light of this, I don't think that adding it to the notebook format
>> makes sense. ?When one of us finds a good purpose for this metadata,
>> let's add it to the nbformat them.
>
>
> I believe the only current use is in the parallel display republishing,
> where the engine ID is added to the display data
> so that frontends could theoretically draw display data differently based on
> which engine it came from.

Yes, we have discussed this.  The only other situation where I
remember thinking about this is if we wanted to use metadata to help a
frontend interpret JSON display data.  There are numerous reasons code
might display JSON data, and that code would have to help the frontend
to know what to do with that data.

Do you think the engine ID idea makes sense to implement or should
that information just be passed in the formatted display data itself?
We could also handle by creating a custom JS widget that knows how to
intelligently display data from multiple engines.

>>
>>
>> The other philosophical line of reasoning that I am being guided by
>> here is simplicity. ?It would be very easy to over design the notebook
>> format and add all sorts of feature that we might need. ?I think this
>> is a wrong direction to go. ?We want a notebook format that is as
>> compact and minimal as possible, where each and every bit of data is
>> there for a well-defined and justified reason.
>
>
> I think it's simple: We have had ideas over and over and over again for
> features requiring metadata attached to cells (hashes, links, timestamps,
> etc.), so this is clearly a feature we have a need for right now.

Yes - maybe I wasn't completely clear.  I do think that having cell
and worksheet metadata right now does make sense.

> ?It would
> be totally silly for adding timestamps to require updating the nbformat in a
> backward-incompatible way.

And I am definitely not suggesting that it would or should.

> ?And the biggest advantage of using json is that
> adding keys has no effect on backwards *readability*. ?It's only adding
> values/types that can cause problems, and should force new versions (e.g.
> changing worsheet to worksheets, or adding new cell types).

Yes, JSON indeed turned out to be much nicer than XML for this type of
thing exactly because of this.

But I am wondering what your thought are about newer notebook versions
being readable by older IPython versions.  I have always thought that
we would promise that older nbformats would *always* be readable by
newer IPython versions, but that we would make no promises about newer
nformats being readable by older IPython versions.  I just want to
clarify what other people are thinking in this respect.

Cheers,

Brian

> -MinRK
>
>>
>> Cheers,
>>
>> Brian
>>
>>
>>
>> On Tue, Jun 19, 2012 at 3:25 PM, MinRK <benjaminrk at gmail.com> wrote:
>> >
>> >
>> > On Tue, Jun 19, 2012 at 3:23 PM, Brian Granger <ellisonbg at gmail.com>
>> > wrote:
>> >>
>> >> On Tue, Jun 19, 2012 at 3:19 PM, MinRK <benjaminrk at gmail.com> wrote:
>> >> >
>> >> >
>> >> > On Tue, Jun 19, 2012 at 3:18 PM, Brian Granger <ellisonbg at gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> On Tue, Jun 19, 2012 at 2:59 PM, Fernando Perez
>> >> >> <fperez.net at gmail.com>
>> >> >> wrote:
>> >> >> > On Tue, Jun 19, 2012 at 1:17 PM, MinRK <benjaminrk at gmail.com>
>> >> >> > wrote:
>> >> >> >> Yes - we put metadata on outputs for a reason, presumably. ?If
>> >> >> >> this
>> >> >> >> shouldn't be saved, it should probably be removed from the API.
>> >> >> >
>> >> >> > I can't recall precisely what we had in mind when we put it in,
>> >> >> > but
>> >> >> > something that springs to mind as potentially useful, for example,
>> >> >> > would be to specify a desired priority order for the various types
>> >> >> > of
>> >> >> > outputs. Right now when a client can display several kinds of
>> >> >> > output
>> >> >> > it just makes a choice, but we could let objects provide a hint of
>> >> >> > the
>> >> >> > preferred order, based on what they know about the relative
>> >> >> > quality
>> >> >> > of
>> >> >> > each.
>> >> >>
>> >> >> I originally put it there to allow objects to provide hints to the
>> >> >> frontend on how it should display a representation. ?This is similar
>> >> >> to how the payloads can indicate where it came from.
>> >> >>
>> >> >> > So I'd vote for not removing this, as it may prove useful...
>> >> >>
>> >> >> I also think it could be useful, although it seems a bit excessive
>> >> >> to
>> >> >> store metadata for each output. ?Here is what I propose. ?We simply
>> >> >> leave it alone until we have an actual use case that will help us
>> >> >> figure out exactly what this should look like. ?Without a concrete
>> >> >> usage case, it is difficult to know what is needed.
>> >> >
>> >> >
>> >> > But this doesn't answer the immediate question: Should this metadata
>> >> > dict be
>> >> > included in the nbformat
>> >>
>> >> I would vote no - not until we have a real usage case. ?I don't like
>> >> to add things to the notebook format until we are actually using them.
>> >
>> >
>> > Then should we remove all of the metadata stuff we just added? ?The
>> > whole
>> > point was to prepare the nbformat for future changes to we don't have to
>> > update the nbformat, which is incredibly painful and should be done as
>> > rarely as possible.
>> >
>> > -MinRK
>> >
>> >>
>> >>
>> >> >>
>> >> >>
>> >> >> > f
>> >> >> > _______________________________________________
>> >> >> > IPython-dev mailing list
>> >> >> > IPython-dev at scipy.org
>> >> >> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Brian E. Granger
>> >> >> Cal Poly State University, San Luis Obispo
>> >> >> bgranger at calpoly.edu and ellisonbg at gmail.com
>> >> >> _______________________________________________
>> >> >> IPython-dev mailing list
>> >> >> IPython-dev at scipy.org
>> >> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > IPython-dev mailing list
>> >> > IPython-dev at scipy.org
>> >> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Brian E. Granger
>> >> Cal Poly State University, San Luis Obispo
>> >> bgranger at calpoly.edu and ellisonbg at gmail.com
>> >> _______________________________________________
>> >> IPython-dev mailing list
>> >> IPython-dev at scipy.org
>> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >
>> >
>> >
>> > _______________________________________________
>> > IPython-dev mailing list
>> > IPython-dev at scipy.org
>> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >
>>
>>
>>
>> --
>> Brian E. Granger
>> Cal Poly State University, San Luis Obispo
>> bgranger at calpoly.edu and ellisonbg at gmail.com
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



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


From benjaminrk at gmail.com  Tue Jun 19 22:49:09 2012
From: benjaminrk at gmail.com (MinRK)
Date: Tue, 19 Jun 2012 19:49:09 -0700
Subject: [IPython-dev] magics and metadata
In-Reply-To: <CAH4pYpQNTZf_ap_vFxs4DeETaebu+rA+z3Z9MFdrH5i68Ahc0A@mail.gmail.com>
References: <CANmCCuSwUiDtOxsNdRKDe5jJxwSP7z=r2x8jSxOGFN+ygiB-Zw@mail.gmail.com>
	<CAOvn4qhjOcGQJWovO0HnUov80nxEnz=PL8Z8ob6KR0OsXxJ_jg@mail.gmail.com>
	<CANmCCuT4eb72b-9A+k1m+Qt9zovL32fESsmoE9u_2WZD6WCNTg@mail.gmail.com>
	<CAOvn4qj0-ULiBwCHZmC+qJBy1512PRny=df+SQs4xo2DQgKkgw@mail.gmail.com>
	<CANmCCuRAdoDEpV4dNHefEPG6uBpc6OzRH-e46cgx6mstm0cczA@mail.gmail.com>
	<CAHNn8BUDEGFGspdbabQdKmWfP7xDKd5Sx0qUymjncjc_rbqmEA@mail.gmail.com>
	<CAH4pYpSno_q1hQpyfrUBxpNVSD+SrLWkBeucGBLuY8=aOJgD3g@mail.gmail.com>
	<CAHNn8BVA8YvvJ4bw3epNR7NA=B7XQgGXa5Dh_x9kzwABkv7bPg@mail.gmail.com>
	<CAHAreOrFUaf_fP4cnjv4KmHciEK5b60A5uhifu8GH2FbmR3dxQ@mail.gmail.com>
	<CAH4pYpTTQ=pwFvF+oiSQFd6JDUo6iw3L6DL7+3WzHwSMSmFvug@mail.gmail.com>
	<CAHNn8BXJRjRYM-i7M2NSfdkfZxS-2WkyqBETOwmGbnCyxvCtEw@mail.gmail.com>
	<CAH4pYpQgCp2FpnDyM5_+uuZvsM+nNojcW3fn9AAUYji3PMeNAQ@mail.gmail.com>
	<CAHNn8BXbMzFqeAkd6wzDK5=0ZbhtFkbtc0EW_TbM+wKpvjihFA@mail.gmail.com>
	<CAH4pYpTSLdQmXKou3x5u9YrYeR1H_w+R6nvQ8YpFmdB1cKWhvw@mail.gmail.com>
	<CAHNn8BVbpo59MX+3aWs3H200cNZNXM4wCOTS3AowwVwXAuztdQ@mail.gmail.com>
	<CAH4pYpQNTZf_ap_vFxs4DeETaebu+rA+z3Z9MFdrH5i68Ahc0A@mail.gmail.com>
Message-ID: <CAHNn8BV+fkzkdz9onTY67_2fRV55u8dBkDTJ0bjiXqjRGxPPDw@mail.gmail.com>

On Tue, Jun 19, 2012 at 7:25 PM, Brian Granger <ellisonbg at gmail.com> wrote:

> On Tue, Jun 19, 2012 at 5:01 PM, MinRK <benjaminrk at gmail.com> wrote:
> >
> >
> > On Tue, Jun 19, 2012 at 4:20 PM, Brian Granger <ellisonbg at gmail.com>
> wrote:
> >>
> >> When the metadata PR come up, I was originally going to vote -1 on it
> >> because of this issue.  I sat on it for a while and in the end decided
> >> that it was OK because I think the need for metadata is already upon
> >> us even though we don't have an actual usage case in our own code base
> >> (for example, we don't have a metadata UI in the notebook web app).
> >>
> >> There is a fine line to walk here.  On one hand, I completely agree
> >> with you that we should try to future-proof the notebook format to
> >> minimize disruptive format changes.  On the other hand, adding things
> >> too soon leads to even more potential disruption for the following
> >> reason.  As I developed the notebook format and notebook UI last
> >> summer, there were multiple situations where I added something to the
> >> notebook format before I actually used it in the UI.  In many of these
> >> cases, when I did get around to developing the UI for it, I realized
> >> that my original thoughts on that element were incomplete.  It wasn't
> >> until I wrote the UI that used the data that I realized exactly what
> >> the format of that data needed to be.  As a result, I had to go back
> >> and modify the notebook format.  After a few iterations of this, I
> >> realized that this approach was broken and started to enforce the
> >> following simple rule on myself: don't add it to the notebook format
> >> until I am ready to write the UI code that uses it.  That rule served
> >> me very well last summer.
> >>
> >> This is why for example the notebook and cells do not currently have
> >> any timestamp information (even though I think we will eventually want
> >> it).  The one notebook feature (which I regret adding to the format)
> >> that doesn't have a UI is the multiple worksheets.  We absolutely want
> >> that as a feature, I just wish I had waited to add it to the notebook
> >> format.  When we do implement the mulitple worksheet UI, it is likely
> >> we will want to go back and make changes to the notebook format to
> >> better reflect the UI (for example, we will probably want to persist
> >> which worksheet is active/open).
> >
> >
> > I couldn't agree less.  There is simply no reason that adding support for
> > multiple worksheets in future versions of IPython should render
> single-sheet
> > notebooks unreadable in 0.13, just like adding new metadata should not
> make
> > the notebook artificially unreadable.
>
> I am not sure I am following you on this.  Are you suggesting that
> 0.14 notebooks (let's say we bump to a v4 nbformat with expanded
> worksheet support) should be readable in 0.13?
>

I think I am saying the opposite - with the current state of 0.13, adding
multi-worksheet support to the *javascript* should not result in
incrementing the notebook version.


>
> >>
> >>
> >> For the cell and worksheet metadata, I knew we would eventually need
> >> it and I didn't want to hold up the beta release any longer.  But
> >> there are still unanswered questions related to it:
> >>
> >> * What types of things go in the metadata?
> >>
> >> * Is this an area for us to write data to, or for advanced users to
> >> write data to?
> >> * Is it entirely unstructured, or will we require a discussion for
> >> each new key/value entry into it.
> >>
> >>
> >> It is not at all clean that the current metadata design will hold up
> >> to our answers of these questions.  But in the end, I sort of wanted
> >> to add the metadata as it is now, so we could being to see how we and
> >> others start to use it.  But just because we added the metadata to the
> >> notebook format definitely doesn't mean that future-proofs this part
> >> of the notebook format.
> >>
> >>
> >> Hope this clarifies things a bit.
> >
> >
> > Sure, while it is extremely clear that we need cell metadata, we cannot
> be
> > 100% certain that
> > a simple dict will solve 100% of the cases we encounter.  But adding it
> now
> > means that we have at least a *chance*
> > of making a release that is not backwards-incompatible.
>
> Yes, I agree with this.
>
> >>
> >>
> >> Back to the question of output-level metadata.  When a bit of code
> >> remains unused for almost a year, I start to question whether we
> >> really need it.  I not convinced we don't need it, I am not sure.  In
> >> light of this, I don't think that adding it to the notebook format
> >> makes sense.  When one of us finds a good purpose for this metadata,
> >> let's add it to the nbformat them.
> >
> >
> > I believe the only current use is in the parallel display republishing,
> > where the engine ID is added to the display data
> > so that frontends could theoretically draw display data differently
> based on
> > which engine it came from.
>
> Yes, we have discussed this.  The only other situation where I
> remember thinking about this is if we wanted to use metadata to help a
> frontend interpret JSON display data.  There are numerous reasons code
> might display JSON data, and that code would have to help the frontend
> to know what to do with that data.
>
> Do you think the engine ID idea makes sense to implement or should
> that information just be passed in the formatted display data itself?
> We could also handle by creating a custom JS widget that knows how to
> intelligently display data from multiple engines.
>

Right now I do both since the metadata is totally ignored, but I think it's
better to have less markup in the output itself.  It is precisely the same
reason we don't embed the rendered prompt in the output of execute replies
- frontends have their own way of rendering them (in the prompt column,
etc.).  The metadata could be used to do that for parallel results, rather
than the current behavior of having fakee prompts in the general output
area.


> >>
> >>
> >> The other philosophical line of reasoning that I am being guided by
> >> here is simplicity.  It would be very easy to over design the notebook
> >> format and add all sorts of feature that we might need.  I think this
> >> is a wrong direction to go.  We want a notebook format that is as
> >> compact and minimal as possible, where each and every bit of data is
> >> there for a well-defined and justified reason.
> >
> >
> > I think it's simple: We have had ideas over and over and over again for
> > features requiring metadata attached to cells (hashes, links, timestamps,
> > etc.), so this is clearly a feature we have a need for right now.
>
> Yes - maybe I wasn't completely clear.  I do think that having cell
> and worksheet metadata right now does make sense.
>
> >  It would
> > be totally silly for adding timestamps to require updating the nbformat
> in a
> > backward-incompatible way.
>
> And I am definitely not suggesting that it would or should.
>
> >  And the biggest advantage of using json is that
> > adding keys has no effect on backwards *readability*.  It's only adding
> > values/types that can cause problems, and should force new versions (e.g.
> > changing worsheet to worksheets, or adding new cell types).
>
> Yes, JSON indeed turned out to be much nicer than XML for this type of
> thing exactly because of this.
>
> But I am wondering what your thought are about newer notebook versions
> being readable by older IPython versions.  I have always thought that
> we would promise that older nbformats would *always* be readable by
> newer IPython versions, but that we would make no promises about newer
> nformats being readable by older IPython versions.  I just want to
> clarify what other people are thinking in this respect.
>

Incrementing the nbformat means making notebooks unreadable in old
versions, yes.
This is very painful if we are doing it every six months.  I am only trying
to make
reasonable efforts that the current nbformat is prepared for changes we
*know* we intend to make soon,
so that incrementing the nbformat is reserved for changes we don't already
have planned, and aren't
already prepared for.
Obviously, if we have a change that we cannot fit into the current format,
then we increment.
But where we are right now, adding to the metadata on cells or adding
multiple worksheets will *not* require
bumping the nbformat.


>
> Cheers,
>
> Brian
>
> > -MinRK
> >
> >>
> >> Cheers,
> >>
> >> Brian
> >>
> >>
> >>
> >> On Tue, Jun 19, 2012 at 3:25 PM, MinRK <benjaminrk at gmail.com> wrote:
> >> >
> >> >
> >> > On Tue, Jun 19, 2012 at 3:23 PM, Brian Granger <ellisonbg at gmail.com>
> >> > wrote:
> >> >>
> >> >> On Tue, Jun 19, 2012 at 3:19 PM, MinRK <benjaminrk at gmail.com> wrote:
> >> >> >
> >> >> >
> >> >> > On Tue, Jun 19, 2012 at 3:18 PM, Brian Granger <
> ellisonbg at gmail.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> On Tue, Jun 19, 2012 at 2:59 PM, Fernando Perez
> >> >> >> <fperez.net at gmail.com>
> >> >> >> wrote:
> >> >> >> > On Tue, Jun 19, 2012 at 1:17 PM, MinRK <benjaminrk at gmail.com>
> >> >> >> > wrote:
> >> >> >> >> Yes - we put metadata on outputs for a reason, presumably.  If
> >> >> >> >> this
> >> >> >> >> shouldn't be saved, it should probably be removed from the API.
> >> >> >> >
> >> >> >> > I can't recall precisely what we had in mind when we put it in,
> >> >> >> > but
> >> >> >> > something that springs to mind as potentially useful, for
> example,
> >> >> >> > would be to specify a desired priority order for the various
> types
> >> >> >> > of
> >> >> >> > outputs. Right now when a client can display several kinds of
> >> >> >> > output
> >> >> >> > it just makes a choice, but we could let objects provide a hint
> of
> >> >> >> > the
> >> >> >> > preferred order, based on what they know about the relative
> >> >> >> > quality
> >> >> >> > of
> >> >> >> > each.
> >> >> >>
> >> >> >> I originally put it there to allow objects to provide hints to the
> >> >> >> frontend on how it should display a representation.  This is
> similar
> >> >> >> to how the payloads can indicate where it came from.
> >> >> >>
> >> >> >> > So I'd vote for not removing this, as it may prove useful...
> >> >> >>
> >> >> >> I also think it could be useful, although it seems a bit excessive
> >> >> >> to
> >> >> >> store metadata for each output.  Here is what I propose.  We
> simply
> >> >> >> leave it alone until we have an actual use case that will help us
> >> >> >> figure out exactly what this should look like.  Without a concrete
> >> >> >> usage case, it is difficult to know what is needed.
> >> >> >
> >> >> >
> >> >> > But this doesn't answer the immediate question: Should this
> metadata
> >> >> > dict be
> >> >> > included in the nbformat
> >> >>
> >> >> I would vote no - not until we have a real usage case.  I don't like
> >> >> to add things to the notebook format until we are actually using
> them.
> >> >
> >> >
> >> > Then should we remove all of the metadata stuff we just added?  The
> >> > whole
> >> > point was to prepare the nbformat for future changes to we don't have
> to
> >> > update the nbformat, which is incredibly painful and should be done as
> >> > rarely as possible.
> >> >
> >> > -MinRK
> >> >
> >> >>
> >> >>
> >> >> >>
> >> >> >>
> >> >> >> > f
> >> >> >> > _______________________________________________
> >> >> >> > IPython-dev mailing list
> >> >> >> > IPython-dev at scipy.org
> >> >> >> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> Brian E. Granger
> >> >> >> Cal Poly State University, San Luis Obispo
> >> >> >> bgranger at calpoly.edu and ellisonbg at gmail.com
> >> >> >> _______________________________________________
> >> >> >> IPython-dev mailing list
> >> >> >> IPython-dev at scipy.org
> >> >> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >> >> >
> >> >> >
> >> >> >
> >> >> > _______________________________________________
> >> >> > IPython-dev mailing list
> >> >> > IPython-dev at scipy.org
> >> >> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Brian E. Granger
> >> >> Cal Poly State University, San Luis Obispo
> >> >> bgranger at calpoly.edu and ellisonbg at gmail.com
> >> >> _______________________________________________
> >> >> IPython-dev mailing list
> >> >> IPython-dev at scipy.org
> >> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > IPython-dev mailing list
> >> > IPython-dev at scipy.org
> >> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> >> >
> >>
> >>
> >>
> >> --
> >> Brian E. Granger
> >> Cal Poly State University, San Luis Obispo
> >> bgranger at calpoly.edu and ellisonbg at gmail.com
> >> _______________________________________________
> >> IPython-dev mailing list
> >> IPython-dev at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >
> >
> >
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> >
>
>
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu and ellisonbg at gmail.com
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120619/a4c3cb5a/attachment.html>

From jason-sage at creativetrax.com  Wed Jun 20 00:54:25 2012
From: jason-sage at creativetrax.com (Jason Grout)
Date: Tue, 19 Jun 2012 23:54:25 -0500
Subject: [IPython-dev] IPythonInputSplitter.cell_magic_parts and
	InteractiveShell
Message-ID: <4FE15781.4010409@creativetrax.com>

I'm working on getting the 0.13beta1 to work with Sage.  One problem is 
that the InteractiveShell code assumes that the input splitter has a 
.cell_magic_parts attribute (see line 2559 of 
IPython/core/interactiveshell.py).  Now, this is not an attribute of 
InputSplitter, but is an attribute of IPythonInputSplitter.  Do we have 
to depend on having this attribute, or should InteractiveShell first 
check for the existence of this attribute?  In Sage, we have our own 
SageInputSplitter which inherits directly from InputSplitter, and so we 
don't have the .cell_magic_parts attribute.

In other words, how decoupled do you want InteractiveShell and the 
IPythonInputSplitter subclass of InputSplitter?

Thanks,

Jason


From benjaminrk at gmail.com  Wed Jun 20 00:58:29 2012
From: benjaminrk at gmail.com (MinRK)
Date: Tue, 19 Jun 2012 21:58:29 -0700
Subject: [IPython-dev] IPythonInputSplitter.cell_magic_parts and
	InteractiveShell
In-Reply-To: <4FE15781.4010409@creativetrax.com>
References: <4FE15781.4010409@creativetrax.com>
Message-ID: <CAHNn8BUbEGuMAi0weTCEh--CkUCeHsGthdzaW+-ox+0ti1O6gw@mail.gmail.com>

On Tue, Jun 19, 2012 at 9:54 PM, Jason Grout <jason-sage at creativetrax.com>wrote:

> I'm working on getting the 0.13beta1 to work with Sage.  One problem is
> that the InteractiveShell code assumes that the input splitter has a
> .cell_magic_parts attribute (see line 2559 of
> IPython/core/interactiveshell.py).  Now, this is not an attribute of
> InputSplitter, but is an attribute of IPythonInputSplitter.  Do we have
> to depend on having this attribute, or should InteractiveShell first
> check for the existence of this attribute?  In Sage, we have our own
> SageInputSplitter which inherits directly from InputSplitter, and so we
> don't have the .cell_magic_parts attribute.
>
> In other words, how decoupled do you want InteractiveShell and the
> IPythonInputSplitter subclass of InputSplitter?
>

I think we can just set InputSplitter.cell_magic_parts = None, so that it's
clearly defined as an unused part of the public input splitter api.

or we use getattr in InteractiveShell, but I think we generally try to
avoid that.




>
> Thanks,
>
> Jason
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120619/14984431/attachment.html>

From jason-sage at creativetrax.com  Wed Jun 20 09:55:53 2012
From: jason-sage at creativetrax.com (Jason Grout)
Date: Wed, 20 Jun 2012 08:55:53 -0500
Subject: [IPython-dev] IPythonInputSplitter.cell_magic_parts and
	InteractiveShell
In-Reply-To: <CAHNn8BUbEGuMAi0weTCEh--CkUCeHsGthdzaW+-ox+0ti1O6gw@mail.gmail.com>
References: <4FE15781.4010409@creativetrax.com>
	<CAHNn8BUbEGuMAi0weTCEh--CkUCeHsGthdzaW+-ox+0ti1O6gw@mail.gmail.com>
Message-ID: <4FE1D669.6020107@creativetrax.com>

On 6/19/12 11:58 PM, MinRK wrote:
>
>
> On Tue, Jun 19, 2012 at 9:54 PM, Jason Grout
> <jason-sage at creativetrax.com <mailto:jason-sage at creativetrax.com>> wrote:
>
>     I'm working on getting the 0.13beta1 to work with Sage.  One problem is
>     that the InteractiveShell code assumes that the input splitter has a
>     .cell_magic_parts attribute (see line 2559 of
>     IPython/core/interactiveshell.py).  Now, this is not an attribute of
>     InputSplitter, but is an attribute of IPythonInputSplitter.  Do we have
>     to depend on having this attribute, or should InteractiveShell first
>     check for the existence of this attribute?  In Sage, we have our own
>     SageInputSplitter which inherits directly from InputSplitter, and so we
>     don't have the .cell_magic_parts attribute.
>
>     In other words, how decoupled do you want InteractiveShell and the
>     IPythonInputSplitter subclass of InputSplitter?
>
>
> I think we can just set InputSplitter.cell_magic_parts = None, so that
> it's clearly defined as an unused part of the public input splitter api.

That seems odd since InputSplitter doesn't do anything else with cell 
magics, right?  But if this is the way to go, it would be great if there 
was documentation (in your huge amount of spare time :) about what 
should go into that variable (seeing how we also have something like 
cell magics that would be interesting to see if we could now push into 
your system).


>
> or we use getattr in InteractiveShell, but I think we generally try to
> avoid that.

It seems like there should be a better solution, unless InputSplitter 
really will have cell magic features.  Maybe some sort of method in 
InputSplitter that creates a cell, instead of having InteractiveShell 
reach into the class to a variable to create a cell's code? 
IPythonSplitter would override the method to deal with cell magics, but 
it could be pretty straightforward in the InputSplitter class. 
Admittedly, I haven't looked very closely at exactly what happens to the 
cell_magic_parts variable, so I don't know if this is a real solution.

Thanks,

Jason


From admin at erazor-zone.de  Wed Jun 20 10:44:27 2012
From: admin at erazor-zone.de (Alexander Krause)
Date: Wed, 20 Jun 2012 16:44:27 +0200
Subject: [IPython-dev] check for "q" or abort in a custom magic-function
Message-ID: <1340203467.22086.12.camel@erazor-zone.de>

Hi all,

I started to play a bit with iPython today and decided to add some
functions for general automation purposes.

I already implemented a pure ModBus master/slave in python and added
wrote a custom class for a ModBus device.

With iPython it's pretty nice to manipulate and program such devices.
I overloaded the __getattr__ and __setattr__ and am able to read the
value of a device by just typing:
In [3]: AC.OnOff
Out[3]: 0

Or write the value via:
In [4]: AC.OnOff=1


Another nice feature would be to actually monitor the value of a object.

For this purpose I started to write a magic function which more or less
does the same like the linux command watch:
<code python>
ip=get_ipython()

def magic_watch(self,cmd):
	sleep_time=1
	import time
	while True:
		self.ex(cmd)
		time.sleep(sleep_time)

ip.define_magic('watch',magic_watch)
</code>

Is there a way to actually call self.ev? I suppose I've to flush some
stdout buffers to get the output?

How can I check for example for the key q to abort the loop?

Thanks a lot for any hints!

Regards,
Alex




From takowl at gmail.com  Wed Jun 20 11:00:53 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Wed, 20 Jun 2012 16:00:53 +0100
Subject: [IPython-dev] check for "q" or abort in a custom magic-function
In-Reply-To: <1340203467.22086.12.camel@erazor-zone.de>
References: <1340203467.22086.12.camel@erazor-zone.de>
Message-ID: <CAOvn4qgGV_n3+uMeYCbWb2Cpy61pc=Jz4YJ2ULOP59=LyuieOA@mail.gmail.com>

On 20 June 2012 15:44, Alexander Krause <admin at erazor-zone.de> wrote:
> Is there a way to actually call self.ev? I suppose I've to flush some
> stdout buffers to get the output?

Note that it should be self.shell.ev (and likewise for ex()) - this
will become important soon, when we release 0.13.

I'm not quite sure what you mean about stdout buffers, but I think you
want something like this:

# e.g. cmd = "AC.OnOff"
prev_value = self.shell.ev(cmd)
while True:
    time.sleep(sleep_time)
    new_value = self.shell.ev(cmd)
    if new_value != prev_value:
        print("%s changed from %r to %r" % (cmd, prev_value, new_value))
    prev_value = new_value

Checking for a key is trickier, especially across different platforms.
The simplest way is just to use Ctrl+C to interrupt the code.

Best wishes,
Thomas


From ellisonbg at gmail.com  Wed Jun 20 13:06:29 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Wed, 20 Jun 2012 10:06:29 -0700
Subject: [IPython-dev] magics and metadata
In-Reply-To: <CAHNn8BV+fkzkdz9onTY67_2fRV55u8dBkDTJ0bjiXqjRGxPPDw@mail.gmail.com>
References: <CANmCCuSwUiDtOxsNdRKDe5jJxwSP7z=r2x8jSxOGFN+ygiB-Zw@mail.gmail.com>
	<CAOvn4qhjOcGQJWovO0HnUov80nxEnz=PL8Z8ob6KR0OsXxJ_jg@mail.gmail.com>
	<CANmCCuT4eb72b-9A+k1m+Qt9zovL32fESsmoE9u_2WZD6WCNTg@mail.gmail.com>
	<CAOvn4qj0-ULiBwCHZmC+qJBy1512PRny=df+SQs4xo2DQgKkgw@mail.gmail.com>
	<CANmCCuRAdoDEpV4dNHefEPG6uBpc6OzRH-e46cgx6mstm0cczA@mail.gmail.com>
	<CAHNn8BUDEGFGspdbabQdKmWfP7xDKd5Sx0qUymjncjc_rbqmEA@mail.gmail.com>
	<CAH4pYpSno_q1hQpyfrUBxpNVSD+SrLWkBeucGBLuY8=aOJgD3g@mail.gmail.com>
	<CAHNn8BVA8YvvJ4bw3epNR7NA=B7XQgGXa5Dh_x9kzwABkv7bPg@mail.gmail.com>
	<CAHAreOrFUaf_fP4cnjv4KmHciEK5b60A5uhifu8GH2FbmR3dxQ@mail.gmail.com>
	<CAH4pYpTTQ=pwFvF+oiSQFd6JDUo6iw3L6DL7+3WzHwSMSmFvug@mail.gmail.com>
	<CAHNn8BXJRjRYM-i7M2NSfdkfZxS-2WkyqBETOwmGbnCyxvCtEw@mail.gmail.com>
	<CAH4pYpQgCp2FpnDyM5_+uuZvsM+nNojcW3fn9AAUYji3PMeNAQ@mail.gmail.com>
	<CAHNn8BXbMzFqeAkd6wzDK5=0ZbhtFkbtc0EW_TbM+wKpvjihFA@mail.gmail.com>
	<CAH4pYpTSLdQmXKou3x5u9YrYeR1H_w+R6nvQ8YpFmdB1cKWhvw@mail.gmail.com>
	<CAHNn8BVbpo59MX+3aWs3H200cNZNXM4wCOTS3AowwVwXAuztdQ@mail.gmail.com>
	<CAH4pYpQNTZf_ap_vFxs4DeETaebu+rA+z3Z9MFdrH5i68Ahc0A@mail.gmail.com>
	<CAHNn8BV+fkzkdz9onTY67_2fRV55u8dBkDTJ0bjiXqjRGxPPDw@mail.gmail.com>
Message-ID: <CAH4pYpQQPhdRDXAVNCLRwqRJ0F=a0vRdau38BzuXTWa3x8jc3g@mail.gmail.com>

On Tue, Jun 19, 2012 at 7:49 PM, MinRK <benjaminrk at gmail.com> wrote:
>
>
> On Tue, Jun 19, 2012 at 7:25 PM, Brian Granger <ellisonbg at gmail.com> wrote:
>>
>> On Tue, Jun 19, 2012 at 5:01 PM, MinRK <benjaminrk at gmail.com> wrote:
>> >
>> >
>> > On Tue, Jun 19, 2012 at 4:20 PM, Brian Granger <ellisonbg at gmail.com>
>> > wrote:
>> >>
>> >> When the metadata PR come up, I was originally going to vote -1 on it
>> >> because of this issue. ?I sat on it for a while and in the end decided
>> >> that it was OK because I think the need for metadata is already upon
>> >> us even though we don't have an actual usage case in our own code base
>> >> (for example, we don't have a metadata UI in the notebook web app).
>> >>
>> >> There is a fine line to walk here. ?On one hand, I completely agree
>> >> with you that we should try to future-proof the notebook format to
>> >> minimize disruptive format changes. ?On the other hand, adding things
>> >> too soon leads to even more potential disruption for the following
>> >> reason. ?As I developed the notebook format and notebook UI last
>> >> summer, there were multiple situations where I added something to the
>> >> notebook format before I actually used it in the UI. ?In many of these
>> >> cases, when I did get around to developing the UI for it, I realized
>> >> that my original thoughts on that element were incomplete. ?It wasn't
>> >> until I wrote the UI that used the data that I realized exactly what
>> >> the format of that data needed to be. ?As a result, I had to go back
>> >> and modify the notebook format. ?After a few iterations of this, I
>> >> realized that this approach was broken and started to enforce the
>> >> following simple rule on myself: don't add it to the notebook format
>> >> until I am ready to write the UI code that uses it. ?That rule served
>> >> me very well last summer.
>> >>
>> >> This is why for example the notebook and cells do not currently have
>> >> any timestamp information (even though I think we will eventually want
>> >> it). ?The one notebook feature (which I regret adding to the format)
>> >> that doesn't have a UI is the multiple worksheets. ?We absolutely want
>> >> that as a feature, I just wish I had waited to add it to the notebook
>> >> format. ?When we do implement the mulitple worksheet UI, it is likely
>> >> we will want to go back and make changes to the notebook format to
>> >> better reflect the UI (for example, we will probably want to persist
>> >> which worksheet is active/open).
>> >
>> >
>> > I couldn't agree less. ?There is simply no reason that adding support
>> > for
>> > multiple worksheets in future versions of IPython should render
>> > single-sheet
>> > notebooks unreadable in 0.13, just like adding new metadata should not
>> > make
>> > the notebook artificially unreadable.
>>
>> I am not sure I am following you on this. ?Are you suggesting that
>> 0.14 notebooks (let's say we bump to a v4 nbformat with expanded
>> worksheet support) should be readable in 0.13?
>
>
> I think I am saying the opposite - with the current state of 0.13, adding
> multi-worksheet support to the *javascript* should not result in
> incrementing the notebook version.

With the current state of the notebook format, I think we can probably
pull this off.  So far, the only changes to the notebook format I can
imagine will be minor version incrementing ones.

>>
>>
>> >>
>> >>
>> >> For the cell and worksheet metadata, I knew we would eventually need
>> >> it and I didn't want to hold up the beta release any longer. ?But
>> >> there are still unanswered questions related to it:
>> >>
>> >> * What types of things go in the metadata?
>> >>
>> >> * Is this an area for us to write data to, or for advanced users to
>> >> write data to?
>> >> * Is it entirely unstructured, or will we require a discussion for
>> >> each new key/value entry into it.
>> >>
>> >>
>> >> It is not at all clean that the current metadata design will hold up
>> >> to our answers of these questions. ?But in the end, I sort of wanted
>> >> to add the metadata as it is now, so we could being to see how we and
>> >> others start to use it. ?But just because we added the metadata to the
>> >> notebook format definitely doesn't mean that future-proofs this part
>> >> of the notebook format.
>> >>
>> >>
>> >> Hope this clarifies things a bit.
>> >
>> >
>> > Sure, while it is extremely clear that we need cell metadata, we cannot
>> > be
>> > 100% certain that
>> > a simple dict will solve 100% of the cases we encounter. ?But adding it
>> > now
>> > means that we have at least a *chance*
>> > of making a release that is not backwards-incompatible.
>>
>> Yes, I agree with this.
>>
>> >>
>> >>
>> >> Back to the question of output-level metadata. ?When a bit of code
>> >> remains unused for almost a year, I start to question whether we
>> >> really need it. ?I not convinced we don't need it, I am not sure. ?In
>> >> light of this, I don't think that adding it to the notebook format
>> >> makes sense. ?When one of us finds a good purpose for this metadata,
>> >> let's add it to the nbformat them.
>> >
>> >
>> > I believe the only current use is in the parallel display republishing,
>> > where the engine ID is added to the display data
>> > so that frontends could theoretically draw display data differently
>> > based on
>> > which engine it came from.
>>
>> Yes, we have discussed this. ?The only other situation where I
>> remember thinking about this is if we wanted to use metadata to help a
>> frontend interpret JSON display data. ?There are numerous reasons code
>> might display JSON data, and that code would have to help the frontend
>> to know what to do with that data.
>>
>> Do you think the engine ID idea makes sense to implement or should
>> that information just be passed in the formatted display data itself?
>> We could also handle by creating a custom JS widget that knows how to
>> intelligently display data from multiple engines.
>
>
> Right now I do both since the metadata is totally ignored, but I think it's
> better to have less markup in the output itself. ?It is precisely the same
> reason we don't embed the rendered prompt in the output of execute replies -
> frontends have their own way of rendering them (in the prompt column, etc.).
> ?The metadata could be used to do that for parallel results, rather than the
> current behavior of having fakee prompts in the general output area.

OK if you think we want to go this route for displaying the engine
IDs, then we should i) keep the display data metadata in the message
itself and ii) move towards persisting that information in the
nbformat.

>>
>> >>
>> >>
>> >> The other philosophical line of reasoning that I am being guided by
>> >> here is simplicity. ?It would be very easy to over design the notebook
>> >> format and add all sorts of feature that we might need. ?I think this
>> >> is a wrong direction to go. ?We want a notebook format that is as
>> >> compact and minimal as possible, where each and every bit of data is
>> >> there for a well-defined and justified reason.
>> >
>> >
>> > I think it's simple: We have had ideas over and over and over again for
>> > features requiring metadata attached to cells (hashes, links,
>> > timestamps,
>> > etc.), so this is clearly a feature we have a need for right now.
>>
>> Yes - maybe I wasn't completely clear. ?I do think that having cell
>> and worksheet metadata right now does make sense.
>>
>> > ?It would
>> > be totally silly for adding timestamps to require updating the nbformat
>> > in a
>> > backward-incompatible way.
>>
>> And I am definitely not suggesting that it would or should.
>>
>> > ?And the biggest advantage of using json is that
>> > adding keys has no effect on backwards *readability*. ?It's only adding
>> > values/types that can cause problems, and should force new versions
>> > (e.g.
>> > changing worsheet to worksheets, or adding new cell types).
>>
>> Yes, JSON indeed turned out to be much nicer than XML for this type of
>> thing exactly because of this.
>>
>> But I am wondering what your thought are about newer notebook versions
>> being readable by older IPython versions. ?I have always thought that
>> we would promise that older nbformats would *always* be readable by
>> newer IPython versions, but that we would make no promises about newer
>> nformats being readable by older IPython versions. ?I just want to
>> clarify what other people are thinking in this respect.
>
>
> Incrementing the nbformat means making notebooks unreadable in old versions,
> yes.
> This is very painful if we are doing it every six months. ?I am only trying
> to make
> reasonable efforts that the current nbformat is prepared for changes we
> *know* we intend to make soon,
> so that incrementing the nbformat is reserved for changes we don't already
> have planned, and aren't
> already prepared for.
> Obviously,?if we have a change that we cannot fit into the current format,
> then we increment.

I honestly can't think of any upcoming changes to the notebook format
that we have thought about which would require a major version
increment like you are talking about.  I think there are lots of minor
ones that we can do using minor version increments.  I like the minor
versioning scheme we have now as it clarifies our policies on this.
So I think overall, the notebook format is pretty future safe for the
time being.  I hope we can stick with the 3.x nbformats for a few
IPython releases.

> But where we are right now, adding to the metadata on cells or adding
> multiple worksheets will *not* require
> bumping the nbformat.

Right.

Cheers,

Brian

>>
>>
>> Cheers,
>>
>> Brian
>>
>> > -MinRK
>> >
>> >>
>> >> Cheers,
>> >>
>> >> Brian
>> >>
>> >>
>> >>
>> >> On Tue, Jun 19, 2012 at 3:25 PM, MinRK <benjaminrk at gmail.com> wrote:
>> >> >
>> >> >
>> >> > On Tue, Jun 19, 2012 at 3:23 PM, Brian Granger <ellisonbg at gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> On Tue, Jun 19, 2012 at 3:19 PM, MinRK <benjaminrk at gmail.com> wrote:
>> >> >> >
>> >> >> >
>> >> >> > On Tue, Jun 19, 2012 at 3:18 PM, Brian Granger
>> >> >> > <ellisonbg at gmail.com>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> On Tue, Jun 19, 2012 at 2:59 PM, Fernando Perez
>> >> >> >> <fperez.net at gmail.com>
>> >> >> >> wrote:
>> >> >> >> > On Tue, Jun 19, 2012 at 1:17 PM, MinRK <benjaminrk at gmail.com>
>> >> >> >> > wrote:
>> >> >> >> >> Yes - we put metadata on outputs for a reason, presumably. ?If
>> >> >> >> >> this
>> >> >> >> >> shouldn't be saved, it should probably be removed from the
>> >> >> >> >> API.
>> >> >> >> >
>> >> >> >> > I can't recall precisely what we had in mind when we put it in,
>> >> >> >> > but
>> >> >> >> > something that springs to mind as potentially useful, for
>> >> >> >> > example,
>> >> >> >> > would be to specify a desired priority order for the various
>> >> >> >> > types
>> >> >> >> > of
>> >> >> >> > outputs. Right now when a client can display several kinds of
>> >> >> >> > output
>> >> >> >> > it just makes a choice, but we could let objects provide a hint
>> >> >> >> > of
>> >> >> >> > the
>> >> >> >> > preferred order, based on what they know about the relative
>> >> >> >> > quality
>> >> >> >> > of
>> >> >> >> > each.
>> >> >> >>
>> >> >> >> I originally put it there to allow objects to provide hints to
>> >> >> >> the
>> >> >> >> frontend on how it should display a representation. ?This is
>> >> >> >> similar
>> >> >> >> to how the payloads can indicate where it came from.
>> >> >> >>
>> >> >> >> > So I'd vote for not removing this, as it may prove useful...
>> >> >> >>
>> >> >> >> I also think it could be useful, although it seems a bit
>> >> >> >> excessive
>> >> >> >> to
>> >> >> >> store metadata for each output. ?Here is what I propose. ?We
>> >> >> >> simply
>> >> >> >> leave it alone until we have an actual use case that will help us
>> >> >> >> figure out exactly what this should look like. ?Without a
>> >> >> >> concrete
>> >> >> >> usage case, it is difficult to know what is needed.
>> >> >> >
>> >> >> >
>> >> >> > But this doesn't answer the immediate question: Should this
>> >> >> > metadata
>> >> >> > dict be
>> >> >> > included in the nbformat
>> >> >>
>> >> >> I would vote no - not until we have a real usage case. ?I don't like
>> >> >> to add things to the notebook format until we are actually using
>> >> >> them.
>> >> >
>> >> >
>> >> > Then should we remove all of the metadata stuff we just added? ?The
>> >> > whole
>> >> > point was to prepare the nbformat for future changes to we don't have
>> >> > to
>> >> > update the nbformat, which is incredibly painful and should be done
>> >> > as
>> >> > rarely as possible.
>> >> >
>> >> > -MinRK
>> >> >
>> >> >>
>> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> > f
>> >> >> >> > _______________________________________________
>> >> >> >> > IPython-dev mailing list
>> >> >> >> > IPython-dev at scipy.org
>> >> >> >> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> Brian E. Granger
>> >> >> >> Cal Poly State University, San Luis Obispo
>> >> >> >> bgranger at calpoly.edu and ellisonbg at gmail.com
>> >> >> >> _______________________________________________
>> >> >> >> IPython-dev mailing list
>> >> >> >> IPython-dev at scipy.org
>> >> >> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > _______________________________________________
>> >> >> > IPython-dev mailing list
>> >> >> > IPython-dev at scipy.org
>> >> >> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Brian E. Granger
>> >> >> Cal Poly State University, San Luis Obispo
>> >> >> bgranger at calpoly.edu and ellisonbg at gmail.com
>> >> >> _______________________________________________
>> >> >> IPython-dev mailing list
>> >> >> IPython-dev at scipy.org
>> >> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > IPython-dev mailing list
>> >> > IPython-dev at scipy.org
>> >> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Brian E. Granger
>> >> Cal Poly State University, San Luis Obispo
>> >> bgranger at calpoly.edu and ellisonbg at gmail.com
>> >> _______________________________________________
>> >> IPython-dev mailing list
>> >> IPython-dev at scipy.org
>> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >
>> >
>> >
>> > _______________________________________________
>> > IPython-dev mailing list
>> > IPython-dev at scipy.org
>> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >
>>
>>
>>
>> --
>> Brian E. Granger
>> Cal Poly State University, San Luis Obispo
>> bgranger at calpoly.edu and ellisonbg at gmail.com
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



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


From asmeurer at gmail.com  Wed Jun 20 18:09:35 2012
From: asmeurer at gmail.com (Aaron Meurer)
Date: Wed, 20 Jun 2012 16:09:35 -0600
Subject: [IPython-dev] magics and metadata
In-Reply-To: <CAH4pYpQQPhdRDXAVNCLRwqRJ0F=a0vRdau38BzuXTWa3x8jc3g@mail.gmail.com>
References: <CANmCCuSwUiDtOxsNdRKDe5jJxwSP7z=r2x8jSxOGFN+ygiB-Zw@mail.gmail.com>
	<CAOvn4qhjOcGQJWovO0HnUov80nxEnz=PL8Z8ob6KR0OsXxJ_jg@mail.gmail.com>
	<CANmCCuT4eb72b-9A+k1m+Qt9zovL32fESsmoE9u_2WZD6WCNTg@mail.gmail.com>
	<CAOvn4qj0-ULiBwCHZmC+qJBy1512PRny=df+SQs4xo2DQgKkgw@mail.gmail.com>
	<CANmCCuRAdoDEpV4dNHefEPG6uBpc6OzRH-e46cgx6mstm0cczA@mail.gmail.com>
	<CAHNn8BUDEGFGspdbabQdKmWfP7xDKd5Sx0qUymjncjc_rbqmEA@mail.gmail.com>
	<CAH4pYpSno_q1hQpyfrUBxpNVSD+SrLWkBeucGBLuY8=aOJgD3g@mail.gmail.com>
	<CAHNn8BVA8YvvJ4bw3epNR7NA=B7XQgGXa5Dh_x9kzwABkv7bPg@mail.gmail.com>
	<CAHAreOrFUaf_fP4cnjv4KmHciEK5b60A5uhifu8GH2FbmR3dxQ@mail.gmail.com>
	<CAH4pYpTTQ=pwFvF+oiSQFd6JDUo6iw3L6DL7+3WzHwSMSmFvug@mail.gmail.com>
	<CAHNn8BXJRjRYM-i7M2NSfdkfZxS-2WkyqBETOwmGbnCyxvCtEw@mail.gmail.com>
	<CAH4pYpQgCp2FpnDyM5_+uuZvsM+nNojcW3fn9AAUYji3PMeNAQ@mail.gmail.com>
	<CAHNn8BXbMzFqeAkd6wzDK5=0ZbhtFkbtc0EW_TbM+wKpvjihFA@mail.gmail.com>
	<CAH4pYpTSLdQmXKou3x5u9YrYeR1H_w+R6nvQ8YpFmdB1cKWhvw@mail.gmail.com>
	<CAHNn8BVbpo59MX+3aWs3H200cNZNXM4wCOTS3AowwVwXAuztdQ@mail.gmail.com>
	<CAH4pYpQNTZf_ap_vFxs4DeETaebu+rA+z3Z9MFdrH5i68Ahc0A@mail.gmail.com>
	<CAHNn8BV+fkzkdz9onTY67_2fRV55u8dBkDTJ0bjiXqjRGxPPDw@mail.gmail.com>
	<CAH4pYpQQPhdRDXAVNCLRwqRJ0F=a0vRdau38BzuXTWa3x8jc3g@mail.gmail.com>
Message-ID: <-2552066753873341102@unknownmsgid>

On Jun 20, 2012, at 11:06 AM, Brian Granger <ellisonbg at gmail.com> wrote:

> On Tue, Jun 19, 2012 at 7:49 PM, MinRK <benjaminrk at gmail.com> wrote:
>>
>>
>> On Tue, Jun 19, 2012 at 7:25 PM, Brian Granger <ellisonbg at gmail.com> wrote:
>>>
>>> On Tue, Jun 19, 2012 at 5:01 PM, MinRK <benjaminrk at gmail.com> wrote:
>>>>
>>>>
>>>> On Tue, Jun 19, 2012 at 4:20 PM, Brian Granger <ellisonbg at gmail.com>
>>>> wrote:
>>>>>
>>>>> When the metadata PR come up, I was originally going to vote -1 on it
>>>>> because of this issue.  I sat on it for a while and in the end decided
>>>>> that it was OK because I think the need for metadata is already upon
>>>>> us even though we don't have an actual usage case in our own code base
>>>>> (for example, we don't have a metadata UI in the notebook web app).
>>>>>
>>>>> There is a fine line to walk here.  On one hand, I completely agree
>>>>> with you that we should try to future-proof the notebook format to
>>>>> minimize disruptive format changes.  On the other hand, adding things
>>>>> too soon leads to even more potential disruption for the following
>>>>> reason.  As I developed the notebook format and notebook UI last
>>>>> summer, there were multiple situations where I added something to the
>>>>> notebook format before I actually used it in the UI.  In many of these
>>>>> cases, when I did get around to developing the UI for it, I realized
>>>>> that my original thoughts on that element were incomplete.  It wasn't
>>>>> until I wrote the UI that used the data that I realized exactly what
>>>>> the format of that data needed to be.  As a result, I had to go back
>>>>> and modify the notebook format.  After a few iterations of this, I
>>>>> realized that this approach was broken and started to enforce the
>>>>> following simple rule on myself: don't add it to the notebook format
>>>>> until I am ready to write the UI code that uses it.  That rule served
>>>>> me very well last summer.
>>>>>
>>>>> This is why for example the notebook and cells do not currently have
>>>>> any timestamp information (even though I think we will eventually want
>>>>> it).  The one notebook feature (which I regret adding to the format)
>>>>> that doesn't have a UI is the multiple worksheets.  We absolutely want
>>>>> that as a feature, I just wish I had waited to add it to the notebook
>>>>> format.  When we do implement the mulitple worksheet UI, it is likely
>>>>> we will want to go back and make changes to the notebook format to
>>>>> better reflect the UI (for example, we will probably want to persist
>>>>> which worksheet is active/open).
>>>>
>>>>
>>>> I couldn't agree less.  There is simply no reason that adding support
>>>> for
>>>> multiple worksheets in future versions of IPython should render
>>>> single-sheet
>>>> notebooks unreadable in 0.13, just like adding new metadata should not
>>>> make
>>>> the notebook artificially unreadable.
>>>
>>> I am not sure I am following you on this.  Are you suggesting that
>>> 0.14 notebooks (let's say we bump to a v4 nbformat with expanded
>>> worksheet support) should be readable in 0.13?
>>
>>
>> I think I am saying the opposite - with the current state of 0.13, adding
>> multi-worksheet support to the *javascript* should not result in
>> incrementing the notebook version.
>
> With the current state of the notebook format, I think we can probably
> pull this off.  So far, the only changes to the notebook format I can
> imagine will be minor version incrementing ones.
>
>>>
>>>
>>>>>
>>>>>
>>>>> For the cell and worksheet metadata, I knew we would eventually need
>>>>> it and I didn't want to hold up the beta release any longer.  But
>>>>> there are still unanswered questions related to it:
>>>>>
>>>>> * What types of things go in the metadata?
>>>>>
>>>>> * Is this an area for us to write data to, or for advanced users to
>>>>> write data to?
>>>>> * Is it entirely unstructured, or will we require a discussion for
>>>>> each new key/value entry into it.
>>>>>
>>>>>
>>>>> It is not at all clean that the current metadata design will hold up
>>>>> to our answers of these questions.  But in the end, I sort of wanted
>>>>> to add the metadata as it is now, so we could being to see how we and
>>>>> others start to use it.  But just because we added the metadata to the
>>>>> notebook format definitely doesn't mean that future-proofs this part
>>>>> of the notebook format.
>>>>>
>>>>>
>>>>> Hope this clarifies things a bit.
>>>>
>>>>
>>>> Sure, while it is extremely clear that we need cell metadata, we cannot
>>>> be
>>>> 100% certain that
>>>> a simple dict will solve 100% of the cases we encounter.  But adding it
>>>> now
>>>> means that we have at least a *chance*
>>>> of making a release that is not backwards-incompatible.
>>>
>>> Yes, I agree with this.
>>>
>>>>>
>>>>>
>>>>> Back to the question of output-level metadata.  When a bit of code
>>>>> remains unused for almost a year, I start to question whether we
>>>>> really need it.  I not convinced we don't need it, I am not sure.  In
>>>>> light of this, I don't think that adding it to the notebook format
>>>>> makes sense.  When one of us finds a good purpose for this metadata,
>>>>> let's add it to the nbformat them.
>>>>
>>>>
>>>> I believe the only current use is in the parallel display republishing,
>>>> where the engine ID is added to the display data
>>>> so that frontends could theoretically draw display data differently
>>>> based on
>>>> which engine it came from.
>>>
>>> Yes, we have discussed this.  The only other situation where I
>>> remember thinking about this is if we wanted to use metadata to help a
>>> frontend interpret JSON display data.  There are numerous reasons code
>>> might display JSON data, and that code would have to help the frontend
>>> to know what to do with that data.
>>>
>>> Do you think the engine ID idea makes sense to implement or should
>>> that information just be passed in the formatted display data itself?
>>> We could also handle by creating a custom JS widget that knows how to
>>> intelligently display data from multiple engines.
>>
>>
>> Right now I do both since the metadata is totally ignored, but I think it's
>> better to have less markup in the output itself.  It is precisely the same
>> reason we don't embed the rendered prompt in the output of execute replies -
>> frontends have their own way of rendering them (in the prompt column, etc.).
>>  The metadata could be used to do that for parallel results, rather than the
>> current behavior of having fakee prompts in the general output area.
>
> OK if you think we want to go this route for displaying the engine
> IDs, then we should i) keep the display data metadata in the message
> itself and ii) move towards persisting that information in the
> nbformat.
>
>>>
>>>>>
>>>>>
>>>>> The other philosophical line of reasoning that I am being guided by
>>>>> here is simplicity.  It would be very easy to over design the notebook
>>>>> format and add all sorts of feature that we might need.  I think this
>>>>> is a wrong direction to go.  We want a notebook format that is as
>>>>> compact and minimal as possible, where each and every bit of data is
>>>>> there for a well-defined and justified reason.
>>>>
>>>>
>>>> I think it's simple: We have had ideas over and over and over again for
>>>> features requiring metadata attached to cells (hashes, links,
>>>> timestamps,
>>>> etc.), so this is clearly a feature we have a need for right now.
>>>
>>> Yes - maybe I wasn't completely clear.  I do think that having cell
>>> and worksheet metadata right now does make sense.
>>>
>>>>  It would
>>>> be totally silly for adding timestamps to require updating the nbformat
>>>> in a
>>>> backward-incompatible way.
>>>
>>> And I am definitely not suggesting that it would or should.
>>>
>>>>  And the biggest advantage of using json is that
>>>> adding keys has no effect on backwards *readability*.  It's only adding
>>>> values/types that can cause problems, and should force new versions
>>>> (e.g.
>>>> changing worsheet to worksheets, or adding new cell types).
>>>
>>> Yes, JSON indeed turned out to be much nicer than XML for this type of
>>> thing exactly because of this.
>>>
>>> But I am wondering what your thought are about newer notebook versions
>>> being readable by older IPython versions.  I have always thought that
>>> we would promise that older nbformats would *always* be readable by
>>> newer IPython versions, but that we would make no promises about newer
>>> nformats being readable by older IPython versions.  I just want to
>>> clarify what other people are thinking in this respect.
>>
>>
>> Incrementing the nbformat means making notebooks unreadable in old versions,
>> yes.
>> This is very painful if we are doing it every six months.  I am only trying
>> to make
>> reasonable efforts that the current nbformat is prepared for changes we
>> *know* we intend to make soon,
>> so that incrementing the nbformat is reserved for changes we don't already
>> have planned, and aren't
>> already prepared for.
>> Obviously, if we have a change that we cannot fit into the current format,
>> then we increment.
>
> I honestly can't think of any upcoming changes to the notebook format
> that we have thought about which would require a major version
> increment like you are talking about.  I think there are lots of minor
> ones that we can do using minor version increments.  I like the minor
> versioning scheme we have now as it clarifies our policies on this.
> So I think overall, the notebook format is pretty future safe for the
> time being.  I hope we can stick with the 3.x nbformats for a few
> IPython releases.

I'm curious what the effective difference between a minor version and
a major version would be to me, the user. Would you try to make minor
versions backward compatible if possible, either by not putting in new
keys if they don't need to be there or by somehow trying to future
proof the notebook to new unexpected notebook format changes?

Because as far as I, the user, am concerned, if a newer notebook
format version doesn't work at all in older versions of IPython (such
as is the case with notebook format v3 and IPython 0.12), then it
hardly matters how "major" or "minor" the changes were. Or maybe you
are thinking more for the benefit of people like Sage who are building
on top of the notebook API?

By the way, I completely agree with Brian that future proofing is
usually a waste of time. But also be careful against overly "past
proofing". I would much rather see new features added to the notebook,
even every release, than to have them held back simply for the
purposes of keeping things backwards compatible. Also, if jumping the
gun on future proofing is a waste of time, so is spending a lot of
effort on making sure that new notebook versions work correctly in
older, unsupported releases.

Aaron Meurer

>
>> But where we are right now, adding to the metadata on cells or adding
>> multiple worksheets will *not* require
>> bumping the nbformat.
>
> Right.
>
> Cheers,
>
> Brian
>
>>>
>>>
>>> Cheers,
>>>
>>> Brian
>>>
>>>> -MinRK
>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Brian
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jun 19, 2012 at 3:25 PM, MinRK <benjaminrk at gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>> On Tue, Jun 19, 2012 at 3:23 PM, Brian Granger <ellisonbg at gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> On Tue, Jun 19, 2012 at 3:19 PM, MinRK <benjaminrk at gmail.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jun 19, 2012 at 3:18 PM, Brian Granger
>>>>>>>> <ellisonbg at gmail.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> On Tue, Jun 19, 2012 at 2:59 PM, Fernando Perez
>>>>>>>>> <fperez.net at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>> On Tue, Jun 19, 2012 at 1:17 PM, MinRK <benjaminrk at gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>> Yes - we put metadata on outputs for a reason, presumably.  If
>>>>>>>>>>> this
>>>>>>>>>>> shouldn't be saved, it should probably be removed from the
>>>>>>>>>>> API.
>>>>>>>>>>
>>>>>>>>>> I can't recall precisely what we had in mind when we put it in,
>>>>>>>>>> but
>>>>>>>>>> something that springs to mind as potentially useful, for
>>>>>>>>>> example,
>>>>>>>>>> would be to specify a desired priority order for the various
>>>>>>>>>> types
>>>>>>>>>> of
>>>>>>>>>> outputs. Right now when a client can display several kinds of
>>>>>>>>>> output
>>>>>>>>>> it just makes a choice, but we could let objects provide a hint
>>>>>>>>>> of
>>>>>>>>>> the
>>>>>>>>>> preferred order, based on what they know about the relative
>>>>>>>>>> quality
>>>>>>>>>> of
>>>>>>>>>> each.
>>>>>>>>>
>>>>>>>>> I originally put it there to allow objects to provide hints to
>>>>>>>>> the
>>>>>>>>> frontend on how it should display a representation.  This is
>>>>>>>>> similar
>>>>>>>>> to how the payloads can indicate where it came from.
>>>>>>>>>
>>>>>>>>>> So I'd vote for not removing this, as it may prove useful...
>>>>>>>>>
>>>>>>>>> I also think it could be useful, although it seems a bit
>>>>>>>>> excessive
>>>>>>>>> to
>>>>>>>>> store metadata for each output.  Here is what I propose.  We
>>>>>>>>> simply
>>>>>>>>> leave it alone until we have an actual use case that will help us
>>>>>>>>> figure out exactly what this should look like.  Without a
>>>>>>>>> concrete
>>>>>>>>> usage case, it is difficult to know what is needed.
>>>>>>>>
>>>>>>>>
>>>>>>>> But this doesn't answer the immediate question: Should this
>>>>>>>> metadata
>>>>>>>> dict be
>>>>>>>> included in the nbformat
>>>>>>>
>>>>>>> I would vote no - not until we have a real usage case.  I don't like
>>>>>>> to add things to the notebook format until we are actually using
>>>>>>> them.
>>>>>>
>>>>>>
>>>>>> Then should we remove all of the metadata stuff we just added?  The
>>>>>> whole
>>>>>> point was to prepare the nbformat for future changes to we don't have
>>>>>> to
>>>>>> update the nbformat, which is incredibly painful and should be done
>>>>>> as
>>>>>> rarely as possible.
>>>>>>
>>>>>> -MinRK
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> f
>>>>>>>>>> _______________________________________________
>>>>>>>>>> IPython-dev mailing list
>>>>>>>>>> IPython-dev at scipy.org
>>>>>>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Brian E. Granger
>>>>>>>>> Cal Poly State University, San Luis Obispo
>>>>>>>>> bgranger at calpoly.edu and ellisonbg at gmail.com
>>>>>>>>> _______________________________________________
>>>>>>>>> IPython-dev mailing list
>>>>>>>>> IPython-dev at scipy.org
>>>>>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> IPython-dev mailing list
>>>>>>>> IPython-dev at scipy.org
>>>>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Brian E. Granger
>>>>>>> Cal Poly State University, San Luis Obispo
>>>>>>> bgranger at calpoly.edu and ellisonbg at gmail.com
>>>>>>> _______________________________________________
>>>>>>> IPython-dev mailing list
>>>>>>> IPython-dev at scipy.org
>>>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> IPython-dev mailing list
>>>>>> IPython-dev at scipy.org
>>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Brian E. Granger
>>>>> Cal Poly State University, San Luis Obispo
>>>>> bgranger at calpoly.edu and ellisonbg at gmail.com
>>>>> _______________________________________________
>>>>> IPython-dev mailing list
>>>>> IPython-dev at scipy.org
>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> IPython-dev mailing list
>>>> IPython-dev at scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>
>>>
>>>
>>>
>>> --
>>> Brian E. Granger
>>> Cal Poly State University, San Luis Obispo
>>> bgranger at calpoly.edu and ellisonbg at gmail.com
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>>
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>
>
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu and ellisonbg at gmail.com
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev


From benjaminrk at gmail.com  Wed Jun 20 19:03:47 2012
From: benjaminrk at gmail.com (MinRK)
Date: Wed, 20 Jun 2012 16:03:47 -0700
Subject: [IPython-dev] magics and metadata
In-Reply-To: <-2552066753873341102@unknownmsgid>
References: <CANmCCuSwUiDtOxsNdRKDe5jJxwSP7z=r2x8jSxOGFN+ygiB-Zw@mail.gmail.com>
	<CAOvn4qhjOcGQJWovO0HnUov80nxEnz=PL8Z8ob6KR0OsXxJ_jg@mail.gmail.com>
	<CANmCCuT4eb72b-9A+k1m+Qt9zovL32fESsmoE9u_2WZD6WCNTg@mail.gmail.com>
	<CAOvn4qj0-ULiBwCHZmC+qJBy1512PRny=df+SQs4xo2DQgKkgw@mail.gmail.com>
	<CANmCCuRAdoDEpV4dNHefEPG6uBpc6OzRH-e46cgx6mstm0cczA@mail.gmail.com>
	<CAHNn8BUDEGFGspdbabQdKmWfP7xDKd5Sx0qUymjncjc_rbqmEA@mail.gmail.com>
	<CAH4pYpSno_q1hQpyfrUBxpNVSD+SrLWkBeucGBLuY8=aOJgD3g@mail.gmail.com>
	<CAHNn8BVA8YvvJ4bw3epNR7NA=B7XQgGXa5Dh_x9kzwABkv7bPg@mail.gmail.com>
	<CAHAreOrFUaf_fP4cnjv4KmHciEK5b60A5uhifu8GH2FbmR3dxQ@mail.gmail.com>
	<CAH4pYpTTQ=pwFvF+oiSQFd6JDUo6iw3L6DL7+3WzHwSMSmFvug@mail.gmail.com>
	<CAHNn8BXJRjRYM-i7M2NSfdkfZxS-2WkyqBETOwmGbnCyxvCtEw@mail.gmail.com>
	<CAH4pYpQgCp2FpnDyM5_+uuZvsM+nNojcW3fn9AAUYji3PMeNAQ@mail.gmail.com>
	<CAHNn8BXbMzFqeAkd6wzDK5=0ZbhtFkbtc0EW_TbM+wKpvjihFA@mail.gmail.com>
	<CAH4pYpTSLdQmXKou3x5u9YrYeR1H_w+R6nvQ8YpFmdB1cKWhvw@mail.gmail.com>
	<CAHNn8BVbpo59MX+3aWs3H200cNZNXM4wCOTS3AowwVwXAuztdQ@mail.gmail.com>
	<CAH4pYpQNTZf_ap_vFxs4DeETaebu+rA+z3Z9MFdrH5i68Ahc0A@mail.gmail.com>
	<CAHNn8BV+fkzkdz9onTY67_2fRV55u8dBkDTJ0bjiXqjRGxPPDw@mail.gmail.com>
	<CAH4pYpQQPhdRDXAVNCLRwqRJ0F=a0vRdau38BzuXTWa3x8jc3g@mail.gmail.com>
	<-2552066753873341102@unknownmsgid>
Message-ID: <CAHNn8BVfsahD2+a_9S1pVzFLx_8+OCzah4kQSPG9fHX9MQXG7Q@mail.gmail.com>

On Wed, Jun 20, 2012 at 3:09 PM, Aaron Meurer <asmeurer at gmail.com> wrote:

> On Jun 20, 2012, at 11:06 AM, Brian Granger <ellisonbg at gmail.com> wrote:
>
> > On Tue, Jun 19, 2012 at 7:49 PM, MinRK <benjaminrk at gmail.com> wrote:
> >>
> >>
> >> On Tue, Jun 19, 2012 at 7:25 PM, Brian Granger <ellisonbg at gmail.com>
> wrote:
> >>>
> >>> On Tue, Jun 19, 2012 at 5:01 PM, MinRK <benjaminrk at gmail.com> wrote:
> >>>>
> >>>>
> >>>> On Tue, Jun 19, 2012 at 4:20 PM, Brian Granger <ellisonbg at gmail.com>
> >>>> wrote:
> >>>>>
> >>>>> When the metadata PR come up, I was originally going to vote -1 on it
> >>>>> because of this issue.  I sat on it for a while and in the end
> decided
> >>>>> that it was OK because I think the need for metadata is already upon
> >>>>> us even though we don't have an actual usage case in our own code
> base
> >>>>> (for example, we don't have a metadata UI in the notebook web app).
> >>>>>
> >>>>> There is a fine line to walk here.  On one hand, I completely agree
> >>>>> with you that we should try to future-proof the notebook format to
> >>>>> minimize disruptive format changes.  On the other hand, adding things
> >>>>> too soon leads to even more potential disruption for the following
> >>>>> reason.  As I developed the notebook format and notebook UI last
> >>>>> summer, there were multiple situations where I added something to the
> >>>>> notebook format before I actually used it in the UI.  In many of
> these
> >>>>> cases, when I did get around to developing the UI for it, I realized
> >>>>> that my original thoughts on that element were incomplete.  It wasn't
> >>>>> until I wrote the UI that used the data that I realized exactly what
> >>>>> the format of that data needed to be.  As a result, I had to go back
> >>>>> and modify the notebook format.  After a few iterations of this, I
> >>>>> realized that this approach was broken and started to enforce the
> >>>>> following simple rule on myself: don't add it to the notebook format
> >>>>> until I am ready to write the UI code that uses it.  That rule served
> >>>>> me very well last summer.
> >>>>>
> >>>>> This is why for example the notebook and cells do not currently have
> >>>>> any timestamp information (even though I think we will eventually
> want
> >>>>> it).  The one notebook feature (which I regret adding to the format)
> >>>>> that doesn't have a UI is the multiple worksheets.  We absolutely
> want
> >>>>> that as a feature, I just wish I had waited to add it to the notebook
> >>>>> format.  When we do implement the mulitple worksheet UI, it is likely
> >>>>> we will want to go back and make changes to the notebook format to
> >>>>> better reflect the UI (for example, we will probably want to persist
> >>>>> which worksheet is active/open).
> >>>>
> >>>>
> >>>> I couldn't agree less.  There is simply no reason that adding support
> >>>> for
> >>>> multiple worksheets in future versions of IPython should render
> >>>> single-sheet
> >>>> notebooks unreadable in 0.13, just like adding new metadata should not
> >>>> make
> >>>> the notebook artificially unreadable.
> >>>
> >>> I am not sure I am following you on this.  Are you suggesting that
> >>> 0.14 notebooks (let's say we bump to a v4 nbformat with expanded
> >>> worksheet support) should be readable in 0.13?
> >>
> >>
> >> I think I am saying the opposite - with the current state of 0.13,
> adding
> >> multi-worksheet support to the *javascript* should not result in
> >> incrementing the notebook version.
> >
> > With the current state of the notebook format, I think we can probably
> > pull this off.  So far, the only changes to the notebook format I can
> > imagine will be minor version incrementing ones.
> >
> >>>
> >>>
> >>>>>
> >>>>>
> >>>>> For the cell and worksheet metadata, I knew we would eventually need
> >>>>> it and I didn't want to hold up the beta release any longer.  But
> >>>>> there are still unanswered questions related to it:
> >>>>>
> >>>>> * What types of things go in the metadata?
> >>>>>
> >>>>> * Is this an area for us to write data to, or for advanced users to
> >>>>> write data to?
> >>>>> * Is it entirely unstructured, or will we require a discussion for
> >>>>> each new key/value entry into it.
> >>>>>
> >>>>>
> >>>>> It is not at all clean that the current metadata design will hold up
> >>>>> to our answers of these questions.  But in the end, I sort of wanted
> >>>>> to add the metadata as it is now, so we could being to see how we and
> >>>>> others start to use it.  But just because we added the metadata to
> the
> >>>>> notebook format definitely doesn't mean that future-proofs this part
> >>>>> of the notebook format.
> >>>>>
> >>>>>
> >>>>> Hope this clarifies things a bit.
> >>>>
> >>>>
> >>>> Sure, while it is extremely clear that we need cell metadata, we
> cannot
> >>>> be
> >>>> 100% certain that
> >>>> a simple dict will solve 100% of the cases we encounter.  But adding
> it
> >>>> now
> >>>> means that we have at least a *chance*
> >>>> of making a release that is not backwards-incompatible.
> >>>
> >>> Yes, I agree with this.
> >>>
> >>>>>
> >>>>>
> >>>>> Back to the question of output-level metadata.  When a bit of code
> >>>>> remains unused for almost a year, I start to question whether we
> >>>>> really need it.  I not convinced we don't need it, I am not sure.  In
> >>>>> light of this, I don't think that adding it to the notebook format
> >>>>> makes sense.  When one of us finds a good purpose for this metadata,
> >>>>> let's add it to the nbformat them.
> >>>>
> >>>>
> >>>> I believe the only current use is in the parallel display
> republishing,
> >>>> where the engine ID is added to the display data
> >>>> so that frontends could theoretically draw display data differently
> >>>> based on
> >>>> which engine it came from.
> >>>
> >>> Yes, we have discussed this.  The only other situation where I
> >>> remember thinking about this is if we wanted to use metadata to help a
> >>> frontend interpret JSON display data.  There are numerous reasons code
> >>> might display JSON data, and that code would have to help the frontend
> >>> to know what to do with that data.
> >>>
> >>> Do you think the engine ID idea makes sense to implement or should
> >>> that information just be passed in the formatted display data itself?
> >>> We could also handle by creating a custom JS widget that knows how to
> >>> intelligently display data from multiple engines.
> >>
> >>
> >> Right now I do both since the metadata is totally ignored, but I think
> it's
> >> better to have less markup in the output itself.  It is precisely the
> same
> >> reason we don't embed the rendered prompt in the output of execute
> replies -
> >> frontends have their own way of rendering them (in the prompt column,
> etc.).
> >>  The metadata could be used to do that for parallel results, rather
> than the
> >> current behavior of having fakee prompts in the general output area.
> >
> > OK if you think we want to go this route for displaying the engine
> > IDs, then we should i) keep the display data metadata in the message
> > itself and ii) move towards persisting that information in the
> > nbformat.
> >
> >>>
> >>>>>
> >>>>>
> >>>>> The other philosophical line of reasoning that I am being guided by
> >>>>> here is simplicity.  It would be very easy to over design the
> notebook
> >>>>> format and add all sorts of feature that we might need.  I think this
> >>>>> is a wrong direction to go.  We want a notebook format that is as
> >>>>> compact and minimal as possible, where each and every bit of data is
> >>>>> there for a well-defined and justified reason.
> >>>>
> >>>>
> >>>> I think it's simple: We have had ideas over and over and over again
> for
> >>>> features requiring metadata attached to cells (hashes, links,
> >>>> timestamps,
> >>>> etc.), so this is clearly a feature we have a need for right now.
> >>>
> >>> Yes - maybe I wasn't completely clear.  I do think that having cell
> >>> and worksheet metadata right now does make sense.
> >>>
> >>>>  It would
> >>>> be totally silly for adding timestamps to require updating the
> nbformat
> >>>> in a
> >>>> backward-incompatible way.
> >>>
> >>> And I am definitely not suggesting that it would or should.
> >>>
> >>>>  And the biggest advantage of using json is that
> >>>> adding keys has no effect on backwards *readability*.  It's only
> adding
> >>>> values/types that can cause problems, and should force new versions
> >>>> (e.g.
> >>>> changing worsheet to worksheets, or adding new cell types).
> >>>
> >>> Yes, JSON indeed turned out to be much nicer than XML for this type of
> >>> thing exactly because of this.
> >>>
> >>> But I am wondering what your thought are about newer notebook versions
> >>> being readable by older IPython versions.  I have always thought that
> >>> we would promise that older nbformats would *always* be readable by
> >>> newer IPython versions, but that we would make no promises about newer
> >>> nformats being readable by older IPython versions.  I just want to
> >>> clarify what other people are thinking in this respect.
> >>
> >>
> >> Incrementing the nbformat means making notebooks unreadable in old
> versions,
> >> yes.
> >> This is very painful if we are doing it every six months.  I am only
> trying
> >> to make
> >> reasonable efforts that the current nbformat is prepared for changes we
> >> *know* we intend to make soon,
> >> so that incrementing the nbformat is reserved for changes we don't
> already
> >> have planned, and aren't
> >> already prepared for.
> >> Obviously, if we have a change that we cannot fit into the current
> format,
> >> then we increment.
> >
> > I honestly can't think of any upcoming changes to the notebook format
> > that we have thought about which would require a major version
> > increment like you are talking about.  I think there are lots of minor
> > ones that we can do using minor version increments.  I like the minor
> > versioning scheme we have now as it clarifies our policies on this.
> > So I think overall, the notebook format is pretty future safe for the
> > time being.  I hope we can stick with the 3.x nbformats for a few
> > IPython releases.
>
> I'm curious what the effective difference between a minor version and
> a major version would be to me, the user. Would you try to make minor
> versions backward compatible if possible, either by not putting in new
> keys if they don't need to be there or by somehow trying to future
> proof the notebook to new unexpected notebook format changes?
>

Major version: totally unreadable, don't even try
Minor revision: newer features are obviously unavailable, but the format is
fundamentally readable

The minor version stuff is not meant to make it impossible, or even any
harder, to update the nbformat.  Only to give us a mechanism for expressing
 "this notebook is newer, and may use features you don't have, but at least
you can still read it", which we did not have before - there was no
distinction between "created by exactly this version" and "totally
unreadable".


> Because as far as I, the user, am concerned, if a newer notebook
> format version doesn't work at all in older versions of IPython (such
> as is the case with notebook format v3 and IPython 0.12), then it
> hardly matters how "major" or "minor" the changes were. Or maybe you
> are thinking more for the benefit of people like Sage who are building
> on top of the notebook API?
>

> By the way, I completely agree with Brian that future proofing is
> usually a waste of time. But also be careful against overly "past
> proofing". I would much rather see new features added to the notebook,
> even every release, than to have them held back simply for the
> purposes of keeping things backwards compatible. Also, if jumping the
> gun on future proofing is a waste of time, so is spending a lot of
> effort on making sure that new notebook versions work correctly in
> older, unsupported releases.
>

I totally agree that we should not spend significant effort on future (or
past) proofing, and we haven't.  Nor is there any reason this would cause
resistance to new features that do require updating the nbformat.  If a
hoop must be leapt through to keep the nbformat, then the nbformat should
be updated.  We have a hoop threshold of zero.  This only aims to prevent
*known, planned, imminent features* from necessarily forcing that
unpleasantness (they still may, since they haven't actually been
implemented).

-MinRK


>
> Aaron Meurer
>
> >
> >> But where we are right now, adding to the metadata on cells or adding
> >> multiple worksheets will *not* require
> >> bumping the nbformat.
> >
> > Right.
> >
> > Cheers,
> >
> > Brian
> >
> >>>
> >>>
> >>> Cheers,
> >>>
> >>> Brian
> >>>
> >>>> -MinRK
> >>>>
> >>>>>
> >>>>> Cheers,
> >>>>>
> >>>>> Brian
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Tue, Jun 19, 2012 at 3:25 PM, MinRK <benjaminrk at gmail.com> wrote:
> >>>>>>
> >>>>>>
> >>>>>> On Tue, Jun 19, 2012 at 3:23 PM, Brian Granger <ellisonbg at gmail.com
> >
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> On Tue, Jun 19, 2012 at 3:19 PM, MinRK <benjaminrk at gmail.com>
> wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Tue, Jun 19, 2012 at 3:18 PM, Brian Granger
> >>>>>>>> <ellisonbg at gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> On Tue, Jun 19, 2012 at 2:59 PM, Fernando Perez
> >>>>>>>>> <fperez.net at gmail.com>
> >>>>>>>>> wrote:
> >>>>>>>>>> On Tue, Jun 19, 2012 at 1:17 PM, MinRK <benjaminrk at gmail.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>> Yes - we put metadata on outputs for a reason, presumably.  If
> >>>>>>>>>>> this
> >>>>>>>>>>> shouldn't be saved, it should probably be removed from the
> >>>>>>>>>>> API.
> >>>>>>>>>>
> >>>>>>>>>> I can't recall precisely what we had in mind when we put it in,
> >>>>>>>>>> but
> >>>>>>>>>> something that springs to mind as potentially useful, for
> >>>>>>>>>> example,
> >>>>>>>>>> would be to specify a desired priority order for the various
> >>>>>>>>>> types
> >>>>>>>>>> of
> >>>>>>>>>> outputs. Right now when a client can display several kinds of
> >>>>>>>>>> output
> >>>>>>>>>> it just makes a choice, but we could let objects provide a hint
> >>>>>>>>>> of
> >>>>>>>>>> the
> >>>>>>>>>> preferred order, based on what they know about the relative
> >>>>>>>>>> quality
> >>>>>>>>>> of
> >>>>>>>>>> each.
> >>>>>>>>>
> >>>>>>>>> I originally put it there to allow objects to provide hints to
> >>>>>>>>> the
> >>>>>>>>> frontend on how it should display a representation.  This is
> >>>>>>>>> similar
> >>>>>>>>> to how the payloads can indicate where it came from.
> >>>>>>>>>
> >>>>>>>>>> So I'd vote for not removing this, as it may prove useful...
> >>>>>>>>>
> >>>>>>>>> I also think it could be useful, although it seems a bit
> >>>>>>>>> excessive
> >>>>>>>>> to
> >>>>>>>>> store metadata for each output.  Here is what I propose.  We
> >>>>>>>>> simply
> >>>>>>>>> leave it alone until we have an actual use case that will help us
> >>>>>>>>> figure out exactly what this should look like.  Without a
> >>>>>>>>> concrete
> >>>>>>>>> usage case, it is difficult to know what is needed.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> But this doesn't answer the immediate question: Should this
> >>>>>>>> metadata
> >>>>>>>> dict be
> >>>>>>>> included in the nbformat
> >>>>>>>
> >>>>>>> I would vote no - not until we have a real usage case.  I don't
> like
> >>>>>>> to add things to the notebook format until we are actually using
> >>>>>>> them.
> >>>>>>
> >>>>>>
> >>>>>> Then should we remove all of the metadata stuff we just added?  The
> >>>>>> whole
> >>>>>> point was to prepare the nbformat for future changes to we don't
> have
> >>>>>> to
> >>>>>> update the nbformat, which is incredibly painful and should be done
> >>>>>> as
> >>>>>> rarely as possible.
> >>>>>>
> >>>>>> -MinRK
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> f
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> IPython-dev mailing list
> >>>>>>>>>> IPython-dev at scipy.org
> >>>>>>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Brian E. Granger
> >>>>>>>>> Cal Poly State University, San Luis Obispo
> >>>>>>>>> bgranger at calpoly.edu and ellisonbg at gmail.com
> >>>>>>>>> _______________________________________________
> >>>>>>>>> IPython-dev mailing list
> >>>>>>>>> IPython-dev at scipy.org
> >>>>>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> IPython-dev mailing list
> >>>>>>>> IPython-dev at scipy.org
> >>>>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Brian E. Granger
> >>>>>>> Cal Poly State University, San Luis Obispo
> >>>>>>> bgranger at calpoly.edu and ellisonbg at gmail.com
> >>>>>>> _______________________________________________
> >>>>>>> IPython-dev mailing list
> >>>>>>> IPython-dev at scipy.org
> >>>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> IPython-dev mailing list
> >>>>>> IPython-dev at scipy.org
> >>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Brian E. Granger
> >>>>> Cal Poly State University, San Luis Obispo
> >>>>> bgranger at calpoly.edu and ellisonbg at gmail.com
> >>>>> _______________________________________________
> >>>>> IPython-dev mailing list
> >>>>> IPython-dev at scipy.org
> >>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> IPython-dev mailing list
> >>>> IPython-dev at scipy.org
> >>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Brian E. Granger
> >>> Cal Poly State University, San Luis Obispo
> >>> bgranger at calpoly.edu and ellisonbg at gmail.com
> >>> _______________________________________________
> >>> IPython-dev mailing list
> >>> IPython-dev at scipy.org
> >>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >>
> >>
> >>
> >> _______________________________________________
> >> IPython-dev mailing list
> >> IPython-dev at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >>
> >
> >
> >
> > --
> > Brian E. Granger
> > Cal Poly State University, San Luis Obispo
> > bgranger at calpoly.edu and ellisonbg at gmail.com
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120620/7a06538b/attachment.html>

From asmeurer at gmail.com  Wed Jun 20 19:11:54 2012
From: asmeurer at gmail.com (Aaron Meurer)
Date: Wed, 20 Jun 2012 17:11:54 -0600
Subject: [IPython-dev] magics and metadata
In-Reply-To: <CAHNn8BVfsahD2+a_9S1pVzFLx_8+OCzah4kQSPG9fHX9MQXG7Q@mail.gmail.com>
References: <CANmCCuSwUiDtOxsNdRKDe5jJxwSP7z=r2x8jSxOGFN+ygiB-Zw@mail.gmail.com>
	<CAOvn4qhjOcGQJWovO0HnUov80nxEnz=PL8Z8ob6KR0OsXxJ_jg@mail.gmail.com>
	<CANmCCuT4eb72b-9A+k1m+Qt9zovL32fESsmoE9u_2WZD6WCNTg@mail.gmail.com>
	<CAOvn4qj0-ULiBwCHZmC+qJBy1512PRny=df+SQs4xo2DQgKkgw@mail.gmail.com>
	<CANmCCuRAdoDEpV4dNHefEPG6uBpc6OzRH-e46cgx6mstm0cczA@mail.gmail.com>
	<CAHNn8BUDEGFGspdbabQdKmWfP7xDKd5Sx0qUymjncjc_rbqmEA@mail.gmail.com>
	<CAH4pYpSno_q1hQpyfrUBxpNVSD+SrLWkBeucGBLuY8=aOJgD3g@mail.gmail.com>
	<CAHNn8BVA8YvvJ4bw3epNR7NA=B7XQgGXa5Dh_x9kzwABkv7bPg@mail.gmail.com>
	<CAHAreOrFUaf_fP4cnjv4KmHciEK5b60A5uhifu8GH2FbmR3dxQ@mail.gmail.com>
	<CAH4pYpTTQ=pwFvF+oiSQFd6JDUo6iw3L6DL7+3WzHwSMSmFvug@mail.gmail.com>
	<CAHNn8BXJRjRYM-i7M2NSfdkfZxS-2WkyqBETOwmGbnCyxvCtEw@mail.gmail.com>
	<CAH4pYpQgCp2FpnDyM5_+uuZvsM+nNojcW3fn9AAUYji3PMeNAQ@mail.gmail.com>
	<CAHNn8BXbMzFqeAkd6wzDK5=0ZbhtFkbtc0EW_TbM+wKpvjihFA@mail.gmail.com>
	<CAH4pYpTSLdQmXKou3x5u9YrYeR1H_w+R6nvQ8YpFmdB1cKWhvw@mail.gmail.com>
	<CAHNn8BVbpo59MX+3aWs3H200cNZNXM4wCOTS3AowwVwXAuztdQ@mail.gmail.com>
	<CAH4pYpQNTZf_ap_vFxs4DeETaebu+rA+z3Z9MFdrH5i68Ahc0A@mail.gmail.com>
	<CAHNn8BV+fkzkdz9onTY67_2fRV55u8dBkDTJ0bjiXqjRGxPPDw@mail.gmail.com>
	<CAH4pYpQQPhdRDXAVNCLRwqRJ0F=a0vRdau38BzuXTWa3x8jc3g@mail.gmail.com>
	<-2552066753873341102@unknownmsgid>
	<CAHNn8BVfsahD2+a_9S1pVzFLx_8+OCzah4kQSPG9fHX9MQXG7Q@mail.gmail.com>
Message-ID: <3503889406590463405@unknownmsgid>

On Jun 20, 2012, at 5:04 PM, MinRK <benjaminrk at gmail.com> wrote:



On Wed, Jun 20, 2012 at 3:09 PM, Aaron Meurer <asmeurer at gmail.com> wrote:

> On Jun 20, 2012, at 11:06 AM, Brian Granger <ellisonbg at gmail.com> wrote:
>
> > On Tue, Jun 19, 2012 at 7:49 PM, MinRK <benjaminrk at gmail.com> wrote:
> >>
> >>
> >> On Tue, Jun 19, 2012 at 7:25 PM, Brian Granger <ellisonbg at gmail.com>
> wrote:
> >>>
> >>> On Tue, Jun 19, 2012 at 5:01 PM, MinRK <benjaminrk at gmail.com> wrote:
> >>>>
> >>>>
> >>>> On Tue, Jun 19, 2012 at 4:20 PM, Brian Granger <ellisonbg at gmail.com>
> >>>> wrote:
> >>>>>
> >>>>> When the metadata PR come up, I was originally going to vote -1 on it
> >>>>> because of this issue.  I sat on it for a while and in the end
> decided
> >>>>> that it was OK because I think the need for metadata is already upon
> >>>>> us even though we don't have an actual usage case in our own code
> base
> >>>>> (for example, we don't have a metadata UI in the notebook web app).
> >>>>>
> >>>>> There is a fine line to walk here.  On one hand, I completely agree
> >>>>> with you that we should try to future-proof the notebook format to
> >>>>> minimize disruptive format changes.  On the other hand, adding things
> >>>>> too soon leads to even more potential disruption for the following
> >>>>> reason.  As I developed the notebook format and notebook UI last
> >>>>> summer, there were multiple situations where I added something to the
> >>>>> notebook format before I actually used it in the UI.  In many of
> these
> >>>>> cases, when I did get around to developing the UI for it, I realized
> >>>>> that my original thoughts on that element were incomplete.  It wasn't
> >>>>> until I wrote the UI that used the data that I realized exactly what
> >>>>> the format of that data needed to be.  As a result, I had to go back
> >>>>> and modify the notebook format.  After a few iterations of this, I
> >>>>> realized that this approach was broken and started to enforce the
> >>>>> following simple rule on myself: don't add it to the notebook format
> >>>>> until I am ready to write the UI code that uses it.  That rule served
> >>>>> me very well last summer.
> >>>>>
> >>>>> This is why for example the notebook and cells do not currently have
> >>>>> any timestamp information (even though I think we will eventually
> want
> >>>>> it).  The one notebook feature (which I regret adding to the format)
> >>>>> that doesn't have a UI is the multiple worksheets.  We absolutely
> want
> >>>>> that as a feature, I just wish I had waited to add it to the notebook
> >>>>> format.  When we do implement the mulitple worksheet UI, it is likely
> >>>>> we will want to go back and make changes to the notebook format to
> >>>>> better reflect the UI (for example, we will probably want to persist
> >>>>> which worksheet is active/open).
> >>>>
> >>>>
> >>>> I couldn't agree less.  There is simply no reason that adding support
> >>>> for
> >>>> multiple worksheets in future versions of IPython should render
> >>>> single-sheet
> >>>> notebooks unreadable in 0.13, just like adding new metadata should not
> >>>> make
> >>>> the notebook artificially unreadable.
> >>>
> >>> I am not sure I am following you on this.  Are you suggesting that
> >>> 0.14 notebooks (let's say we bump to a v4 nbformat with expanded
> >>> worksheet support) should be readable in 0.13?
> >>
> >>
> >> I think I am saying the opposite - with the current state of 0.13,
> adding
> >> multi-worksheet support to the *javascript* should not result in
> >> incrementing the notebook version.
> >
> > With the current state of the notebook format, I think we can probably
> > pull this off.  So far, the only changes to the notebook format I can
> > imagine will be minor version incrementing ones.
> >
> >>>
> >>>
> >>>>>
> >>>>>
> >>>>> For the cell and worksheet metadata, I knew we would eventually need
> >>>>> it and I didn't want to hold up the beta release any longer.  But
> >>>>> there are still unanswered questions related to it:
> >>>>>
> >>>>> * What types of things go in the metadata?
> >>>>>
> >>>>> * Is this an area for us to write data to, or for advanced users to
> >>>>> write data to?
> >>>>> * Is it entirely unstructured, or will we require a discussion for
> >>>>> each new key/value entry into it.
> >>>>>
> >>>>>
> >>>>> It is not at all clean that the current metadata design will hold up
> >>>>> to our answers of these questions.  But in the end, I sort of wanted
> >>>>> to add the metadata as it is now, so we could being to see how we and
> >>>>> others start to use it.  But just because we added the metadata to
> the
> >>>>> notebook format definitely doesn't mean that future-proofs this part
> >>>>> of the notebook format.
> >>>>>
> >>>>>
> >>>>> Hope this clarifies things a bit.
> >>>>
> >>>>
> >>>> Sure, while it is extremely clear that we need cell metadata, we
> cannot
> >>>> be
> >>>> 100% certain that
> >>>> a simple dict will solve 100% of the cases we encounter.  But adding
> it
> >>>> now
> >>>> means that we have at least a *chance*
> >>>> of making a release that is not backwards-incompatible.
> >>>
> >>> Yes, I agree with this.
> >>>
> >>>>>
> >>>>>
> >>>>> Back to the question of output-level metadata.  When a bit of code
> >>>>> remains unused for almost a year, I start to question whether we
> >>>>> really need it.  I not convinced we don't need it, I am not sure.  In
> >>>>> light of this, I don't think that adding it to the notebook format
> >>>>> makes sense.  When one of us finds a good purpose for this metadata,
> >>>>> let's add it to the nbformat them.
> >>>>
> >>>>
> >>>> I believe the only current use is in the parallel display
> republishing,
> >>>> where the engine ID is added to the display data
> >>>> so that frontends could theoretically draw display data differently
> >>>> based on
> >>>> which engine it came from.
> >>>
> >>> Yes, we have discussed this.  The only other situation where I
> >>> remember thinking about this is if we wanted to use metadata to help a
> >>> frontend interpret JSON display data.  There are numerous reasons code
> >>> might display JSON data, and that code would have to help the frontend
> >>> to know what to do with that data.
> >>>
> >>> Do you think the engine ID idea makes sense to implement or should
> >>> that information just be passed in the formatted display data itself?
> >>> We could also handle by creating a custom JS widget that knows how to
> >>> intelligently display data from multiple engines.
> >>
> >>
> >> Right now I do both since the metadata is totally ignored, but I think
> it's
> >> better to have less markup in the output itself.  It is precisely the
> same
> >> reason we don't embed the rendered prompt in the output of execute
> replies -
> >> frontends have their own way of rendering them (in the prompt column,
> etc.).
> >>  The metadata could be used to do that for parallel results, rather
> than the
> >> current behavior of having fakee prompts in the general output area.
> >
> > OK if you think we want to go this route for displaying the engine
> > IDs, then we should i) keep the display data metadata in the message
> > itself and ii) move towards persisting that information in the
> > nbformat.
> >
> >>>
> >>>>>
> >>>>>
> >>>>> The other philosophical line of reasoning that I am being guided by
> >>>>> here is simplicity.  It would be very easy to over design the
> notebook
> >>>>> format and add all sorts of feature that we might need.  I think this
> >>>>> is a wrong direction to go.  We want a notebook format that is as
> >>>>> compact and minimal as possible, where each and every bit of data is
> >>>>> there for a well-defined and justified reason.
> >>>>
> >>>>
> >>>> I think it's simple: We have had ideas over and over and over again
> for
> >>>> features requiring metadata attached to cells (hashes, links,
> >>>> timestamps,
> >>>> etc.), so this is clearly a feature we have a need for right now.
> >>>
> >>> Yes - maybe I wasn't completely clear.  I do think that having cell
> >>> and worksheet metadata right now does make sense.
> >>>
> >>>>  It would
> >>>> be totally silly for adding timestamps to require updating the
> nbformat
> >>>> in a
> >>>> backward-incompatible way.
> >>>
> >>> And I am definitely not suggesting that it would or should.
> >>>
> >>>>  And the biggest advantage of using json is that
> >>>> adding keys has no effect on backwards *readability*.  It's only
> adding
> >>>> values/types that can cause problems, and should force new versions
> >>>> (e.g.
> >>>> changing worsheet to worksheets, or adding new cell types).
> >>>
> >>> Yes, JSON indeed turned out to be much nicer than XML for this type of
> >>> thing exactly because of this.
> >>>
> >>> But I am wondering what your thought are about newer notebook versions
> >>> being readable by older IPython versions.  I have always thought that
> >>> we would promise that older nbformats would *always* be readable by
> >>> newer IPython versions, but that we would make no promises about newer
> >>> nformats being readable by older IPython versions.  I just want to
> >>> clarify what other people are thinking in this respect.
> >>
> >>
> >> Incrementing the nbformat means making notebooks unreadable in old
> versions,
> >> yes.
> >> This is very painful if we are doing it every six months.  I am only
> trying
> >> to make
> >> reasonable efforts that the current nbformat is prepared for changes we
> >> *know* we intend to make soon,
> >> so that incrementing the nbformat is reserved for changes we don't
> already
> >> have planned, and aren't
> >> already prepared for.
> >> Obviously, if we have a change that we cannot fit into the current
> format,
> >> then we increment.
> >
> > I honestly can't think of any upcoming changes to the notebook format
> > that we have thought about which would require a major version
> > increment like you are talking about.  I think there are lots of minor
> > ones that we can do using minor version increments.  I like the minor
> > versioning scheme we have now as it clarifies our policies on this.
> > So I think overall, the notebook format is pretty future safe for the
> > time being.  I hope we can stick with the 3.x nbformats for a few
> > IPython releases.
>
> I'm curious what the effective difference between a minor version and
> a major version would be to me, the user. Would you try to make minor
> versions backward compatible if possible, either by not putting in new
> keys if they don't need to be there or by somehow trying to future
> proof the notebook to new unexpected notebook format changes?
>

Major version: totally unreadable, don't even try
Minor revision: newer features are obviously unavailable, but the format is
fundamentally readable

The minor version stuff is not meant to make it impossible, or even any
harder, to update the nbformat.  Only to give us a mechanism for expressing
 "this notebook is newer, and may use features you don't have, but at least
you can still read it", which we did not have before - there was no
distinction between "created by exactly this version" and "totally
unreadable".


So you are going to attempt to keep minor versions backwards compatible?
 Or maybe I'm misunderstanding what you mean by "readable".

Aaron Meurer



> Because as far as I, the user, am concerned, if a newer notebook
> format version doesn't work at all in older versions of IPython (such
> as is the case with notebook format v3 and IPython 0.12), then it
> hardly matters how "major" or "minor" the changes were. Or maybe you
> are thinking more for the benefit of people like Sage who are building
> on top of the notebook API?
>

> By the way, I completely agree with Brian that future proofing is
> usually a waste of time. But also be careful against overly "past
> proofing". I would much rather see new features added to the notebook,
> even every release, than to have them held back simply for the
> purposes of keeping things backwards compatible. Also, if jumping the
> gun on future proofing is a waste of time, so is spending a lot of
> effort on making sure that new notebook versions work correctly in
> older, unsupported releases.
>

I totally agree that we should not spend significant effort on future (or
past) proofing, and we haven't.  Nor is there any reason this would cause
resistance to new features that do require updating the nbformat.  If a
hoop must be leapt through to keep the nbformat, then the nbformat should
be updated.  We have a hoop threshold of zero.  This only aims to prevent
*known, planned, imminent features* from necessarily forcing that
unpleasantness (they still may, since they haven't actually been
implemented).

-MinRK


>
> Aaron Meurer
>
> >
> >> But where we are right now, adding to the metadata on cells or adding
> >> multiple worksheets will *not* require
> >> bumping the nbformat.
> >
> > Right.
> >
> > Cheers,
> >
> > Brian
> >
> >>>
> >>>
> >>> Cheers,
> >>>
> >>> Brian
> >>>
> >>>> -MinRK
> >>>>
> >>>>>
> >>>>> Cheers,
> >>>>>
> >>>>> Brian
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Tue, Jun 19, 2012 at 3:25 PM, MinRK <benjaminrk at gmail.com> wrote:
> >>>>>>
> >>>>>>
> >>>>>> On Tue, Jun 19, 2012 at 3:23 PM, Brian Granger <ellisonbg at gmail.com
> >
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> On Tue, Jun 19, 2012 at 3:19 PM, MinRK <benjaminrk at gmail.com>
> wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Tue, Jun 19, 2012 at 3:18 PM, Brian Granger
> >>>>>>>> <ellisonbg at gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> On Tue, Jun 19, 2012 at 2:59 PM, Fernando Perez
> >>>>>>>>> <fperez.net at gmail.com>
> >>>>>>>>> wrote:
> >>>>>>>>>> On Tue, Jun 19, 2012 at 1:17 PM, MinRK <benjaminrk at gmail.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>> Yes - we put metadata on outputs for a reason, presumably.  If
> >>>>>>>>>>> this
> >>>>>>>>>>> shouldn't be saved, it should probably be removed from the
> >>>>>>>>>>> API.
> >>>>>>>>>>
> >>>>>>>>>> I can't recall precisely what we had in mind when we put it in,
> >>>>>>>>>> but
> >>>>>>>>>> something that springs to mind as potentially useful, for
> >>>>>>>>>> example,
> >>>>>>>>>> would be to specify a desired priority order for the various
> >>>>>>>>>> types
> >>>>>>>>>> of
> >>>>>>>>>> outputs. Right now when a client can display several kinds of
> >>>>>>>>>> output
> >>>>>>>>>> it just makes a choice, but we could let objects provide a hint
> >>>>>>>>>> of
> >>>>>>>>>> the
> >>>>>>>>>> preferred order, based on what they know about the relative
> >>>>>>>>>> quality
> >>>>>>>>>> of
> >>>>>>>>>> each.
> >>>>>>>>>
> >>>>>>>>> I originally put it there to allow objects to provide hints to
> >>>>>>>>> the
> >>>>>>>>> frontend on how it should display a representation.  This is
> >>>>>>>>> similar
> >>>>>>>>> to how the payloads can indicate where it came from.
> >>>>>>>>>
> >>>>>>>>>> So I'd vote for not removing this, as it may prove useful...
> >>>>>>>>>
> >>>>>>>>> I also think it could be useful, although it seems a bit
> >>>>>>>>> excessive
> >>>>>>>>> to
> >>>>>>>>> store metadata for each output.  Here is what I propose.  We
> >>>>>>>>> simply
> >>>>>>>>> leave it alone until we have an actual use case that will help us
> >>>>>>>>> figure out exactly what this should look like.  Without a
> >>>>>>>>> concrete
> >>>>>>>>> usage case, it is difficult to know what is needed.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> But this doesn't answer the immediate question: Should this
> >>>>>>>> metadata
> >>>>>>>> dict be
> >>>>>>>> included in the nbformat
> >>>>>>>
> >>>>>>> I would vote no - not until we have a real usage case.  I don't
> like
> >>>>>>> to add things to the notebook format until we are actually using
> >>>>>>> them.
> >>>>>>
> >>>>>>
> >>>>>> Then should we remove all of the metadata stuff we just added?  The
> >>>>>> whole
> >>>>>> point was to prepare the nbformat for future changes to we don't
> have
> >>>>>> to
> >>>>>> update the nbformat, which is incredibly painful and should be done
> >>>>>> as
> >>>>>> rarely as possible.
> >>>>>>
> >>>>>> -MinRK
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> f
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> IPython-dev mailing list
> >>>>>>>>>> IPython-dev at scipy.org
> >>>>>>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Brian E. Granger
> >>>>>>>>> Cal Poly State University, San Luis Obispo
> >>>>>>>>> bgranger at calpoly.edu and ellisonbg at gmail.com
> >>>>>>>>> _______________________________________________
> >>>>>>>>> IPython-dev mailing list
> >>>>>>>>> IPython-dev at scipy.org
> >>>>>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> IPython-dev mailing list
> >>>>>>>> IPython-dev at scipy.org
> >>>>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Brian E. Granger
> >>>>>>> Cal Poly State University, San Luis Obispo
> >>>>>>> bgranger at calpoly.edu and ellisonbg at gmail.com
> >>>>>>> _______________________________________________
> >>>>>>> IPython-dev mailing list
> >>>>>>> IPython-dev at scipy.org
> >>>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> IPython-dev mailing list
> >>>>>> IPython-dev at scipy.org
> >>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Brian E. Granger
> >>>>> Cal Poly State University, San Luis Obispo
> >>>>> bgranger at calpoly.edu and ellisonbg at gmail.com
> >>>>> _______________________________________________
> >>>>> IPython-dev mailing list
> >>>>> IPython-dev at scipy.org
> >>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> IPython-dev mailing list
> >>>> IPython-dev at scipy.org
> >>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Brian E. Granger
> >>> Cal Poly State University, San Luis Obispo
> >>> bgranger at calpoly.edu and ellisonbg at gmail.com
> >>> _______________________________________________
> >>> IPython-dev mailing list
> >>> IPython-dev at scipy.org
> >>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >>
> >>
> >>
> >> _______________________________________________
> >> IPython-dev mailing list
> >> IPython-dev at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >>
> >
> >
> >
> > --
> > Brian E. Granger
> > Cal Poly State University, San Luis Obispo
> > bgranger at calpoly.edu and ellisonbg at gmail.com
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>

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

From benjaminrk at gmail.com  Wed Jun 20 19:28:53 2012
From: benjaminrk at gmail.com (MinRK)
Date: Wed, 20 Jun 2012 16:28:53 -0700
Subject: [IPython-dev] magics and metadata
In-Reply-To: <3503889406590463405@unknownmsgid>
References: <CANmCCuSwUiDtOxsNdRKDe5jJxwSP7z=r2x8jSxOGFN+ygiB-Zw@mail.gmail.com>
	<CAOvn4qhjOcGQJWovO0HnUov80nxEnz=PL8Z8ob6KR0OsXxJ_jg@mail.gmail.com>
	<CANmCCuT4eb72b-9A+k1m+Qt9zovL32fESsmoE9u_2WZD6WCNTg@mail.gmail.com>
	<CAOvn4qj0-ULiBwCHZmC+qJBy1512PRny=df+SQs4xo2DQgKkgw@mail.gmail.com>
	<CANmCCuRAdoDEpV4dNHefEPG6uBpc6OzRH-e46cgx6mstm0cczA@mail.gmail.com>
	<CAHNn8BUDEGFGspdbabQdKmWfP7xDKd5Sx0qUymjncjc_rbqmEA@mail.gmail.com>
	<CAH4pYpSno_q1hQpyfrUBxpNVSD+SrLWkBeucGBLuY8=aOJgD3g@mail.gmail.com>
	<CAHNn8BVA8YvvJ4bw3epNR7NA=B7XQgGXa5Dh_x9kzwABkv7bPg@mail.gmail.com>
	<CAHAreOrFUaf_fP4cnjv4KmHciEK5b60A5uhifu8GH2FbmR3dxQ@mail.gmail.com>
	<CAH4pYpTTQ=pwFvF+oiSQFd6JDUo6iw3L6DL7+3WzHwSMSmFvug@mail.gmail.com>
	<CAHNn8BXJRjRYM-i7M2NSfdkfZxS-2WkyqBETOwmGbnCyxvCtEw@mail.gmail.com>
	<CAH4pYpQgCp2FpnDyM5_+uuZvsM+nNojcW3fn9AAUYji3PMeNAQ@mail.gmail.com>
	<CAHNn8BXbMzFqeAkd6wzDK5=0ZbhtFkbtc0EW_TbM+wKpvjihFA@mail.gmail.com>
	<CAH4pYpTSLdQmXKou3x5u9YrYeR1H_w+R6nvQ8YpFmdB1cKWhvw@mail.gmail.com>
	<CAHNn8BVbpo59MX+3aWs3H200cNZNXM4wCOTS3AowwVwXAuztdQ@mail.gmail.com>
	<CAH4pYpQNTZf_ap_vFxs4DeETaebu+rA+z3Z9MFdrH5i68Ahc0A@mail.gmail.com>
	<CAHNn8BV+fkzkdz9onTY67_2fRV55u8dBkDTJ0bjiXqjRGxPPDw@mail.gmail.com>
	<CAH4pYpQQPhdRDXAVNCLRwqRJ0F=a0vRdau38BzuXTWa3x8jc3g@mail.gmail.com>
	<-2552066753873341102@unknownmsgid>
	<CAHNn8BVfsahD2+a_9S1pVzFLx_8+OCzah4kQSPG9fHX9MQXG7Q@mail.gmail.com>
	<3503889406590463405@unknownmsgid>
Message-ID: <CAHNn8BUNHP_spWb4PpXK66+fRNhJ4wUBVHQH_T_9j4o+hNxqiw@mail.gmail.com>

On Wed, Jun 20, 2012 at 4:11 PM, Aaron Meurer <asmeurer at gmail.com> wrote:

> On Jun 20, 2012, at 5:04 PM, MinRK <benjaminrk at gmail.com> wrote:
>
>
>
> On Wed, Jun 20, 2012 at 3:09 PM, Aaron Meurer <asmeurer at gmail.com> wrote:
>
>> On Jun 20, 2012, at 11:06 AM, Brian Granger <ellisonbg at gmail.com> wrote:
>>
>> > On Tue, Jun 19, 2012 at 7:49 PM, MinRK <benjaminrk at gmail.com> wrote:
>> >>
>> >>
>> >> On Tue, Jun 19, 2012 at 7:25 PM, Brian Granger <ellisonbg at gmail.com>
>> wrote:
>> >>>
>> >>> On Tue, Jun 19, 2012 at 5:01 PM, MinRK <benjaminrk at gmail.com> wrote:
>> >>>>
>> >>>>
>> >>>> On Tue, Jun 19, 2012 at 4:20 PM, Brian Granger <ellisonbg at gmail.com>
>> >>>> wrote:
>> >>>>>
>> >>>>> When the metadata PR come up, I was originally going to vote -1 on
>> it
>> >>>>> because of this issue.  I sat on it for a while and in the end
>> decided
>> >>>>> that it was OK because I think the need for metadata is already upon
>> >>>>> us even though we don't have an actual usage case in our own code
>> base
>> >>>>> (for example, we don't have a metadata UI in the notebook web app).
>> >>>>>
>> >>>>> There is a fine line to walk here.  On one hand, I completely agree
>> >>>>> with you that we should try to future-proof the notebook format to
>> >>>>> minimize disruptive format changes.  On the other hand, adding
>> things
>> >>>>> too soon leads to even more potential disruption for the following
>> >>>>> reason.  As I developed the notebook format and notebook UI last
>> >>>>> summer, there were multiple situations where I added something to
>> the
>> >>>>> notebook format before I actually used it in the UI.  In many of
>> these
>> >>>>> cases, when I did get around to developing the UI for it, I realized
>> >>>>> that my original thoughts on that element were incomplete.  It
>> wasn't
>> >>>>> until I wrote the UI that used the data that I realized exactly what
>> >>>>> the format of that data needed to be.  As a result, I had to go back
>> >>>>> and modify the notebook format.  After a few iterations of this, I
>> >>>>> realized that this approach was broken and started to enforce the
>> >>>>> following simple rule on myself: don't add it to the notebook format
>> >>>>> until I am ready to write the UI code that uses it.  That rule
>> served
>> >>>>> me very well last summer.
>> >>>>>
>> >>>>> This is why for example the notebook and cells do not currently have
>> >>>>> any timestamp information (even though I think we will eventually
>> want
>> >>>>> it).  The one notebook feature (which I regret adding to the format)
>> >>>>> that doesn't have a UI is the multiple worksheets.  We absolutely
>> want
>> >>>>> that as a feature, I just wish I had waited to add it to the
>> notebook
>> >>>>> format.  When we do implement the mulitple worksheet UI, it is
>> likely
>> >>>>> we will want to go back and make changes to the notebook format to
>> >>>>> better reflect the UI (for example, we will probably want to persist
>> >>>>> which worksheet is active/open).
>> >>>>
>> >>>>
>> >>>> I couldn't agree less.  There is simply no reason that adding support
>> >>>> for
>> >>>> multiple worksheets in future versions of IPython should render
>> >>>> single-sheet
>> >>>> notebooks unreadable in 0.13, just like adding new metadata should
>> not
>> >>>> make
>> >>>> the notebook artificially unreadable.
>> >>>
>> >>> I am not sure I am following you on this.  Are you suggesting that
>> >>> 0.14 notebooks (let's say we bump to a v4 nbformat with expanded
>> >>> worksheet support) should be readable in 0.13?
>> >>
>> >>
>> >> I think I am saying the opposite - with the current state of 0.13,
>> adding
>> >> multi-worksheet support to the *javascript* should not result in
>> >> incrementing the notebook version.
>> >
>> > With the current state of the notebook format, I think we can probably
>> > pull this off.  So far, the only changes to the notebook format I can
>> > imagine will be minor version incrementing ones.
>> >
>> >>>
>> >>>
>> >>>>>
>> >>>>>
>> >>>>> For the cell and worksheet metadata, I knew we would eventually need
>> >>>>> it and I didn't want to hold up the beta release any longer.  But
>> >>>>> there are still unanswered questions related to it:
>> >>>>>
>> >>>>> * What types of things go in the metadata?
>> >>>>>
>> >>>>> * Is this an area for us to write data to, or for advanced users to
>> >>>>> write data to?
>> >>>>> * Is it entirely unstructured, or will we require a discussion for
>> >>>>> each new key/value entry into it.
>> >>>>>
>> >>>>>
>> >>>>> It is not at all clean that the current metadata design will hold up
>> >>>>> to our answers of these questions.  But in the end, I sort of wanted
>> >>>>> to add the metadata as it is now, so we could being to see how we
>> and
>> >>>>> others start to use it.  But just because we added the metadata to
>> the
>> >>>>> notebook format definitely doesn't mean that future-proofs this part
>> >>>>> of the notebook format.
>> >>>>>
>> >>>>>
>> >>>>> Hope this clarifies things a bit.
>> >>>>
>> >>>>
>> >>>> Sure, while it is extremely clear that we need cell metadata, we
>> cannot
>> >>>> be
>> >>>> 100% certain that
>> >>>> a simple dict will solve 100% of the cases we encounter.  But adding
>> it
>> >>>> now
>> >>>> means that we have at least a *chance*
>> >>>> of making a release that is not backwards-incompatible.
>> >>>
>> >>> Yes, I agree with this.
>> >>>
>> >>>>>
>> >>>>>
>> >>>>> Back to the question of output-level metadata.  When a bit of code
>> >>>>> remains unused for almost a year, I start to question whether we
>> >>>>> really need it.  I not convinced we don't need it, I am not sure.
>>  In
>> >>>>> light of this, I don't think that adding it to the notebook format
>> >>>>> makes sense.  When one of us finds a good purpose for this metadata,
>> >>>>> let's add it to the nbformat them.
>> >>>>
>> >>>>
>> >>>> I believe the only current use is in the parallel display
>> republishing,
>> >>>> where the engine ID is added to the display data
>> >>>> so that frontends could theoretically draw display data differently
>> >>>> based on
>> >>>> which engine it came from.
>> >>>
>> >>> Yes, we have discussed this.  The only other situation where I
>> >>> remember thinking about this is if we wanted to use metadata to help a
>> >>> frontend interpret JSON display data.  There are numerous reasons code
>> >>> might display JSON data, and that code would have to help the frontend
>> >>> to know what to do with that data.
>> >>>
>> >>> Do you think the engine ID idea makes sense to implement or should
>> >>> that information just be passed in the formatted display data itself?
>> >>> We could also handle by creating a custom JS widget that knows how to
>> >>> intelligently display data from multiple engines.
>> >>
>> >>
>> >> Right now I do both since the metadata is totally ignored, but I think
>> it's
>> >> better to have less markup in the output itself.  It is precisely the
>> same
>> >> reason we don't embed the rendered prompt in the output of execute
>> replies -
>> >> frontends have their own way of rendering them (in the prompt column,
>> etc.).
>> >>  The metadata could be used to do that for parallel results, rather
>> than the
>> >> current behavior of having fakee prompts in the general output area.
>> >
>> > OK if you think we want to go this route for displaying the engine
>> > IDs, then we should i) keep the display data metadata in the message
>> > itself and ii) move towards persisting that information in the
>> > nbformat.
>> >
>> >>>
>> >>>>>
>> >>>>>
>> >>>>> The other philosophical line of reasoning that I am being guided by
>> >>>>> here is simplicity.  It would be very easy to over design the
>> notebook
>> >>>>> format and add all sorts of feature that we might need.  I think
>> this
>> >>>>> is a wrong direction to go.  We want a notebook format that is as
>> >>>>> compact and minimal as possible, where each and every bit of data is
>> >>>>> there for a well-defined and justified reason.
>> >>>>
>> >>>>
>> >>>> I think it's simple: We have had ideas over and over and over again
>> for
>> >>>> features requiring metadata attached to cells (hashes, links,
>> >>>> timestamps,
>> >>>> etc.), so this is clearly a feature we have a need for right now.
>> >>>
>> >>> Yes - maybe I wasn't completely clear.  I do think that having cell
>> >>> and worksheet metadata right now does make sense.
>> >>>
>> >>>>  It would
>> >>>> be totally silly for adding timestamps to require updating the
>> nbformat
>> >>>> in a
>> >>>> backward-incompatible way.
>> >>>
>> >>> And I am definitely not suggesting that it would or should.
>> >>>
>> >>>>  And the biggest advantage of using json is that
>> >>>> adding keys has no effect on backwards *readability*.  It's only
>> adding
>> >>>> values/types that can cause problems, and should force new versions
>> >>>> (e.g.
>> >>>> changing worsheet to worksheets, or adding new cell types).
>> >>>
>> >>> Yes, JSON indeed turned out to be much nicer than XML for this type of
>> >>> thing exactly because of this.
>> >>>
>> >>> But I am wondering what your thought are about newer notebook versions
>> >>> being readable by older IPython versions.  I have always thought that
>> >>> we would promise that older nbformats would *always* be readable by
>> >>> newer IPython versions, but that we would make no promises about newer
>> >>> nformats being readable by older IPython versions.  I just want to
>> >>> clarify what other people are thinking in this respect.
>> >>
>> >>
>> >> Incrementing the nbformat means making notebooks unreadable in old
>> versions,
>> >> yes.
>> >> This is very painful if we are doing it every six months.  I am only
>> trying
>> >> to make
>> >> reasonable efforts that the current nbformat is prepared for changes we
>> >> *know* we intend to make soon,
>> >> so that incrementing the nbformat is reserved for changes we don't
>> already
>> >> have planned, and aren't
>> >> already prepared for.
>> >> Obviously, if we have a change that we cannot fit into the current
>> format,
>> >> then we increment.
>> >
>> > I honestly can't think of any upcoming changes to the notebook format
>> > that we have thought about which would require a major version
>> > increment like you are talking about.  I think there are lots of minor
>> > ones that we can do using minor version increments.  I like the minor
>> > versioning scheme we have now as it clarifies our policies on this.
>> > So I think overall, the notebook format is pretty future safe for the
>> > time being.  I hope we can stick with the 3.x nbformats for a few
>> > IPython releases.
>>
>> I'm curious what the effective difference between a minor version and
>> a major version would be to me, the user. Would you try to make minor
>> versions backward compatible if possible, either by not putting in new
>> keys if they don't need to be there or by somehow trying to future
>> proof the notebook to new unexpected notebook format changes?
>>
>
> Major version: totally unreadable, don't even try
> Minor revision: newer features are obviously unavailable, but the format
> is fundamentally readable
>
> The minor version stuff is not meant to make it impossible, or even any
> harder, to update the nbformat.  Only to give us a mechanism for expressing
>  "this notebook is newer, and may use features you don't have, but at least
> you can still read it", which we did not have before - there was no
> distinction between "created by exactly this version" and "totally
> unreadable".
>
>
> So you are going to attempt to keep minor versions backwards compatible?
>  Or maybe I'm misunderstanding what you mean by "readable".
>

Backward-compatible only in that the general file format remains readable.
 Obviously, if you make use of features that depend on the changes in the
minor-revision, that part of your notebook will not work.  But if the
fundamental format of the notebook does not change, users of 0.13 can open
the new notebooks, and will get a warning that it was created by newer
IPython.



>
> Aaron Meurer
>
>
>
>> Because as far as I, the user, am concerned, if a newer notebook
>> format version doesn't work at all in older versions of IPython (such
>> as is the case with notebook format v3 and IPython 0.12), then it
>> hardly matters how "major" or "minor" the changes were. Or maybe you
>> are thinking more for the benefit of people like Sage who are building
>> on top of the notebook API?
>>
>
>> By the way, I completely agree with Brian that future proofing is
>> usually a waste of time. But also be careful against overly "past
>> proofing". I would much rather see new features added to the notebook,
>> even every release, than to have them held back simply for the
>> purposes of keeping things backwards compatible. Also, if jumping the
>> gun on future proofing is a waste of time, so is spending a lot of
>> effort on making sure that new notebook versions work correctly in
>> older, unsupported releases.
>>
>
> I totally agree that we should not spend significant effort on future (or
> past) proofing, and we haven't.  Nor is there any reason this would cause
> resistance to new features that do require updating the nbformat.  If a
> hoop must be leapt through to keep the nbformat, then the nbformat should
> be updated.  We have a hoop threshold of zero.  This only aims to prevent
> *known, planned, imminent features* from necessarily forcing that
> unpleasantness (they still may, since they haven't actually been
> implemented).
>
> -MinRK
>
>
>>
>> Aaron Meurer
>>
>> >
>> >> But where we are right now, adding to the metadata on cells or adding
>> >> multiple worksheets will *not* require
>> >> bumping the nbformat.
>> >
>> > Right.
>> >
>> > Cheers,
>> >
>> > Brian
>> >
>> >>>
>> >>>
>> >>> Cheers,
>> >>>
>> >>> Brian
>> >>>
>> >>>> -MinRK
>> >>>>
>> >>>>>
>> >>>>> Cheers,
>> >>>>>
>> >>>>> Brian
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> On Tue, Jun 19, 2012 at 3:25 PM, MinRK <benjaminrk at gmail.com>
>> wrote:
>> >>>>>>
>> >>>>>>
>> >>>>>> On Tue, Jun 19, 2012 at 3:23 PM, Brian Granger <
>> ellisonbg at gmail.com>
>> >>>>>> wrote:
>> >>>>>>>
>> >>>>>>> On Tue, Jun 19, 2012 at 3:19 PM, MinRK <benjaminrk at gmail.com>
>> wrote:
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> On Tue, Jun 19, 2012 at 3:18 PM, Brian Granger
>> >>>>>>>> <ellisonbg at gmail.com>
>> >>>>>>>> wrote:
>> >>>>>>>>>
>> >>>>>>>>> On Tue, Jun 19, 2012 at 2:59 PM, Fernando Perez
>> >>>>>>>>> <fperez.net at gmail.com>
>> >>>>>>>>> wrote:
>> >>>>>>>>>> On Tue, Jun 19, 2012 at 1:17 PM, MinRK <benjaminrk at gmail.com>
>> >>>>>>>>>> wrote:
>> >>>>>>>>>>> Yes - we put metadata on outputs for a reason, presumably.  If
>> >>>>>>>>>>> this
>> >>>>>>>>>>> shouldn't be saved, it should probably be removed from the
>> >>>>>>>>>>> API.
>> >>>>>>>>>>
>> >>>>>>>>>> I can't recall precisely what we had in mind when we put it in,
>> >>>>>>>>>> but
>> >>>>>>>>>> something that springs to mind as potentially useful, for
>> >>>>>>>>>> example,
>> >>>>>>>>>> would be to specify a desired priority order for the various
>> >>>>>>>>>> types
>> >>>>>>>>>> of
>> >>>>>>>>>> outputs. Right now when a client can display several kinds of
>> >>>>>>>>>> output
>> >>>>>>>>>> it just makes a choice, but we could let objects provide a hint
>> >>>>>>>>>> of
>> >>>>>>>>>> the
>> >>>>>>>>>> preferred order, based on what they know about the relative
>> >>>>>>>>>> quality
>> >>>>>>>>>> of
>> >>>>>>>>>> each.
>> >>>>>>>>>
>> >>>>>>>>> I originally put it there to allow objects to provide hints to
>> >>>>>>>>> the
>> >>>>>>>>> frontend on how it should display a representation.  This is
>> >>>>>>>>> similar
>> >>>>>>>>> to how the payloads can indicate where it came from.
>> >>>>>>>>>
>> >>>>>>>>>> So I'd vote for not removing this, as it may prove useful...
>> >>>>>>>>>
>> >>>>>>>>> I also think it could be useful, although it seems a bit
>> >>>>>>>>> excessive
>> >>>>>>>>> to
>> >>>>>>>>> store metadata for each output.  Here is what I propose.  We
>> >>>>>>>>> simply
>> >>>>>>>>> leave it alone until we have an actual use case that will help
>> us
>> >>>>>>>>> figure out exactly what this should look like.  Without a
>> >>>>>>>>> concrete
>> >>>>>>>>> usage case, it is difficult to know what is needed.
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> But this doesn't answer the immediate question: Should this
>> >>>>>>>> metadata
>> >>>>>>>> dict be
>> >>>>>>>> included in the nbformat
>> >>>>>>>
>> >>>>>>> I would vote no - not until we have a real usage case.  I don't
>> like
>> >>>>>>> to add things to the notebook format until we are actually using
>> >>>>>>> them.
>> >>>>>>
>> >>>>>>
>> >>>>>> Then should we remove all of the metadata stuff we just added?  The
>> >>>>>> whole
>> >>>>>> point was to prepare the nbformat for future changes to we don't
>> have
>> >>>>>> to
>> >>>>>> update the nbformat, which is incredibly painful and should be done
>> >>>>>> as
>> >>>>>> rarely as possible.
>> >>>>>>
>> >>>>>> -MinRK
>> >>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>> f
>> >>>>>>>>>> _______________________________________________
>> >>>>>>>>>> IPython-dev mailing list
>> >>>>>>>>>> IPython-dev at scipy.org
>> >>>>>>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> --
>> >>>>>>>>> Brian E. Granger
>> >>>>>>>>> Cal Poly State University, San Luis Obispo
>> >>>>>>>>> bgranger at calpoly.edu and ellisonbg at gmail.com
>> >>>>>>>>> _______________________________________________
>> >>>>>>>>> IPython-dev mailing list
>> >>>>>>>>> IPython-dev at scipy.org
>> >>>>>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> _______________________________________________
>> >>>>>>>> IPython-dev mailing list
>> >>>>>>>> IPython-dev at scipy.org
>> >>>>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>> Brian E. Granger
>> >>>>>>> Cal Poly State University, San Luis Obispo
>> >>>>>>> bgranger at calpoly.edu and ellisonbg at gmail.com
>> >>>>>>> _______________________________________________
>> >>>>>>> IPython-dev mailing list
>> >>>>>>> IPython-dev at scipy.org
>> >>>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> _______________________________________________
>> >>>>>> IPython-dev mailing list
>> >>>>>> IPython-dev at scipy.org
>> >>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> Brian E. Granger
>> >>>>> Cal Poly State University, San Luis Obispo
>> >>>>> bgranger at calpoly.edu and ellisonbg at gmail.com
>> >>>>> _______________________________________________
>> >>>>> IPython-dev mailing list
>> >>>>> IPython-dev at scipy.org
>> >>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> IPython-dev mailing list
>> >>>> IPython-dev at scipy.org
>> >>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Brian E. Granger
>> >>> Cal Poly State University, San Luis Obispo
>> >>> bgranger at calpoly.edu and ellisonbg at gmail.com
>> >>> _______________________________________________
>> >>> IPython-dev mailing list
>> >>> IPython-dev at scipy.org
>> >>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> IPython-dev mailing list
>> >> IPython-dev at scipy.org
>> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >>
>> >
>> >
>> >
>> > --
>> > Brian E. Granger
>> > Cal Poly State University, San Luis Obispo
>> > bgranger at calpoly.edu and ellisonbg at gmail.com
>> > _______________________________________________
>> > IPython-dev mailing list
>> > IPython-dev at scipy.org
>> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120620/205971a7/attachment.html>

From massimodisasha at gmail.com  Wed Jun 20 22:03:45 2012
From: massimodisasha at gmail.com (Massimo Di Stefano)
Date: Wed, 20 Jun 2012 22:03:45 -0400
Subject: [IPython-dev] ipython on webfaction hosting
Message-ID: <1462386D-2B40-4527-88A1-59098FB1BDEE@gmail.com>

Hi All,

is anyone familiar with webfaction [1] ?

it is a web-hosting service .. i'm tring to run the ipython notebook from it but something is going wrong.

i sent already a mail to the suppport, but i was wondering if someone here knows how to fix it.



the link to the notebook is :

http://geohab.org/ipython

i can see the page is loaded but is not able to load the application ... something is going wrong.
all the js and css files are not loaded.


trying to understand what's going on ?

using firefox : if i click on the text on the top "Ipython Notebook"

it should point to the same page, instead is going back to the web-root : http://geohab.org

have you any clue on what i should do in order to have it running properly ?

many thanks!

Massimo.


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

From ellisonbg at gmail.com  Wed Jun 20 22:17:25 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Wed, 20 Jun 2012 19:17:25 -0700
Subject: [IPython-dev] ipython on webfaction hosting
In-Reply-To: <1462386D-2B40-4527-88A1-59098FB1BDEE@gmail.com>
References: <1462386D-2B40-4527-88A1-59098FB1BDEE@gmail.com>
Message-ID: <CAH4pYpTby4UcmgZvjeiWf2RFPc2hm_mQv7btcdexJFOH2CtFkg@mail.gmail.com>

I think you need to set the following config variables:

--NotebookApp.base_kernel_url=<Unicode>
    Default: '/'
    The base URL for the kernel server
--NotebookApp.base_project_url=<Unicode>
    Default: '/'
    The base URL for the notebook server

In either the command line or terminal:

ipython notebook
--NotebookApp.base_project_url=http://geohab.org/ipython/
--NotebookApp.base_kernel_url=http://geohab.org/ipython/

Cheers,

Brian

On Wed, Jun 20, 2012 at 7:03 PM, Massimo Di Stefano
<massimodisasha at gmail.com> wrote:
> Hi All,
>
> is anyone familiar with webfaction [1] ?
>
> it is a web-hosting service .. i'm tring to run the ipython notebook from it but something is going wrong.
>
> i sent already a mail to the suppport, but i was wondering if someone here knows how to fix it.
>
>
>
> the link to the notebook is :
>
> http://geohab.org/ipython
>
> i can see the page is loaded but is not able to load the application ... something is going wrong.
> all the js and css files are not loaded.
>
>
> trying to understand what's going on ?
>
> using firefox : if i click on the text on the top "Ipython Notebook"
>
> it should point to the same page, instead is going back to the web-root : http://geohab.org
>
> have you any clue on what i should do in order to have it running properly ?
>
> many thanks!
>
> Massimo.
>
>
> [1] ?http://www.webfaction.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
bgranger at calpoly.edu and ellisonbg at gmail.com


From massimodisasha at gmail.com  Wed Jun 20 23:05:19 2012
From: massimodisasha at gmail.com (Massimo Di Stefano)
Date: Wed, 20 Jun 2012 23:05:19 -0400
Subject: [IPython-dev] ipython on webfaction hosting
In-Reply-To: <CAH4pYpTby4UcmgZvjeiWf2RFPc2hm_mQv7btcdexJFOH2CtFkg@mail.gmail.com>
References: <1462386D-2B40-4527-88A1-59098FB1BDEE@gmail.com>
	<CAH4pYpTby4UcmgZvjeiWf2RFPc2hm_mQv7btcdexJFOH2CtFkg@mail.gmail.com>
Message-ID: <5463AECA-BA6C-453C-A4A0-CFE9F27283FB@gmail.com>

ipython notebook --profile geohab --NotebookApp.base_project_url=http://geohab.org/ipython --NotebookApp.base_kernel_url=http://geohab.org/ipython

[NotebookApp] Using existing profile dir: u'/home/epy/.ipython/profile_geohab'
[NotebookApp] WARNING: the notebook server is listening on all IP addresses but not using any encryption or authentication. This is highly insecure and not recommended.
[NotebookApp] The IPython Notebook is running at: http://[all ip addresses on your system]:30333http://geohab.org/ipython


the log :
[NotebookApp] The IPython Notebook is running at: http://[all ip addresses on your system]:30333http://geohab.org/ipython

seems bad so  i tryed :


(env1)[epy at web317 ~]$ ipython notebook --profile geohab --NotebookApp.base_project_url=/ipython --NotebookApp.base_kernel_url=/ipython[NotebookApp] Using existing profile dir: u'/home/epy/.ipython/profile_geohab'
[NotebookApp] WARNING: the notebook server is listening on all IP addresses but not using any encryption or authentication. This is highly insecure and not recommended.
[NotebookApp] The IPython Notebook is running at: http://[all ip addresses on your system]:30333/ipython


in this case if i point the browser to :

http://geohab.org/ipython

i have in the browser :

404: Not Found

in the shell logs :

WARNING:root:404 GET / (127.0.0.1) 0.48ms


if i point the browser to :

http://geohab.org/ipython/ipython/

i got again the html page without js/css

but this time the log in the shell is :

WARNING:root:404 GET /ipython (127.0.0.1) 0.41ms


any clue ?

thanks!!!

Massimo.



Il giorno Jun 20, 2012, alle ore 10:17 PM, Brian Granger ha scritto:

> I think you need to set the following config variables:
> 
> --NotebookApp.base_kernel_url=<Unicode>
>    Default: '/'
>    The base URL for the kernel server
> --NotebookApp.base_project_url=<Unicode>
>    Default: '/'
>    The base URL for the notebook server
> 
> In either the command line or terminal:
> 
> ipython notebook
> --NotebookApp.base_project_url=http://geohab.org/ipython/
> --NotebookApp.base_kernel_url=http://geohab.org/ipython/
> 
> Cheers,
> 
> Brian
> 
> On Wed, Jun 20, 2012 at 7:03 PM, Massimo Di Stefano
> <massimodisasha at gmail.com> wrote:
>> Hi All,
>> 
>> is anyone familiar with webfaction [1] ?
>> 
>> it is a web-hosting service .. i'm tring to run the ipython notebook from it but something is going wrong.
>> 
>> i sent already a mail to the suppport, but i was wondering if someone here knows how to fix it.
>> 
>> 
>> 
>> the link to the notebook is :
>> 
>> http://geohab.org/ipython
>> 
>> i can see the page is loaded but is not able to load the application ... something is going wrong.
>> all the js and css files are not loaded.
>> 
>> 
>> trying to understand what's going on ?
>> 
>> using firefox : if i click on the text on the top "Ipython Notebook"
>> 
>> it should point to the same page, instead is going back to the web-root : http://geohab.org
>> 
>> have you any clue on what i should do in order to have it running properly ?
>> 
>> many thanks!
>> 
>> Massimo.
>> 
>> 
>> [1]  http://www.webfaction.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
> 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



From benjaminrk at gmail.com  Wed Jun 20 23:33:03 2012
From: benjaminrk at gmail.com (MinRK)
Date: Wed, 20 Jun 2012 20:33:03 -0700
Subject: [IPython-dev] ipython on webfaction hosting
In-Reply-To: <5463AECA-BA6C-453C-A4A0-CFE9F27283FB@gmail.com>
References: <1462386D-2B40-4527-88A1-59098FB1BDEE@gmail.com>
	<CAH4pYpTby4UcmgZvjeiWf2RFPc2hm_mQv7btcdexJFOH2CtFkg@mail.gmail.com>
	<5463AECA-BA6C-453C-A4A0-CFE9F27283FB@gmail.com>
Message-ID: <CAHNn8BVbwcmdFE6Tbjs0VwFqGCRvEcSf7Ybe6nEcbTi72U0fzg@mail.gmail.com>

The static url is also getting confused.

Try:

ipython notebook --profile geohab --NotebookApp.base_project_url=/ipython/
--NotebookApp.base_kernel_url=/ipython/
--NotebookApp.webapp_settings='{"static_url_prefix": "/ipython/static/"}'

Which in your ipython_notebook_config.py would be:

c = get_config()

prefix = '/ipython/'
c.NotebookApp.base_project_url = prefix
c.NotebookApp.base_kernel_url = prefix
c.NotebookApp.webapp_settings = {'static_url_prefix' : prefix + 'static/'}

At which point you can just do:

ipython notebook --profile geohab

It would certainly appear that a meta-trait that does these three things
together would be desirable.

-MinRK

On Wed, Jun 20, 2012 at 8:05 PM, Massimo Di Stefano <
massimodisasha at gmail.com> wrote:

> ipython notebook --profile geohab --NotebookApp.base_project_url=
> http://geohab.org/ipython --NotebookApp.base_kernel_url=
> http://geohab.org/ipython
>
> [NotebookApp] Using existing profile dir:
> u'/home/epy/.ipython/profile_geohab'
> [NotebookApp] WARNING: the notebook server is listening on all IP
> addresses but not using any encryption or authentication. This is highly
> insecure and not recommended.
> [NotebookApp] The IPython Notebook is running at: http://[all ip
> addresses on your system]:30333http://geohab.org/ipython
>
>
> the log :
> [NotebookApp] The IPython Notebook is running at: http://[all ip
> addresses on your system]:30333http://geohab.org/ipython
>
> seems bad so  i tryed :
>
>
> (env1)[epy at web317 ~]$ ipython notebook --profile geohab
> --NotebookApp.base_project_url=/ipython
> --NotebookApp.base_kernel_url=/ipython[NotebookApp] Using existing profile
> dir: u'/home/epy/.ipython/profile_geohab'
> [NotebookApp] WARNING: the notebook server is listening on all IP
> addresses but not using any encryption or authentication. This is highly
> insecure and not recommended.
> [NotebookApp] The IPython Notebook is running at: http://[all ip
> addresses on your system]:30333/ipython
>
>
> in this case if i point the browser to :
>
> http://geohab.org/ipython
>
> i have in the browser :
>
> 404: Not Found
>
> in the shell logs :
>
> WARNING:root:404 GET / (127.0.0.1) 0.48ms
>
>
> if i point the browser to :
>
> http://geohab.org/ipython/ipython/
>
> i got again the html page without js/css
>
> but this time the log in the shell is :
>
> WARNING:root:404 GET /ipython (127.0.0.1) 0.41ms
>
>
> any clue ?
>
> thanks!!!
>
> Massimo.
>
>
>
> Il giorno Jun 20, 2012, alle ore 10:17 PM, Brian Granger ha scritto:
>
> > I think you need to set the following config variables:
> >
> > --NotebookApp.base_kernel_url=<Unicode>
> >    Default: '/'
> >    The base URL for the kernel server
> > --NotebookApp.base_project_url=<Unicode>
> >    Default: '/'
> >    The base URL for the notebook server
> >
> > In either the command line or terminal:
> >
> > ipython notebook
> > --NotebookApp.base_project_url=http://geohab.org/ipython/
> > --NotebookApp.base_kernel_url=http://geohab.org/ipython/
> >
> > Cheers,
> >
> > Brian
> >
> > On Wed, Jun 20, 2012 at 7:03 PM, Massimo Di Stefano
> > <massimodisasha at gmail.com> wrote:
> >> Hi All,
> >>
> >> is anyone familiar with webfaction [1] ?
> >>
> >> it is a web-hosting service .. i'm tring to run the ipython notebook
> from it but something is going wrong.
> >>
> >> i sent already a mail to the suppport, but i was wondering if someone
> here knows how to fix it.
> >>
> >>
> >>
> >> the link to the notebook is :
> >>
> >> http://geohab.org/ipython
> >>
> >> i can see the page is loaded but is not able to load the application
> ... something is going wrong.
> >> all the js and css files are not loaded.
> >>
> >>
> >> trying to understand what's going on ?
> >>
> >> using firefox : if i click on the text on the top "Ipython Notebook"
> >>
> >> it should point to the same page, instead is going back to the web-root
> : http://geohab.org
> >>
> >> have you any clue on what i should do in order to have it running
> properly ?
> >>
> >> many thanks!
> >>
> >> Massimo.
> >>
> >>
> >> [1]  http://www.webfaction.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
> > bgranger at calpoly.edu and ellisonbg at gmail.com
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120620/01bc079a/attachment.html>

From massimodisasha at gmail.com  Wed Jun 20 23:49:53 2012
From: massimodisasha at gmail.com (Massimo Di Stefano)
Date: Wed, 20 Jun 2012 23:49:53 -0400
Subject: [IPython-dev] ipython on webfaction hosting
In-Reply-To: <CAHNn8BVbwcmdFE6Tbjs0VwFqGCRvEcSf7Ybe6nEcbTi72U0fzg@mail.gmail.com>
References: <1462386D-2B40-4527-88A1-59098FB1BDEE@gmail.com>
	<CAH4pYpTby4UcmgZvjeiWf2RFPc2hm_mQv7btcdexJFOH2CtFkg@mail.gmail.com>
	<5463AECA-BA6C-453C-A4A0-CFE9F27283FB@gmail.com>
	<CAHNn8BVbwcmdFE6Tbjs0VwFqGCRvEcSf7Ybe6nEcbTi72U0fzg@mail.gmail.com>
Message-ID: <109468B8-2B83-425D-83A7-6B477212F4DC@gmail.com>

i applied the changes in the config file

something is changing in the log :

# url in the browser :

http://geohab.org/ipython/

# log in the shell :

WARNING:root:404 GET / (127.0.0.1) 0.49ms
--

# url in the browser :
http://geohab.org/ipython/ipython

# log in the shell :
WARNING:root:404 GET /ipython (127.0.0.1) 0.36ms
--

# url in the browser :
http://geohab.org/ipython/ipython/

# log in the shell :
WARNING:root:404 GET /static/jquery/css/themes/base/jquery-ui.min.css?v=d1a93 (127.0.0.1) 0.37ms
WARNING:root:404 GET /static/css/fbm.css?v=34be8 (127.0.0.1) 0.42ms
WARNING:root:404 GET /static/css/boilerplate.css?v=befd7 (127.0.0.1) 0.29ms
WARNING:root:404 GET /static/css/page.css?v=4c306 (127.0.0.1) 0.51ms
WARNING:root:404 GET /static/css/projectdashboard.css?v=87030 (127.0.0.1) 0.29ms
WARNING:root:404 GET /static/jquery/js/jquery-1.7.1.min.js?v=ddb84 (127.0.0.1) 0.29ms
WARNING:root:404 GET /static/jquery/js/jquery-ui.min.js?v=9fc86 (127.0.0.1) 0.38ms
WARNING:root:404 GET /static/js/loginwidget.js?v=cd12c (127.0.0.1) 0.30ms
WARNING:root:404 GET /static/js/notebooklist.js?v=ffa0b (127.0.0.1) 0.30ms
WARNING:root:404 GET /static/js/clusterlist.js?v=da6d3 (127.0.0.1) 0.33ms
WARNING:root:404 GET /static/js/namespace.js?v=9e4e0 (127.0.0.1) 0.29ms
WARNING:root:404 GET /static/js/page.js?v=d306b (127.0.0.1) 0.30ms
WARNING:root:404 GET /static/ipynblogo.png?v=5892b (127.0.0.1) 0.37ms
WARNING:root:404 GET /static/js/projectdashboardmain.js?v=64f33 (127.0.0.1) 0.29ms



click on the logo (firefox is able to find it, safari instead is not ?) it point to the url :
 
http://geohab.org/ipython/


thanks!

Massimo.


Il giorno Jun 20, 2012, alle ore 11:33 PM, MinRK ha scritto:

> The static url is also getting confused.
> 
> Try:
> 
> ipython notebook --profile geohab --NotebookApp.base_project_url=/ipython/ --NotebookApp.base_kernel_url=/ipython/ --NotebookApp.webapp_settings='{"static_url_prefix": "/ipython/static/"}'
> 
> Which in your ipython_notebook_config.py would be:
> 
> c = get_config()
> 
> prefix = '/ipython/'
> c.NotebookApp.base_project_url = prefix
> c.NotebookApp.base_kernel_url = prefix
> c.NotebookApp.webapp_settings = {'static_url_prefix' : prefix + 'static/'}
> 
> At which point you can just do:
> 
> ipython notebook --profile geohab
> 
> It would certainly appear that a meta-trait that does these three things together would be desirable.
> 
> -MinRK
> 
> On Wed, Jun 20, 2012 at 8:05 PM, Massimo Di Stefano <massimodisasha at gmail.com> wrote:
> ipython notebook --profile geohab --NotebookApp.base_project_url=http://geohab.org/ipython --NotebookApp.base_kernel_url=http://geohab.org/ipython
> 
> [NotebookApp] Using existing profile dir: u'/home/epy/.ipython/profile_geohab'
> [NotebookApp] WARNING: the notebook server is listening on all IP addresses but not using any encryption or authentication. This is highly insecure and not recommended.
> [NotebookApp] The IPython Notebook is running at: http://[all ip addresses on your system]:30333http://geohab.org/ipython
> 
> 
> the log :
> [NotebookApp] The IPython Notebook is running at: http://[all ip addresses on your system]:30333http://geohab.org/ipython
> 
> seems bad so  i tryed :
> 
> 
> (env1)[epy at web317 ~]$ ipython notebook --profile geohab --NotebookApp.base_project_url=/ipython --NotebookApp.base_kernel_url=/ipython[NotebookApp] Using existing profile dir: u'/home/epy/.ipython/profile_geohab'
> [NotebookApp] WARNING: the notebook server is listening on all IP addresses but not using any encryption or authentication. This is highly insecure and not recommended.
> [NotebookApp] The IPython Notebook is running at: http://[all ip addresses on your system]:30333/ipython
> 
> 
> in this case if i point the browser to :
> 
> http://geohab.org/ipython
> 
> i have in the browser :
> 
> 404: Not Found
> 
> in the shell logs :
> 
> WARNING:root:404 GET / (127.0.0.1) 0.48ms
> 
> 
> if i point the browser to :
> 
> http://geohab.org/ipython/ipython/
> 
> i got again the html page without js/css
> 
> but this time the log in the shell is :
> 
> WARNING:root:404 GET /ipython (127.0.0.1) 0.41ms
> 
> 
> any clue ?
> 
> thanks!!!
> 
> Massimo.
> 
> 
> 
> Il giorno Jun 20, 2012, alle ore 10:17 PM, Brian Granger ha scritto:
> 
> > I think you need to set the following config variables:
> >
> > --NotebookApp.base_kernel_url=<Unicode>
> >    Default: '/'
> >    The base URL for the kernel server
> > --NotebookApp.base_project_url=<Unicode>
> >    Default: '/'
> >    The base URL for the notebook server
> >
> > In either the command line or terminal:
> >
> > ipython notebook
> > --NotebookApp.base_project_url=http://geohab.org/ipython/
> > --NotebookApp.base_kernel_url=http://geohab.org/ipython/
> >
> > Cheers,
> >
> > Brian
> >
> > On Wed, Jun 20, 2012 at 7:03 PM, Massimo Di Stefano
> > <massimodisasha at gmail.com> wrote:
> >> Hi All,
> >>
> >> is anyone familiar with webfaction [1] ?
> >>
> >> it is a web-hosting service .. i'm tring to run the ipython notebook from it but something is going wrong.
> >>
> >> i sent already a mail to the suppport, but i was wondering if someone here knows how to fix it.
> >>
> >>
> >>
> >> the link to the notebook is :
> >>
> >> http://geohab.org/ipython
> >>
> >> i can see the page is loaded but is not able to load the application ... something is going wrong.
> >> all the js and css files are not loaded.
> >>
> >>
> >> trying to understand what's going on ?
> >>
> >> using firefox : if i click on the text on the top "Ipython Notebook"
> >>
> >> it should point to the same page, instead is going back to the web-root : http://geohab.org
> >>
> >> have you any clue on what i should do in order to have it running properly ?
> >>
> >> many thanks!
> >>
> >> Massimo.
> >>
> >>
> >> [1]  http://www.webfaction.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
> > bgranger at calpoly.edu and ellisonbg at gmail.com
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> 
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
> 
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev

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

From benjaminrk at gmail.com  Thu Jun 21 00:03:23 2012
From: benjaminrk at gmail.com (MinRK)
Date: Wed, 20 Jun 2012 21:03:23 -0700
Subject: [IPython-dev] ipython on webfaction hosting
In-Reply-To: <109468B8-2B83-425D-83A7-6B477212F4DC@gmail.com>
References: <1462386D-2B40-4527-88A1-59098FB1BDEE@gmail.com>
	<CAH4pYpTby4UcmgZvjeiWf2RFPc2hm_mQv7btcdexJFOH2CtFkg@mail.gmail.com>
	<5463AECA-BA6C-453C-A4A0-CFE9F27283FB@gmail.com>
	<CAHNn8BVbwcmdFE6Tbjs0VwFqGCRvEcSf7Ybe6nEcbTi72U0fzg@mail.gmail.com>
	<109468B8-2B83-425D-83A7-6B477212F4DC@gmail.com>
Message-ID: <CAHNn8BXYMUdjZ91taScpadek1=-gDa+Qgr3Ge9zLZRXDYQjiPA@mail.gmail.com>

There's something a bit funny in your proxy.

Try adding one more '/ipython' to just the static url:

c.NotebookApp.webapp_settings = {'static_url_prefix' : prefix +
'ipython/static/'}

On Wed, Jun 20, 2012 at 8:49 PM, Massimo Di Stefano <
massimodisasha at gmail.com> wrote:

> i applied the changes in the config file
>
> something is changing in the log :
>
> # url in the browser :
>
> http://geohab.org/ipython/
>
> # log in the shell :
>
> WARNING:root:404 GET / (127.0.0.1) 0.49ms
> --
>
> # url in the browser :
> http://geohab.org/ipython/ipython
>
> # log in the shell :
> WARNING:root:404 GET /ipython (127.0.0.1) 0.36ms
> --
>
> # url in the browser :
> http://geohab.org/ipython/ipython/
>
> # log in the shell :
> WARNING:root:404 GET
> /static/jquery/css/themes/base/jquery-ui.min.css?v=d1a93 (127.0.0.1) 0.37ms
> WARNING:root:404 GET /static/css/fbm.css?v=34be8 (127.0.0.1) 0.42ms
> WARNING:root:404 GET /static/css/boilerplate.css?v=befd7 (127.0.0.1) 0.29ms
> WARNING:root:404 GET /static/css/page.css?v=4c306 (127.0.0.1) 0.51ms
> WARNING:root:404 GET /static/css/projectdashboard.css?v=87030 (127.0.0.1)
> 0.29ms
> WARNING:root:404 GET /static/jquery/js/jquery-1.7.1.min.js?v=ddb84
> (127.0.0.1) 0.29ms
> WARNING:root:404 GET /static/jquery/js/jquery-ui.min.js?v=9fc86
> (127.0.0.1) 0.38ms
> WARNING:root:404 GET /static/js/loginwidget.js?v=cd12c (127.0.0.1) 0.30ms
> WARNING:root:404 GET /static/js/notebooklist.js?v=ffa0b (127.0.0.1) 0.30ms
> WARNING:root:404 GET /static/js/clusterlist.js?v=da6d3 (127.0.0.1) 0.33ms
> WARNING:root:404 GET /static/js/namespace.js?v=9e4e0 (127.0.0.1) 0.29ms
> WARNING:root:404 GET /static/js/page.js?v=d306b (127.0.0.1) 0.30ms
> WARNING:root:404 GET /static/ipynblogo.png?v=5892b (127.0.0.1) 0.37ms
> WARNING:root:404 GET /static/js/projectdashboardmain.js?v=64f33
> (127.0.0.1) 0.29ms
>
>
>
> click on the logo (firefox is able to find it, safari instead is not ?) it
> point to the url :
>
> http://geohab.org/ipython/
>
>
> thanks!
>
> Massimo.
>
>
> Il giorno Jun 20, 2012, alle ore 11:33 PM, MinRK ha scritto:
>
> The static url is also getting confused.
>
> Try:
>
> ipython notebook --profile geohab --NotebookApp.base_project_url=/ipython/
> --NotebookApp.base_kernel_url=/ipython/
> --NotebookApp.webapp_settings='{"static_url_prefix": "/ipython/static/"}'
>
> Which in your ipython_notebook_config.py would be:
>
> c = get_config()
>
> prefix = '/ipython/'
> c.NotebookApp.base_project_url = prefix
> c.NotebookApp.base_kernel_url = prefix
> c.NotebookApp.webapp_settings = {'static_url_prefix' : prefix + 'static/'}
>
> At which point you can just do:
>
> ipython notebook --profile geohab
>
> It would certainly appear that a meta-trait that does these three things
> together would be desirable.
>
> -MinRK
>
> On Wed, Jun 20, 2012 at 8:05 PM, Massimo Di Stefano <
> massimodisasha at gmail.com> wrote:
>
>> ipython notebook --profile geohab --NotebookApp.base_project_url=
>> http://geohab.org/ipython --NotebookApp.base_kernel_url=
>> http://geohab.org/ipython
>>
>> [NotebookApp] Using existing profile dir:
>> u'/home/epy/.ipython/profile_geohab'
>> [NotebookApp] WARNING: the notebook server is listening on all IP
>> addresses but not using any encryption or authentication. This is highly
>> insecure and not recommended.
>> [NotebookApp] The IPython Notebook is running at: http://[all ip
>> addresses on your system]:30333http://geohab.org/ipython
>>
>>
>> the log :
>> [NotebookApp] The IPython Notebook is running at: http://[all ip
>> addresses on your system]:30333http://geohab.org/ipython
>>
>> seems bad so  i tryed :
>>
>>
>> (env1)[epy at web317 ~]$ ipython notebook --profile geohab
>> --NotebookApp.base_project_url=/ipython
>> --NotebookApp.base_kernel_url=/ipython[NotebookApp] Using existing profile
>> dir: u'/home/epy/.ipython/profile_geohab'
>> [NotebookApp] WARNING: the notebook server is listening on all IP
>> addresses but not using any encryption or authentication. This is highly
>> insecure and not recommended.
>> [NotebookApp] The IPython Notebook is running at: http://[all ip
>> addresses on your system]:30333/ipython
>>
>>
>> in this case if i point the browser to :
>>
>> http://geohab.org/ipython
>>
>> i have in the browser :
>>
>> 404: Not Found
>>
>> in the shell logs :
>>
>> WARNING:root:404 GET / (127.0.0.1) 0.48ms
>>
>>
>> if i point the browser to :
>>
>> http://geohab.org/ipython/ipython/
>>
>> i got again the html page without js/css
>>
>> but this time the log in the shell is :
>>
>> WARNING:root:404 GET /ipython (127.0.0.1) 0.41ms
>>
>>
>> any clue ?
>>
>> thanks!!!
>>
>> Massimo.
>>
>>
>>
>> Il giorno Jun 20, 2012, alle ore 10:17 PM, Brian Granger ha scritto:
>>
>> > I think you need to set the following config variables:
>> >
>> > --NotebookApp.base_kernel_url=<Unicode>
>> >    Default: '/'
>> >    The base URL for the kernel server
>> > --NotebookApp.base_project_url=<Unicode>
>> >    Default: '/'
>> >    The base URL for the notebook server
>> >
>> > In either the command line or terminal:
>> >
>> > ipython notebook
>> > --NotebookApp.base_project_url=http://geohab.org/ipython/
>> > --NotebookApp.base_kernel_url=http://geohab.org/ipython/
>> >
>> > Cheers,
>> >
>> > Brian
>> >
>> > On Wed, Jun 20, 2012 at 7:03 PM, Massimo Di Stefano
>> > <massimodisasha at gmail.com> wrote:
>> >> Hi All,
>> >>
>> >> is anyone familiar with webfaction [1] ?
>> >>
>> >> it is a web-hosting service .. i'm tring to run the ipython notebook
>> from it but something is going wrong.
>> >>
>> >> i sent already a mail to the suppport, but i was wondering if someone
>> here knows how to fix it.
>> >>
>> >>
>> >>
>> >> the link to the notebook is :
>> >>
>> >> http://geohab.org/ipython
>> >>
>> >> i can see the page is loaded but is not able to load the application
>> ... something is going wrong.
>> >> all the js and css files are not loaded.
>> >>
>> >>
>> >> trying to understand what's going on ?
>> >>
>> >> using firefox : if i click on the text on the top "Ipython Notebook"
>> >>
>> >> it should point to the same page, instead is going back to the
>> web-root : http://geohab.org
>> >>
>> >> have you any clue on what i should do in order to have it running
>> properly ?
>> >>
>> >> many thanks!
>> >>
>> >> Massimo.
>> >>
>> >>
>> >> [1]  http://www.webfaction.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
>> > bgranger at calpoly.edu and ellisonbg at gmail.com
>> > _______________________________________________
>> > IPython-dev mailing list
>> > IPython-dev at scipy.org
>> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120620/0157aa75/attachment.html>

From bob+ipython at mcelrath.org  Thu Jun 21 00:09:41 2012
From: bob+ipython at mcelrath.org (Bob McElrath)
Date: Thu, 21 Jun 2012 04:09:41 +0000
Subject: [IPython-dev] kernel restart
Message-ID: <20120621040941.GH6159@mcelrath.org>

Very dumb question, but what do I have to type into a cell to restart the
kernel?

I like to put restart(); (Maple) in the first cell of my worksheet so it's easy
to re-run everything cleanly.

A %restart magic would be very useful.

--
Cheers, Bob McElrath

"The individual has always had to struggle to keep from being overwhelmed by
the tribe.  If you try it, you will be lonely often, and sometimes frightened.
But no price is too high to pay for the privilege of owning yourself." 
    -- Friedrich Nietzsche


From massimodisasha at gmail.com  Thu Jun 21 00:24:05 2012
From: massimodisasha at gmail.com (Massimo Di Stefano)
Date: Thu, 21 Jun 2012 00:24:05 -0400
Subject: [IPython-dev] ipython on webfaction hosting
In-Reply-To: <CAHNn8BXYMUdjZ91taScpadek1=-gDa+Qgr3Ge9zLZRXDYQjiPA@mail.gmail.com>
References: <1462386D-2B40-4527-88A1-59098FB1BDEE@gmail.com>
	<CAH4pYpTby4UcmgZvjeiWf2RFPc2hm_mQv7btcdexJFOH2CtFkg@mail.gmail.com>
	<5463AECA-BA6C-453C-A4A0-CFE9F27283FB@gmail.com>
	<CAHNn8BVbwcmdFE6Tbjs0VwFqGCRvEcSf7Ybe6nEcbTi72U0fzg@mail.gmail.com>
	<109468B8-2B83-425D-83A7-6B477212F4DC@gmail.com>
	<CAHNn8BXYMUdjZ91taScpadek1=-gDa+Qgr3Ge9zLZRXDYQjiPA@mail.gmail.com>
Message-ID: <479CE78E-257F-457E-96E5-F4A58EF0653F@gmail.com>

tried  it gave the same logs.
  
i left the kernel running

is there anything i can do 
maybe moving some of the ipython files in the root directory and see if he find it ?


Il giorno Jun 21, 2012, alle ore 12:03 AM, MinRK ha scritto:

> There's something a bit funny in your proxy.
> 
> Try adding one more '/ipython' to just the static url:
> 
> c.NotebookApp.webapp_settings = {'static_url_prefix' : prefix + 'ipython/static/'}
> 
> On Wed, Jun 20, 2012 at 8:49 PM, Massimo Di Stefano <massimodisasha at gmail.com> wrote:
> i applied the changes in the config file
> 
> something is changing in the log :
> 
> # url in the browser :
> 
> http://geohab.org/ipython/
> 
> # log in the shell :
> 
> WARNING:root:404 GET / (127.0.0.1) 0.49ms
> --
> 
> # url in the browser :
> http://geohab.org/ipython/ipython
> 
> # log in the shell :
> WARNING:root:404 GET /ipython (127.0.0.1) 0.36ms
> --
> 
> # url in the browser :
> http://geohab.org/ipython/ipython/
> 
> # log in the shell :
> WARNING:root:404 GET /static/jquery/css/themes/base/jquery-ui.min.css?v=d1a93 (127.0.0.1) 0.37ms
> WARNING:root:404 GET /static/css/fbm.css?v=34be8 (127.0.0.1) 0.42ms
> WARNING:root:404 GET /static/css/boilerplate.css?v=befd7 (127.0.0.1) 0.29ms
> WARNING:root:404 GET /static/css/page.css?v=4c306 (127.0.0.1) 0.51ms
> WARNING:root:404 GET /static/css/projectdashboard.css?v=87030 (127.0.0.1) 0.29ms
> WARNING:root:404 GET /static/jquery/js/jquery-1.7.1.min.js?v=ddb84 (127.0.0.1) 0.29ms
> WARNING:root:404 GET /static/jquery/js/jquery-ui.min.js?v=9fc86 (127.0.0.1) 0.38ms
> WARNING:root:404 GET /static/js/loginwidget.js?v=cd12c (127.0.0.1) 0.30ms
> WARNING:root:404 GET /static/js/notebooklist.js?v=ffa0b (127.0.0.1) 0.30ms
> WARNING:root:404 GET /static/js/clusterlist.js?v=da6d3 (127.0.0.1) 0.33ms
> WARNING:root:404 GET /static/js/namespace.js?v=9e4e0 (127.0.0.1) 0.29ms
> WARNING:root:404 GET /static/js/page.js?v=d306b (127.0.0.1) 0.30ms
> WARNING:root:404 GET /static/ipynblogo.png?v=5892b (127.0.0.1) 0.37ms
> WARNING:root:404 GET /static/js/projectdashboardmain.js?v=64f33 (127.0.0.1) 0.29ms
> 
> 
> 
> click on the logo (firefox is able to find it, safari instead is not ?) it point to the url :
>  
> http://geohab.org/ipython/
> 
> 
> thanks!
> 
> Massimo.
> 
> 
> Il giorno Jun 20, 2012, alle ore 11:33 PM, MinRK ha scritto:
> 
>> The static url is also getting confused.
>> 
>> Try:
>> 
>> ipython notebook --profile geohab --NotebookApp.base_project_url=/ipython/ --NotebookApp.base_kernel_url=/ipython/ --NotebookApp.webapp_settings='{"static_url_prefix": "/ipython/static/"}'
>> 
>> Which in your ipython_notebook_config.py would be:
>> 
>> c = get_config()
>> 
>> prefix = '/ipython/'
>> c.NotebookApp.base_project_url = prefix
>> c.NotebookApp.base_kernel_url = prefix
>> c.NotebookApp.webapp_settings = {'static_url_prefix' : prefix + 'static/'}
>> 
>> At which point you can just do:
>> 
>> ipython notebook --profile geohab
>> 
>> It would certainly appear that a meta-trait that does these three things together would be desirable.
>> 
>> -MinRK
>> 
>> On Wed, Jun 20, 2012 at 8:05 PM, Massimo Di Stefano <massimodisasha at gmail.com> wrote:
>> ipython notebook --profile geohab --NotebookApp.base_project_url=http://geohab.org/ipython --NotebookApp.base_kernel_url=http://geohab.org/ipython
>> 
>> [NotebookApp] Using existing profile dir: u'/home/epy/.ipython/profile_geohab'
>> [NotebookApp] WARNING: the notebook server is listening on all IP addresses but not using any encryption or authentication. This is highly insecure and not recommended.
>> [NotebookApp] The IPython Notebook is running at: http://[all ip addresses on your system]:30333http://geohab.org/ipython
>> 
>> 
>> the log :
>> [NotebookApp] The IPython Notebook is running at: http://[all ip addresses on your system]:30333http://geohab.org/ipython
>> 
>> seems bad so  i tryed :
>> 
>> 
>> (env1)[epy at web317 ~]$ ipython notebook --profile geohab --NotebookApp.base_project_url=/ipython --NotebookApp.base_kernel_url=/ipython[NotebookApp] Using existing profile dir: u'/home/epy/.ipython/profile_geohab'
>> [NotebookApp] WARNING: the notebook server is listening on all IP addresses but not using any encryption or authentication. This is highly insecure and not recommended.
>> [NotebookApp] The IPython Notebook is running at: http://[all ip addresses on your system]:30333/ipython
>> 
>> 
>> in this case if i point the browser to :
>> 
>> http://geohab.org/ipython
>> 
>> i have in the browser :
>> 
>> 404: Not Found
>> 
>> in the shell logs :
>> 
>> WARNING:root:404 GET / (127.0.0.1) 0.48ms
>> 
>> 
>> if i point the browser to :
>> 
>> http://geohab.org/ipython/ipython/
>> 
>> i got again the html page without js/css
>> 
>> but this time the log in the shell is :
>> 
>> WARNING:root:404 GET /ipython (127.0.0.1) 0.41ms
>> 
>> 
>> any clue ?
>> 
>> thanks!!!
>> 
>> Massimo.
>> 
>> 
>> 
>> Il giorno Jun 20, 2012, alle ore 10:17 PM, Brian Granger ha scritto:
>> 
>> > I think you need to set the following config variables:
>> >
>> > --NotebookApp.base_kernel_url=<Unicode>
>> >    Default: '/'
>> >    The base URL for the kernel server
>> > --NotebookApp.base_project_url=<Unicode>
>> >    Default: '/'
>> >    The base URL for the notebook server
>> >
>> > In either the command line or terminal:
>> >
>> > ipython notebook
>> > --NotebookApp.base_project_url=http://geohab.org/ipython/
>> > --NotebookApp.base_kernel_url=http://geohab.org/ipython/
>> >
>> > Cheers,
>> >
>> > Brian
>> >
>> > On Wed, Jun 20, 2012 at 7:03 PM, Massimo Di Stefano
>> > <massimodisasha at gmail.com> wrote:
>> >> Hi All,
>> >>
>> >> is anyone familiar with webfaction [1] ?
>> >>
>> >> it is a web-hosting service .. i'm tring to run the ipython notebook from it but something is going wrong.
>> >>
>> >> i sent already a mail to the suppport, but i was wondering if someone here knows how to fix it.
>> >>
>> >>
>> >>
>> >> the link to the notebook is :
>> >>
>> >> http://geohab.org/ipython
>> >>
>> >> i can see the page is loaded but is not able to load the application ... something is going wrong.
>> >> all the js and css files are not loaded.
>> >>
>> >>
>> >> trying to understand what's going on ?
>> >>
>> >> using firefox : if i click on the text on the top "Ipython Notebook"
>> >>
>> >> it should point to the same page, instead is going back to the web-root : http://geohab.org
>> >>
>> >> have you any clue on what i should do in order to have it running properly ?
>> >>
>> >> many thanks!
>> >>
>> >> Massimo.
>> >>
>> >>
>> >> [1]  http://www.webfaction.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
>> > bgranger at calpoly.edu and ellisonbg at gmail.com
>> > _______________________________________________
>> > IPython-dev mailing list
>> > IPython-dev at scipy.org
>> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>> 
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>> 
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> 
> 
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
> 
> 
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev

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

From benjaminrk at gmail.com  Thu Jun 21 00:26:25 2012
From: benjaminrk at gmail.com (MinRK)
Date: Wed, 20 Jun 2012 21:26:25 -0700
Subject: [IPython-dev] ipython on webfaction hosting
In-Reply-To: <479CE78E-257F-457E-96E5-F4A58EF0653F@gmail.com>
References: <1462386D-2B40-4527-88A1-59098FB1BDEE@gmail.com>
	<CAH4pYpTby4UcmgZvjeiWf2RFPc2hm_mQv7btcdexJFOH2CtFkg@mail.gmail.com>
	<5463AECA-BA6C-453C-A4A0-CFE9F27283FB@gmail.com>
	<CAHNn8BVbwcmdFE6Tbjs0VwFqGCRvEcSf7Ybe6nEcbTi72U0fzg@mail.gmail.com>
	<109468B8-2B83-425D-83A7-6B477212F4DC@gmail.com>
	<CAHNn8BXYMUdjZ91taScpadek1=-gDa+Qgr3Ge9zLZRXDYQjiPA@mail.gmail.com>
	<479CE78E-257F-457E-96E5-F4A58EF0653F@gmail.com>
Message-ID: <CAHNn8BX_pTktnA06XzEKSoOP-k-rS+iay5k8uGdEJtMFaU=vPg@mail.gmail.com>

On Wed, Jun 20, 2012 at 9:24 PM, Massimo Di Stefano <
massimodisasha at gmail.com> wrote:

> tried  it gave the same logs.
>
> i left the kernel running
>
> is there anything i can do
> maybe moving some of the ipython files in the root directory and see if he
> find it ?
>

That's all I've got, so I have nothing left to help with, sorry.  I would
just try to play with permutations of the prefixes, and check with your
proxy configuration, if you can.


>
>
> Il giorno Jun 21, 2012, alle ore 12:03 AM, MinRK ha scritto:
>
> There's something a bit funny in your proxy.
>
> Try adding one more '/ipython' to just the static url:
>
> c.NotebookApp.webapp_settings = {'static_url_prefix' : prefix +
> 'ipython/static/'}
>
> On Wed, Jun 20, 2012 at 8:49 PM, Massimo Di Stefano <
> massimodisasha at gmail.com> wrote:
>
>> i applied the changes in the config file
>>
>> something is changing in the log :
>>
>> # url in the browser :
>>
>> http://geohab.org/ipython/
>>
>> # log in the shell :
>>
>> WARNING:root:404 GET / (127.0.0.1) 0.49ms
>> --
>>
>> # url in the browser :
>> http://geohab.org/ipython/ipython
>>
>> # log in the shell :
>> WARNING:root:404 GET /ipython (127.0.0.1) 0.36ms
>> --
>>
>> # url in the browser :
>> http://geohab.org/ipython/ipython/
>>
>> # log in the shell :
>> WARNING:root:404 GET
>> /static/jquery/css/themes/base/jquery-ui.min.css?v=d1a93 (127.0.0.1) 0.37ms
>> WARNING:root:404 GET /static/css/fbm.css?v=34be8 (127.0.0.1) 0.42ms
>> WARNING:root:404 GET /static/css/boilerplate.css?v=befd7 (127.0.0.1)
>> 0.29ms
>> WARNING:root:404 GET /static/css/page.css?v=4c306 (127.0.0.1) 0.51ms
>> WARNING:root:404 GET /static/css/projectdashboard.css?v=87030 (127.0.0.1)
>> 0.29ms
>> WARNING:root:404 GET /static/jquery/js/jquery-1.7.1.min.js?v=ddb84
>> (127.0.0.1) 0.29ms
>> WARNING:root:404 GET /static/jquery/js/jquery-ui.min.js?v=9fc86
>> (127.0.0.1) 0.38ms
>> WARNING:root:404 GET /static/js/loginwidget.js?v=cd12c (127.0.0.1) 0.30ms
>> WARNING:root:404 GET /static/js/notebooklist.js?v=ffa0b (127.0.0.1) 0.30ms
>> WARNING:root:404 GET /static/js/clusterlist.js?v=da6d3 (127.0.0.1) 0.33ms
>> WARNING:root:404 GET /static/js/namespace.js?v=9e4e0 (127.0.0.1) 0.29ms
>> WARNING:root:404 GET /static/js/page.js?v=d306b (127.0.0.1) 0.30ms
>> WARNING:root:404 GET /static/ipynblogo.png?v=5892b (127.0.0.1) 0.37ms
>> WARNING:root:404 GET /static/js/projectdashboardmain.js?v=64f33
>> (127.0.0.1) 0.29ms
>>
>>
>>
>> click on the logo (firefox is able to find it, safari instead is not ?)
>> it point to the url :
>>
>> http://geohab.org/ipython/
>>
>>
>> thanks!
>>
>> Massimo.
>>
>>
>> Il giorno Jun 20, 2012, alle ore 11:33 PM, MinRK ha scritto:
>>
>> The static url is also getting confused.
>>
>> Try:
>>
>> ipython notebook --profile
>> geohab --NotebookApp.base_project_url=/ipython/
>> --NotebookApp.base_kernel_url=/ipython/
>> --NotebookApp.webapp_settings='{"static_url_prefix": "/ipython/static/"}'
>>
>> Which in your ipython_notebook_config.py would be:
>>
>> c = get_config()
>>
>> prefix = '/ipython/'
>> c.NotebookApp.base_project_url = prefix
>> c.NotebookApp.base_kernel_url = prefix
>> c.NotebookApp.webapp_settings = {'static_url_prefix' : prefix + 'static/'}
>>
>> At which point you can just do:
>>
>> ipython notebook --profile geohab
>>
>> It would certainly appear that a meta-trait that does these three things
>> together would be desirable.
>>
>> -MinRK
>>
>> On Wed, Jun 20, 2012 at 8:05 PM, Massimo Di Stefano <
>> massimodisasha at gmail.com> wrote:
>>
>>> ipython notebook --profile geohab --NotebookApp.base_project_url=
>>> http://geohab.org/ipython --NotebookApp.base_kernel_url=
>>> http://geohab.org/ipython
>>>
>>> [NotebookApp] Using existing profile dir:
>>> u'/home/epy/.ipython/profile_geohab'
>>> [NotebookApp] WARNING: the notebook server is listening on all IP
>>> addresses but not using any encryption or authentication. This is highly
>>> insecure and not recommended.
>>> [NotebookApp] The IPython Notebook is running at: http://[all ip
>>> addresses on your system]:30333http://geohab.org/ipython
>>>
>>>
>>> the log :
>>> [NotebookApp] The IPython Notebook is running at: http://[all ip
>>> addresses on your system]:30333http://geohab.org/ipython
>>>
>>> seems bad so  i tryed :
>>>
>>>
>>> (env1)[epy at web317 ~]$ ipython notebook --profile geohab
>>> --NotebookApp.base_project_url=/ipython
>>> --NotebookApp.base_kernel_url=/ipython[NotebookApp] Using existing profile
>>> dir: u'/home/epy/.ipython/profile_geohab'
>>> [NotebookApp] WARNING: the notebook server is listening on all IP
>>> addresses but not using any encryption or authentication. This is highly
>>> insecure and not recommended.
>>> [NotebookApp] The IPython Notebook is running at: http://[all ip
>>> addresses on your system]:30333/ipython
>>>
>>>
>>> in this case if i point the browser to :
>>>
>>> http://geohab.org/ipython
>>>
>>> i have in the browser :
>>>
>>> 404: Not Found
>>>
>>> in the shell logs :
>>>
>>> WARNING:root:404 GET / (127.0.0.1) 0.48ms
>>>
>>>
>>> if i point the browser to :
>>>
>>> http://geohab.org/ipython/ipython/
>>>
>>> i got again the html page without js/css
>>>
>>> but this time the log in the shell is :
>>>
>>> WARNING:root:404 GET /ipython (127.0.0.1) 0.41ms
>>>
>>>
>>> any clue ?
>>>
>>> thanks!!!
>>>
>>> Massimo.
>>>
>>>
>>>
>>> Il giorno Jun 20, 2012, alle ore 10:17 PM, Brian Granger ha scritto:
>>>
>>> > I think you need to set the following config variables:
>>> >
>>> > --NotebookApp.base_kernel_url=<Unicode>
>>> >    Default: '/'
>>> >    The base URL for the kernel server
>>> > --NotebookApp.base_project_url=<Unicode>
>>> >    Default: '/'
>>> >    The base URL for the notebook server
>>> >
>>> > In either the command line or terminal:
>>> >
>>> > ipython notebook
>>> > --NotebookApp.base_project_url=http://geohab.org/ipython/
>>> > --NotebookApp.base_kernel_url=http://geohab.org/ipython/
>>> >
>>> > Cheers,
>>> >
>>> > Brian
>>> >
>>> > On Wed, Jun 20, 2012 at 7:03 PM, Massimo Di Stefano
>>> > <massimodisasha at gmail.com> wrote:
>>> >> Hi All,
>>> >>
>>> >> is anyone familiar with webfaction [1] ?
>>> >>
>>> >> it is a web-hosting service .. i'm tring to run the ipython notebook
>>> from it but something is going wrong.
>>> >>
>>> >> i sent already a mail to the suppport, but i was wondering if someone
>>> here knows how to fix it.
>>> >>
>>> >>
>>> >>
>>> >> the link to the notebook is :
>>> >>
>>> >> http://geohab.org/ipython
>>> >>
>>> >> i can see the page is loaded but is not able to load the application
>>> ... something is going wrong.
>>> >> all the js and css files are not loaded.
>>> >>
>>> >>
>>> >> trying to understand what's going on ?
>>> >>
>>> >> using firefox : if i click on the text on the top "Ipython Notebook"
>>> >>
>>> >> it should point to the same page, instead is going back to the
>>> web-root : http://geohab.org
>>> >>
>>> >> have you any clue on what i should do in order to have it running
>>> properly ?
>>> >>
>>> >> many thanks!
>>> >>
>>> >> Massimo.
>>> >>
>>> >>
>>> >> [1]  http://www.webfaction.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
>>> > bgranger at calpoly.edu and ellisonbg at gmail.com
>>> > _______________________________________________
>>> > IPython-dev mailing list
>>> > IPython-dev at scipy.org
>>> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>>
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120620/ecf5b2f0/attachment.html>

From benjaminrk at gmail.com  Thu Jun 21 00:28:51 2012
From: benjaminrk at gmail.com (MinRK)
Date: Wed, 20 Jun 2012 21:28:51 -0700
Subject: [IPython-dev] kernel restart
In-Reply-To: <20120621040941.GH6159@mcelrath.org>
References: <20120621040941.GH6159@mcelrath.org>
Message-ID: <CAHNn8BU6a_9gKoX1_SfKk252ikD4p+K7-vop3t1Kf-fjPh+T4w@mail.gmail.com>

On Wed, Jun 20, 2012 at 9:09 PM, Bob McElrath <bob+ipython at mcelrath.org>wrote:

> Very dumb question, but what do I have to type into a cell to restart the
> kernel?
>
> I like to put restart(); (Maple) in the first cell of my worksheet so it's
> easy
> to re-run everything cleanly.
>
> A %restart magic would be very useful.
>

All code in cells runs on the kernel, and the kernel cannot restart itself.
Restart involves killing the kernel, and logically enough, a kernel cannot
start up again *after* it has killed itself.

If you want to clean the namespace and not halt the whole process, this is
what %reset is for.

If you want a convenient mechanism to restart kernels, there is the
keyboard shortcut: ^M-. (control-M, period)  which will restart the kernel.

If you do `exit` in a cell, the kernel will halt, which will trigger a
restart *by the server*.


>
> --
> Cheers, Bob McElrath
>
> "The individual has always had to struggle to keep from being overwhelmed
> by
> the tribe.  If you try it, you will be lonely often, and sometimes
> frightened.
> But no price is too high to pay for the privilege of owning yourself."
>    -- Friedrich Nietzsche
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120620/0e3d70d5/attachment.html>

From massimodisasha at gmail.com  Thu Jun 21 00:36:37 2012
From: massimodisasha at gmail.com (Massimo Di Stefano)
Date: Thu, 21 Jun 2012 00:36:37 -0400
Subject: [IPython-dev] ipython on webfaction hosting
In-Reply-To: <CAHNn8BXYMUdjZ91taScpadek1=-gDa+Qgr3Ge9zLZRXDYQjiPA@mail.gmail.com>
References: <1462386D-2B40-4527-88A1-59098FB1BDEE@gmail.com>
	<CAH4pYpTby4UcmgZvjeiWf2RFPc2hm_mQv7btcdexJFOH2CtFkg@mail.gmail.com>
	<5463AECA-BA6C-453C-A4A0-CFE9F27283FB@gmail.com>
	<CAHNn8BVbwcmdFE6Tbjs0VwFqGCRvEcSf7Ybe6nEcbTi72U0fzg@mail.gmail.com>
	<109468B8-2B83-425D-83A7-6B477212F4DC@gmail.com>
	<CAHNn8BXYMUdjZ91taScpadek1=-gDa+Qgr3Ge9zLZRXDYQjiPA@mail.gmail.com>
Message-ID: <DDD6E759-9891-427D-BF2F-C88882662D02@gmail.com>


i'll continue to try,  but i'm a bit hopeless. ;)

i guess is all in how the server-proxy is configured,
i'll wait an answer from the support and let you know

thanks for the help!

Massimo.

will be nice to see ipython running on a basic web-hosting solution (100$ per year) 

Il giorno Jun 21, 2012, alle ore 12:03 AM, MinRK ha scritto:

> There's something a bit funny in your proxy.
> 
> Try adding one more '/ipython' to just the static url:
> 
> c.NotebookApp.webapp_settings = {'static_url_prefix' : prefix + 'ipython/static/'}
> 
> On Wed, Jun 20, 2012 at 8:49 PM, Massimo Di Stefano <massimodisasha at gmail.com> wrote:
> i applied the changes in the config file
> 
> something is changing in the log :
> 
> # url in the browser :
> 
> http://geohab.org/ipython/
> 
> # log in the shell :
> 
> WARNING:root:404 GET / (127.0.0.1) 0.49ms
> --
> 
> # url in the browser :
> http://geohab.org/ipython/ipython
> 
> # log in the shell :
> WARNING:root:404 GET /ipython (127.0.0.1) 0.36ms
> --
> 
> # url in the browser :
> http://geohab.org/ipython/ipython/
> 
> # log in the shell :
> WARNING:root:404 GET /static/jquery/css/themes/base/jquery-ui.min.css?v=d1a93 (127.0.0.1) 0.37ms
> WARNING:root:404 GET /static/css/fbm.css?v=34be8 (127.0.0.1) 0.42ms
> WARNING:root:404 GET /static/css/boilerplate.css?v=befd7 (127.0.0.1) 0.29ms
> WARNING:root:404 GET /static/css/page.css?v=4c306 (127.0.0.1) 0.51ms
> WARNING:root:404 GET /static/css/projectdashboard.css?v=87030 (127.0.0.1) 0.29ms
> WARNING:root:404 GET /static/jquery/js/jquery-1.7.1.min.js?v=ddb84 (127.0.0.1) 0.29ms
> WARNING:root:404 GET /static/jquery/js/jquery-ui.min.js?v=9fc86 (127.0.0.1) 0.38ms
> WARNING:root:404 GET /static/js/loginwidget.js?v=cd12c (127.0.0.1) 0.30ms
> WARNING:root:404 GET /static/js/notebooklist.js?v=ffa0b (127.0.0.1) 0.30ms
> WARNING:root:404 GET /static/js/clusterlist.js?v=da6d3 (127.0.0.1) 0.33ms
> WARNING:root:404 GET /static/js/namespace.js?v=9e4e0 (127.0.0.1) 0.29ms
> WARNING:root:404 GET /static/js/page.js?v=d306b (127.0.0.1) 0.30ms
> WARNING:root:404 GET /static/ipynblogo.png?v=5892b (127.0.0.1) 0.37ms
> WARNING:root:404 GET /static/js/projectdashboardmain.js?v=64f33 (127.0.0.1) 0.29ms
> 
> 
> 
> click on the logo (firefox is able to find it, safari instead is not ?) it point to the url :
>  
> http://geohab.org/ipython/
> 
> 
> thanks!
> 
> Massimo.
> 
> 
> Il giorno Jun 20, 2012, alle ore 11:33 PM, MinRK ha scritto:
> 
>> The static url is also getting confused.
>> 
>> Try:
>> 
>> ipython notebook --profile geohab --NotebookApp.base_project_url=/ipython/ --NotebookApp.base_kernel_url=/ipython/ --NotebookApp.webapp_settings='{"static_url_prefix": "/ipython/static/"}'
>> 
>> Which in your ipython_notebook_config.py would be:
>> 
>> c = get_config()
>> 
>> prefix = '/ipython/'
>> c.NotebookApp.base_project_url = prefix
>> c.NotebookApp.base_kernel_url = prefix
>> c.NotebookApp.webapp_settings = {'static_url_prefix' : prefix + 'static/'}
>> 
>> At which point you can just do:
>> 
>> ipython notebook --profile geohab
>> 
>> It would certainly appear that a meta-trait that does these three things together would be desirable.
>> 
>> -MinRK
>> 
>> On Wed, Jun 20, 2012 at 8:05 PM, Massimo Di Stefano <massimodisasha at gmail.com> wrote:
>> ipython notebook --profile geohab --NotebookApp.base_project_url=http://geohab.org/ipython --NotebookApp.base_kernel_url=http://geohab.org/ipython
>> 
>> [NotebookApp] Using existing profile dir: u'/home/epy/.ipython/profile_geohab'
>> [NotebookApp] WARNING: the notebook server is listening on all IP addresses but not using any encryption or authentication. This is highly insecure and not recommended.
>> [NotebookApp] The IPython Notebook is running at: http://[all ip addresses on your system]:30333http://geohab.org/ipython
>> 
>> 
>> the log :
>> [NotebookApp] The IPython Notebook is running at: http://[all ip addresses on your system]:30333http://geohab.org/ipython
>> 
>> seems bad so  i tryed :
>> 
>> 
>> (env1)[epy at web317 ~]$ ipython notebook --profile geohab --NotebookApp.base_project_url=/ipython --NotebookApp.base_kernel_url=/ipython[NotebookApp] Using existing profile dir: u'/home/epy/.ipython/profile_geohab'
>> [NotebookApp] WARNING: the notebook server is listening on all IP addresses but not using any encryption or authentication. This is highly insecure and not recommended.
>> [NotebookApp] The IPython Notebook is running at: http://[all ip addresses on your system]:30333/ipython
>> 
>> 
>> in this case if i point the browser to :
>> 
>> http://geohab.org/ipython
>> 
>> i have in the browser :
>> 
>> 404: Not Found
>> 
>> in the shell logs :
>> 
>> WARNING:root:404 GET / (127.0.0.1) 0.48ms
>> 
>> 
>> if i point the browser to :
>> 
>> http://geohab.org/ipython/ipython/
>> 
>> i got again the html page without js/css
>> 
>> but this time the log in the shell is :
>> 
>> WARNING:root:404 GET /ipython (127.0.0.1) 0.41ms
>> 
>> 
>> any clue ?
>> 
>> thanks!!!
>> 
>> Massimo.
>> 
>> 
>> 
>> Il giorno Jun 20, 2012, alle ore 10:17 PM, Brian Granger ha scritto:
>> 
>> > I think you need to set the following config variables:
>> >
>> > --NotebookApp.base_kernel_url=<Unicode>
>> >    Default: '/'
>> >    The base URL for the kernel server
>> > --NotebookApp.base_project_url=<Unicode>
>> >    Default: '/'
>> >    The base URL for the notebook server
>> >
>> > In either the command line or terminal:
>> >
>> > ipython notebook
>> > --NotebookApp.base_project_url=http://geohab.org/ipython/
>> > --NotebookApp.base_kernel_url=http://geohab.org/ipython/
>> >
>> > Cheers,
>> >
>> > Brian
>> >
>> > On Wed, Jun 20, 2012 at 7:03 PM, Massimo Di Stefano
>> > <massimodisasha at gmail.com> wrote:
>> >> Hi All,
>> >>
>> >> is anyone familiar with webfaction [1] ?
>> >>
>> >> it is a web-hosting service .. i'm tring to run the ipython notebook from it but something is going wrong.
>> >>
>> >> i sent already a mail to the suppport, but i was wondering if someone here knows how to fix it.
>> >>
>> >>
>> >>
>> >> the link to the notebook is :
>> >>
>> >> http://geohab.org/ipython
>> >>
>> >> i can see the page is loaded but is not able to load the application ... something is going wrong.
>> >> all the js and css files are not loaded.
>> >>
>> >>
>> >> trying to understand what's going on ?
>> >>
>> >> using firefox : if i click on the text on the top "Ipython Notebook"
>> >>
>> >> it should point to the same page, instead is going back to the web-root : http://geohab.org
>> >>
>> >> have you any clue on what i should do in order to have it running properly ?
>> >>
>> >> many thanks!
>> >>
>> >> Massimo.
>> >>
>> >>
>> >> [1]  http://www.webfaction.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
>> > bgranger at calpoly.edu and ellisonbg at gmail.com
>> > _______________________________________________
>> > IPython-dev mailing list
>> > IPython-dev at scipy.org
>> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>> 
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>> 
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> 
> 
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
> 
> 
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev

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

From bob+ipython at mcelrath.org  Thu Jun 21 01:11:42 2012
From: bob+ipython at mcelrath.org (Bob McElrath)
Date: Thu, 21 Jun 2012 05:11:42 +0000
Subject: [IPython-dev] kernel restart
In-Reply-To: <CAHNn8BU6a_9gKoX1_SfKk252ikD4p+K7-vop3t1Kf-fjPh+T4w@mail.gmail.com>
References: <20120621040941.GH6159@mcelrath.org>
	<CAHNn8BU6a_9gKoX1_SfKk252ikD4p+K7-vop3t1Kf-fjPh+T4w@mail.gmail.com>
Message-ID: <20120621051142.GI6159@mcelrath.org>

MinRK [benjaminrk at gmail.com] wrote:
> 
> All code in cells runs on the kernel, and the kernel cannot restart itself.
> Restart involves killing the kernel, and logically enough, a kernel cannot
> start up again *after* it has killed itself.
> 
> If you want to clean the namespace and not halt the whole process, this is what
> %reset is for.

This is insufficient as a programmatic restart.  Imported packages are not
cleanly re-imported.  See the caveats surrounding reload() for instance.

%reset seems to be a bit worse though, as far as I can tell it does NOT reload()
modules (does not recompile them).  What would be required to make %reset see
source changes on imported modules?

So maybe it wasn't a stupid question, as this functionality doesn't exist...

--
Cheers, Bob McElrath

"The individual has always had to struggle to keep from being overwhelmed by
the tribe.  If you try it, you will be lonely often, and sometimes frightened.
But no price is too high to pay for the privilege of owning yourself." 
    -- Friedrich Nietzsche


From ellisonbg at gmail.com  Thu Jun 21 01:15:12 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Wed, 20 Jun 2012 22:15:12 -0700
Subject: [IPython-dev] ipython on webfaction hosting
In-Reply-To: <DDD6E759-9891-427D-BF2F-C88882662D02@gmail.com>
References: <1462386D-2B40-4527-88A1-59098FB1BDEE@gmail.com>
	<CAH4pYpTby4UcmgZvjeiWf2RFPc2hm_mQv7btcdexJFOH2CtFkg@mail.gmail.com>
	<5463AECA-BA6C-453C-A4A0-CFE9F27283FB@gmail.com>
	<CAHNn8BVbwcmdFE6Tbjs0VwFqGCRvEcSf7Ybe6nEcbTi72U0fzg@mail.gmail.com>
	<109468B8-2B83-425D-83A7-6B477212F4DC@gmail.com>
	<CAHNn8BXYMUdjZ91taScpadek1=-gDa+Qgr3Ge9zLZRXDYQjiPA@mail.gmail.com>
	<DDD6E759-9891-427D-BF2F-C88882662D02@gmail.com>
Message-ID: <CAH4pYpRjEwbY5HuO5aTAh=UnwdWtsCkRa3HKsHpfSSmmojgx6Q@mail.gmail.com>

What proxy are you using?  Many proxies don't support WebSockets.

Brian

On Wed, Jun 20, 2012 at 9:36 PM, Massimo Di Stefano
<massimodisasha at gmail.com> wrote:
>
> i'll continue to try, ?but i'm a bit hopeless. ;)
>
> i guess is all in how the server-proxy is configured,
> i'll wait an answer from the support and let you know
>
> thanks for the help!
>
> Massimo.
>
> will be nice to see ipython running on a basic web-hosting solution (100$
> per year)
>
> Il giorno Jun 21, 2012, alle ore 12:03 AM, MinRK ha scritto:
>
> There's something a bit funny in your proxy.
>
> Try adding one more '/ipython' to just the static url:
>
> c.NotebookApp.webapp_settings = {'static_url_prefix' : prefix +
> 'ipython/static/'}
>
> On Wed, Jun 20, 2012 at 8:49 PM, Massimo Di Stefano
> <massimodisasha at gmail.com> wrote:
>>
>> i applied the changes in the config file
>>
>> something is changing in the log :
>>
>> # url in the browser :
>>
>> http://geohab.org/ipython/
>>
>> # log in the shell :
>>
>> WARNING:root:404 GET / (127.0.0.1) 0.49ms
>> --
>>
>> # url in the browser :
>> http://geohab.org/ipython/ipython
>>
>> # log in the shell :
>> WARNING:root:404 GET /ipython (127.0.0.1) 0.36ms
>> --
>>
>> # url in the browser :
>> http://geohab.org/ipython/ipython/
>>
>> # log in the shell :
>> WARNING:root:404 GET
>> /static/jquery/css/themes/base/jquery-ui.min.css?v=d1a93 (127.0.0.1) 0.37ms
>> WARNING:root:404 GET /static/css/fbm.css?v=34be8 (127.0.0.1) 0.42ms
>> WARNING:root:404 GET /static/css/boilerplate.css?v=befd7 (127.0.0.1)
>> 0.29ms
>> WARNING:root:404 GET /static/css/page.css?v=4c306 (127.0.0.1) 0.51ms
>> WARNING:root:404 GET /static/css/projectdashboard.css?v=87030 (127.0.0.1)
>> 0.29ms
>> WARNING:root:404 GET /static/jquery/js/jquery-1.7.1.min.js?v=ddb84
>> (127.0.0.1) 0.29ms
>> WARNING:root:404 GET /static/jquery/js/jquery-ui.min.js?v=9fc86
>> (127.0.0.1) 0.38ms
>> WARNING:root:404 GET /static/js/loginwidget.js?v=cd12c (127.0.0.1) 0.30ms
>> WARNING:root:404 GET /static/js/notebooklist.js?v=ffa0b (127.0.0.1) 0.30ms
>> WARNING:root:404 GET /static/js/clusterlist.js?v=da6d3 (127.0.0.1) 0.33ms
>> WARNING:root:404 GET /static/js/namespace.js?v=9e4e0 (127.0.0.1) 0.29ms
>> WARNING:root:404 GET /static/js/page.js?v=d306b (127.0.0.1) 0.30ms
>> WARNING:root:404 GET /static/ipynblogo.png?v=5892b (127.0.0.1) 0.37ms
>> WARNING:root:404 GET /static/js/projectdashboardmain.js?v=64f33
>> (127.0.0.1) 0.29ms
>>
>>
>>
>> click on the logo (firefox is able to find it, safari instead is not ?) it
>> point to the url :
>>
>> http://geohab.org/ipython/
>>
>>
>> thanks!
>>
>> Massimo.
>>
>>
>> Il giorno Jun 20, 2012, alle ore 11:33 PM, MinRK ha scritto:
>>
>> The static url is also getting confused.
>>
>> Try:
>>
>> ipython notebook --profile geohab?--NotebookApp.base_project_url=/ipython/
>> --NotebookApp.base_kernel_url=/ipython/
>> --NotebookApp.webapp_settings='{"static_url_prefix": "/ipython/static/"}'
>>
>> Which in your ipython_notebook_config.py would be:
>>
>> c = get_config()
>>
>> prefix = '/ipython/'
>> c.NotebookApp.base_project_url = prefix
>> c.NotebookApp.base_kernel_url = prefix
>> c.NotebookApp.webapp_settings = {'static_url_prefix' : prefix + 'static/'}
>>
>> At which point you can just do:
>>
>> ipython?notebook --profile geohab
>>
>> It would certainly appear that a meta-trait that does these three things
>> together would be desirable.
>>
>> -MinRK
>>
>> On Wed, Jun 20, 2012 at 8:05 PM, Massimo Di Stefano
>> <massimodisasha at gmail.com> wrote:
>>>
>>> ipython notebook --profile geohab
>>> --NotebookApp.base_project_url=http://geohab.org/ipython
>>> --NotebookApp.base_kernel_url=http://geohab.org/ipython
>>>
>>> [NotebookApp] Using existing profile dir:
>>> u'/home/epy/.ipython/profile_geohab'
>>> [NotebookApp] WARNING: the notebook server is listening on all IP
>>> addresses but not using any encryption or authentication. This is highly
>>> insecure and not recommended.
>>> [NotebookApp] The IPython Notebook is running at: http://[all ip
>>> addresses on your system]:30333http://geohab.org/ipython
>>>
>>>
>>> the log :
>>> [NotebookApp] The IPython Notebook is running at: http://[all ip
>>> addresses on your system]:30333http://geohab.org/ipython
>>>
>>> seems bad so ?i tryed :
>>>
>>>
>>> (env1)[epy at web317 ~]$ ipython notebook --profile geohab
>>> --NotebookApp.base_project_url=/ipython
>>> --NotebookApp.base_kernel_url=/ipython[NotebookApp] Using existing profile
>>> dir: u'/home/epy/.ipython/profile_geohab'
>>> [NotebookApp] WARNING: the notebook server is listening on all IP
>>> addresses but not using any encryption or authentication. This is highly
>>> insecure and not recommended.
>>> [NotebookApp] The IPython Notebook is running at: http://[all ip
>>> addresses on your system]:30333/ipython
>>>
>>>
>>> in this case if i point the browser to :
>>>
>>> http://geohab.org/ipython
>>>
>>> i have in the browser :
>>>
>>> 404: Not Found
>>>
>>> in the shell logs :
>>>
>>> WARNING:root:404 GET / (127.0.0.1) 0.48ms
>>>
>>>
>>> if i point the browser to :
>>>
>>> http://geohab.org/ipython/ipython/
>>>
>>> i got again the html page without js/css
>>>
>>> but this time the log in the shell is :
>>>
>>> WARNING:root:404 GET /ipython (127.0.0.1) 0.41ms
>>>
>>>
>>> any clue ?
>>>
>>> thanks!!!
>>>
>>> Massimo.
>>>
>>>
>>>
>>> Il giorno Jun 20, 2012, alle ore 10:17 PM, Brian Granger ha scritto:
>>>
>>> > I think you need to set the following config variables:
>>> >
>>> > --NotebookApp.base_kernel_url=<Unicode>
>>> > ? ?Default: '/'
>>> > ? ?The base URL for the kernel server
>>> > --NotebookApp.base_project_url=<Unicode>
>>> > ? ?Default: '/'
>>> > ? ?The base URL for the notebook server
>>> >
>>> > In either the command line or terminal:
>>> >
>>> > ipython notebook
>>> > --NotebookApp.base_project_url=http://geohab.org/ipython/
>>> > --NotebookApp.base_kernel_url=http://geohab.org/ipython/
>>> >
>>> > Cheers,
>>> >
>>> > Brian
>>> >
>>> > On Wed, Jun 20, 2012 at 7:03 PM, Massimo Di Stefano
>>> > <massimodisasha at gmail.com> wrote:
>>> >> Hi All,
>>> >>
>>> >> is anyone familiar with webfaction [1] ?
>>> >>
>>> >> it is a web-hosting service .. i'm tring to run the ipython notebook
>>> >> from it but something is going wrong.
>>> >>
>>> >> i sent already a mail to the suppport, but i was wondering if someone
>>> >> here knows how to fix it.
>>> >>
>>> >>
>>> >>
>>> >> the link to the notebook is :
>>> >>
>>> >> http://geohab.org/ipython
>>> >>
>>> >> i can see the page is loaded but is not able to load the application
>>> >> ... something is going wrong.
>>> >> all the js and css files are not loaded.
>>> >>
>>> >>
>>> >> trying to understand what's going on ?
>>> >>
>>> >> using firefox : if i click on the text on the top "Ipython Notebook"
>>> >>
>>> >> it should point to the same page, instead is going back to the
>>> >> web-root : http://geohab.org
>>> >>
>>> >> have you any clue on what i should do in order to have it running
>>> >> properly ?
>>> >>
>>> >> many thanks!
>>> >>
>>> >> Massimo.
>>> >>
>>> >>
>>> >> [1] ?http://www.webfaction.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
>>> > bgranger at calpoly.edu and ellisonbg at gmail.com
>>> > _______________________________________________
>>> > IPython-dev mailing list
>>> > IPython-dev at scipy.org
>>> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>>
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



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


From benjaminrk at gmail.com  Thu Jun 21 01:18:07 2012
From: benjaminrk at gmail.com (MinRK)
Date: Wed, 20 Jun 2012 22:18:07 -0700
Subject: [IPython-dev] kernel restart
In-Reply-To: <20120621051142.GI6159@mcelrath.org>
References: <20120621040941.GH6159@mcelrath.org>
	<CAHNn8BU6a_9gKoX1_SfKk252ikD4p+K7-vop3t1Kf-fjPh+T4w@mail.gmail.com>
	<20120621051142.GI6159@mcelrath.org>
Message-ID: <CAHNn8BVo-uCibFpo_upUpA1b4MOC1DiATkT=njyHmsZg8vdrWw@mail.gmail.com>

On Wed, Jun 20, 2012 at 10:11 PM, Bob McElrath <bob+ipython at mcelrath.org>wrote:

> MinRK [benjaminrk at gmail.com] wrote:
> >
> > All code in cells runs on the kernel, and the kernel cannot restart
> itself.
> > Restart involves killing the kernel, and logically enough, a kernel
> cannot
> > start up again *after* it has killed itself.
> >
> > If you want to clean the namespace and not halt the whole process, this
> is what
> > %reset is for.
>
> This is insufficient as a programmatic restart.  Imported packages are not
> cleanly re-imported.  See the caveats surrounding reload() for instance.
>
> %reset seems to be a bit worse though, as far as I can tell it does NOT
> reload()
> modules (does not recompile them).  What would be required to make %reset
> see
> source changes on imported modules?
>
> So maybe it wasn't a stupid question, as this functionality doesn't
> exist...
>

Nope - it doesn't and I don't believe it can.


>
> --
> Cheers, Bob McElrath
>
> "The individual has always had to struggle to keep from being overwhelmed
> by
> the tribe.  If you try it, you will be lonely often, and sometimes
> frightened.
> But no price is too high to pay for the privilege of owning yourself."
>    -- Friedrich Nietzsche
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120620/c3984e65/attachment.html>

From fperez.net at gmail.com  Thu Jun 21 01:32:07 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 20 Jun 2012 22:32:07 -0700
Subject: [IPython-dev] kernel restart
In-Reply-To: <20120621051142.GI6159@mcelrath.org>
References: <20120621040941.GH6159@mcelrath.org>
	<CAHNn8BU6a_9gKoX1_SfKk252ikD4p+K7-vop3t1Kf-fjPh+T4w@mail.gmail.com>
	<20120621051142.GI6159@mcelrath.org>
Message-ID: <CAHAreOruPPD6FuatCoTpAYKHaXZrRTLi1tdoCU2G+PUuoa7DQA@mail.gmail.com>

On Wed, Jun 20, 2012 at 10:11 PM, Bob McElrath <bob+ipython at mcelrath.org> wrote:
> %reset seems to be a bit worse though, as far as I can tell it does NOT reload()
> modules (does not recompile them). ?What would be required to make %reset see
> source changes on imported modules?

%reset was only meant to delete all variables from your namespace, not
to have anything to do with module import/reload.

You may want to look at the autoreload extension:

http://ipython.org/ipython-doc/dev/config/extensions/autoreload.html

and at the dreload() function we also provide:

http://ipython.org/ipython-doc/dev/interactive/reference.html#recursive-reload

Note that neither of these can reload extension modules, as that is a
limitation of Python itself.

Cheers,

f


From massimodisasha at gmail.com  Thu Jun 21 02:36:10 2012
From: massimodisasha at gmail.com (Massimo Di Stefano)
Date: Thu, 21 Jun 2012 02:36:10 -0400
Subject: [IPython-dev] ipython on webfaction hosting
In-Reply-To: <CAH4pYpRjEwbY5HuO5aTAh=UnwdWtsCkRa3HKsHpfSSmmojgx6Q@mail.gmail.com>
References: <1462386D-2B40-4527-88A1-59098FB1BDEE@gmail.com>
	<CAH4pYpTby4UcmgZvjeiWf2RFPc2hm_mQv7btcdexJFOH2CtFkg@mail.gmail.com>
	<5463AECA-BA6C-453C-A4A0-CFE9F27283FB@gmail.com>
	<CAHNn8BVbwcmdFE6Tbjs0VwFqGCRvEcSf7Ybe6nEcbTi72U0fzg@mail.gmail.com>
	<109468B8-2B83-425D-83A7-6B477212F4DC@gmail.com>
	<CAHNn8BXYMUdjZ91taScpadek1=-gDa+Qgr3Ge9zLZRXDYQjiPA@mail.gmail.com>
	<DDD6E759-9891-427D-BF2F-C88882662D02@gmail.com>
	<CAH4pYpRjEwbY5HuO5aTAh=UnwdWtsCkRa3HKsHpfSSmmojgx6Q@mail.gmail.com>
Message-ID: <1EAE81AF-D686-487D-8B75-26A10DB84E60@gmail.com>

Brian, 

you're right!

From the support on webfaction (i pointed him to this topic) :


From this mailing list question, it looks like you're trying to use WebSockets. The front-end Nginx proxy won't support that, but we can add a free "second shared IP address" to your account and on this IP we can open your custom application port. Then, your application can communicate directly over the internet without a proxy (Nginx).

Would you like us to add this IP at this time?

?


not it's runnning fine!
i have to type the IP instead of the host name .. but it's fine :)


thanks!!!



Il giorno Jun 21, 2012, alle ore 1:15 AM, Brian Granger ha scritto:

> What proxy are you using?  Many proxies don't support WebSockets.
> 
> Brian
> 
> On Wed, Jun 20, 2012 at 9:36 PM, Massimo Di Stefano
> <massimodisasha at gmail.com> wrote:
>> 
>> i'll continue to try,  but i'm a bit hopeless. ;)
>> 
>> i guess is all in how the server-proxy is configured,
>> i'll wait an answer from the support and let you know
>> 
>> thanks for the help!
>> 
>> Massimo.
>> 
>> will be nice to see ipython running on a basic web-hosting solution (100$
>> per year)
>> 
>> Il giorno Jun 21, 2012, alle ore 12:03 AM, MinRK ha scritto:
>> 
>> There's something a bit funny in your proxy.
>> 
>> Try adding one more '/ipython' to just the static url:
>> 
>> c.NotebookApp.webapp_settings = {'static_url_prefix' : prefix +
>> 'ipython/static/'}
>> 
>> On Wed, Jun 20, 2012 at 8:49 PM, Massimo Di Stefano
>> <massimodisasha at gmail.com> wrote:
>>> 
>>> i applied the changes in the config file
>>> 
>>> something is changing in the log :
>>> 
>>> # url in the browser :
>>> 
>>> http://geohab.org/ipython/
>>> 
>>> # log in the shell :
>>> 
>>> WARNING:root:404 GET / (127.0.0.1) 0.49ms
>>> --
>>> 
>>> # url in the browser :
>>> http://geohab.org/ipython/ipython
>>> 
>>> # log in the shell :
>>> WARNING:root:404 GET /ipython (127.0.0.1) 0.36ms
>>> --
>>> 
>>> # url in the browser :
>>> http://geohab.org/ipython/ipython/
>>> 
>>> # log in the shell :
>>> WARNING:root:404 GET
>>> /static/jquery/css/themes/base/jquery-ui.min.css?v=d1a93 (127.0.0.1) 0.37ms
>>> WARNING:root:404 GET /static/css/fbm.css?v=34be8 (127.0.0.1) 0.42ms
>>> WARNING:root:404 GET /static/css/boilerplate.css?v=befd7 (127.0.0.1)
>>> 0.29ms
>>> WARNING:root:404 GET /static/css/page.css?v=4c306 (127.0.0.1) 0.51ms
>>> WARNING:root:404 GET /static/css/projectdashboard.css?v=87030 (127.0.0.1)
>>> 0.29ms
>>> WARNING:root:404 GET /static/jquery/js/jquery-1.7.1.min.js?v=ddb84
>>> (127.0.0.1) 0.29ms
>>> WARNING:root:404 GET /static/jquery/js/jquery-ui.min.js?v=9fc86
>>> (127.0.0.1) 0.38ms
>>> WARNING:root:404 GET /static/js/loginwidget.js?v=cd12c (127.0.0.1) 0.30ms
>>> WARNING:root:404 GET /static/js/notebooklist.js?v=ffa0b (127.0.0.1) 0.30ms
>>> WARNING:root:404 GET /static/js/clusterlist.js?v=da6d3 (127.0.0.1) 0.33ms
>>> WARNING:root:404 GET /static/js/namespace.js?v=9e4e0 (127.0.0.1) 0.29ms
>>> WARNING:root:404 GET /static/js/page.js?v=d306b (127.0.0.1) 0.30ms
>>> WARNING:root:404 GET /static/ipynblogo.png?v=5892b (127.0.0.1) 0.37ms
>>> WARNING:root:404 GET /static/js/projectdashboardmain.js?v=64f33
>>> (127.0.0.1) 0.29ms
>>> 
>>> 
>>> 
>>> click on the logo (firefox is able to find it, safari instead is not ?) it
>>> point to the url :
>>> 
>>> http://geohab.org/ipython/
>>> 
>>> 
>>> thanks!
>>> 
>>> Massimo.
>>> 
>>> 
>>> Il giorno Jun 20, 2012, alle ore 11:33 PM, MinRK ha scritto:
>>> 
>>> The static url is also getting confused.
>>> 
>>> Try:
>>> 
>>> ipython notebook --profile geohab --NotebookApp.base_project_url=/ipython/
>>> --NotebookApp.base_kernel_url=/ipython/
>>> --NotebookApp.webapp_settings='{"static_url_prefix": "/ipython/static/"}'
>>> 
>>> Which in your ipython_notebook_config.py would be:
>>> 
>>> c = get_config()
>>> 
>>> prefix = '/ipython/'
>>> c.NotebookApp.base_project_url = prefix
>>> c.NotebookApp.base_kernel_url = prefix
>>> c.NotebookApp.webapp_settings = {'static_url_prefix' : prefix + 'static/'}
>>> 
>>> At which point you can just do:
>>> 
>>> ipython notebook --profile geohab
>>> 
>>> It would certainly appear that a meta-trait that does these three things
>>> together would be desirable.
>>> 
>>> -MinRK
>>> 
>>> On Wed, Jun 20, 2012 at 8:05 PM, Massimo Di Stefano
>>> <massimodisasha at gmail.com> wrote:
>>>> 
>>>> ipython notebook --profile geohab
>>>> --NotebookApp.base_project_url=http://geohab.org/ipython
>>>> --NotebookApp.base_kernel_url=http://geohab.org/ipython
>>>> 
>>>> [NotebookApp] Using existing profile dir:
>>>> u'/home/epy/.ipython/profile_geohab'
>>>> [NotebookApp] WARNING: the notebook server is listening on all IP
>>>> addresses but not using any encryption or authentication. This is highly
>>>> insecure and not recommended.
>>>> [NotebookApp] The IPython Notebook is running at: http://[all ip
>>>> addresses on your system]:30333http://geohab.org/ipython
>>>> 
>>>> 
>>>> the log :
>>>> [NotebookApp] The IPython Notebook is running at: http://[all ip
>>>> addresses on your system]:30333http://geohab.org/ipython
>>>> 
>>>> seems bad so  i tryed :
>>>> 
>>>> 
>>>> (env1)[epy at web317 ~]$ ipython notebook --profile geohab
>>>> --NotebookApp.base_project_url=/ipython
>>>> --NotebookApp.base_kernel_url=/ipython[NotebookApp] Using existing profile
>>>> dir: u'/home/epy/.ipython/profile_geohab'
>>>> [NotebookApp] WARNING: the notebook server is listening on all IP
>>>> addresses but not using any encryption or authentication. This is highly
>>>> insecure and not recommended.
>>>> [NotebookApp] The IPython Notebook is running at: http://[all ip
>>>> addresses on your system]:30333/ipython
>>>> 
>>>> 
>>>> in this case if i point the browser to :
>>>> 
>>>> http://geohab.org/ipython
>>>> 
>>>> i have in the browser :
>>>> 
>>>> 404: Not Found
>>>> 
>>>> in the shell logs :
>>>> 
>>>> WARNING:root:404 GET / (127.0.0.1) 0.48ms
>>>> 
>>>> 
>>>> if i point the browser to :
>>>> 
>>>> http://geohab.org/ipython/ipython/
>>>> 
>>>> i got again the html page without js/css
>>>> 
>>>> but this time the log in the shell is :
>>>> 
>>>> WARNING:root:404 GET /ipython (127.0.0.1) 0.41ms
>>>> 
>>>> 
>>>> any clue ?
>>>> 
>>>> thanks!!!
>>>> 
>>>> Massimo.
>>>> 
>>>> 
>>>> 
>>>> Il giorno Jun 20, 2012, alle ore 10:17 PM, Brian Granger ha scritto:
>>>> 
>>>>> I think you need to set the following config variables:
>>>>> 
>>>>> --NotebookApp.base_kernel_url=<Unicode>
>>>>>    Default: '/'
>>>>>    The base URL for the kernel server
>>>>> --NotebookApp.base_project_url=<Unicode>
>>>>>    Default: '/'
>>>>>    The base URL for the notebook server
>>>>> 
>>>>> In either the command line or terminal:
>>>>> 
>>>>> ipython notebook
>>>>> --NotebookApp.base_project_url=http://geohab.org/ipython/
>>>>> --NotebookApp.base_kernel_url=http://geohab.org/ipython/
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> Brian
>>>>> 
>>>>> On Wed, Jun 20, 2012 at 7:03 PM, Massimo Di Stefano
>>>>> <massimodisasha at gmail.com> wrote:
>>>>>> Hi All,
>>>>>> 
>>>>>> is anyone familiar with webfaction [1] ?
>>>>>> 
>>>>>> it is a web-hosting service .. i'm tring to run the ipython notebook
>>>>>> from it but something is going wrong.
>>>>>> 
>>>>>> i sent already a mail to the suppport, but i was wondering if someone
>>>>>> here knows how to fix it.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> the link to the notebook is :
>>>>>> 
>>>>>> http://geohab.org/ipython
>>>>>> 
>>>>>> i can see the page is loaded but is not able to load the application
>>>>>> ... something is going wrong.
>>>>>> all the js and css files are not loaded.
>>>>>> 
>>>>>> 
>>>>>> trying to understand what's going on ?
>>>>>> 
>>>>>> using firefox : if i click on the text on the top "Ipython Notebook"
>>>>>> 
>>>>>> it should point to the same page, instead is going back to the
>>>>>> web-root : http://geohab.org
>>>>>> 
>>>>>> have you any clue on what i should do in order to have it running
>>>>>> properly ?
>>>>>> 
>>>>>> many thanks!
>>>>>> 
>>>>>> Massimo.
>>>>>> 
>>>>>> 
>>>>>> [1]  http://www.webfaction.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
>>>>> bgranger at calpoly.edu and ellisonbg at gmail.com
>>>>> _______________________________________________
>>>>> IPython-dev mailing list
>>>>> IPython-dev at scipy.org
>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>> 
>>>> _______________________________________________
>>>> IPython-dev mailing list
>>>> IPython-dev at scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>> 
>>> 
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>> 
>> 
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>> 
>> 
>> 
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>> 
> 
> 
> 
> -- 
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu and ellisonbg at gmail.com
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



From massimodisasha at gmail.com  Thu Jun 21 06:17:59 2012
From: massimodisasha at gmail.com (Massimo Di Stefano)
Date: Thu, 21 Jun 2012 06:17:59 -0400
Subject: [IPython-dev] ipython on webfaction hosting
In-Reply-To: <1EAE81AF-D686-487D-8B75-26A10DB84E60@gmail.com>
References: <1462386D-2B40-4527-88A1-59098FB1BDEE@gmail.com>
	<CAH4pYpTby4UcmgZvjeiWf2RFPc2hm_mQv7btcdexJFOH2CtFkg@mail.gmail.com>
	<5463AECA-BA6C-453C-A4A0-CFE9F27283FB@gmail.com>
	<CAHNn8BVbwcmdFE6Tbjs0VwFqGCRvEcSf7Ybe6nEcbTi72U0fzg@mail.gmail.com>
	<109468B8-2B83-425D-83A7-6B477212F4DC@gmail.com>
	<CAHNn8BXYMUdjZ91taScpadek1=-gDa+Qgr3Ge9zLZRXDYQjiPA@mail.gmail.com>
	<DDD6E759-9891-427D-BF2F-C88882662D02@gmail.com>
	<CAH4pYpRjEwbY5HuO5aTAh=UnwdWtsCkRa3HKsHpfSSmmojgx6Q@mail.gmail.com>
	<1EAE81AF-D686-487D-8B75-26A10DB84E60@gmail.com>
Message-ID: <87186175-9B48-4CD5-9F8B-00E824714659@gmail.com>

i forgot ?


Using an html file like :

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>IPython</title>
<META name="IPython" content="IPython"><META name="keywords" content="IPython">
</head>
<frameset rows="100%,*" border="0">
<frame src="
http://xx.xx.xx.xx:yyyyy/ipython/" frameborder="0" />
<frame frameborder="0" noresize />
</frameset>
</html>


i can avoid to type the IP (hints from webfaction support)
happy notebook!!!

;)

Il giorno Jun 21, 2012, alle ore 2:36 AM, Massimo Di Stefano ha scritto:

> Brian, 
> 
> you're right!
> 
> From the support on webfaction (i pointed him to this topic) :
> 
> 
> From this mailing list question, it looks like you're trying to use WebSockets. The front-end Nginx proxy won't support that, but we can add a free "second shared IP address" to your account and on this IP we can open your custom application port. Then, your application can communicate directly over the internet without a proxy (Nginx).
> 
> Would you like us to add this IP at this time?
> 
> ?
> 
> 
> not it's runnning fine!
> i have to type the IP instead of the host name .. but it's fine :)
> 
> 
> thanks!!!
> 
> 
> 
> Il giorno Jun 21, 2012, alle ore 1:15 AM, Brian Granger ha scritto:
> 
>> What proxy are you using?  Many proxies don't support WebSockets.
>> 
>> Brian
>> 
>> On Wed, Jun 20, 2012 at 9:36 PM, Massimo Di Stefano
>> <massimodisasha at gmail.com> wrote:
>>> 
>>> i'll continue to try,  but i'm a bit hopeless. ;)
>>> 
>>> i guess is all in how the server-proxy is configured,
>>> i'll wait an answer from the support and let you know
>>> 
>>> thanks for the help!
>>> 
>>> Massimo.
>>> 
>>> will be nice to see ipython running on a basic web-hosting solution (100$
>>> per year)
>>> 
>>> Il giorno Jun 21, 2012, alle ore 12:03 AM, MinRK ha scritto:
>>> 
>>> There's something a bit funny in your proxy.
>>> 
>>> Try adding one more '/ipython' to just the static url:
>>> 
>>> c.NotebookApp.webapp_settings = {'static_url_prefix' : prefix +
>>> 'ipython/static/'}
>>> 
>>> On Wed, Jun 20, 2012 at 8:49 PM, Massimo Di Stefano
>>> <massimodisasha at gmail.com> wrote:
>>>> 
>>>> i applied the changes in the config file
>>>> 
>>>> something is changing in the log :
>>>> 
>>>> # url in the browser :
>>>> 
>>>> http://geohab.org/ipython/
>>>> 
>>>> # log in the shell :
>>>> 
>>>> WARNING:root:404 GET / (127.0.0.1) 0.49ms
>>>> --
>>>> 
>>>> # url in the browser :
>>>> http://geohab.org/ipython/ipython
>>>> 
>>>> # log in the shell :
>>>> WARNING:root:404 GET /ipython (127.0.0.1) 0.36ms
>>>> --
>>>> 
>>>> # url in the browser :
>>>> http://geohab.org/ipython/ipython/
>>>> 
>>>> # log in the shell :
>>>> WARNING:root:404 GET
>>>> /static/jquery/css/themes/base/jquery-ui.min.css?v=d1a93 (127.0.0.1) 0.37ms
>>>> WARNING:root:404 GET /static/css/fbm.css?v=34be8 (127.0.0.1) 0.42ms
>>>> WARNING:root:404 GET /static/css/boilerplate.css?v=befd7 (127.0.0.1)
>>>> 0.29ms
>>>> WARNING:root:404 GET /static/css/page.css?v=4c306 (127.0.0.1) 0.51ms
>>>> WARNING:root:404 GET /static/css/projectdashboard.css?v=87030 (127.0.0.1)
>>>> 0.29ms
>>>> WARNING:root:404 GET /static/jquery/js/jquery-1.7.1.min.js?v=ddb84
>>>> (127.0.0.1) 0.29ms
>>>> WARNING:root:404 GET /static/jquery/js/jquery-ui.min.js?v=9fc86
>>>> (127.0.0.1) 0.38ms
>>>> WARNING:root:404 GET /static/js/loginwidget.js?v=cd12c (127.0.0.1) 0.30ms
>>>> WARNING:root:404 GET /static/js/notebooklist.js?v=ffa0b (127.0.0.1) 0.30ms
>>>> WARNING:root:404 GET /static/js/clusterlist.js?v=da6d3 (127.0.0.1) 0.33ms
>>>> WARNING:root:404 GET /static/js/namespace.js?v=9e4e0 (127.0.0.1) 0.29ms
>>>> WARNING:root:404 GET /static/js/page.js?v=d306b (127.0.0.1) 0.30ms
>>>> WARNING:root:404 GET /static/ipynblogo.png?v=5892b (127.0.0.1) 0.37ms
>>>> WARNING:root:404 GET /static/js/projectdashboardmain.js?v=64f33
>>>> (127.0.0.1) 0.29ms
>>>> 
>>>> 
>>>> 
>>>> click on the logo (firefox is able to find it, safari instead is not ?) it
>>>> point to the url :
>>>> 
>>>> http://geohab.org/ipython/
>>>> 
>>>> 
>>>> thanks!
>>>> 
>>>> Massimo.
>>>> 
>>>> 
>>>> Il giorno Jun 20, 2012, alle ore 11:33 PM, MinRK ha scritto:
>>>> 
>>>> The static url is also getting confused.
>>>> 
>>>> Try:
>>>> 
>>>> ipython notebook --profile geohab --NotebookApp.base_project_url=/ipython/
>>>> --NotebookApp.base_kernel_url=/ipython/
>>>> --NotebookApp.webapp_settings='{"static_url_prefix": "/ipython/static/"}'
>>>> 
>>>> Which in your ipython_notebook_config.py would be:
>>>> 
>>>> c = get_config()
>>>> 
>>>> prefix = '/ipython/'
>>>> c.NotebookApp.base_project_url = prefix
>>>> c.NotebookApp.base_kernel_url = prefix
>>>> c.NotebookApp.webapp_settings = {'static_url_prefix' : prefix + 'static/'}
>>>> 
>>>> At which point you can just do:
>>>> 
>>>> ipython notebook --profile geohab
>>>> 
>>>> It would certainly appear that a meta-trait that does these three things
>>>> together would be desirable.
>>>> 
>>>> -MinRK
>>>> 
>>>> On Wed, Jun 20, 2012 at 8:05 PM, Massimo Di Stefano
>>>> <massimodisasha at gmail.com> wrote:
>>>>> 
>>>>> ipython notebook --profile geohab
>>>>> --NotebookApp.base_project_url=http://geohab.org/ipython
>>>>> --NotebookApp.base_kernel_url=http://geohab.org/ipython
>>>>> 
>>>>> [NotebookApp] Using existing profile dir:
>>>>> u'/home/epy/.ipython/profile_geohab'
>>>>> [NotebookApp] WARNING: the notebook server is listening on all IP
>>>>> addresses but not using any encryption or authentication. This is highly
>>>>> insecure and not recommended.
>>>>> [NotebookApp] The IPython Notebook is running at: http://[all ip
>>>>> addresses on your system]:30333http://geohab.org/ipython
>>>>> 
>>>>> 
>>>>> the log :
>>>>> [NotebookApp] The IPython Notebook is running at: http://[all ip
>>>>> addresses on your system]:30333http://geohab.org/ipython
>>>>> 
>>>>> seems bad so  i tryed :
>>>>> 
>>>>> 
>>>>> (env1)[epy at web317 ~]$ ipython notebook --profile geohab
>>>>> --NotebookApp.base_project_url=/ipython
>>>>> --NotebookApp.base_kernel_url=/ipython[NotebookApp] Using existing profile
>>>>> dir: u'/home/epy/.ipython/profile_geohab'
>>>>> [NotebookApp] WARNING: the notebook server is listening on all IP
>>>>> addresses but not using any encryption or authentication. This is highly
>>>>> insecure and not recommended.
>>>>> [NotebookApp] The IPython Notebook is running at: http://[all ip
>>>>> addresses on your system]:30333/ipython
>>>>> 
>>>>> 
>>>>> in this case if i point the browser to :
>>>>> 
>>>>> http://geohab.org/ipython
>>>>> 
>>>>> i have in the browser :
>>>>> 
>>>>> 404: Not Found
>>>>> 
>>>>> in the shell logs :
>>>>> 
>>>>> WARNING:root:404 GET / (127.0.0.1) 0.48ms
>>>>> 
>>>>> 
>>>>> if i point the browser to :
>>>>> 
>>>>> http://geohab.org/ipython/ipython/
>>>>> 
>>>>> i got again the html page without js/css
>>>>> 
>>>>> but this time the log in the shell is :
>>>>> 
>>>>> WARNING:root:404 GET /ipython (127.0.0.1) 0.41ms
>>>>> 
>>>>> 
>>>>> any clue ?
>>>>> 
>>>>> thanks!!!
>>>>> 
>>>>> Massimo.
>>>>> 
>>>>> 
>>>>> 
>>>>> Il giorno Jun 20, 2012, alle ore 10:17 PM, Brian Granger ha scritto:
>>>>> 
>>>>>> I think you need to set the following config variables:
>>>>>> 
>>>>>> --NotebookApp.base_kernel_url=<Unicode>
>>>>>>   Default: '/'
>>>>>>   The base URL for the kernel server
>>>>>> --NotebookApp.base_project_url=<Unicode>
>>>>>>   Default: '/'
>>>>>>   The base URL for the notebook server
>>>>>> 
>>>>>> In either the command line or terminal:
>>>>>> 
>>>>>> ipython notebook
>>>>>> --NotebookApp.base_project_url=http://geohab.org/ipython/
>>>>>> --NotebookApp.base_kernel_url=http://geohab.org/ipython/
>>>>>> 
>>>>>> Cheers,
>>>>>> 
>>>>>> Brian
>>>>>> 
>>>>>> On Wed, Jun 20, 2012 at 7:03 PM, Massimo Di Stefano
>>>>>> <massimodisasha at gmail.com> wrote:
>>>>>>> Hi All,
>>>>>>> 
>>>>>>> is anyone familiar with webfaction [1] ?
>>>>>>> 
>>>>>>> it is a web-hosting service .. i'm tring to run the ipython notebook
>>>>>>> from it but something is going wrong.
>>>>>>> 
>>>>>>> i sent already a mail to the suppport, but i was wondering if someone
>>>>>>> here knows how to fix it.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> the link to the notebook is :
>>>>>>> 
>>>>>>> http://geohab.org/ipython
>>>>>>> 
>>>>>>> i can see the page is loaded but is not able to load the application
>>>>>>> ... something is going wrong.
>>>>>>> all the js and css files are not loaded.
>>>>>>> 
>>>>>>> 
>>>>>>> trying to understand what's going on ?
>>>>>>> 
>>>>>>> using firefox : if i click on the text on the top "Ipython Notebook"
>>>>>>> 
>>>>>>> it should point to the same page, instead is going back to the
>>>>>>> web-root : http://geohab.org
>>>>>>> 
>>>>>>> have you any clue on what i should do in order to have it running
>>>>>>> properly ?
>>>>>>> 
>>>>>>> many thanks!
>>>>>>> 
>>>>>>> Massimo.
>>>>>>> 
>>>>>>> 
>>>>>>> [1]  http://www.webfaction.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
>>>>>> bgranger at calpoly.edu and ellisonbg at gmail.com
>>>>>> _______________________________________________
>>>>>> IPython-dev mailing list
>>>>>> IPython-dev at scipy.org
>>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>> 
>>>>> _______________________________________________
>>>>> IPython-dev mailing list
>>>>> IPython-dev at scipy.org
>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>> 
>>>> 
>>>> _______________________________________________
>>>> IPython-dev mailing list
>>>> IPython-dev at scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> IPython-dev mailing list
>>>> IPython-dev at scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>> 
>>> 
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>> 
>> 
>> 
>> 
>> -- 
>> Brian E. Granger
>> Cal Poly State University, San Luis Obispo
>> bgranger at calpoly.edu and ellisonbg at gmail.com
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> 



From fperez.net at gmail.com  Thu Jun 21 18:56:00 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 21 Jun 2012 15:56:00 -0700
Subject: [IPython-dev] And we cross the issue #2000 line today!
Message-ID: <CAHAreOq_XTZeWreQKRqdRpsHszxGXzEWhi+zK_UTSL=aqS43WA@mail.gmail.com>

Hi folks,

Thomas opened issue 1000 on 11/15/2011, which was roughly 1 1/2 years
after we started using the github tracker (I think I did the launchpad
conversion around May 2010).  Since the issue list was seeded from
launchpad with the first 114 tickets, that means it took us ~18 months
to file ~900 issues, or a rate of ~50 issues per month.

Today we have #2000:

https://github.com/ipython/ipython/pull/2000

so the second bacth of 1000 issues has taken ~7 months, or ~140 issues
per month, which is close to a 3x rate increase.  Thanks everyone for
the hard work!  This issue was opened by @kramer314, who's a new face
on our repo, and hopefully a new long-term contributor :)

And thinking of these kinds of numbers brings an idea to mind: a fun
project for anyone with a bit of time to kill would be a
'github-stats' tool that you could point to a project with optionally
a date range, and would create a bunch of summary visualizations for
the history of a repo, rate of issues and PRs opened and closed, pull
request size stats as well as numbers of commits, etc.  Github offers
a handful of graphs automatically, but a bunch more would be fun to
have.  Make it a nice notebook with the figures in matplotlib and send
it our way so we can include it with as an example :)

Cheers,

f


From jonathan.taylor at stanford.edu  Fri Jun 22 03:29:47 2012
From: jonathan.taylor at stanford.edu (Jonathan Taylor)
Date: Fri, 22 Jun 2012 00:29:47 -0700
Subject: [IPython-dev] magics and metadata
In-Reply-To: <CAHNn8BUDEGFGspdbabQdKmWfP7xDKd5Sx0qUymjncjc_rbqmEA@mail.gmail.com>
References: <CANmCCuSwUiDtOxsNdRKDe5jJxwSP7z=r2x8jSxOGFN+ygiB-Zw@mail.gmail.com>
	<CAOvn4qhjOcGQJWovO0HnUov80nxEnz=PL8Z8ob6KR0OsXxJ_jg@mail.gmail.com>
	<CANmCCuT4eb72b-9A+k1m+Qt9zovL32fESsmoE9u_2WZD6WCNTg@mail.gmail.com>
	<CAOvn4qj0-ULiBwCHZmC+qJBy1512PRny=df+SQs4xo2DQgKkgw@mail.gmail.com>
	<CANmCCuRAdoDEpV4dNHefEPG6uBpc6OzRH-e46cgx6mstm0cczA@mail.gmail.com>
	<CAHNn8BUDEGFGspdbabQdKmWfP7xDKd5Sx0qUymjncjc_rbqmEA@mail.gmail.com>
Message-ID: <CANmCCuQ4i-HfiYYP+UKCwixD3QqUKjK8jZFwspCAk+azB5Ewaw@mail.gmail.com>

Quick question: it would seem that the metadata in publish_display_data
would get added to an output but not a cell. Is that right?

On Tue, Jun 19, 2012 at 12:21 PM, MinRK <benjaminrk at gmail.com> wrote:

>
>
> On Tue, Jun 19, 2012 at 12:05 PM, Jonathan Taylor <
> jonathan.taylor at stanford.edu> wrote:
>
>> That's the sort of use case I imagine as well, where a cell magic wants
>> to about something to the frontend a little more information about what
>> kind of cell it is (in your %%bash example, it would be a code cell for
>> which the code_mirror might use bash highlighting instead of python). This
>> seems like it could be accomplished with something parallel to
>> "publish_display_data" for cell metadata which different frontends can
>> handle differently.
>>
>
> publish_display_data already takes a metadata arg.  This has always been
> the case, but so far it's totally unused.
>
> I just noticed, this metadata is *not* included in the added fields
> preserved in the notebook, but I will get on that.
>
> -MinRK
>
>
>>
>> On Tue, Jun 19, 2012 at 8:49 AM, Thomas Kluyver <takowl at gmail.com> wrote:
>>
>>> On 19 June 2012 16:08, Jonathan Taylor <jonathan.taylor at stanford.edu>
>>> wrote:
>>> > Yes, it would not be good to have the API of cell magics be notebook
>>> > specific. What about providing a reference to the current cell
>>> metadata in
>>> > the Magics class that can be used to update the NotebookNode after
>>> executing
>>> > cell.input? So, cell_magics would not have access to the metadata on
>>> > execution but could pass any metadata it wanted to back to the
>>> notebook.
>>>
>>> Before we get too far into the mechanism, let's try to think about
>>> actual use cases, so we can figure out how things need to work.
>>>
>>> We can also see cell magics themselves as a sort of within-cell
>>> metadata. For example, the frontend might one day be aware that if a
>>> cell starts with %%bash, different syntax highlighting and tab
>>> completion rules apply to it. I think this would need to be within the
>>> frontend, rather than going through the kernel, because we want to use
>>> the new highlighting & completion before the cell is executed.
>>>
>>> Thomas
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>
>>
>>
>>
>> --
>> Jonathan Taylor
>> Dept. of Statistics
>> Sequoia Hall, 137
>> 390 Serra Mall
>> Stanford, CA 94305
>> Tel:   650.723.9230
>> Fax:   650.725.8977
>> Web: http://www-stat.stanford.edu/~jtaylo
>>
>> _______________________________________________
>> 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
>
>


-- 
Jonathan Taylor
Dept. of Statistics
Sequoia Hall, 137
390 Serra Mall
Stanford, CA 94305
Tel:   650.723.9230
Fax:   650.725.8977
Web: http://www-stat.stanford.edu/~jtaylo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120622/d3ad6191/attachment.html>

From jonathan.taylor at stanford.edu  Fri Jun 22 03:41:09 2012
From: jonathan.taylor at stanford.edu (Jonathan Taylor)
Date: Fri, 22 Jun 2012 00:41:09 -0700
Subject: [IPython-dev] magics and metadata
In-Reply-To: <CAHAreOp27cEnt+EGuYHtzmwDFpiLHgAFxfMC1fK1QB8XecE50g@mail.gmail.com>
References: <CANmCCuSwUiDtOxsNdRKDe5jJxwSP7z=r2x8jSxOGFN+ygiB-Zw@mail.gmail.com>
	<CAOvn4qhjOcGQJWovO0HnUov80nxEnz=PL8Z8ob6KR0OsXxJ_jg@mail.gmail.com>
	<CANmCCuT4eb72b-9A+k1m+Qt9zovL32fESsmoE9u_2WZD6WCNTg@mail.gmail.com>
	<CAOvn4qj0-ULiBwCHZmC+qJBy1512PRny=df+SQs4xo2DQgKkgw@mail.gmail.com>
	<CANmCCuRAdoDEpV4dNHefEPG6uBpc6OzRH-e46cgx6mstm0cczA@mail.gmail.com>
	<CAHAreOp27cEnt+EGuYHtzmwDFpiLHgAFxfMC1fK1QB8XecE50g@mail.gmail.com>
Message-ID: <CANmCCuSEzUJ2aZG0Sf23WnR+CPpzwrzqOri4dn3S+wLrEmxTeA@mail.gmail.com>

> The trick is to find a clean way of expressing this that happens:
>
> 1. before execution of the cell. Highlighting isn't very useful by the
> time the cell has been run
>

Fair enough, but the browser can update the highlighting if it is told
(after execution) that it is a %%bash cell. So, after execution, the
highlighting would look OK (much like after rendering markdown looks like
rendered LaTeX).



> 2. keeping the separation between kernels and notebooks we currently
> have.  Keep in mind that the kernel has *no idea* that it's being
> called by a notebook, all it knows is that it was given a chunk of
> code to run.
>

Each chunk can be thought of as a cell. In the console, a chunk would be
either one line or a multiline input, much as cell magics work in the
console right now.
Some frontends could use the metadata associated
to that chunk, others might not.

I don't know the internals of the console that well, but how different is
it to the logic
in Min's test script for a notebook (https://gist.github.com/2620876)? If
each call
goes through something like line 32 in that file, then it seems like it is
reasonable to have
a msg that is a "metadata" for that last execute request. This script has
no notebook, but I would be happy
if I could send the iochannel some metadata (via the shell channel) for the
last execute request.

What would be needed is for the execute request to generate some "metadata"
requests.

Jonathan




-- 
Jonathan Taylor
Dept. of Statistics
Sequoia Hall, 137
390 Serra Mall
Stanford, CA 94305
Tel:   650.723.9230
Fax:   650.725.8977
Web: http://www-stat.stanford.edu/~jtaylo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120622/bb1e60cd/attachment.html>

From jonathan.taylor at stanford.edu  Fri Jun 22 03:50:34 2012
From: jonathan.taylor at stanford.edu (Jonathan Taylor)
Date: Fri, 22 Jun 2012 00:50:34 -0700
Subject: [IPython-dev] magics and metadata
In-Reply-To: <CAH4pYpTSLdQmXKou3x5u9YrYeR1H_w+R6nvQ8YpFmdB1cKWhvw@mail.gmail.com>
References: <CANmCCuSwUiDtOxsNdRKDe5jJxwSP7z=r2x8jSxOGFN+ygiB-Zw@mail.gmail.com>
	<CAOvn4qhjOcGQJWovO0HnUov80nxEnz=PL8Z8ob6KR0OsXxJ_jg@mail.gmail.com>
	<CANmCCuT4eb72b-9A+k1m+Qt9zovL32fESsmoE9u_2WZD6WCNTg@mail.gmail.com>
	<CAOvn4qj0-ULiBwCHZmC+qJBy1512PRny=df+SQs4xo2DQgKkgw@mail.gmail.com>
	<CANmCCuRAdoDEpV4dNHefEPG6uBpc6OzRH-e46cgx6mstm0cczA@mail.gmail.com>
	<CAHNn8BUDEGFGspdbabQdKmWfP7xDKd5Sx0qUymjncjc_rbqmEA@mail.gmail.com>
	<CAH4pYpSno_q1hQpyfrUBxpNVSD+SrLWkBeucGBLuY8=aOJgD3g@mail.gmail.com>
	<CAHNn8BVA8YvvJ4bw3epNR7NA=B7XQgGXa5Dh_x9kzwABkv7bPg@mail.gmail.com>
	<CAHAreOrFUaf_fP4cnjv4KmHciEK5b60A5uhifu8GH2FbmR3dxQ@mail.gmail.com>
	<CAH4pYpTTQ=pwFvF+oiSQFd6JDUo6iw3L6DL7+3WzHwSMSmFvug@mail.gmail.com>
	<CAHNn8BXJRjRYM-i7M2NSfdkfZxS-2WkyqBETOwmGbnCyxvCtEw@mail.gmail.com>
	<CAH4pYpQgCp2FpnDyM5_+uuZvsM+nNojcW3fn9AAUYji3PMeNAQ@mail.gmail.com>
	<CAHNn8BXbMzFqeAkd6wzDK5=0ZbhtFkbtc0EW_TbM+wKpvjihFA@mail.gmail.com>
	<CAH4pYpTSLdQmXKou3x5u9YrYeR1H_w+R6nvQ8YpFmdB1cKWhvw@mail.gmail.com>
Message-ID: <CANmCCuRd8v+gybfY=b=CZTdt0vJWKU4zj9WtEnTijRXcCZCHBA@mail.gmail.com>

> Back to the question of output-level metadata.  When a bit of code
> remains unused for almost a year, I start to question whether we
> really need it.  I not convinced we don't need it, I am not sure.  In
> light of this, I don't think that adding it to the notebook format
> makes sense.  When one of us finds a good purpose for this metadata,
> let's add it to the nbformat them.
>

I agree that output metadata might not be that useful, but I think it would
be useful
to be able to add metadata to the output of any "execute" on an ipython
kernel where by
execute I mean anything that passes a string to an ipython kernel.

The notebook is only one frontend that passes a string to ipython and the
notebook
is such that the return value is a NotebookNode which allows the
possibility of metadata and there
is not even any way to set that metadata via a mechanism like
"publish_display_data".

But, "publish_display_data" appends something to the output of the result
of executing "chunk" that all
frontends have to deal with. Why can't there be something that adds
something (i.e. metadata) to the result
of executing "chunk" that all frontends have to deal with (and most can
ignore if they want). It would be like
a silent "publish_display_data"...

Jonathan

-- 
Jonathan Taylor
Dept. of Statistics
Sequoia Hall, 137
390 Serra Mall
Stanford, CA 94305
Tel:   650.723.9230
Fax:   650.725.8977
Web: http://www-stat.stanford.edu/~jtaylo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120622/096d98bd/attachment.html>

From jason-sage at creativetrax.com  Fri Jun 22 17:17:44 2012
From: jason-sage at creativetrax.com (Jason Grout)
Date: Fri, 22 Jun 2012 16:17:44 -0500
Subject: [IPython-dev] published worksheet website for R
Message-ID: <4FE4E0F8.9040705@creativetrax.com>

Karl-Dieter Crisman just posted this up in the Sage lists about what the 
R project is doing to publish their markdown-enhanced worksheets:

http://www.rpubs.com/

I forget if this has been mentioned here, but I do remember some 
discussion about some such repository for IPython.

In the Sage project, we ( = Byron Varberg here at Drake) are working on 
our own database of snippets and things at interact.sagemath.org.  It's 
more for small snippets rather than full-blown worksheets, but we are 
also adding the ability to upload Sage worksheets.

Jason


From fperez.net at gmail.com  Fri Jun 22 19:21:48 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 22 Jun 2012 16:21:48 -0700
Subject: [IPython-dev] published worksheet website for R
In-Reply-To: <4FE4E0F8.9040705@creativetrax.com>
References: <4FE4E0F8.9040705@creativetrax.com>
Message-ID: <CAHAreOoA=wKJtkYepaCPGVqnt4eSmaZJQLbQ3LUcWEjhS6GZHw@mail.gmail.com>

On Fri, Jun 22, 2012 at 2:17 PM, Jason Grout
<jason-sage at creativetrax.com> wrote:
> Karl-Dieter Crisman just posted this up in the Sage lists about what the
> R project is doing to publish their markdown-enhanced worksheets:
>
> http://www.rpubs.com/
>
> I forget if this has been mentioned here, but I do remember some
> discussion about some such repository for IPython.

Yup, it's very cool, I'd seen it recently.  We do need a bit of love
and care on nbconvert:

https://github.com/ipython/nbconvert

so that our generated html is cleaner.  And then it will be much
easier to make this kind of high-quality standalone pages (people have
been asking me a lot for good html they can directly paste into blogs,
for example).  We could then start uploading them into scipy-central,
which as of now doesn't have too much traffic but does exist, and I'd
like to see it thriving more:

http://scipy-central.org/

Cheers,

f


From fperez.net at gmail.com  Fri Jun 22 21:16:30 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 22 Jun 2012 18:16:30 -0700
Subject: [IPython-dev] Debian freeze date set to June 30th,
	we *might* pull off a release...
Message-ID: <CAHAreOobBg97vSKJfU6+0tNU59fCfwUOTC0rxe1fu4fPsN4H-w@mail.gmail.com>

Hi folks,

the freeze date for Debian was announced as officially being set to June 30th.

We haven't really had any negative (though no positive either)
feedback from the beta, so the question is whether to try and cut an
RC1 this weekend (Monday at the latest) and try to meet the freeze
date.  It would be nice to have 0.13 in the next Debian by default,
and it would also put us in a good position to use it at SciPy'2012.

Right now we only have one issue that I marked as blocker today mostly
because it was very recently introduced and it's really ugly:

https://github.com/ipython/ipython/issues/2005

It's a really annoying bug in Courier New that Bob McElrath has been
valiantly fighting with and which keeps on giving us trouble.  But I
think we can find a sensible approach for it in time for the release,
so I'm not too worried.

Then there's the PRs we have open, where we should continue to
carefully triage and merge the important/polish stuff that's low risk
and stay away from anything high risk.

What do people think?  I do have some time I can devote to this next
week, and given that Thomas has already started helping out with the
release notes and website, I think it's possible.

At the same time, we won't rush the release: I'd rather miss the
freeze date than ship with nasty brokenness, so nobody should read
this as a 'release or death' message.  I'm just suggesting we *try* to
make it.

Cheers,

f


From fperez.net at gmail.com  Fri Jun 22 22:30:54 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 22 Jun 2012 19:30:54 -0700
Subject: [IPython-dev] Traceback in frontend tests
Message-ID: <CAHAreOqSaMjrp4m8UWiNA=zox=Uz6sMpAyTUkaqHRg0MaN3rjA@mail.gmail.com>

Howdy,

by accident I just saw this traceback when running

iptest IPython.frontend

...

Traceback (most recent call last):
  File "/home/fperez/usr/lib/python2.7/site-packages/IPython/frontend/qt/console/completion_html.py",
line 152, in eventFilter
    if obj == self._text_edit:
AttributeError: 'CompletionHtml' object has no attribute '_text_edit'


It does *not* cause an actual test error, so it's easy to miss it and
may have been there for a long time.  But if anyone can provide a
quick fix for it (I"m working on another bug), it would be great.  I'd
really like to ship 0.13 with a squeaky-clean test suite.

Cheers,

f


From fperez.net at gmail.com  Fri Jun 22 22:50:08 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 22 Jun 2012 19:50:08 -0700
Subject: [IPython-dev] Is IPython useful for your research/industry work?
 Feedback wanted for grant proposal.
Message-ID: <CAHAreOqfMFJkuxe=unhu+20CKYNX61_KRn6TmaaJFoAgJcAASA@mail.gmail.com>

Hi folks,

sorry for the cross-post, but I expect all replies to this to happen off-list.

I'm in the process of writing an NSF grant that will partly include
IPython support, and along with Brian we will soon be doing more of
the same.  In the past we haven't had the best of luck with the NFS,
hopefully this time it will be better.  I think one mistake we've made
has been to have very little in the way of hard evidence of the value
(if any) that IPython provides to the scientific work of others and to
industry.

So I would greatly appreciate if you can contact me off-list (best at
Fernando.Perez at berkeley.edu) with any info that I could use in a
typical NSF grant application.  I'm not looking for marketing-type
testimonials nor letters of support (the NSF frowns on those), but
rather specific info, best if backed by journal citations, on how and
where IPython plays an important role in your research or industry
project (while the NSF is a science funding agency, it also has as
part of its mission the economic well-being of the US).

I'd also like to clarify that I'm not looking for quotes strictly of
personal use as an interactive shell, since I know in this community
most people do that.  What I'm after are things like:

- a research project that builds on IPython in some capacity
- important results obtained with the IPython parallel machinery that
were better/easier/whatever than a classical approach with other tools
- uses of the notebook in education
- anything else along these lines you can think of, that goes beyond
pure personal shell use.

Thanks! Again, in the interest of keeping list noise down, please
reply directly to me:  Fernando.Perez at berkeley.edu.


f


From damianavila at gmail.com  Fri Jun 22 22:51:17 2012
From: damianavila at gmail.com (=?ISO-8859-1?Q?Dami=E1n_Avila?=)
Date: Fri, 22 Jun 2012 23:51:17 -0300
Subject: [IPython-dev] published worksheet website for R
In-Reply-To: <CAHAreOoA=wKJtkYepaCPGVqnt4eSmaZJQLbQ3LUcWEjhS6GZHw@mail.gmail.com>
References: <4FE4E0F8.9040705@creativetrax.com>
	<CAHAreOoA=wKJtkYepaCPGVqnt4eSmaZJQLbQ3LUcWEjhS6GZHw@mail.gmail.com>
Message-ID: <4FE52F25.8050109@gmail.com>

El 22/06/12 20:21, Fernando Perez escribi?:
> On Fri, Jun 22, 2012 at 2:17 PM, Jason Grout
> <jason-sage at creativetrax.com>  wrote:
>> Karl-Dieter Crisman just posted this up in the Sage lists about what the
>> R project is doing to publish their markdown-enhanced worksheets:
>>
>> http://www.rpubs.com/
>>
>> I forget if this has been mentioned here, but I do remember some
>> discussion about some such repository for IPython.
> Yup, it's very cool, I'd seen it recently.  We do need a bit of love
> and care on nbconvert:
>
> https://github.com/ipython/nbconvert
>
> so that our generated html is cleaner.  And then it will be much
> easier to make this kind of high-quality standalone pages (people have
> been asking me a lot for good html they can directly paste into blogs,
> for example).  We could then start uploading them into scipy-central,
> which as of now doesn't have too much traffic but does exist, and I'd
> like to see it thriving more:
>
> http://scipy-central.org/
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev

I take some parts of nbconvert to implement a html conversion in vIPer 
(a web-browser specifically designed to work with IPython notebooks).

You can see a video (recorded by vIPer itself) showing this kind of 
conversion: http://goo.gl/TUVku

I will release vIPer soon... I will announce it in the user list when it 
is done.

Regards.

Dami?n.



From fperez.net at gmail.com  Fri Jun 22 22:53:37 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 22 Jun 2012 19:53:37 -0700
Subject: [IPython-dev] published worksheet website for R
In-Reply-To: <4FE52F25.8050109@gmail.com>
References: <4FE4E0F8.9040705@creativetrax.com>
	<CAHAreOoA=wKJtkYepaCPGVqnt4eSmaZJQLbQ3LUcWEjhS6GZHw@mail.gmail.com>
	<4FE52F25.8050109@gmail.com>
Message-ID: <CAHAreOoN_348VT8CQf2p-zSwFArWQRqwQGJfUegdv3X3iivw2w@mail.gmail.com>

On Fri, Jun 22, 2012 at 7:51 PM, Dami?n Avila <damianavila at gmail.com> wrote:
> You can see a video (recorded by vIPer itself) showing this kind of
> conversion: http://goo.gl/TUVku

Wow!  Definitely keep us posted, that looks great!

And please submit any fixes as PRs for nbconvert, so we can get it in
shape for production work :)

f


From damianavila at gmail.com  Fri Jun 22 23:38:18 2012
From: damianavila at gmail.com (=?ISO-8859-1?Q?Dami=E1n_Avila?=)
Date: Sat, 23 Jun 2012 00:38:18 -0300
Subject: [IPython-dev] published worksheet website for R
In-Reply-To: <CAHAreOoN_348VT8CQf2p-zSwFArWQRqwQGJfUegdv3X3iivw2w@mail.gmail.com>
References: <4FE4E0F8.9040705@creativetrax.com>
	<CAHAreOoA=wKJtkYepaCPGVqnt4eSmaZJQLbQ3LUcWEjhS6GZHw@mail.gmail.com>
	<4FE52F25.8050109@gmail.com>
	<CAHAreOoN_348VT8CQf2p-zSwFArWQRqwQGJfUegdv3X3iivw2w@mail.gmail.com>
Message-ID: <4FE53A2A.2060205@gmail.com>

El 22/06/12 23:53, Fernando Perez escribi?:
> On Fri, Jun 22, 2012 at 7:51 PM, Dami?n Avila<damianavila at gmail.com>  wrote:
>> You can see a video (recorded by vIPer itself) showing this kind of
>> conversion: http://goo.gl/TUVku
> Wow!  Definitely keep us posted, that looks great!
>
> And please submit any fixes as PRs for nbconvert, so we can get it in
> shape for production work :)
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev

I will do it for sure!!!

Oh, check this out: http://goo.gl/SuHZo

This is the feature I love...

Last week, I wrote a presentation for a talk in quantitative finance 
with the IPython notebook
and I used vIPer as the interface to work with the notebook and to 
create the slideshow view ...

It was a great experience!

Regards.

Dami?n.


From satra at mit.edu  Sat Jun 23 00:23:38 2012
From: satra at mit.edu (Satrajit Ghosh)
Date: Fri, 22 Jun 2012 21:23:38 -0700
Subject: [IPython-dev] published worksheet website for R
In-Reply-To: <4FE53A2A.2060205@gmail.com>
References: <4FE4E0F8.9040705@creativetrax.com>
	<CAHAreOoA=wKJtkYepaCPGVqnt4eSmaZJQLbQ3LUcWEjhS6GZHw@mail.gmail.com>
	<4FE52F25.8050109@gmail.com>
	<CAHAreOoN_348VT8CQf2p-zSwFArWQRqwQGJfUegdv3X3iivw2w@mail.gmail.com>
	<4FE53A2A.2060205@gmail.com>
Message-ID: <CA+A4wOn4hzxXwqB6yLhVGu6-cFq+G7vVXcdaaFhq_+XAmMgEDg@mail.gmail.com>

that's really cool.

cheers,

satra

On Fri, Jun 22, 2012 at 8:38 PM, Dami?n Avila <damianavila at gmail.com> wrote:

> El 22/06/12 23:53, Fernando Perez escribi?:
> > On Fri, Jun 22, 2012 at 7:51 PM, Dami?n Avila<damianavila at gmail.com>
>  wrote:
> >> You can see a video (recorded by vIPer itself) showing this kind of
> >> conversion: http://goo.gl/TUVku
> > Wow!  Definitely keep us posted, that looks great!
> >
> > And please submit any fixes as PRs for nbconvert, so we can get it in
> > shape for production work :)
> >
> > f
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>
> I will do it for sure!!!
>
> Oh, check this out: http://goo.gl/SuHZo
>
> This is the feature I love...
>
> Last week, I wrote a presentation for a talk in quantitative finance
> with the IPython notebook
> and I used vIPer as the interface to work with the notebook and to
> create the slideshow view ...
>
> It was a great experience!
>
> Regards.
>
> Dami?n.
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120622/4fe28a91/attachment.html>

From fperez.net at gmail.com  Sat Jun 23 01:16:38 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 22 Jun 2012 22:16:38 -0700
Subject: [IPython-dev] published worksheet website for R
In-Reply-To: <4FE53A2A.2060205@gmail.com>
References: <4FE4E0F8.9040705@creativetrax.com>
	<CAHAreOoA=wKJtkYepaCPGVqnt4eSmaZJQLbQ3LUcWEjhS6GZHw@mail.gmail.com>
	<4FE52F25.8050109@gmail.com>
	<CAHAreOoN_348VT8CQf2p-zSwFArWQRqwQGJfUegdv3X3iivw2w@mail.gmail.com>
	<4FE53A2A.2060205@gmail.com>
Message-ID: <CAHAreOr8Xe-2RxMx+a+g0WN023raAVNHY=n-FXE42v2LzeVphw@mail.gmail.com>

On Fri, Jun 22, 2012 at 8:38 PM, Dami?n Avila <damianavila at gmail.com> wrote:
> I will do it for sure!!!
>
> Oh, check this out: http://goo.gl/SuHZo
>
> This is the feature I love...
>
> Last week, I wrote a presentation for a talk in quantitative finance
> with the IPython notebook
> and I used vIPer as the interface to work with the notebook and to
> create the slideshow view ...
>
> It was a great experience!

OK, that  is just AWESOME.

We're waiting here... (taps fingers anxiously :)

f


From takowl at gmail.com  Sat Jun 23 07:07:25 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Sat, 23 Jun 2012 12:07:25 +0100
Subject: [IPython-dev] Debian freeze date set to June 30th,
 we *might* pull off a release...
In-Reply-To: <CAHAreOobBg97vSKJfU6+0tNU59fCfwUOTC0rxe1fu4fPsN4H-w@mail.gmail.com>
References: <CAHAreOobBg97vSKJfU6+0tNU59fCfwUOTC0rxe1fu4fPsN4H-w@mail.gmail.com>
Message-ID: <CAOvn4qhdo9kXUMNtFAYZDtpaV58sxtdO4p=-8OPdvFOgm3B1jA@mail.gmail.com>

On 23 June 2012 02:16, Fernando Perez <fperez.net at gmail.com> wrote:
> What do people think? ?I do have some time I can devote to this next
> week, and given that Thomas has already started helping out with the
> release notes and website, I think it's possible.

I agree with what you're suggesting - let's aim for it, but as a soft
deadline that we can go past if we need to.

I'm around this weekend, but away at a conference next weekend.

Thomas


From benjaminrk at gmail.com  Sat Jun 23 14:31:03 2012
From: benjaminrk at gmail.com (MinRK)
Date: Sat, 23 Jun 2012 11:31:03 -0700
Subject: [IPython-dev] Traceback in frontend tests
In-Reply-To: <CAHAreOqSaMjrp4m8UWiNA=zox=Uz6sMpAyTUkaqHRg0MaN3rjA@mail.gmail.com>
References: <CAHAreOqSaMjrp4m8UWiNA=zox=Uz6sMpAyTUkaqHRg0MaN3rjA@mail.gmail.com>
Message-ID: <CAHNn8BV5L9rvAuBpv9z=swoe0fHAnG8ajDZ515jFJb=NwHMyEA@mail.gmail.com>

Also reported here<https://github.com/ipython/ipython/pull/1996#issuecomment-6498981>

On Fri, Jun 22, 2012 at 7:30 PM, Fernando Perez <fperez.net at gmail.com>wrote:

> Howdy,
>
> by accident I just saw this traceback when running
>
> iptest IPython.frontend
>
> ...
>
> Traceback (most recent call last):
>  File
> "/home/fperez/usr/lib/python2.7/site-packages/IPython/frontend/qt/console/completion_html.py",
> line 152, in eventFilter
>    if obj == self._text_edit:
> AttributeError: 'CompletionHtml' object has no attribute '_text_edit'
>
>
> It does *not* cause an actual test error, so it's easy to miss it and
> may have been there for a long time.  But if anyone can provide a
> quick fix for it (I"m working on another bug), it would be great.  I'd
> really like to ship 0.13 with a squeaky-clean test suite.
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120623/6ac95204/attachment.html>

From fperez.net at gmail.com  Sat Jun 23 14:38:50 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 23 Jun 2012 11:38:50 -0700
Subject: [IPython-dev] Traceback in frontend tests
In-Reply-To: <CAHNn8BV5L9rvAuBpv9z=swoe0fHAnG8ajDZ515jFJb=NwHMyEA@mail.gmail.com>
References: <CAHAreOqSaMjrp4m8UWiNA=zox=Uz6sMpAyTUkaqHRg0MaN3rjA@mail.gmail.com>
	<CAHNn8BV5L9rvAuBpv9z=swoe0fHAnG8ajDZ515jFJb=NwHMyEA@mail.gmail.com>
Message-ID: <CAHAreOrJMpisc5vccXPEzuAdCVGyCJsxCLeezZurUMsimMbL2w@mail.gmail.com>

On Sat, Jun 23, 2012 at 11:31 AM, MinRK <benjaminrk at gmail.com> wrote:
> Also reported here

Great, thanks.  Hadn't seen that one.

f


From damianavila at gmail.com  Sat Jun 23 16:19:22 2012
From: damianavila at gmail.com (=?ISO-8859-1?Q?Dami=E1n_Avila?=)
Date: Sat, 23 Jun 2012 17:19:22 -0300
Subject: [IPython-dev] published worksheet website for R
In-Reply-To: <CAHAreOr8Xe-2RxMx+a+g0WN023raAVNHY=n-FXE42v2LzeVphw@mail.gmail.com>
References: <4FE4E0F8.9040705@creativetrax.com>
	<CAHAreOoA=wKJtkYepaCPGVqnt4eSmaZJQLbQ3LUcWEjhS6GZHw@mail.gmail.com>
	<4FE52F25.8050109@gmail.com>
	<CAHAreOoN_348VT8CQf2p-zSwFArWQRqwQGJfUegdv3X3iivw2w@mail.gmail.com>
	<4FE53A2A.2060205@gmail.com>
	<CAHAreOr8Xe-2RxMx+a+g0WN023raAVNHY=n-FXE42v2LzeVphw@mail.gmail.com>
Message-ID: <4FE624CA.5080706@gmail.com>

El 23/06/12 02:16, Fernando Perez escribi?:
> On Fri, Jun 22, 2012 at 8:38 PM, Dami?n Avila<damianavila at gmail.com>  wrote:
>> I will do it for sure!!!
>>
>> Oh, check this out: http://goo.gl/SuHZo
>>
>> This is the feature I love...
>>
>> Last week, I wrote a presentation for a talk in quantitative finance
>> with the IPython notebook
>> and I used vIPer as the interface to work with the notebook and to
>> create the slideshow view ...
>>
>> It was a great experience!
> OK, that  is just AWESOME.
>
> We're waiting here... (taps fingers anxiously :)
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev

I have to clean the code a little more and add some other things,
but it will be available soon... in a few weeks, I guess ;-)

Regards.

Dami?n.





From fperez.net at gmail.com  Sat Jun 23 16:51:53 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 23 Jun 2012 13:51:53 -0700
Subject: [IPython-dev] published worksheet website for R
In-Reply-To: <4FE624CA.5080706@gmail.com>
References: <4FE4E0F8.9040705@creativetrax.com>
	<CAHAreOoA=wKJtkYepaCPGVqnt4eSmaZJQLbQ3LUcWEjhS6GZHw@mail.gmail.com>
	<4FE52F25.8050109@gmail.com>
	<CAHAreOoN_348VT8CQf2p-zSwFArWQRqwQGJfUegdv3X3iivw2w@mail.gmail.com>
	<4FE53A2A.2060205@gmail.com>
	<CAHAreOr8Xe-2RxMx+a+g0WN023raAVNHY=n-FXE42v2LzeVphw@mail.gmail.com>
	<4FE624CA.5080706@gmail.com>
Message-ID: <CAHAreOpEgby4e6Yw317wvoGA4k6-LmXLuKTzWUH=zo2n3L3uMQ@mail.gmail.com>

On Sat, Jun 23, 2012 at 1:19 PM, Dami?n Avila <damianavila at gmail.com> wrote:
> I have to clean the code a little more and add some other things,
> but it will be available soon... in a few weeks, I guess ;-)

Ah, but I'd love to use it for my talk at SciPy 2012... :)


From fperez.net at gmail.com  Sat Jun 23 17:14:39 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 23 Jun 2012 14:14:39 -0700
Subject: [IPython-dev] Debian freeze date set to June 30th,
 we *might* pull off a release...
In-Reply-To: <CAOvn4qhdo9kXUMNtFAYZDtpaV58sxtdO4p=-8OPdvFOgm3B1jA@mail.gmail.com>
References: <CAHAreOobBg97vSKJfU6+0tNU59fCfwUOTC0rxe1fu4fPsN4H-w@mail.gmail.com>
	<CAOvn4qhdo9kXUMNtFAYZDtpaV58sxtdO4p=-8OPdvFOgm3B1jA@mail.gmail.com>
Message-ID: <CAHAreOqveRVugVy=+ZL1820e33oNYyt1-piNK3XtaxQAgKg0WA@mail.gmail.com>

On Sat, Jun 23, 2012 at 4:07 AM, Thomas Kluyver <takowl at gmail.com> wrote:
> I agree with what you're suggesting - let's aim for it, but as a soft
> deadline that we can go past if we need to.

OK, let's go with that as a plan then.

So everyone who has any bandwidth available, please pitch in
especially with reviewing open PRs and closing our high-priority bugs
(only 7, no blockers):

https://github.com/ipython/ipython/issues?labels=prio-high&milestone=7&page=1&state=open

We also have 15 medium-priority ones where I suspect several may have
actually been fixed and just not closed.  Triage on those would be
great so we have a better idea of what is genuinely left over:

https://github.com/ipython/ipython/issues?labels=prio-medium&milestone=7&page=1&state=open

I've given everything a first triage pass already, so with a few more
hands on deck we should be able to wrap up without too much pain.

Thanks, everyone!


From damianavila at gmail.com  Sat Jun 23 17:30:05 2012
From: damianavila at gmail.com (=?ISO-8859-1?Q?Dami=E1n_Avila?=)
Date: Sat, 23 Jun 2012 18:30:05 -0300
Subject: [IPython-dev] published worksheet website for R
In-Reply-To: <CAHAreOpEgby4e6Yw317wvoGA4k6-LmXLuKTzWUH=zo2n3L3uMQ@mail.gmail.com>
References: <4FE4E0F8.9040705@creativetrax.com>
	<CAHAreOoA=wKJtkYepaCPGVqnt4eSmaZJQLbQ3LUcWEjhS6GZHw@mail.gmail.com>
	<4FE52F25.8050109@gmail.com>
	<CAHAreOoN_348VT8CQf2p-zSwFArWQRqwQGJfUegdv3X3iivw2w@mail.gmail.com>
	<4FE53A2A.2060205@gmail.com>
	<CAHAreOr8Xe-2RxMx+a+g0WN023raAVNHY=n-FXE42v2LzeVphw@mail.gmail.com>
	<4FE624CA.5080706@gmail.com>
	<CAHAreOpEgby4e6Yw317wvoGA4k6-LmXLuKTzWUH=zo2n3L3uMQ@mail.gmail.com>
Message-ID: <4FE6355D.8090107@gmail.com>

El 23/06/12 17:51, Fernando Perez escribi?:
> On Sat, Jun 23, 2012 at 1:19 PM, Dami?n Avila<damianavila at gmail.com>  wrote:
>> I have to clean the code a little more and add some other things,
>> but it will be available soon... in a few weeks, I guess ;-)
> Ah, but I'd love to use it for my talk at SciPy 2012... :)
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev

:-)
If I get some time this week,  I could submit to github a working but 
"stable" version...
It would be great if you use it for your talk at SciPy 2012...

Regards.

Dami?n.



From fperez.net at gmail.com  Sat Jun 23 17:33:11 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 23 Jun 2012 14:33:11 -0700
Subject: [IPython-dev] published worksheet website for R
In-Reply-To: <4FE6355D.8090107@gmail.com>
References: <4FE4E0F8.9040705@creativetrax.com>
	<CAHAreOoA=wKJtkYepaCPGVqnt4eSmaZJQLbQ3LUcWEjhS6GZHw@mail.gmail.com>
	<4FE52F25.8050109@gmail.com>
	<CAHAreOoN_348VT8CQf2p-zSwFArWQRqwQGJfUegdv3X3iivw2w@mail.gmail.com>
	<4FE53A2A.2060205@gmail.com>
	<CAHAreOr8Xe-2RxMx+a+g0WN023raAVNHY=n-FXE42v2LzeVphw@mail.gmail.com>
	<4FE624CA.5080706@gmail.com>
	<CAHAreOpEgby4e6Yw317wvoGA4k6-LmXLuKTzWUH=zo2n3L3uMQ@mail.gmail.com>
	<4FE6355D.8090107@gmail.com>
Message-ID: <CAHAreOoW4y=Rk+5VO_Y8ChtfxxmCDSw8o1S5vDFBc6fkCVe_Cw@mail.gmail.com>

On Sat, Jun 23, 2012 at 2:30 PM, Dami?n Avila <damianavila at gmail.com> wrote:
> :-)
> If I get some time this week, ?I could submit to github a working but
> "stable" version...

Great!

> It would be great if you use it for your talk at SciPy 2012...

I'd love to at least demo it.  I plan on mostly doing live notebook
work, so showing this would be very nice.


From bob+ipython at mcelrath.org  Sun Jun 24 14:01:23 2012
From: bob+ipython at mcelrath.org (Bob McElrath)
Date: Sun, 24 Jun 2012 18:01:23 +0000
Subject: [IPython-dev] SVG figures status report
Message-ID: <20120624180123.GL6159@mcelrath.org>

I thought I'd give a status report on using SVG figures in IPython.

It seems for reason of visual appearance, PNG was chosen as a default.  This can
be circumvented by appropriately choosing figure.figsize.  The reason for the
aliasing at some choices (including the default PNG size) is still unknown to
me.  My best guess is that it has to do with rounding of internal pt
coordinates to pixels (and not to do with the display mechanism -- such jaggy
figures appear jaggy in Chrome, Firefox, and Inkscape).

SVG figures involve a lot of elements, added to the same DOM as the rest of the
page.  The result of this is that by the time you have ~20 figures in one
notebook, the page is perceivably slow.  Scrolling, clicking, editing are all
noticeably slow and difficult.  Page load times increase substantially and cause
browser timeouts.  The ultimate reason for this is simply the large DOM.  This
is true both in Firefox and Chrome (mozilla/webkit).

It turns out this is well known, and a target of SVG 2.0 discussions:
    http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM 
But I would not be surprised that even with a bunch of SVG 2.0 improvements, a
worksheet with many figures would still be intolerably slow.  One can find many
speed-related SVG bugs on Mozilla's bugzilla as well as Chrome.  It seems both
SVG implementations are not nearly as heavily optimized as HTML, and may involve
many O(n) or worse algorithms.  I have noticed that simply having other SVG
elements on the page seems to slow down the operations on any ONE of them (I
perceive the slowdown to be linear).  Likewise adding the (n+1)'th SVG is slower
than adding the n'th SVG to the worksheet.  Something here is linear in time.

Therefore, I think SVG as the default figure format is not an option now, or in
the foreseeable future, and SVG as an option should be discouraged.

However, there are probably some clever optimizations that could be performed to
retain worksheet interactivity in the presence of many figures.  For instance,
each SVG figure could be cached as a PNG or Canvas element.  This reduces the
number of elements in the DOM, and the SVG figure could be stored as a string.
If the user wishes to interact with the figure (clicks on it) we could replace
the bitmap PNG/Canvas element with the SVG.  This way there would be no more
than one SVG in the DOM at a given time.

I believe it is possible that some of the slowdowns I see are due to some
unrelated code in the worksheet (such as if jQuery handlers were attached to
every SVG node).  If this is the case, it will also show up also in notebooks
with no SVG. (see issue #1975)

Maybe people already knew all this, but I thought I'd share my findings, because
I wanted to use SVG instead.

Related: issues #1881, #1975, PR #1881.

--
Cheers, Bob McElrath


From takowl at gmail.com  Sun Jun 24 19:53:24 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 25 Jun 2012 00:53:24 +0100
Subject: [IPython-dev] Fwd: [Passed] ipython/ipython#1 (master - 57bdf5b)
In-Reply-To: <4fe7a1f0635d8_17e413909b@0418f90e-e975-4489-b9fc-0ab0fbe45cf9.mail>
References: <4fe7a1f0635d8_17e413909b@0418f90e-e975-4489-b9fc-0ab0fbe45cf9.mail>
Message-ID: <CAOvn4qhoMHQYi7XuT=e37W2Tvww6eND9gPO92Kz+7HPUjprW3w@mail.gmail.com>

We now have tests on Travis CI as well as ShiningPanda. Thanks to Marc
Abramowitz for driving that.

---------- Forwarded message ----------
From: Travis-CI <notifications at travis-ci.org>
Date: 25 June 2012 00:25
Subject: [Passed] ipython/ipython#1 (master - 57bdf5b)
To: "takowl at gmail.com" <takowl at gmail.com>, "ipython at gmail.com" <
ipython at gmail.com>


**
   The build passed.   Repository ipython/ipython  Build #1
http://travis-ci.org/ipython/ipython/builds/1696995  Changeset
https://github.com/ipython/ipython/compare/7d189da36fde...57bdf5b338ea
Commit 57bdf5b (master)  Message Merge pull request #2016 from
jdmarch/quotes-for-test-runner

BUG: test runner fails in Windows if filenames contain spaces.  Author Thomas
Kluyver  Duration 6 minutes and 39 seconds
   You can configure recipients for build notifications in your configuration
file <http://about.travis-ci.org/docs/user/build-configuration>. Further
documentation about Travis CI can be found
here<http://about.travis-ci.org/docs>.
For help please join our IRC channel irc.freenode.net#travis.
    We need your help!

Travis CI has run 406,714 tests for 5,442 OSS projects to date, including
Ruby, Rails, Rubinius, Rubygems, Bundler, Node.js, Leiningen, Symfony ...

If you use any of these then you benefit from Travis CI.

Please donate so we can make Travis CI even better!<http://love.travis-ci.org>
        <http://cloudcontrol.com>  cloudControl
<http://cloudcontrol.com>is PaaS made in Berlin, Germany. Since 2009
we're dedicated to supercharge
development by building the best platform possible to help developers build
better apps faster.
   The delivery of this email was kindly sponsored by
Postmark<http://postmarkapp.com>,
an amazing service for transactional email delivery.

See all of our sponsors ? <http://love.travis-ci.org/sponsors>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120625/c0c4f9ab/attachment.html>

From fperez.net at gmail.com  Sun Jun 24 20:30:37 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 24 Jun 2012 17:30:37 -0700
Subject: [IPython-dev] Fwd: [Passed] ipython/ipython#1 (master - 57bdf5b)
In-Reply-To: <CAOvn4qhoMHQYi7XuT=e37W2Tvww6eND9gPO92Kz+7HPUjprW3w@mail.gmail.com>
References: <4fe7a1f0635d8_17e413909b@0418f90e-e975-4489-b9fc-0ab0fbe45cf9.mail>
	<CAOvn4qhoMHQYi7XuT=e37W2Tvww6eND9gPO92Kz+7HPUjprW3w@mail.gmail.com>
Message-ID: <CAHAreOq+srx7UM9We6RVNR-bw-q02Vk3K2C1U7TQPtvSGzFO3g@mail.gmail.com>

On Sun, Jun 24, 2012 at 4:53 PM, Thomas Kluyver <takowl at gmail.com> wrote:

> We now have tests on Travis CI as well as ShiningPanda. Thanks to Marc
> Abramowitz for driving that.
>

Great! BTW, we should probably change our front page link to have both SP
and Travis now, at least when we make the 0.13 site-wide updates.

Cheers,

f
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120624/7df244e8/attachment.html>

From carl.input at gmail.com  Sun Jun 24 20:42:47 2012
From: carl.input at gmail.com (Carl Smith)
Date: Mon, 25 Jun 2012 01:42:47 +0100
Subject: [IPython-dev] NotebookCloud: Update
Message-ID: <CAP-uhDcK6a=aAfma+kXfWqRELq6Xc60kYDPpwUvO39n_DSyTJA@mail.gmail.com>

I've been working to get the source onto github and to tidy it up so
it's readable. I've just pushed that work so you can flick through the
files now without too much stress.

I've also added a Project page to the wiki. It's currently reads more
like a blog post, but anyone wondering where this is all going longer
term should check that out.

Thanks again to everyone for their support.

Cheers

Carl


From fperez.net at gmail.com  Sun Jun 24 21:59:05 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 24 Jun 2012 18:59:05 -0700
Subject: [IPython-dev] NotebookCloud: Update
In-Reply-To: <CAP-uhDcK6a=aAfma+kXfWqRELq6Xc60kYDPpwUvO39n_DSyTJA@mail.gmail.com>
References: <CAP-uhDcK6a=aAfma+kXfWqRELq6Xc60kYDPpwUvO39n_DSyTJA@mail.gmail.com>
Message-ID: <CAHAreOpU2fTDOj2mSv92ie+1xBqDEAQtym-pejOEp68K0Tm_Nw@mail.gmail.com>

On Sun, Jun 24, 2012 at 5:42 PM, Carl Smith <carl.input at gmail.com> wrote:
> I've been working to get the source onto github and to tidy it up so
> it's readable. I've just pushed that work so you can flick through the
> files now without too much stress.
>
> I've also added a Project page to the wiki. It's currently reads more
> like a blog post, but anyone wondering where this is all going longer
> term should check that out.
>
> Thanks again to everyone for their support.

Great, this has already been useful to me for a couple of demos, many
thanks to you for the great work.  I think you forgot to give the gh
link, here it is for reference

https://github.com/carlsmith/nbcloud

Cheers,

f


From carl.input at gmail.com  Sun Jun 24 22:00:48 2012
From: carl.input at gmail.com (Carl Smith)
Date: Mon, 25 Jun 2012 03:00:48 +0100
Subject: [IPython-dev] NotebookCloud: Update
In-Reply-To: <CAHAreOpU2fTDOj2mSv92ie+1xBqDEAQtym-pejOEp68K0Tm_Nw@mail.gmail.com>
References: <CAP-uhDcK6a=aAfma+kXfWqRELq6Xc60kYDPpwUvO39n_DSyTJA@mail.gmail.com>
	<CAHAreOpU2fTDOj2mSv92ie+1xBqDEAQtym-pejOEp68K0Tm_Nw@mail.gmail.com>
Message-ID: <CAP-uhDfmRW=wvWwCB2Wk+9CJRBZcy=_G8pKBqyfqzw-ojTFfNw@mail.gmail.com>

Nice one. I always forget the link!
On Jun 25, 2012 2:59 AM, "Fernando Perez" <fperez.net at gmail.com> wrote:

> On Sun, Jun 24, 2012 at 5:42 PM, Carl Smith <carl.input at gmail.com> wrote:
> > I've been working to get the source onto github and to tidy it up so
> > it's readable. I've just pushed that work so you can flick through the
> > files now without too much stress.
> >
> > I've also added a Project page to the wiki. It's currently reads more
> > like a blog post, but anyone wondering where this is all going longer
> > term should check that out.
> >
> > Thanks again to everyone for their support.
>
> Great, this has already been useful to me for a couple of demos, many
> thanks to you for the great work.  I think you forgot to give the gh
> link, here it is for reference
>
> https://github.com/carlsmith/nbcloud
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120625/14dc7465/attachment.html>

From fperez.net at gmail.com  Tue Jun 26 00:26:13 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 25 Jun 2012 21:26:13 -0700
Subject: [IPython-dev] SVG figures status report
In-Reply-To: <20120624180123.GL6159@mcelrath.org>
References: <20120624180123.GL6159@mcelrath.org>
Message-ID: <CAHAreOr2_DfwJBoF1UskayXhVdWPykZ2z2zPjJ0Dvaj1CW6Hog@mail.gmail.com>

Hi Bob,

On Sun, Jun 24, 2012 at 11:01 AM, Bob McElrath <bob+ipython at mcelrath.org> wrote:
> I thought I'd give a status report on using SVG figures in IPython.

[...]

> Therefore, I think SVG as the default figure format is not an option now, or in
> the foreseeable future, and SVG as an option should be discouraged.

Thanks for this detailed and careful assessment of the situation.
It's an unfortunate state of affairs, especially as it strongly
tempers my enthusiasm for tools like d3.js being truly effective in
the notebook.  But better to know than to enthusiastically build
things that will in practice only work for toy problems but will
inescapably fail to scale in more complex production environments.

> Maybe people already knew all this, but I thought I'd share my findings, because
> I wanted to use SVG instead.

Not necessarily, I think this analysis is extremely valuable.

In this spirit, have you had a chance to play with tools like this?

http://paperjs.org/about/

Since it goes directly to the canvas element and is not SVG, I wonder
if interactive figures built upon it would fare any better than the
SVG ones.

Cheers,

f


From fperez.net at gmail.com  Tue Jun 26 01:54:45 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 25 Jun 2012 22:54:45 -0700
Subject: [IPython-dev] We might actually make 0.13 by June 30,
	jump in to make it possible!
Message-ID: <CAHAreOqBH0K1LA371s_CZJo+SS=3MBYx8-GLjdShUVDvs+u6RQ@mail.gmail.com>

Hi all,

the 0.13 milestone board is actually looking pretty solid (after some
aggressive triage and new code today):

https://github.com/ipython/ipython/issues?labels=&milestone=7&page=1&state=open

We have 7 open PRs and 5 issues, 4 of which are closed by a  PR.  The
remaining issue, #1702, has a pending discussion on what we should do
with it given there's no code ready to close it.

So I think that if people can jump in with testing and review on any
of these that you can help with, and we get the release notes in
shape, we can actually do the release quite quickly.

Our CI bots on Shining Panda and Travis are looking solid:

https://jenkins.shiningpanda.com/ipython
http://travis-ci.org/#!/ipython/ipython

On SP we cover python 2.6, 2.7, 3.1, 3.2 and 3.3, and Linux, Mac and
Windows, though not all OSes cover all python versions, so I think
it's not unreasonable to move forward with the release once we merge
the PRs we have open.

So please jump in if you can help, esp. with the release notes/website
work, so we can cut this quickly and open again for development.

Thanks to everyone for all the great recent contributions, and a
special one to Thomas Kluyver and Marc Abramowitz for the Shining
Panda and Travis-CI setup.  The value of CI becomes particularly clear
near release time, as I feel much more confident moving forward
without having to wait for weeks of RCs going out to people for manual
testing.

Cheers,

f


From zvoros at gmail.com  Tue Jun 26 03:43:44 2012
From: zvoros at gmail.com (=?ISO-8859-1?Q?Zolt=E1n_V=F6r=F6s?=)
Date: Tue, 26 Jun 2012 09:43:44 +0200
Subject: [IPython-dev] SVG figures status report
In-Reply-To: <CAHAreOr2_DfwJBoF1UskayXhVdWPykZ2z2zPjJ0Dvaj1CW6Hog@mail.gmail.com>
References: <20120624180123.GL6159@mcelrath.org>
	<CAHAreOr2_DfwJBoF1UskayXhVdWPykZ2z2zPjJ0Dvaj1CW6Hog@mail.gmail.com>
Message-ID: <4FE96830.1080803@gmail.com>

Dear Fernando, and Bob,

I didn't want to bring up this issue before the new release, given that 
that has the higher priority, but since a new thread was opened along 
the same lines, I would like to respond to a couple of points raised 
here, and here: 
http://mail.scipy.org/pipermail/ipython-dev/2012-June/009476.html which 
I will quote here.

Based on these two threads, I have the feeling that the views on what an 
interactive plot should do are somewhat diverging, and we should first 
come to some consensus as to what we exactly want.

First, here are a couple of use cases for the notebook (From Fernando's 
comments)

> On Fri, Jun 8, 2012 at 8:49 AM, Bob McElrath<bob+ipython at mcelrath.org  <http://mail.scipy.org/mailman/listinfo/ipython-dev>>  wrote:
> >/  Well I'll just say that IPython and matplotlib have quickly become my primary
> />/  computational tool.  So I would not simply call it an "exploratory" tool.  I
> />/  could already do exploratory computing with the (i)python command line.  The
> />/  notebook allows me to save, repeat/reproduce, and communicate a computation.  In
> />/  particular it allows me to record how I produced the final version of a plot.
> /
> 1. Individual exploratory work: play with some code, some data, ...
> 2. Collaboration with colleagues.  ...
> 3. Parallel production work: ...
>
>   ... if your results do pan out, you'll want to publish them!...
>
> 4. The same notebook can then be exported to latex or html for
> publication.  We're not really at the point of the notebook being what
> you send to a journal, but the notebooks right now are perfect as
> supplementary materials that remain *executable*.

I think, implementing all of these in a single tool is too ambitious, 
and unrealistic, and the requirements are even conflicting. This would 
mean, e.g., that the notebook should be aware of LaTeX packages. But 
since at this point, it uses MathJaX, and since MathJaX does not 
implement the full LaTeX command set, I don't see how this could be 
pulled off. Even worse, many journals require the use of a specific 
stylesheet, and figures have to be submitted as separate files. So, one 
would have to implement at least two separate backends, one for 
interactive work, and one for PDFs...

Also, if executability is a requirement (I think, it is a reasonable 
one), then for plots we are left with js or SVG, that can work as a 
stand-alone figure, without relying on the ipython kernel. Another 
reason for decoupling the plot from the kernel is that in this way, one 
could explore plots in the notebook, while another calculation is 
running in the kernel.

I would like to quote Brian's comments "I would love to see that emerge 
out of matplotlib, rather than YAPL (yet another plotting library).". I 
couldn't agree more. But if this is the case, then there are some major 
modifications to be implemented in matplotlib itself. I think, we have 
already realised that we would have to have access to not only the 
canvas elements, but the underlying data. At this point, there is no 
easy way of exposing those in matplotlib. So, the bottom line is that, 
if this plotting tool is to emerge from matplotlib, then we have to work 
with the matplotlib developers, and we can't just piggyback on what is 
already there. In such a case, however, we would have to have a very 
clear idea as to what is needed, for otherwise, it will be quite hard to 
convince the matplotlib developers.

As I said earlier, after having played with the javascript backend, I 
could implement coordinate reporting, cross-hairs, and grid toggling in 
a standalone file, and more would most probably be not possible. If this 
is enough, then we should just go with that. If not, then the javascript 
backend is not an option, and SVG would not offer significantly more.
> 5. ... With the traditional approaches we've mostly used so far, each of the
> steps above typically required shifting tools completely.  That hurts
> productivity, kills reproducibility, and fundamentally impairs your
> ability to *iterate* on an idea...
In my view, this point is perhaps the most problematic: if the user
is capable of changing a figure significantly, then there's got to be
a mechanism for tracing those changes, otherwise, reproducibility will
be severely compromised, if at a different level. However, implementing
such a tracking mechanism is most certainly a huge undertaking.


On 06/26/2012 06:26 AM, Fernando Perez wrote:
> Hi Bob,
>
> In this spirit, have you had a chance to play with tools like this?
>
> http://paperjs.org/about/
>
> Since it goes directly to the canvas element and is not SVG, I wonder
> if interactive figures built upon it would fare any better than the
> SVG ones.
I have looked at quite a few of the examples, and it seems to me that 
this library is rather CPU-hungry. But it might just be an issue with 
firefox... However, this might be a problem, even if we start from 
matplotlib, and implement a javascript backend from scratch. Static 
plots certainly have the advantage that once produced, they don't 
require CPU resources anymore...
Cheers,
Zolt?n

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

From benjaminrk at gmail.com  Tue Jun 26 04:41:31 2012
From: benjaminrk at gmail.com (MinRK)
Date: Tue, 26 Jun 2012 01:41:31 -0700
Subject: [IPython-dev] SVG figures status report
In-Reply-To: <4FE96830.1080803@gmail.com>
References: <20120624180123.GL6159@mcelrath.org>
	<CAHAreOr2_DfwJBoF1UskayXhVdWPykZ2z2zPjJ0Dvaj1CW6Hog@mail.gmail.com>
	<4FE96830.1080803@gmail.com>
Message-ID: <CAHNn8BVdOvDkWqfVLa-paK2HGQ03sb=44xy33FNqJ3CqXF-KNQ@mail.gmail.com>

On Tue, Jun 26, 2012 at 12:43 AM, Zolt?n V?r?s <zvoros at gmail.com> wrote:

>  Dear Fernando, and Bob,
>
> I didn't want to bring up this issue before the new release, given that
> that has the higher priority, but since a new thread was opened along the
> same lines, I would like to respond to a couple of points raised here, and
> here: http://mail.scipy.org/pipermail/ipython-dev/2012-June/009476.htmlwhich I will quote here.
>
> Based on these two threads, I have the feeling that the views on what an
> interactive plot should do are somewhat diverging, and we should first come
> to some consensus as to what we exactly want.
>
> First, here are a couple of use cases for the notebook (From Fernando's
> comments)
>
>  On Fri, Jun 8, 2012 at 8:49 AM, Bob McElrath <bob+ipython at mcelrath.org <http://mail.scipy.org/mailman/listinfo/ipython-dev>> wrote:
> >* Well I'll just say that IPython and matplotlib have quickly become my primary*>* computational tool.  So I would not simply call it an "exploratory" tool.  I*>* could already do exploratory computing with the (i)python command line.  The*>* notebook allows me to save, repeat/reproduce, and communicate a computation.  In*>* particular it allows me to record how I produced the final version of a plot.*
> 1. Individual exploratory work: play with some code, some data, ...
> 2. Collaboration with colleagues.  ...
> 3. Parallel production work: ...
>
>  ... if your results do pan out, you'll want to publish them!...
>
> 4. The same notebook can then be exported to latex or html for
> publication.  We're not really at the point of the notebook being what
> you send to a journal, but the notebooks right now are perfect as
> supplementary materials that remain *executable*.
>
>
> I think, implementing all of these in a single tool is too ambitious, and
> unrealistic, and the requirements are even conflicting. This would mean,
> e.g., that the notebook should be aware of LaTeX packages. But since at
> this point, it uses MathJaX, and since MathJaX does not implement the full
> LaTeX command set, I don't see how this could be pulled off. Even worse,
> many journals require the use of a specific stylesheet, and figures have to
> be submitted as separate files. So, one would have to implement at least
> two separate backends, one for interactive work, and one for PDFs...
>

I don't see any need for tex in the browser to be aware of packages, nor
for MathJax to be any limitation on latex *export* of notebooks.  MathJax
renders snippets for interactive use, but when you export a notebook to
LaTeX,(or PDF via latex) MathJax is not involved at all.  Further, you can
use raw cells to add perfectly arbitrary LaTeX to the notebook
(stylesheets, packages, etc.), which will be included at export.  People
are already doing this today.

-MinRK


>
> Also, if executability is a requirement (I think, it is a reasonable one),
> then for plots we are left with js or SVG, that can work as a stand-alone
> figure, without relying on the ipython kernel. Another reason for
> decoupling the plot from the kernel is that in this way, one could explore
> plots in the notebook, while another calculation is running in the kernel.
>
> I would like to quote Brian's comments "I would love to see that emerge
> out of matplotlib, rather than YAPL (yet another plotting library).". I
> couldn't agree more. But if this is the case, then there are some major
> modifications to be implemented in matplotlib itself. I think, we have
> already realised that we would have to have access to not only the canvas
> elements, but the underlying data. At this point, there is no easy way of
> exposing those in matplotlib. So, the bottom line is that, if this plotting
> tool is to emerge from matplotlib, then we have to work with the matplotlib
> developers, and we can't just piggyback on what is already there. In such a
> case, however, we would have to have a very clear idea as to what is
> needed, for otherwise, it will be quite hard to convince the matplotlib
> developers.
>
> As I said earlier, after having played with the javascript backend, I
> could implement coordinate reporting, cross-hairs, and grid toggling in a
> standalone file, and more would most probably be not possible. If this is
> enough, then we should just go with that. If not, then the javascript
> backend is not an option, and SVG would not offer significantly more.
>
> 5. ... With the traditional approaches we've mostly used so far, each of the
> steps above typically required shifting tools completely.  That hurts
> productivity, kills reproducibility, and fundamentally impairs your
> ability to *iterate* on an idea...
>
>  In my view, this point is perhaps the most problematic: if the user
> is capable of changing a figure significantly, then there's got to be
> a mechanism for tracing those changes, otherwise, reproducibility will
> be severely compromised, if at a different level. However, implementing
> such a tracking mechanism is most certainly a huge undertaking.
>
>
> On 06/26/2012 06:26 AM, Fernando Perez wrote:
>
> Hi Bob,
>
> In this spirit, have you had a chance to play with tools like this?
>
> http://paperjs.org/about/
>
> Since it goes directly to the canvas element and is not SVG, I wonder
> if interactive figures built upon it would fare any better than the
> SVG ones.
>
>  I have looked at quite a few of the examples, and it seems to me that
> this library is rather CPU-hungry. But it might just be an issue with
> firefox... However, this might be a problem, even if we start from
> matplotlib, and implement a javascript backend from scratch. Static plots
> certainly have the advantage that once produced, they don't require CPU
> resources anymore...
> Cheers,
> Zolt?n
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120626/16b7a187/attachment.html>

From ludwig.schwardt at gmail.com  Tue Jun 26 05:53:54 2012
From: ludwig.schwardt at gmail.com (Ludwig Schwardt)
Date: Tue, 26 Jun 2012 11:53:54 +0200
Subject: [IPython-dev] SVG figures status report
In-Reply-To: <mailman.4515.1340699860.1208.ipython-dev@scipy.org>
References: <mailman.4515.1340699860.1208.ipython-dev@scipy.org>
Message-ID: <25FD34EFC2B44573BE2A2AB7BC11C404@gmail.com>

Hi Bob and Fernando, 

On Tuesday 26 June 2012 at 10:37 AM, ipython-dev-request at scipy.org wrote: 
> Thanks for this detailed and careful assessment of the situation.
> It's an unfortunate state of affairs, especially as it strongly
> tempers my enthusiasm for tools like d3.js being truly effective in
> the notebook. But better to know than to enthusiastically build
> things that will in practice only work for toy problems but will
> inescapably fail to scale in more complex production environments.
> 
> 

Thanks for the report from my side as well. This has also been our experience with large SVG images in the past.

Simon and I have been concerned with performance and scalability ever since the birth of the mplh5canvas backend. Our original use-case is to visualise datasets that are too large to copy to your local machine. We serve mplh5canvas from the remote machine with the dataset and use the browser on the local machine to view it. We want to be able to visualise millions of points, also in animated form. Hopefully mplh5canvas can get there someday :-) We also want to minimise traffic between the server and the browser (making use of e.g. matplotlib's path simplification), which seems to be a problem for d3.js. 
> 
> In this spirit, have you had a chance to play with tools like this?
> 
> http://paperjs.org/about/
I have also recently stumbled upon Paper.js. Libraries like these have the potential to greatly simplify the mplh5canvas backend as it can directly accept the paths produced by matplotlib. The downside is an extra dependency for probably little speed-up, as the performance mostly depends on the functionality exposed by the HTML5 Canvas itself as far as I can tell.

Regards,
Ludwig

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

From bob+ipython at mcelrath.org  Tue Jun 26 06:54:24 2012
From: bob+ipython at mcelrath.org (Bob McElrath)
Date: Tue, 26 Jun 2012 10:54:24 +0000
Subject: [IPython-dev] SVG figures status report
In-Reply-To: <4FE96830.1080803@gmail.com>
References: <20120624180123.GL6159@mcelrath.org>
	<CAHAreOr2_DfwJBoF1UskayXhVdWPykZ2z2zPjJ0Dvaj1CW6Hog@mail.gmail.com>
	<4FE96830.1080803@gmail.com>
Message-ID: <20120626105423.GO6159@mcelrath.org>

Zolt?n V?r?s [zvoros at gmail.com] wrote:
> Dear Fernando, and Bob,
> 
> I didn't want to bring up this issue before the new release, given that that
> has the higher priority, but since a new thread was opened along the same
> lines, I would like to respond to a couple of points raised here, and here:
> http://mail.scipy.org/pipermail/ipython-dev/2012-June/009476.html which I will
> quote here.

Sorry that I did not see that mail previously.  :-/

But just a couple of comments.

> Based on these two threads, I have the feeling that the views on what an
> interactive plot should do are somewhat diverging, and we should first come to
> some consensus as to what we exactly want.

1. There's a lot of good code in mplh5canvas:
        http://code.google.com/p/mplh5canvas/
   I think it may be possible to extract their matplotlib backend and adapt it
   to IPython.  This could be relatively quick to do, and behaves exactly like
   the other matplotlib GUI's.

2. I'm using my SVG branch daily and I will continue to beat on SVG.  I'm not
    entirely convinced that the bugs I see are not due to some bad
    jQuery/CodeMirror interaction.  I have one example in which the CodeMirror
    updateDisplay() is using a ton of CPU when output cells with a lot of SVG
    figures are focused.  Other profiling I've done indicates it's style
    recalculations that are eating a ton of CPU.  A PNG or Canvas image cache
    rendering is really a hack, and the long-term future is in SVG.

3. I'd say that computationally-oriented tasks, such as coordinate reporting,
    changing to log axes, should be a top priority for interactive figures.
    Secondary to that is massaging a figure into a final form, such as changing
    ticks/labels etc, and importantly, *saving* it in a convenient form.
    Switching to SVG or Canvas for figures will obscure one's ability to save
    the figure and move it into your LaTeX document.  (can't just right
    click->save as anymore).

4. WRT Latex in worksheets and exporting: yet another major failing of
    Maple/Mathematica was their slow evolution into horrible hackish document
    processing systems.  Mathematica made a bizarre Frankenstein beast in which
    you could create entire documents, user interfaces, and unrelated garbage
    with Mathematica commands.  Maple added "2d math input" which is just a
    nightmare of figuring out where it's going to put the cursor next, so you
    can reposition it with the arrow keys.  These things are just hacks, and no
    one uses them to write papers, and never will.  IPython should not have
    delusions of grandeur, and I suggest focusing on computation is more useful.
    The only elements of these "document processing systems" that I ever used
    was annotation text around calculations, and folding blocks of code for
    organization.  IPython already has the former, I expect the latter will come
    soon.  Latex packages are very, very far from the realm of things I want to
    worry about in a worksheet.

5. I'm far more concerned about the repeatability of calculations due to the
    worksheet/kernel separation, and the general organization of a calculation
    in a worksheet, than exporting in a "presentation" form.  I think the
    "worksheet" as a computing paradigm is weak and has many flaws, and I would
    love to see some new and innovative ideas on this front.  I'm not interested
    in a reimplementation of Mathematica's interface.

I'll scratch my itch when it comes to IPython, and I hope it's helpful, but I
don't have the time or resources to implement much this.  So, for the
maintainers, please don't depend on me in this regard.

--
Cheers, Bob McElrath

"The individual has always had to struggle to keep from being overwhelmed by
the tribe.  If you try it, you will be lonely often, and sometimes frightened.
But no price is too high to pay for the privilege of owning yourself." 
    -- Friedrich Nietzsche


From ellisonbg at gmail.com  Tue Jun 26 12:08:57 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Tue, 26 Jun 2012 09:08:57 -0700
Subject: [IPython-dev] SVG figures status report
In-Reply-To: <4FE96830.1080803@gmail.com>
References: <20120624180123.GL6159@mcelrath.org>
	<CAHAreOr2_DfwJBoF1UskayXhVdWPykZ2z2zPjJ0Dvaj1CW6Hog@mail.gmail.com>
	<4FE96830.1080803@gmail.com>
Message-ID: <CAH4pYpQJgoLJvEoqeQOyWrM+K094uCRe5X5yTO79PVKspjXxVA@mail.gmail.com>

On Tue, Jun 26, 2012 at 12:43 AM, Zolt?n V?r?s <zvoros at gmail.com> wrote:
> Dear Fernando, and Bob,
>
> I didn't want to bring up this issue before the new release, given that that
> has the higher priority, but since a new thread was opened along the same
> lines, I would like to respond to a couple of points raised here, and here:
> http://mail.scipy.org/pipermail/ipython-dev/2012-June/009476.html which I
> will quote here.
>
> Based on these two threads, I have the feeling that the views on what an
> interactive plot should do are somewhat diverging, and we should first come
> to some consensus as to what we exactly want.
>
> First, here are a couple of use cases for the notebook (From Fernando's
> comments)
>
> On Fri, Jun 8, 2012 at 8:49 AM, Bob McElrath <bob+ipython at mcelrath.org>
> wrote:
>> Well I'll just say that IPython and matplotlib have quickly become my
>> primary
>> computational tool. ?So I would not simply call it an "exploratory" tool.
>> ?I
>> could already do exploratory computing with the (i)python command line.
>> ?The
>> notebook allows me to save, repeat/reproduce, and communicate a
>> computation. ?In
>> particular it allows me to record how I produced the final version of a
>> plot.
>
> 1. Individual exploratory work: play with some code, some data, ...
> 2. Collaboration with colleagues.  ...
> 3. Parallel production work: ...
>
>  ... if your results do pan out, you'll want to publish them!...
>
> 4. The same notebook can then be exported to latex or html for
> publication.  We're not really at the point of the notebook being what
> you send to a journal, but the notebooks right now are perfect as
> supplementary materials that remain *executable*.
>
>
> I think, implementing all of these in a single tool is too ambitious, and
> unrealistic, and the requirements are even conflicting. This would mean,
> e.g., that the notebook should be aware of LaTeX packages. But since at this
> point, it uses MathJaX, and since MathJaX does not implement the full LaTeX
> command set, I don't see how this could be pulled off. Even worse, many
> journals require the use of a specific stylesheet, and figures have to be
> submitted as separate files. So, one would have to implement at least two
> separate backends, one for interactive work, and one for PDFs...

As Min mentioned if you want full LaTeX support you would have to use
the notebook in a different mode.  You put all the LaTeX in raw text
cells and give up the nice MathJaX browser rendering.  You are right
that it would be difficult to support full LaTeX in Markdown cells
with MathJaX rendering.

> Also, if executability is a requirement (I think, it is a reasonable one),
> then for plots we are left with js or SVG, that can work as a stand-alone
> figure, without relying on the ipython kernel. Another reason for decoupling
> the plot from the kernel is that in this way, one could explore plots in the
> notebook, while another calculation is running in the kernel.
>
> I would like to quote Brian's comments "I would love to see that emerge out
> of matplotlib, rather than YAPL (yet another plotting library).". I couldn't
> agree more. But if this is the case, then there are some major modifications
> to be implemented in matplotlib itself. I think, we have already realised
> that we would have to have access to not only the canvas elements, but the
> underlying data. At this point, there is no easy way of exposing those in
> matplotlib. So, the bottom line is that, if this plotting tool is to emerge
> from matplotlib, then we have to work with the matplotlib developers, and we
> can't just piggyback on what is already there. In such a case, however, we
> would have to have a very clear idea as to what is needed, for otherwise, it
> will be quite hard to convince the matplotlib developers.

I pretty much agree with this.  If we want the interactive plotting to
be integrated with matplotlib, we will have to have someone on the mpl
team basically leading the effort.  We would have to work closely with
them to make sure it all works together.

> As I said earlier, after having played with the javascript backend, I could
> implement coordinate reporting, cross-hairs, and grid toggling in a
> standalone file, and more would most probably be not possible. If this is
> enough, then we should just go with that. If not, then the javascript
> backend is not an option, and SVG would not offer significantly more.
>
> 5. ... With the traditional approaches we've mostly used so far, each of the
> steps above typically required shifting tools completely.  That hurts
> productivity, kills reproducibility, and fundamentally impairs your
> ability to *iterate* on an idea...
>
> In my view, this point is perhaps the most problematic: if the user
> is capable of changing a figure significantly, then there's got to be
> a mechanism for tracing those changes, otherwise, reproducibility will
> be severely compromised, if at a different level. However, implementing
> such a tracking mechanism is most certainly a huge undertaking.

Again, I agree.  Full interactivity does conflict with reproducibility
and we have to have a way of going back and forth between different
representations.

Cheers,

Brian

> On 06/26/2012 06:26 AM, Fernando Perez wrote:
>
> Hi Bob,
>
> In this spirit, have you had a chance to play with tools like this?
>
> http://paperjs.org/about/
>
> Since it goes directly to the canvas element and is not SVG, I wonder
> if interactive figures built upon it would fare any better than the
> SVG ones.
>
> I have looked at quite a few of the examples, and it seems to me that this
> library is rather CPU-hungry. But it might just be an issue with firefox...
> However, this might be a problem, even if we start from matplotlib, and
> implement a javascript backend from scratch. Static plots certainly have the
> advantage that once produced, they don't require CPU resources anymore...
> Cheers,
> Zolt?n
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



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


From jason-sage at creativetrax.com  Tue Jun 26 12:10:27 2012
From: jason-sage at creativetrax.com (Jason Grout)
Date: Tue, 26 Jun 2012 11:10:27 -0500
Subject: [IPython-dev] SVG figures status report
In-Reply-To: <CAH4pYpQJgoLJvEoqeQOyWrM+K094uCRe5X5yTO79PVKspjXxVA@mail.gmail.com>
References: <20120624180123.GL6159@mcelrath.org>
	<CAHAreOr2_DfwJBoF1UskayXhVdWPykZ2z2zPjJ0Dvaj1CW6Hog@mail.gmail.com>
	<4FE96830.1080803@gmail.com>
	<CAH4pYpQJgoLJvEoqeQOyWrM+K094uCRe5X5yTO79PVKspjXxVA@mail.gmail.com>
Message-ID: <4FE9DEF3.1060908@creativetrax.com>

On 6/26/12 11:08 AM, Brian Granger wrote:
> I pretty much agree with this.  If we want the interactive plotting to
> be integrated with matplotlib, we will have to have someone on the mpl
> team basically leading the effort.  We would have to work closely with
> them to make sure it all works together.

If someone spearheaded this, we in the Sage project would also be 
interested in being involved in defining the API, etc.

Jason



From zvoros at gmail.com  Tue Jun 26 13:32:07 2012
From: zvoros at gmail.com (=?ISO-8859-1?Q?Zolt=E1n_V=F6r=F6s?=)
Date: Tue, 26 Jun 2012 19:32:07 +0200
Subject: [IPython-dev] SVG figures status report
In-Reply-To: <20120626105423.GO6159@mcelrath.org>
References: <20120624180123.GL6159@mcelrath.org>
	<CAHAreOr2_DfwJBoF1UskayXhVdWPykZ2z2zPjJ0Dvaj1CW6Hog@mail.gmail.com>
	<4FE96830.1080803@gmail.com> <20120626105423.GO6159@mcelrath.org>
Message-ID: <4FE9F217.1040001@gmail.com>

Hi Bob,

On 06/26/2012 12:54 PM, Bob McElrath wrote:
> 1. There's a lot of good code in mplh5canvas:
>          http://code.google.com/p/mplh5canvas/
>     I think it may be possible to extract their matplotlib backend and adapt it
>     to IPython.  This could be relatively quick to do, and behaves exactly like
>     the other matplotlib GUI's.
We have discussed this a couple of times before. The question is not 
whether mplh5canvas could be used. However, that canvas runs it own 
server, and while it could probably be adapted to ipython, it is not 
even clear whether running plots at a places other than the notebook is 
a good idea in the first place.
Besides, I think, Ludwig Schwardt pointed out that some things in the 
html5 backend don't work perfectly.
> 3. I'd say that computationally-oriented tasks, such as coordinate reporting,
>      changing to log axes, should be a top priority for interactive figures.
>      Secondary to that is massaging a figure into a final form, such as changing
>      ticks/labels etc, and importantly, *saving* it in a convenient form.
>      Switching to SVG or Canvas for figures will obscure one's ability to save
>      the figure and move it into your LaTeX document.  (can't just right
>      click->save as anymore).
I think this is the point where our views totally differ. All but 
coordinate reporting can be done in a script, and I believe, those 
should be done in a script, for, e.g., moving the ticks modifies a 
figure in a way that is substantial, and it compromises repeatability. I 
can change the axis to log by issuing logy on the console, however, I 
can't read off coordinates from the console.
As far as interactivity is concerned, changing to log axis, changing the 
labels and so on are a question of convenience. On the other hand, 
coordinate reporting can be done only by pointing the mouse to a 
specific location on the graph. For this reason, I would say that 
cross-hairs/coordinate reporting is a 1000 times more important in an 
interactive plot than anything else. In other words, we have to ask the 
question what interactivity brings to the table.

Cheers,
Zolt?n


From zvoros at gmail.com  Tue Jun 26 13:41:16 2012
From: zvoros at gmail.com (=?ISO-8859-1?Q?Zolt=E1n_V=F6r=F6s?=)
Date: Tue, 26 Jun 2012 19:41:16 +0200
Subject: [IPython-dev] SVG figures status report
In-Reply-To: <CAH4pYpQJgoLJvEoqeQOyWrM+K094uCRe5X5yTO79PVKspjXxVA@mail.gmail.com>
References: <20120624180123.GL6159@mcelrath.org>
	<CAHAreOr2_DfwJBoF1UskayXhVdWPykZ2z2zPjJ0Dvaj1CW6Hog@mail.gmail.com>
	<4FE96830.1080803@gmail.com>
	<CAH4pYpQJgoLJvEoqeQOyWrM+K094uCRe5X5yTO79PVKspjXxVA@mail.gmail.com>
Message-ID: <4FE9F43C.4020406@gmail.com>

Hi Brian,

On 06/26/2012 06:08 PM, Brian Granger wrote:
> As Min mentioned if you want full LaTeX support you would have to use 
> the notebook in a different mode. You put all the LaTeX in raw text 
> cells and give up the nice MathJaX browser rendering. You are right 
> that it would be difficult to support full LaTeX in Markdown cells 
> with MathJaX rendering. 

Yes, that is what I had in mind. Not that I think it is really 
important, but my first reading of Fernando's comment on this was that 
he sort of wanted to have a LaTeX editor... Though, I have to admit that 
almost realtime rendering of LaTeX code in the notebook is rather sexy:)

>> ... So, the bottom line is that, if this plotting tool is to emerge
>> from matplotlib, then we have to work with the matplotlib developers, and we
>> can't just piggyback on what is already there. In such a case, however, we
>> would have to have a very clear idea as to what is needed, for otherwise, it
>> will be quite hard to convince the matplotlib developers.
> I pretty much agree with this.  If we want the interactive plotting to
> be integrated with matplotlib, we will have to have someone on the mpl
> team basically leading the effort.  We would have to work closely with
> them to make sure it all works together.
According to reports from Bob McElrath and Ludwig Schwardt, there might 
be bandwidth problems, if the figures are complex, and contain much 
data. I really liked your idea of having something like a json backend, 
but then it would introduce a lot of redundancy. A png figure will 
always be something like a 100 kB (of course, you can blow that up, but 
for standard graphs in the notebook), but the json backend would be 
unpredictable in this regard. Do you think that might be a problem?

Cheers,
Zolt?n


From zvoros at gmail.com  Tue Jun 26 13:44:24 2012
From: zvoros at gmail.com (=?ISO-8859-1?Q?Zolt=E1n_V=F6r=F6s?=)
Date: Tue, 26 Jun 2012 19:44:24 +0200
Subject: [IPython-dev] SVG figures status report
In-Reply-To: <4FE9DEF3.1060908@creativetrax.com>
References: <20120624180123.GL6159@mcelrath.org>
	<CAHAreOr2_DfwJBoF1UskayXhVdWPykZ2z2zPjJ0Dvaj1CW6Hog@mail.gmail.com>
	<4FE96830.1080803@gmail.com>
	<CAH4pYpQJgoLJvEoqeQOyWrM+K094uCRe5X5yTO79PVKspjXxVA@mail.gmail.com>
	<4FE9DEF3.1060908@creativetrax.com>
Message-ID: <4FE9F4F8.7010404@gmail.com>

Hi Jason,

On 06/26/2012 06:10 PM, Jason Grout wrote:
> On 6/26/12 11:08 AM, Brian Granger wrote:
>> I pretty much agree with this.  If we want the interactive plotting to
>> be integrated with matplotlib, we will have to have someone on the mpl
>> team basically leading the effort.  We would have to work closely with
>> them to make sure it all works together.
> If someone spearheaded this, we in the Sage project would also be
> interested in being involved in defining the API, etc.
>
> Jason
In that case, should we try to move this whole discussion to the 
mpl-devel list? Or do you think that the ideas here and at sage still 
need some ironing-out?
Cheers,
Zolt?n



From dlsun at stanford.edu  Tue Jun 26 14:19:11 2012
From: dlsun at stanford.edu (Dennis Sun)
Date: Tue, 26 Jun 2012 11:19:11 -0700
Subject: [IPython-dev] multiple worksheets and tabs
Message-ID: <CADLczKBgA5Esr94xoUwU2pCwv-dvYAnbxvWGtgjmAJ9+4eWepg@mail.gmail.com>

Hello all,

I've heard that iPython will support multiple worksheets in the future,
with the idea being that each worksheet would get a separate tab. It seems
like this would be an extremely useful feature that I would like to try to
implement myself if it's not already in the works. Just so that I don't
rediscover the wheel -- what are the conceptual or technical difficulties
that are holding a feature like this back?

Thanks,
Dennis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120626/c624e433/attachment.html>

From ellisonbg at gmail.com  Tue Jun 26 15:07:43 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Tue, 26 Jun 2012 12:07:43 -0700
Subject: [IPython-dev] multiple worksheets and tabs
In-Reply-To: <CADLczKBgA5Esr94xoUwU2pCwv-dvYAnbxvWGtgjmAJ9+4eWepg@mail.gmail.com>
References: <CADLczKBgA5Esr94xoUwU2pCwv-dvYAnbxvWGtgjmAJ9+4eWepg@mail.gmail.com>
Message-ID: <CAH4pYpTSN2+amQuxAjFWpSObq+yU7vbrh1R3Meaw_1ETQzh2DQ@mail.gmail.com>

Our existing Notebook class (notebook.js) will have to be refactored
into two pieces:

Worksheet (which manages a sequence of cells)
Notebook (which manages a sequence of worksheets)

This is a serious amount of JS coding, not particularly hard, but
there are a lot of moving pieces.

* Then there is the creation of the UI within these classes.
* We will also probably have to do some new layout logic to manage the
scrolling properly.
* Finally, there are issues with focus/refresh/etc.  These will be
pretty subtle.



On Tue, Jun 26, 2012 at 11:19 AM, Dennis Sun <dlsun at stanford.edu> wrote:
> Hello all,
>
> I've heard that iPython will support multiple worksheets in the future, with
> the idea being that each worksheet would get a separate tab. It seems like
> this would be an extremely useful feature that I would like to try to
> implement myself if it's not already in the works. Just so that I don't
> rediscover the wheel -- what are the conceptual or technical difficulties
> that are holding a feature like this back?
>
> Thanks,
> Dennis
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



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


From jason-sage at creativetrax.com  Tue Jun 26 16:47:24 2012
From: jason-sage at creativetrax.com (Jason Grout)
Date: Tue, 26 Jun 2012 15:47:24 -0500
Subject: [IPython-dev] SVG figures status report
In-Reply-To: <4FE9F4F8.7010404@gmail.com>
References: <20120624180123.GL6159@mcelrath.org>
	<CAHAreOr2_DfwJBoF1UskayXhVdWPykZ2z2zPjJ0Dvaj1CW6Hog@mail.gmail.com>
	<4FE96830.1080803@gmail.com>
	<CAH4pYpQJgoLJvEoqeQOyWrM+K094uCRe5X5yTO79PVKspjXxVA@mail.gmail.com>
	<4FE9DEF3.1060908@creativetrax.com> <4FE9F4F8.7010404@gmail.com>
Message-ID: <4FEA1FDC.3030606@creativetrax.com>

On 6/26/12 12:44 PM, Zolt?n V?r?s wrote:
> In that case, should we try to move this whole discussion to the
> mpl-devel list? Or do you think that the ideas here and at sage still
> need some ironing-out?

I think ironing the ideas out certainly needs to be done.  I don't have 
an extremely clear idea of exactly what I want, for example, and others 
have noted that we need to take a step back and see exactly what we 
want.  For example, I agree that some sort of tracing/coordinate display 
(no communication back to the server) would already be a huge help for Sage.

I think it should move to mpl-developers anyway, as Brian alluded when 
he said someone in mpl would have to spearhead it.  Brian, Fernando, or 
Min, do you by chance happen to subscribe to mpl-dev?

Jason


From jason-sage at creativetrax.com  Tue Jun 26 17:32:38 2012
From: jason-sage at creativetrax.com (Jason Grout)
Date: Tue, 26 Jun 2012 16:32:38 -0500
Subject: [IPython-dev] SockJS
Message-ID: <4FEA2A76.5050807@creativetrax.com>

Have you guys thought about using the SockJS library to implement the 
websockets?  It falls back to older methods if the browser doesn't 
support Websockets, and is designed as a drop-in replacement for 
websocket objects.  There is a tornado-sockjs package as well.

Here are some relevant links:

https://github.com/sockjs

https://github.com/MrJoes/sockjs-tornado

https://groups.google.com/forum/#!topic/sockjs/lgzxVnlth54/discussion 
(see in particular Serge's post; third one from the top).

http://www.rabbitmq.com/blog/2011/08/22/sockjs-web-messaging-aint-easy/

http://www.rabbitmq.com/blog/2011/09/13/sockjs-websocket-emulation/

Thanks,

Jason


From benjaminrk at gmail.com  Tue Jun 26 17:39:16 2012
From: benjaminrk at gmail.com (MinRK)
Date: Tue, 26 Jun 2012 14:39:16 -0700
Subject: [IPython-dev] SockJS
In-Reply-To: <4FEA2A76.5050807@creativetrax.com>
References: <4FEA2A76.5050807@creativetrax.com>
Message-ID: <CAHNn8BXpv0vX2Hut5r8dBcWmWQRYa=ORpon8P+s9y0VYSvmN1g@mail.gmail.com>

On Tue, Jun 26, 2012 at 2:32 PM, Jason Grout <jason-sage at creativetrax.com>wrote:

> Have you guys thought about using the SockJS library to implement the
> websockets?  It falls back to older methods if the browser doesn't
> support Websockets, and is designed as a drop-in replacement for
> websocket objects.  There is a tornado-sockjs package as well.
>

Yes, I'm aware of this (and similar projects, like socket.io).

I think it will be quite some time before we have done enough of the more
interesting/important work before we get to considering supporting
Websocket-less environments, at which point we can look at whether
websocket support has not improved enough.


>
> Here are some relevant links:
>
> https://github.com/sockjs
>
> https://github.com/MrJoes/sockjs-tornado
>
> https://groups.google.com/forum/#!topic/sockjs/lgzxVnlth54/discussion
> (see in particular Serge's post; third one from the top).
>
> http://www.rabbitmq.com/blog/2011/08/22/sockjs-web-messaging-aint-easy/
>
> http://www.rabbitmq.com/blog/2011/09/13/sockjs-websocket-emulation/
>
> Thanks,
>
> Jason
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120626/3f650dc3/attachment.html>

From ellisonbg at gmail.com  Tue Jun 26 17:51:47 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Tue, 26 Jun 2012 14:51:47 -0700
Subject: [IPython-dev] SockJS
In-Reply-To: <4FEA2A76.5050807@creativetrax.com>
References: <4FEA2A76.5050807@creativetrax.com>
Message-ID: <CAH4pYpTK1EAb03JZaxOMGcYxfcSg82igvdakrzDkAsKi-1k6ag@mail.gmail.com>

We are aware of these alternatives.  My philosophy (and I think it is
reflected in the rest of the team) is this:  by sticking with plain
old WebSockets, all we have to do is *wait* for the situation to
improve.  That is super easy to do!  Once IE 10 comes out, we should
cover most browsers.  If we go another route, *we* have to do all the
work, and in the end, we will throw that work away because WebSockets
will eventually have universal support.  That sounds like extremely
low priority work to me.

People should not be running older browsers anyways.  There is simply
no reason, you almost have to try hard to run an older browser.

The main area where I find WebSockets to be lacking is in the
proxy/load balancer support.  As far as I know, Apache and nginx don't
support WebSocket proxying, but HAproxy does.  I don't think the load
balancers on Rackspace or AWS do.  But *today* these things are not
show stoppers for the notebook.  As the notebook is run in different
contexts we will have to explore this space further.  But again,
waiting is golden.

Cheers,

Brian


On Tue, Jun 26, 2012 at 2:32 PM, Jason Grout
<jason-sage at creativetrax.com> wrote:
> Have you guys thought about using the SockJS library to implement the
> websockets? ?It falls back to older methods if the browser doesn't
> support Websockets, and is designed as a drop-in replacement for
> websocket objects. ?There is a tornado-sockjs package as well.
>
> Here are some relevant links:
>
> https://github.com/sockjs
>
> https://github.com/MrJoes/sockjs-tornado
>
> https://groups.google.com/forum/#!topic/sockjs/lgzxVnlth54/discussion
> (see in particular Serge's post; third one from the top).
>
> http://www.rabbitmq.com/blog/2011/08/22/sockjs-web-messaging-aint-easy/
>
> http://www.rabbitmq.com/blog/2011/09/13/sockjs-websocket-emulation/
>
> Thanks,
>
> Jason
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



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


From carl.input at gmail.com  Tue Jun 26 17:52:32 2012
From: carl.input at gmail.com (Carl Smith)
Date: Tue, 26 Jun 2012 22:52:32 +0100
Subject: [IPython-dev] We might actually make 0.13 by June 30,
 jump in to make it possible!
In-Reply-To: <CAHAreOqBH0K1LA371s_CZJo+SS=3MBYx8-GLjdShUVDvs+u6RQ@mail.gmail.com>
References: <CAHAreOqBH0K1LA371s_CZJo+SS=3MBYx8-GLjdShUVDvs+u6RQ@mail.gmail.com>
Message-ID: <CAP-uhDfC06xa39UEk3sFgvXAaxGw2LUJqG4T7J2sb7qaGTVtXA@mail.gmail.com>

Can we get a new flag for the issue tracker that indicates that it's
expected to be an issue you can go at without knowing much IPython voodoo?

I'm happy to knock out some copy for the site if I can get something to
work from.
On Jun 26, 2012 6:55 AM, "Fernando Perez" <fperez.net at gmail.com> wrote:

> Hi all,
>
> the 0.13 milestone board is actually looking pretty solid (after some
> aggressive triage and new code today):
>
>
> https://github.com/ipython/ipython/issues?labels=&milestone=7&page=1&state=open
>
> We have 7 open PRs and 5 issues, 4 of which are closed by a  PR.  The
> remaining issue, #1702, has a pending discussion on what we should do
> with it given there's no code ready to close it.
>
> So I think that if people can jump in with testing and review on any
> of these that you can help with, and we get the release notes in
> shape, we can actually do the release quite quickly.
>
> Our CI bots on Shining Panda and Travis are looking solid:
>
> https://jenkins.shiningpanda.com/ipython
> http://travis-ci.org/#!/ipython/ipython
>
> On SP we cover python 2.6, 2.7, 3.1, 3.2 and 3.3, and Linux, Mac and
> Windows, though not all OSes cover all python versions, so I think
> it's not unreasonable to move forward with the release once we merge
> the PRs we have open.
>
> So please jump in if you can help, esp. with the release notes/website
> work, so we can cut this quickly and open again for development.
>
> Thanks to everyone for all the great recent contributions, and a
> special one to Thomas Kluyver and Marc Abramowitz for the Shining
> Panda and Travis-CI setup.  The value of CI becomes particularly clear
> near release time, as I feel much more confident moving forward
> without having to wait for weeks of RCs going out to people for manual
> testing.
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120626/aab4decd/attachment.html>

From fperez.net at gmail.com  Tue Jun 26 17:57:28 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 26 Jun 2012 14:57:28 -0700
Subject: [IPython-dev] We might actually make 0.13 by June 30,
 jump in to make it possible!
In-Reply-To: <CAP-uhDfC06xa39UEk3sFgvXAaxGw2LUJqG4T7J2sb7qaGTVtXA@mail.gmail.com>
References: <CAHAreOqBH0K1LA371s_CZJo+SS=3MBYx8-GLjdShUVDvs+u6RQ@mail.gmail.com>
	<CAP-uhDfC06xa39UEk3sFgvXAaxGw2LUJqG4T7J2sb7qaGTVtXA@mail.gmail.com>
Message-ID: <CAHAreOrdt1nCegvd-T4HaZ8ikJ1JspHBNrq9Oyi55yrqenvBZA@mail.gmail.com>

On Tue, Jun 26, 2012 at 2:52 PM, Carl Smith <carl.input at gmail.com> wrote:
> Can we get a new flag for the issue tracker that indicates that it's
> expected to be an issue you can go at without knowing much IPython voodoo?

That does exist, it's called 'quickfix':

https://github.com/ipython/ipython/issues?labels=quickfix&milestone=&page=1&state=open

> I'm happy to knock out some copy for the site if I can get something to work
> from.

That would be great!  Here is Thomas' PR to get things going:

https://github.com/ipython/ipython-website/pull/10

Cheers,

f


From carl.input at gmail.com  Tue Jun 26 18:01:59 2012
From: carl.input at gmail.com (Carl Smith)
Date: Tue, 26 Jun 2012 23:01:59 +0100
Subject: [IPython-dev] We might actually make 0.13 by June 30,
 jump in to make it possible!
In-Reply-To: <CAHAreOrdt1nCegvd-T4HaZ8ikJ1JspHBNrq9Oyi55yrqenvBZA@mail.gmail.com>
References: <CAHAreOqBH0K1LA371s_CZJo+SS=3MBYx8-GLjdShUVDvs+u6RQ@mail.gmail.com>
	<CAP-uhDfC06xa39UEk3sFgvXAaxGw2LUJqG4T7J2sb7qaGTVtXA@mail.gmail.com>
	<CAHAreOrdt1nCegvd-T4HaZ8ikJ1JspHBNrq9Oyi55yrqenvBZA@mail.gmail.com>
Message-ID: <CAP-uhDeh+L+dz0WYUCj8NaTCfu0MhTVX++O47QjbrDzVUrsbcg@mail.gmail.com>

I finish work in an hour. I'll have a look at Thomas' PR then. I didn't
know about quickfix, I'll keep it in mind.
On Jun 26, 2012 10:58 PM, "Fernando Perez" <fperez.net at gmail.com> wrote:

> On Tue, Jun 26, 2012 at 2:52 PM, Carl Smith <carl.input at gmail.com> wrote:
> > Can we get a new flag for the issue tracker that indicates that it's
> > expected to be an issue you can go at without knowing much IPython
> voodoo?
>
> That does exist, it's called 'quickfix':
>
>
> https://github.com/ipython/ipython/issues?labels=quickfix&milestone=&page=1&state=open
>
> > I'm happy to knock out some copy for the site if I can get something to
> work
> > from.
>
> That would be great!  Here is Thomas' PR to get things going:
>
> https://github.com/ipython/ipython-website/pull/10
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120626/b438a395/attachment.html>

From benjaminrk at gmail.com  Tue Jun 26 18:05:11 2012
From: benjaminrk at gmail.com (MinRK)
Date: Tue, 26 Jun 2012 15:05:11 -0700
Subject: [IPython-dev] We might actually make 0.13 by June 30,
 jump in to make it possible!
In-Reply-To: <CAP-uhDeh+L+dz0WYUCj8NaTCfu0MhTVX++O47QjbrDzVUrsbcg@mail.gmail.com>
References: <CAHAreOqBH0K1LA371s_CZJo+SS=3MBYx8-GLjdShUVDvs+u6RQ@mail.gmail.com>
	<CAP-uhDfC06xa39UEk3sFgvXAaxGw2LUJqG4T7J2sb7qaGTVtXA@mail.gmail.com>
	<CAHAreOrdt1nCegvd-T4HaZ8ikJ1JspHBNrq9Oyi55yrqenvBZA@mail.gmail.com>
	<CAP-uhDeh+L+dz0WYUCj8NaTCfu0MhTVX++O47QjbrDzVUrsbcg@mail.gmail.com>
Message-ID: <CAHNn8BXi8vFH+CcbctSPu+rsBE+mYZ8rLf3qcZ1q3j_MJZM7Hg@mail.gmail.com>

On Tue, Jun 26, 2012 at 3:01 PM, Carl Smith <carl.input at gmail.com> wrote:

> I finish work in an hour. I'll have a look at Thomas' PR then. I didn't
> know about quickfix, I'll keep it in mind.
>
A bit more specifically, quickfix is usually code or docs where the
solution is known, but nobody has typed it up. Many of these are meant to
be welcoming to new contributors.  Any documentation issues should be
marked with 'doc', if you don't want to be looking at actual code.

-MinRK



> On Jun 26, 2012 10:58 PM, "Fernando Perez" <fperez.net at gmail.com> wrote:
>
>> On Tue, Jun 26, 2012 at 2:52 PM, Carl Smith <carl.input at gmail.com> wrote:
>> > Can we get a new flag for the issue tracker that indicates that it's
>> > expected to be an issue you can go at without knowing much IPython
>> voodoo?
>>
>> That does exist, it's called 'quickfix':
>>
>>
>> https://github.com/ipython/ipython/issues?labels=quickfix&milestone=&page=1&state=open
>>
>> > I'm happy to knock out some copy for the site if I can get something to
>> work
>> > from.
>>
>> That would be great!  Here is Thomas' PR to get things going:
>>
>> https://github.com/ipython/ipython-website/pull/10
>>
>> Cheers,
>>
>> f
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120626/13e2c33a/attachment.html>

From carl.input at gmail.com  Tue Jun 26 18:14:46 2012
From: carl.input at gmail.com (Carl Smith)
Date: Tue, 26 Jun 2012 23:14:46 +0100
Subject: [IPython-dev] We might actually make 0.13 by June 30,
 jump in to make it possible!
In-Reply-To: <CAHNn8BXi8vFH+CcbctSPu+rsBE+mYZ8rLf3qcZ1q3j_MJZM7Hg@mail.gmail.com>
References: <CAHAreOqBH0K1LA371s_CZJo+SS=3MBYx8-GLjdShUVDvs+u6RQ@mail.gmail.com>
	<CAP-uhDfC06xa39UEk3sFgvXAaxGw2LUJqG4T7J2sb7qaGTVtXA@mail.gmail.com>
	<CAHAreOrdt1nCegvd-T4HaZ8ikJ1JspHBNrq9Oyi55yrqenvBZA@mail.gmail.com>
	<CAP-uhDeh+L+dz0WYUCj8NaTCfu0MhTVX++O47QjbrDzVUrsbcg@mail.gmail.com>
	<CAHNn8BXi8vFH+CcbctSPu+rsBE+mYZ8rLf3qcZ1q3j_MJZM7Hg@mail.gmail.com>
Message-ID: <CAP-uhDdQ61oe7d9KHM6H3VPJG=qZ6ggmVB2N=LOZa+fFhYKNeA@mail.gmail.com>

I don't mind a bit of code, but thanks for the heads up. I will try and
pitch in to get 0.13 out.
On Jun 26, 2012 11:05 PM, "MinRK" <benjaminrk at gmail.com> wrote:

>
>
> On Tue, Jun 26, 2012 at 3:01 PM, Carl Smith <carl.input at gmail.com> wrote:
>
>> I finish work in an hour. I'll have a look at Thomas' PR then. I didn't
>> know about quickfix, I'll keep it in mind.
>>
> A bit more specifically, quickfix is usually code or docs where the
> solution is known, but nobody has typed it up. Many of these are meant to
> be welcoming to new contributors.  Any documentation issues should be
> marked with 'doc', if you don't want to be looking at actual code.
>
> -MinRK
>
>
>
>> On Jun 26, 2012 10:58 PM, "Fernando Perez" <fperez.net at gmail.com> wrote:
>>
>>> On Tue, Jun 26, 2012 at 2:52 PM, Carl Smith <carl.input at gmail.com>
>>> wrote:
>>> > Can we get a new flag for the issue tracker that indicates that it's
>>> > expected to be an issue you can go at without knowing much IPython
>>> voodoo?
>>>
>>> That does exist, it's called 'quickfix':
>>>
>>>
>>> https://github.com/ipython/ipython/issues?labels=quickfix&milestone=&page=1&state=open
>>>
>>> > I'm happy to knock out some copy for the site if I can get something
>>> to work
>>> > from.
>>>
>>> That would be great!  Here is Thomas' PR to get things going:
>>>
>>> https://github.com/ipython/ipython-website/pull/10
>>>
>>> Cheers,
>>>
>>> f
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120626/d8cd6816/attachment.html>

From fperez.net at gmail.com  Tue Jun 26 18:18:15 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 26 Jun 2012 15:18:15 -0700
Subject: [IPython-dev] SockJS
In-Reply-To: <CAH4pYpTK1EAb03JZaxOMGcYxfcSg82igvdakrzDkAsKi-1k6ag@mail.gmail.com>
References: <4FEA2A76.5050807@creativetrax.com>
	<CAH4pYpTK1EAb03JZaxOMGcYxfcSg82igvdakrzDkAsKi-1k6ag@mail.gmail.com>
Message-ID: <CAHAreOoBu2NoUuhM=_AHStW_uSZQ9W5Q5QNZTT1_TNTb8pehCQ@mail.gmail.com>

On Tue, Jun 26, 2012 at 2:51 PM, Brian Granger <ellisonbg at gmail.com> wrote:
> We are aware of these alternatives. ?My philosophy (and I think it is
> reflected in the rest of the team) is this: ?by sticking with plain
> old WebSockets, all we have to do is *wait* for the situation to
> improve. ?That is super easy to do! ?Once IE 10 comes out, we should
> cover most browsers. ?If we go another route, *we* have to do all the
> work, and in the end, we will throw that work away because WebSockets
> will eventually have universal support. ?That sounds like extremely
> low priority work to me.

+1 (and also with Min).

> People should not be running older browsers anyways. ?There is simply
> no reason, you almost have to try hard to run an older browser.

There are real-world scenarios where individual users are *forced* to
run older browser by constraints beyond their control, such as
university/school/company-run machines where they have no admin
control at all.  So I do see that *in principle* it would indeed be
nice to support older browsers.

But given the extremely high cost of development to us of such
support, I just don't think it's a realistic proposition: we'd get
bogged in a tarpit of old browser support that would easily consume
all our limited dev resources.

So I simply accept that IPython isn't the right tool for those in such
constrained environments, unfortunately.  We have to pick our battles
carefully if we're going to make progress, and this is one such
tactical choice.

Cheers,

f


From ellisonbg at gmail.com  Tue Jun 26 18:32:52 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Tue, 26 Jun 2012 15:32:52 -0700
Subject: [IPython-dev] SockJS
In-Reply-To: <CAHAreOoBu2NoUuhM=_AHStW_uSZQ9W5Q5QNZTT1_TNTb8pehCQ@mail.gmail.com>
References: <4FEA2A76.5050807@creativetrax.com>
	<CAH4pYpTK1EAb03JZaxOMGcYxfcSg82igvdakrzDkAsKi-1k6ag@mail.gmail.com>
	<CAHAreOoBu2NoUuhM=_AHStW_uSZQ9W5Q5QNZTT1_TNTb8pehCQ@mail.gmail.com>
Message-ID: <CAH4pYpQMG_uyZd9sd3gyhZdK6JUWvc-O5gQEY_hjHP8k134BxQ@mail.gmail.com>

Oh, the other thing that I didn't mention is that we use other
features (such as the flexible box model) that older browsers don't
support.  Tackling all of these things would amount to rewriting major
portions of the notebook.

On Tue, Jun 26, 2012 at 3:18 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Tue, Jun 26, 2012 at 2:51 PM, Brian Granger <ellisonbg at gmail.com> wrote:
>> We are aware of these alternatives. ?My philosophy (and I think it is
>> reflected in the rest of the team) is this: ?by sticking with plain
>> old WebSockets, all we have to do is *wait* for the situation to
>> improve. ?That is super easy to do! ?Once IE 10 comes out, we should
>> cover most browsers. ?If we go another route, *we* have to do all the
>> work, and in the end, we will throw that work away because WebSockets
>> will eventually have universal support. ?That sounds like extremely
>> low priority work to me.
>
> +1 (and also with Min).
>
>> People should not be running older browsers anyways. ?There is simply
>> no reason, you almost have to try hard to run an older browser.
>
> There are real-world scenarios where individual users are *forced* to
> run older browser by constraints beyond their control, such as
> university/school/company-run machines where they have no admin
> control at all. ?So I do see that *in principle* it would indeed be
> nice to support older browsers.
>
> But given the extremely high cost of development to us of such
> support, I just don't think it's a realistic proposition: we'd get
> bogged in a tarpit of old browser support that would easily consume
> all our limited dev resources.
>
> So I simply accept that IPython isn't the right tool for those in such
> constrained environments, unfortunately. ?We have to pick our battles
> carefully if we're going to make progress, and this is one such
> tactical choice.
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



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


From jason-sage at creativetrax.com  Tue Jun 26 18:34:58 2012
From: jason-sage at creativetrax.com (Jason Grout)
Date: Tue, 26 Jun 2012 17:34:58 -0500
Subject: [IPython-dev] SockJS
In-Reply-To: <CAHAreOoBu2NoUuhM=_AHStW_uSZQ9W5Q5QNZTT1_TNTb8pehCQ@mail.gmail.com>
References: <4FEA2A76.5050807@creativetrax.com>
	<CAH4pYpTK1EAb03JZaxOMGcYxfcSg82igvdakrzDkAsKi-1k6ag@mail.gmail.com>
	<CAHAreOoBu2NoUuhM=_AHStW_uSZQ9W5Q5QNZTT1_TNTb8pehCQ@mail.gmail.com>
Message-ID: <4FEA3912.5020006@creativetrax.com>

On 6/26/12 5:18 PM, Fernando Perez wrote:
> On Tue, Jun 26, 2012 at 2:51 PM, Brian Granger<ellisonbg at gmail.com>  wrote:
>> We are aware of these alternatives.  My philosophy (and I think it is
>> reflected in the rest of the team) is this:  by sticking with plain
>> old WebSockets, all we have to do is *wait* for the situation to
>> improve.  That is super easy to do!  Once IE 10 comes out, we should
>> cover most browsers.  If we go another route, *we* have to do all the
>> work, and in the end, we will throw that work away because WebSockets
>> will eventually have universal support.  That sounds like extremely
>> low priority work to me.
>
> +1 (and also with Min).
>
>> People should not be running older browsers anyways.  There is simply
>> no reason, you almost have to try hard to run an older browser.
>
> There are real-world scenarios where individual users are *forced* to
> run older browser by constraints beyond their control, such as
> university/school/company-run machines where they have no admin
> control at all.  So I do see that *in principle* it would indeed be
> nice to support older browsers.
>
> But given the extremely high cost of development to us of such
> support,

I thought SockJS was pretty much a drop-in replacement for Websockets. 
Theoretically.  Of course, we haven't actually tried it out.

Or I suppose you're also talking about lots of other quirks with older 
browsers beyond this issue.


> I just don't think it's a realistic proposition: we'd get
> bogged in a tarpit of old browser support that would easily consume
> all our limited dev resources.
>
> So I simply accept that IPython isn't the right tool for those in such
> constrained environments, unfortunately.  We have to pick our battles
> carefully if we're going to make progress, and this is one such
> tactical choice.

Thanks; that sounds like nearly unanimous replies from the three major 
people.  We were in much the same position a year ago regarding IPython; 
we could wait for IPython 0.12/0.13 to mature to base our sage cell 
server work on, or we could forge ahead with the Sage cell server on the 
old IPython.  I'm glad we forged ahead; we've learned a lot about how 
the environment works, and we've had a lot of adoption.  Now we're 
rewriting it all to use the IPython framework this summer :).

I see more clearly the different audiences we cater.  IPython can force 
a browser choice because the using the notebook is usually a personal 
choice for a personal user.  In our case, universities are a primary 
target, so we'll use SockJS in our deployment of IPython/Sage web 
interfaces, which will hopefully go away in a few years when websockets 
is ubiquitous.  The nice thing is that (theoretically) SockJS is a 
drop-in replacement for websockets, so it should be really easy to push 
things back to websockets when the time comes.

Anyways, good to know it was considered!

Thanks,

Jason


From ellisonbg at gmail.com  Tue Jun 26 20:17:40 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Tue, 26 Jun 2012 17:17:40 -0700
Subject: [IPython-dev] Notebook filename badness
Message-ID: <CAH4pYpSV3Gewh0nsS+j+nhe=xcgqRD7GOU=SkaciY43hujjOaQ@mail.gmail.com>

Hi,

I just finished implementing a new Azure Blob Storage backend for notebooks:

https://github.com/ipython/ipython/pull/2045

It should be easy to add new notebook manager subclasses for S3 and
other stores.

While doing this, I came to the realization that our existing notebook
storage systems has a fundamental and problematic assumption:

* Notebook *names* are unique (they are used as the unique identifier
when saving notebooks).

This is a problem because our entire web application is based on
different assumptions:

* Notebook *ids* are unique.  This is why our URLs are id based for example.
* Notebook names can be repeated.  Our UI makes no attempt to enforce
name uniqueness.

This mismatch leads to all sorts of problems:

* Renaming a notebook to the name of an existing file overwrites that file.
* Uploading a new notebook can overwrite an existing file.
* Because notebook ids are not persisted between sessions of the
notebook server, you can't refer to them by URL and reload notebook
pages between server restarts.

I propose a simple fix to all of this:

* We create a new notebook manager that stores notebooks in a hidden
.ipynb directory.  I guess we could also use a visible subdir as well.
* In that directory, we use the notebook_id as the filename:
[notebook_id].ipynb
* Each time the notebook server restarts, it reads the notebook_ids
and notebook names.  This will ensure that the notebook_ids are always
the same.

As I think about adding other backends, all of the ones I can think of
will use a notebook_id as the unique notebook identifier.  Note, I am
not proposing that we do away with the existing notebook manager.  We
should continue to support it, but we should *not* try to fix its the
fundamental problems it has.  I know there are many disadvantages to
what I am proposing, but this is where I see things going = multiple
backend notebook stores and the need to support all of them from a
common and uniform base = (notebook ids are unique, notebook names are
not)

Cheers,

Brian








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


From takowl at gmail.com  Tue Jun 26 20:36:05 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Wed, 27 Jun 2012 01:36:05 +0100
Subject: [IPython-dev] Notebook filename badness
In-Reply-To: <CAH4pYpSV3Gewh0nsS+j+nhe=xcgqRD7GOU=SkaciY43hujjOaQ@mail.gmail.com>
References: <CAH4pYpSV3Gewh0nsS+j+nhe=xcgqRD7GOU=SkaciY43hujjOaQ@mail.gmail.com>
Message-ID: <CAOvn4qj72UNzx9YWQd+=8pofbettzk99XOM3+eEV81A_JJ8zJw@mail.gmail.com>

On 27 June 2012 01:17, Brian Granger <ellisonbg at gmail.com> wrote:
> * Because notebook ids are not persisted between sessions of the
> notebook server, you can't refer to them by URL and reload notebook
> pages between server restarts.

This may well be stupid, but is there a good reason we can't, with a
filesystem-based store, use URLs like
"http://localhost:8888/my_notebook.ipynb"? Even if that simply
redirects to a UUID-based URL, it would mean there's a predictable way
to get to them.

> Note, I am not proposing that we do away with the existing notebook manager. We should continue to support it, but we should *not* try to fix its the fundamental problems it has.

The notebook has proven very valuable as a local application, and I
think we should make it work well for that case as well as the webapp
case, even if that means some extra complexity in the code. Maybe I
haven't properly grasped the complexities involved, but the idea that
we should accept fairly serious problems with local use, and focus on
it as a web application, leaves a bad taste in my mouth.

Also, I don't think these problems are entirely unique to the file
system. Notebooks stored in a database still need human readable
names, and I'd still expect some way to handle conflicts in those.
Meaningful URLs would also be nice, regardless of the storage used.

Best wishes,
Thomas


From carl.input at gmail.com  Tue Jun 26 21:03:49 2012
From: carl.input at gmail.com (Carl Smith)
Date: Wed, 27 Jun 2012 02:03:49 +0100
Subject: [IPython-dev] We might actually make 0.13 by June 30,
 jump in to make it possible!
In-Reply-To: <CAP-uhDdQ61oe7d9KHM6H3VPJG=qZ6ggmVB2N=LOZa+fFhYKNeA@mail.gmail.com>
References: <CAHAreOqBH0K1LA371s_CZJo+SS=3MBYx8-GLjdShUVDvs+u6RQ@mail.gmail.com>
	<CAP-uhDfC06xa39UEk3sFgvXAaxGw2LUJqG4T7J2sb7qaGTVtXA@mail.gmail.com>
	<CAHAreOrdt1nCegvd-T4HaZ8ikJ1JspHBNrq9Oyi55yrqenvBZA@mail.gmail.com>
	<CAP-uhDeh+L+dz0WYUCj8NaTCfu0MhTVX++O47QjbrDzVUrsbcg@mail.gmail.com>
	<CAHNn8BXi8vFH+CcbctSPu+rsBE+mYZ8rLf3qcZ1q3j_MJZM7Hg@mail.gmail.com>
	<CAP-uhDdQ61oe7d9KHM6H3VPJG=qZ6ggmVB2N=LOZa+fFhYKNeA@mail.gmail.com>
Message-ID: <CAP-uhDcPm7SHrzfMi73wEfmZUQmaAZn36MYK=MN0wwMxnpeY3g@mail.gmail.com>

Can I fork a branch, or branch a branch, on github?

I'm looking at ipython-website 0.13, where Thomas has made some
changes, and I wanted to carry on with his branch, but keep ending up
with a fork of master where they are not merged yet.

Sorry. I'm new to github.

On 26 June 2012 23:14, Carl Smith <carl.input at gmail.com> wrote:
> I don't mind a bit of code, but thanks for the heads up. I will try and
> pitch in to get 0.13 out.
>
> On Jun 26, 2012 11:05 PM, "MinRK" <benjaminrk at gmail.com> wrote:
>>
>>
>>
>> On Tue, Jun 26, 2012 at 3:01 PM, Carl Smith <carl.input at gmail.com> wrote:
>>>
>>> I finish work in an hour. I'll have a look at Thomas' PR then. I didn't
>>> know about quickfix, I'll keep it in mind.
>>
>> A bit more specifically, quickfix is usually code or docs where the
>> solution is known, but nobody has typed it up. Many of these are meant to be
>> welcoming to new contributors. ?Any documentation issues should be marked
>> with 'doc', if you don't want to be looking at actual code.
>>
>> -MinRK
>>
>>
>>>
>>> On Jun 26, 2012 10:58 PM, "Fernando Perez" <fperez.net at gmail.com> wrote:
>>>>
>>>> On Tue, Jun 26, 2012 at 2:52 PM, Carl Smith <carl.input at gmail.com>
>>>> wrote:
>>>> > Can we get a new flag for the issue tracker that indicates that it's
>>>> > expected to be an issue you can go at without knowing much IPython
>>>> > voodoo?
>>>>
>>>> That does exist, it's called 'quickfix':
>>>>
>>>>
>>>> https://github.com/ipython/ipython/issues?labels=quickfix&milestone=&page=1&state=open
>>>>
>>>> > I'm happy to knock out some copy for the site if I can get something
>>>> > to work
>>>> > from.
>>>>
>>>> That would be great! ?Here is Thomas' PR to get things going:
>>>>
>>>> https://github.com/ipython/ipython-website/pull/10
>>>>
>>>> Cheers,
>>>>
>>>> f
>>>> _______________________________________________
>>>> IPython-dev mailing list
>>>> IPython-dev at scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>
>>>
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>
>>
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>


From carl.input at gmail.com  Tue Jun 26 21:08:02 2012
From: carl.input at gmail.com (Carl Smith)
Date: Wed, 27 Jun 2012 02:08:02 +0100
Subject: [IPython-dev] We might actually make 0.13 by June 30,
 jump in to make it possible!
In-Reply-To: <CAP-uhDcPm7SHrzfMi73wEfmZUQmaAZn36MYK=MN0wwMxnpeY3g@mail.gmail.com>
References: <CAHAreOqBH0K1LA371s_CZJo+SS=3MBYx8-GLjdShUVDvs+u6RQ@mail.gmail.com>
	<CAP-uhDfC06xa39UEk3sFgvXAaxGw2LUJqG4T7J2sb7qaGTVtXA@mail.gmail.com>
	<CAHAreOrdt1nCegvd-T4HaZ8ikJ1JspHBNrq9Oyi55yrqenvBZA@mail.gmail.com>
	<CAP-uhDeh+L+dz0WYUCj8NaTCfu0MhTVX++O47QjbrDzVUrsbcg@mail.gmail.com>
	<CAHNn8BXi8vFH+CcbctSPu+rsBE+mYZ8rLf3qcZ1q3j_MJZM7Hg@mail.gmail.com>
	<CAP-uhDdQ61oe7d9KHM6H3VPJG=qZ6ggmVB2N=LOZa+fFhYKNeA@mail.gmail.com>
	<CAP-uhDcPm7SHrzfMi73wEfmZUQmaAZn36MYK=MN0wwMxnpeY3g@mail.gmail.com>
Message-ID: <CAP-uhDdvz38jGj2Enzy6rhQLWhdxFwOEHkO47C5bX2xfZOQZmw@mail.gmail.com>

Ah, figured it I think. False alarm.

On 27 June 2012 02:03, Carl Smith <carl.input at gmail.com> wrote:
> Can I fork a branch, or branch a branch, on github?
>
> I'm looking at ipython-website 0.13, where Thomas has made some
> changes, and I wanted to carry on with his branch, but keep ending up
> with a fork of master where they are not merged yet.
>
> Sorry. I'm new to github.
>
> On 26 June 2012 23:14, Carl Smith <carl.input at gmail.com> wrote:
>> I don't mind a bit of code, but thanks for the heads up. I will try and
>> pitch in to get 0.13 out.
>>
>> On Jun 26, 2012 11:05 PM, "MinRK" <benjaminrk at gmail.com> wrote:
>>>
>>>
>>>
>>> On Tue, Jun 26, 2012 at 3:01 PM, Carl Smith <carl.input at gmail.com> wrote:
>>>>
>>>> I finish work in an hour. I'll have a look at Thomas' PR then. I didn't
>>>> know about quickfix, I'll keep it in mind.
>>>
>>> A bit more specifically, quickfix is usually code or docs where the
>>> solution is known, but nobody has typed it up. Many of these are meant to be
>>> welcoming to new contributors. ?Any documentation issues should be marked
>>> with 'doc', if you don't want to be looking at actual code.
>>>
>>> -MinRK
>>>
>>>
>>>>
>>>> On Jun 26, 2012 10:58 PM, "Fernando Perez" <fperez.net at gmail.com> wrote:
>>>>>
>>>>> On Tue, Jun 26, 2012 at 2:52 PM, Carl Smith <carl.input at gmail.com>
>>>>> wrote:
>>>>> > Can we get a new flag for the issue tracker that indicates that it's
>>>>> > expected to be an issue you can go at without knowing much IPython
>>>>> > voodoo?
>>>>>
>>>>> That does exist, it's called 'quickfix':
>>>>>
>>>>>
>>>>> https://github.com/ipython/ipython/issues?labels=quickfix&milestone=&page=1&state=open
>>>>>
>>>>> > I'm happy to knock out some copy for the site if I can get something
>>>>> > to work
>>>>> > from.
>>>>>
>>>>> That would be great! ?Here is Thomas' PR to get things going:
>>>>>
>>>>> https://github.com/ipython/ipython-website/pull/10
>>>>>
>>>>> Cheers,
>>>>>
>>>>> f
>>>>> _______________________________________________
>>>>> IPython-dev mailing list
>>>>> IPython-dev at scipy.org
>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> IPython-dev mailing list
>>>> IPython-dev at scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>
>>


From ellisonbg at gmail.com  Tue Jun 26 21:10:04 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Tue, 26 Jun 2012 18:10:04 -0700
Subject: [IPython-dev] Notebook filename badness
In-Reply-To: <CAOvn4qj72UNzx9YWQd+=8pofbettzk99XOM3+eEV81A_JJ8zJw@mail.gmail.com>
References: <CAH4pYpSV3Gewh0nsS+j+nhe=xcgqRD7GOU=SkaciY43hujjOaQ@mail.gmail.com>
	<CAOvn4qj72UNzx9YWQd+=8pofbettzk99XOM3+eEV81A_JJ8zJw@mail.gmail.com>
Message-ID: <CAH4pYpTEiG1EzP5s4WMapKXW_D7BxPFhSvVBaHsV13d8nve1hg@mail.gmail.com>

On Tue, Jun 26, 2012 at 5:36 PM, Thomas Kluyver <takowl at gmail.com> wrote:
> On 27 June 2012 01:17, Brian Granger <ellisonbg at gmail.com> wrote:
>> * Because notebook ids are not persisted between sessions of the
>> notebook server, you can't refer to them by URL and reload notebook
>> pages between server restarts.
>
> This may well be stupid, but is there a good reason we can't, with a
> filesystem-based store, use URLs like
> "http://localhost:8888/my_notebook.ipynb"? Even if that simply
> redirects to a UUID-based URL, it would mean there's a predictable way
> to get to them.

This example is a perfect illustration of the problem with the
"notebook name = unique identifier" model:

* Notebook renames become nearly impossible to manage.
  - Once a rename is done, the URL has to be updated.  For that you
need to either i) reload the page or ii) muck with URL rewriting.
  - Even if you can solve that, you can only solve it for the notebook
web page instance where the rename took place.  If you have that
notebook open in another tab, that other tab will not see the rename
and will subsequently write to the old filenames upon save.
  - If a user renames a file while the notebook server is running,
things get into an inconsistent state.
  - I actually coded this up last summer when I got started two
different times and there was no way to make it work acceptably.
  - These problems exist even for a single local user.

* These URLs in practice are not that pretty because they have to be escaped.

* Sharing/publishing becomes impossible:

Alice:  Here Bob, have a look at this cool notebook I created.

Bob:  Alice, I finally got around to looking at the notebook you
shared with me, but I am getting a 404.

Alice:  Hmm, I don't know what happened, I can see it fine.

Bob:  Did you rename it?

Alice:  Oh, crap, here is the new URL.

The reason Google Docs works so well for sharing is that they use
guids in their URLs.  Anyone can change the name at any time.


>> Note, I am not proposing that we do away with the existing notebook manager. We should continue to support it, but we should *not* try to fix its the fundamental problems it has.
>
> The notebook has proven very valuable as a local application, and I
> think we should make it work well for that case as well as the webapp
> case, even if that means some extra complexity in the code. Maybe I
> haven't properly grasped the complexities involved, but the idea that
> we should accept fairly serious problems with local use, and focus on
> it as a web application, leaves a bad taste in my mouth.

What I am proposing would *improve* local use dramatically:

* Persistent URLs that you can bookmark and reload across sessions.
* No more worrying about accidentally renaming/uploading over an
existing notebook.
* A natural place for autosave files.

> Also, I don't think these problems are entirely unique to the file
> system. Notebooks stored in a database still need human readable
> names, and I'd still expect some way to handle conflicts in those.
> Meaningful URLs would also be nice, regardless of the storage used.

When notebook are written to any database'y storage backend, they are
referred to by some guid.  The human readable names don't have to be
unique.  This is true of whether we are using Azure Blob Storage, AWS
3D, mongodb, or a traditional relational db.

The one point that I *don't* like about my proposal is that version
controlling filenames with guids would be ugly.  But this is why we
need to keep our existing notebook manager.  I am also not convinced
we can get creative in terms of how notebooks are version controlled.
Don't know what that looks like, but I think we need to think more
about it.

Cheers,

Brian

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



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


From carl.input at gmail.com  Tue Jun 26 21:11:11 2012
From: carl.input at gmail.com (Carl Smith)
Date: Wed, 27 Jun 2012 02:11:11 +0100
Subject: [IPython-dev] We might actually make 0.13 by June 30,
 jump in to make it possible!
In-Reply-To: <CAP-uhDdvz38jGj2Enzy6rhQLWhdxFwOEHkO47C5bX2xfZOQZmw@mail.gmail.com>
References: <CAHAreOqBH0K1LA371s_CZJo+SS=3MBYx8-GLjdShUVDvs+u6RQ@mail.gmail.com>
	<CAP-uhDfC06xa39UEk3sFgvXAaxGw2LUJqG4T7J2sb7qaGTVtXA@mail.gmail.com>
	<CAHAreOrdt1nCegvd-T4HaZ8ikJ1JspHBNrq9Oyi55yrqenvBZA@mail.gmail.com>
	<CAP-uhDeh+L+dz0WYUCj8NaTCfu0MhTVX++O47QjbrDzVUrsbcg@mail.gmail.com>
	<CAHNn8BXi8vFH+CcbctSPu+rsBE+mYZ8rLf3qcZ1q3j_MJZM7Hg@mail.gmail.com>
	<CAP-uhDdQ61oe7d9KHM6H3VPJG=qZ6ggmVB2N=LOZa+fFhYKNeA@mail.gmail.com>
	<CAP-uhDcPm7SHrzfMi73wEfmZUQmaAZn36MYK=MN0wwMxnpeY3g@mail.gmail.com>
	<CAP-uhDdvz38jGj2Enzy6rhQLWhdxFwOEHkO47C5bX2xfZOQZmw@mail.gmail.com>
Message-ID: <CAP-uhDeWEMDhLsaYYRL-y-5UfH45UCapzULamF6LPmd292y_ig@mail.gmail.com>

Nope. I can't get this to work. I tried editing one of the files in
0.13 and it told me it would fork it for me, but the fork is of
master.

I'm lost now :(

On 27 June 2012 02:08, Carl Smith <carl.input at gmail.com> wrote:
> Ah, figured it I think. False alarm.
>
> On 27 June 2012 02:03, Carl Smith <carl.input at gmail.com> wrote:
>> Can I fork a branch, or branch a branch, on github?
>>
>> I'm looking at ipython-website 0.13, where Thomas has made some
>> changes, and I wanted to carry on with his branch, but keep ending up
>> with a fork of master where they are not merged yet.
>>
>> Sorry. I'm new to github.
>>
>> On 26 June 2012 23:14, Carl Smith <carl.input at gmail.com> wrote:
>>> I don't mind a bit of code, but thanks for the heads up. I will try and
>>> pitch in to get 0.13 out.
>>>
>>> On Jun 26, 2012 11:05 PM, "MinRK" <benjaminrk at gmail.com> wrote:
>>>>
>>>>
>>>>
>>>> On Tue, Jun 26, 2012 at 3:01 PM, Carl Smith <carl.input at gmail.com> wrote:
>>>>>
>>>>> I finish work in an hour. I'll have a look at Thomas' PR then. I didn't
>>>>> know about quickfix, I'll keep it in mind.
>>>>
>>>> A bit more specifically, quickfix is usually code or docs where the
>>>> solution is known, but nobody has typed it up. Many of these are meant to be
>>>> welcoming to new contributors. ?Any documentation issues should be marked
>>>> with 'doc', if you don't want to be looking at actual code.
>>>>
>>>> -MinRK
>>>>
>>>>
>>>>>
>>>>> On Jun 26, 2012 10:58 PM, "Fernando Perez" <fperez.net at gmail.com> wrote:
>>>>>>
>>>>>> On Tue, Jun 26, 2012 at 2:52 PM, Carl Smith <carl.input at gmail.com>
>>>>>> wrote:
>>>>>> > Can we get a new flag for the issue tracker that indicates that it's
>>>>>> > expected to be an issue you can go at without knowing much IPython
>>>>>> > voodoo?
>>>>>>
>>>>>> That does exist, it's called 'quickfix':
>>>>>>
>>>>>>
>>>>>> https://github.com/ipython/ipython/issues?labels=quickfix&milestone=&page=1&state=open
>>>>>>
>>>>>> > I'm happy to knock out some copy for the site if I can get something
>>>>>> > to work
>>>>>> > from.
>>>>>>
>>>>>> That would be great! ?Here is Thomas' PR to get things going:
>>>>>>
>>>>>> https://github.com/ipython/ipython-website/pull/10
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> f
>>>>>> _______________________________________________
>>>>>> IPython-dev mailing list
>>>>>> IPython-dev at scipy.org
>>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> IPython-dev mailing list
>>>>> IPython-dev at scipy.org
>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> IPython-dev mailing list
>>>> IPython-dev at scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>
>>>


From fperez.net at gmail.com  Tue Jun 26 21:17:21 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 26 Jun 2012 18:17:21 -0700
Subject: [IPython-dev] We might actually make 0.13 by June 30,
 jump in to make it possible!
In-Reply-To: <CAP-uhDeWEMDhLsaYYRL-y-5UfH45UCapzULamF6LPmd292y_ig@mail.gmail.com>
References: <CAHAreOqBH0K1LA371s_CZJo+SS=3MBYx8-GLjdShUVDvs+u6RQ@mail.gmail.com>
	<CAP-uhDfC06xa39UEk3sFgvXAaxGw2LUJqG4T7J2sb7qaGTVtXA@mail.gmail.com>
	<CAHAreOrdt1nCegvd-T4HaZ8ikJ1JspHBNrq9Oyi55yrqenvBZA@mail.gmail.com>
	<CAP-uhDeh+L+dz0WYUCj8NaTCfu0MhTVX++O47QjbrDzVUrsbcg@mail.gmail.com>
	<CAHNn8BXi8vFH+CcbctSPu+rsBE+mYZ8rLf3qcZ1q3j_MJZM7Hg@mail.gmail.com>
	<CAP-uhDdQ61oe7d9KHM6H3VPJG=qZ6ggmVB2N=LOZa+fFhYKNeA@mail.gmail.com>
	<CAP-uhDcPm7SHrzfMi73wEfmZUQmaAZn36MYK=MN0wwMxnpeY3g@mail.gmail.com>
	<CAP-uhDdvz38jGj2Enzy6rhQLWhdxFwOEHkO47C5bX2xfZOQZmw@mail.gmail.com>
	<CAP-uhDeWEMDhLsaYYRL-y-5UfH45UCapzULamF6LPmd292y_ig@mail.gmail.com>
Message-ID: <CAHAreOoANmjnyWxWqFAmRC4weVqp0HqcPmQd7OO5Bh0sc6n+oQ@mail.gmail.com>

On Tue, Jun 26, 2012 at 6:11 PM, Carl Smith <carl.input at gmail.com> wrote:
> Nope. I can't get this to work. I tried editing one of the files in
> 0.13 and it told me it would fork it for me, but the fork is of
> master.
>
> I'm lost now :(

Sorry Carl, some quick help but I'm in the middle of a pile of
non-ipython things so I'll have to keep this brief.  Basically you
need to:

1. clik the 'fork' button on the ipython-website repo so you have your own fork
2. clone that fork locally to your computer
3. check out the 0.13 branch (the one Thomas made)
4. make a *new* branch off that one, with your new commits, say '0.13-carl'
5. push that new branch to *your* fork on github
6. got to github, and ask for a pull request from '0.13-carl' in your
repo to '0.13' in the official repo.

This is the standard PR workflow, with only one twist: that you're
branching off a branch other than master, step 3 above.

I hope this sketch gets you going, with a bit of manual
experimentation until you're comfortable with the details.

Cheers,

f


From carl.input at gmail.com  Tue Jun 26 21:26:40 2012
From: carl.input at gmail.com (Carl Smith)
Date: Wed, 27 Jun 2012 02:26:40 +0100
Subject: [IPython-dev] Best approach for uploading files through the
	Notebook?
Message-ID: <CAP-uhDdo1H5UrK=Ne6_N7rSxsgT10UDwVk1o5bXjGHzPEBEgYQ@mail.gmail.com>

Hi all

I was asked... what is the best way to upload data through the IPython
Notebook interface, from the machine running the client, onto the
machine serving the notebook.

This is for NotebookCloud, so there's no option to just use ssh. There
should, if there isn't already, be an easy way to chuck data into a
notebook and have it upload onto the server. There's a few ways it
could be done, and the user has found a workaround, but I just
wondered what you guys thought.


From carl.input at gmail.com  Tue Jun 26 21:28:15 2012
From: carl.input at gmail.com (Carl Smith)
Date: Wed, 27 Jun 2012 02:28:15 +0100
Subject: [IPython-dev] We might actually make 0.13 by June 30,
 jump in to make it possible!
In-Reply-To: <CAHAreOoANmjnyWxWqFAmRC4weVqp0HqcPmQd7OO5Bh0sc6n+oQ@mail.gmail.com>
References: <CAHAreOqBH0K1LA371s_CZJo+SS=3MBYx8-GLjdShUVDvs+u6RQ@mail.gmail.com>
	<CAP-uhDfC06xa39UEk3sFgvXAaxGw2LUJqG4T7J2sb7qaGTVtXA@mail.gmail.com>
	<CAHAreOrdt1nCegvd-T4HaZ8ikJ1JspHBNrq9Oyi55yrqenvBZA@mail.gmail.com>
	<CAP-uhDeh+L+dz0WYUCj8NaTCfu0MhTVX++O47QjbrDzVUrsbcg@mail.gmail.com>
	<CAHNn8BXi8vFH+CcbctSPu+rsBE+mYZ8rLf3qcZ1q3j_MJZM7Hg@mail.gmail.com>
	<CAP-uhDdQ61oe7d9KHM6H3VPJG=qZ6ggmVB2N=LOZa+fFhYKNeA@mail.gmail.com>
	<CAP-uhDcPm7SHrzfMi73wEfmZUQmaAZn36MYK=MN0wwMxnpeY3g@mail.gmail.com>
	<CAP-uhDdvz38jGj2Enzy6rhQLWhdxFwOEHkO47C5bX2xfZOQZmw@mail.gmail.com>
	<CAP-uhDeWEMDhLsaYYRL-y-5UfH45UCapzULamF6LPmd292y_ig@mail.gmail.com>
	<CAHAreOoANmjnyWxWqFAmRC4weVqp0HqcPmQd7OO5Bh0sc6n+oQ@mail.gmail.com>
Message-ID: <CAP-uhDdfnmGmQpiZXhKesioei5htPKXKP3KgNTmynaz68nhRtw@mail.gmail.com>

Cheers Fernando, step 3 is what I needed.

On 27 June 2012 02:17, Fernando Perez <fperez.net at gmail.com> wrote:
> On Tue, Jun 26, 2012 at 6:11 PM, Carl Smith <carl.input at gmail.com> wrote:
>> Nope. I can't get this to work. I tried editing one of the files in
>> 0.13 and it told me it would fork it for me, but the fork is of
>> master.
>>
>> I'm lost now :(
>
> Sorry Carl, some quick help but I'm in the middle of a pile of
> non-ipython things so I'll have to keep this brief. ?Basically you
> need to:
>
> 1. clik the 'fork' button on the ipython-website repo so you have your own fork
> 2. clone that fork locally to your computer
> 3. check out the 0.13 branch (the one Thomas made)
> 4. make a *new* branch off that one, with your new commits, say '0.13-carl'
> 5. push that new branch to *your* fork on github
> 6. got to github, and ask for a pull request from '0.13-carl' in your
> repo to '0.13' in the official repo.
>
> This is the standard PR workflow, with only one twist: that you're
> branching off a branch other than master, step 3 above.
>
> I hope this sketch gets you going, with a bit of manual
> experimentation until you're comfortable with the details.
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev


From fperez.net at gmail.com  Tue Jun 26 21:31:10 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 26 Jun 2012 18:31:10 -0700
Subject: [IPython-dev] Best approach for uploading files through the
	Notebook?
In-Reply-To: <CAP-uhDdo1H5UrK=Ne6_N7rSxsgT10UDwVk1o5bXjGHzPEBEgYQ@mail.gmail.com>
References: <CAP-uhDdo1H5UrK=Ne6_N7rSxsgT10UDwVk1o5bXjGHzPEBEgYQ@mail.gmail.com>
Message-ID: <CAHAreOoaX6c9JuZk03-iPxx4_7qBhozDiPpB3oSrYPReVMv=Rw@mail.gmail.com>

On Tue, Jun 26, 2012 at 6:26 PM, Carl Smith <carl.input at gmail.com> wrote:
> This is for NotebookCloud, so there's no option to just use ssh. There
> should, if there isn't already, be an easy way to chuck data into a
> notebook and have it upload onto the server. There's a few ways it
> could be done, and the user has found a workaround, but I just
> wondered what you guys thought.

Easiest solution: write a magic function, called %upload, that
triggers the javascript to invoke the browser's file upload dialog,
and then saves the files in the notebook directory.

Can be done completely client-side as a magic without any changes to
the notebook server.

Cheers,

f


From carl.input at gmail.com  Tue Jun 26 21:44:55 2012
From: carl.input at gmail.com (Carl Smith)
Date: Wed, 27 Jun 2012 02:44:55 +0100
Subject: [IPython-dev] Best approach for uploading files through the
	Notebook?
In-Reply-To: <CAHAreOoaX6c9JuZk03-iPxx4_7qBhozDiPpB3oSrYPReVMv=Rw@mail.gmail.com>
References: <CAP-uhDdo1H5UrK=Ne6_N7rSxsgT10UDwVk1o5bXjGHzPEBEgYQ@mail.gmail.com>
	<CAHAreOoaX6c9JuZk03-iPxx4_7qBhozDiPpB3oSrYPReVMv=Rw@mail.gmail.com>
Message-ID: <CAP-uhDdCzJw2DuvyG=-9fxpVGFTqe2zmo4xGdMVpEMknHtYpOg@mail.gmail.com>

Nice one, Fernando.

Before long, we'll need to be able to download files too. It might be
nice to have a graphical file browser with these kinds of features
that you can open with a magic. I'll think about it some more and
maybe write something later. For now, I think your suggestion will
keep people happy.

On 27 June 2012 02:31, Fernando Perez <fperez.net at gmail.com> wrote:
> On Tue, Jun 26, 2012 at 6:26 PM, Carl Smith <carl.input at gmail.com> wrote:
>> This is for NotebookCloud, so there's no option to just use ssh. There
>> should, if there isn't already, be an easy way to chuck data into a
>> notebook and have it upload onto the server. There's a few ways it
>> could be done, and the user has found a workaround, but I just
>> wondered what you guys thought.
>
> Easiest solution: write a magic function, called %upload, that
> triggers the javascript to invoke the browser's file upload dialog,
> and then saves the files in the notebook directory.
>
> Can be done completely client-side as a magic without any changes to
> the notebook server.
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev


From carl.input at gmail.com  Tue Jun 26 21:52:07 2012
From: carl.input at gmail.com (Carl Smith)
Date: Wed, 27 Jun 2012 02:52:07 +0100
Subject: [IPython-dev] Best approach for uploading files through the
	Notebook?
In-Reply-To: <CAP-uhDdCzJw2DuvyG=-9fxpVGFTqe2zmo4xGdMVpEMknHtYpOg@mail.gmail.com>
References: <CAP-uhDdo1H5UrK=Ne6_N7rSxsgT10UDwVk1o5bXjGHzPEBEgYQ@mail.gmail.com>
	<CAHAreOoaX6c9JuZk03-iPxx4_7qBhozDiPpB3oSrYPReVMv=Rw@mail.gmail.com>
	<CAP-uhDdCzJw2DuvyG=-9fxpVGFTqe2zmo4xGdMVpEMknHtYpOg@mail.gmail.com>
Message-ID: <CAP-uhDfdo0nfjKi4aBwaaK1y-yc+gJtN4R0Mo8p=bUgwtQ0hKA@mail.gmail.com>

Just to be clear; I mean as a HTML widget you can display, not as a
feature of the Notebook itself.

Thanks again

Carl


From fperez.net at gmail.com  Tue Jun 26 21:57:34 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 26 Jun 2012 18:57:34 -0700
Subject: [IPython-dev] Best approach for uploading files through the
	Notebook?
In-Reply-To: <CAP-uhDfdo0nfjKi4aBwaaK1y-yc+gJtN4R0Mo8p=bUgwtQ0hKA@mail.gmail.com>
References: <CAP-uhDdo1H5UrK=Ne6_N7rSxsgT10UDwVk1o5bXjGHzPEBEgYQ@mail.gmail.com>
	<CAHAreOoaX6c9JuZk03-iPxx4_7qBhozDiPpB3oSrYPReVMv=Rw@mail.gmail.com>
	<CAP-uhDdCzJw2DuvyG=-9fxpVGFTqe2zmo4xGdMVpEMknHtYpOg@mail.gmail.com>
	<CAP-uhDfdo0nfjKi4aBwaaK1y-yc+gJtN4R0Mo8p=bUgwtQ0hKA@mail.gmail.com>
Message-ID: <CAHAreOrVXqtV5OxVPEdvJCs4vQvSfrbPi5wQ3t2ZwzARpbDK1A@mail.gmail.com>

On Tue, Jun 26, 2012 at 6:52 PM, Carl Smith <carl.input at gmail.com> wrote:
> Just to be clear; I mean as a HTML widget you can display, not as a
> feature of the Notebook itself.

Sure, that would also work easily. %download.


From ellisonbg at gmail.com  Tue Jun 26 21:58:28 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Tue, 26 Jun 2012 18:58:28 -0700
Subject: [IPython-dev] Best approach for uploading files through the
	Notebook?
In-Reply-To: <CAHAreOoaX6c9JuZk03-iPxx4_7qBhozDiPpB3oSrYPReVMv=Rw@mail.gmail.com>
References: <CAP-uhDdo1H5UrK=Ne6_N7rSxsgT10UDwVk1o5bXjGHzPEBEgYQ@mail.gmail.com>
	<CAHAreOoaX6c9JuZk03-iPxx4_7qBhozDiPpB3oSrYPReVMv=Rw@mail.gmail.com>
Message-ID: <CAH4pYpRErLQNcp4n_etP+S+4FV2Onfh=btR+r62xDnBXBapxbw@mail.gmail.com>

On Tue, Jun 26, 2012 at 6:31 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Tue, Jun 26, 2012 at 6:26 PM, Carl Smith <carl.input at gmail.com> wrote:
>> This is for NotebookCloud, so there's no option to just use ssh. There
>> should, if there isn't already, be an easy way to chuck data into a
>> notebook and have it upload onto the server. There's a few ways it
>> could be done, and the user has found a workaround, but I just
>> wondered what you guys thought.
>
> Easiest solution: write a magic function, called %upload, that
> triggers the javascript to invoke the browser's file upload dialog,
> and then saves the files in the notebook directory.

But saving the file requires a server side handler.  We would have to
make changes to both sides to do this.

> Can be done completely client-side as a magic without any changes to
> the notebook server.
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



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


From fperez.net at gmail.com  Tue Jun 26 22:09:40 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 26 Jun 2012 19:09:40 -0700
Subject: [IPython-dev] Best approach for uploading files through the
	Notebook?
In-Reply-To: <CAH4pYpRErLQNcp4n_etP+S+4FV2Onfh=btR+r62xDnBXBapxbw@mail.gmail.com>
References: <CAP-uhDdo1H5UrK=Ne6_N7rSxsgT10UDwVk1o5bXjGHzPEBEgYQ@mail.gmail.com>
	<CAHAreOoaX6c9JuZk03-iPxx4_7qBhozDiPpB3oSrYPReVMv=Rw@mail.gmail.com>
	<CAH4pYpRErLQNcp4n_etP+S+4FV2Onfh=btR+r62xDnBXBapxbw@mail.gmail.com>
Message-ID: <CAHAreOpzRPDDaLHy5Vnai7wbAw2UAJ3Sim0tOyz2tAtYbpnQ-Q@mail.gmail.com>

On Tue, Jun 26, 2012 at 6:58 PM, Brian Granger <ellisonbg at gmail.com> wrote:
> But saving the file requires a server side handler. ?We would have to
> make changes to both sides to do this.

Ah, yes, I forgot to consider the request would need to trigger a
handler when posted to the server...


From ellisonbg at gmail.com  Tue Jun 26 23:05:37 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Tue, 26 Jun 2012 20:05:37 -0700
Subject: [IPython-dev] SVG figures status report
In-Reply-To: <4FEA1FDC.3030606@creativetrax.com>
References: <20120624180123.GL6159@mcelrath.org>
	<CAHAreOr2_DfwJBoF1UskayXhVdWPykZ2z2zPjJ0Dvaj1CW6Hog@mail.gmail.com>
	<4FE96830.1080803@gmail.com>
	<CAH4pYpQJgoLJvEoqeQOyWrM+K094uCRe5X5yTO79PVKspjXxVA@mail.gmail.com>
	<4FE9DEF3.1060908@creativetrax.com> <4FE9F4F8.7010404@gmail.com>
	<4FEA1FDC.3030606@creativetrax.com>
Message-ID: <CAH4pYpRwkHYnaQ7_Mpd9ahWV1XGp7+yePRMzd+NpLTqEwZgJSw@mail.gmail.com>

I don't regularly subscribe to mpl-devel, but if there is a discussion
there I could join for a while.

Brian

On Tue, Jun 26, 2012 at 1:47 PM, Jason Grout
<jason-sage at creativetrax.com> wrote:
> On 6/26/12 12:44 PM, Zolt?n V?r?s wrote:
>> In that case, should we try to move this whole discussion to the
>> mpl-devel list? Or do you think that the ideas here and at sage still
>> need some ironing-out?
>
> I think ironing the ideas out certainly needs to be done. ?I don't have
> an extremely clear idea of exactly what I want, for example, and others
> have noted that we need to take a step back and see exactly what we
> want. ?For example, I agree that some sort of tracing/coordinate display
> (no communication back to the server) would already be a huge help for Sage.
>
> I think it should move to mpl-developers anyway, as Brian alluded when
> he said someone in mpl would have to spearhead it. ?Brian, Fernando, or
> Min, do you by chance happen to subscribe to mpl-dev?
>
> Jason
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



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


From carl.input at gmail.com  Wed Jun 27 02:48:12 2012
From: carl.input at gmail.com (Carl Smith)
Date: Wed, 27 Jun 2012 07:48:12 +0100
Subject: [IPython-dev] Best approach for uploading files through the
	Notebook?
In-Reply-To: <CAHAreOpzRPDDaLHy5Vnai7wbAw2UAJ3Sim0tOyz2tAtYbpnQ-Q@mail.gmail.com>
References: <CAP-uhDdo1H5UrK=Ne6_N7rSxsgT10UDwVk1o5bXjGHzPEBEgYQ@mail.gmail.com>
	<CAHAreOoaX6c9JuZk03-iPxx4_7qBhozDiPpB3oSrYPReVMv=Rw@mail.gmail.com>
	<CAH4pYpRErLQNcp4n_etP+S+4FV2Onfh=btR+r62xDnBXBapxbw@mail.gmail.com>
	<CAHAreOpzRPDDaLHy5Vnai7wbAw2UAJ3Sim0tOyz2tAtYbpnQ-Q@mail.gmail.com>
Message-ID: <CAP-uhDeo3fjpJiborG-ux8f6wYK=dsmLMhvXCmOaM2xbxJR-EA@mail.gmail.com>

I had a go at it last night, but didn't get very far. Brian's right of
course, but that wasn't the only problem.

I was looking more at displaying a download link for each file in the
current dir, rather than upping stuff, but got nowhere before bedtime.

I'll have another go at this today. I think it'll be important for NBC. If
this is something you think might go into IPython, it might be good to look
at doing something properly, else I'll be happy with a hack for now to be
honest.
On Jun 27, 2012 3:10 AM, "Fernando Perez" <fperez.net at gmail.com> wrote:

> On Tue, Jun 26, 2012 at 6:58 PM, Brian Granger <ellisonbg at gmail.com>
> wrote:
> > But saving the file requires a server side handler.  We would have to
> > make changes to both sides to do this.
>
> Ah, yes, I forgot to consider the request would need to trigger a
> handler when posted to the server...
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120627/96f55527/attachment.html>

From bussonniermatthias at gmail.com  Wed Jun 27 03:06:13 2012
From: bussonniermatthias at gmail.com (Matthias BUSSONNIER)
Date: Wed, 27 Jun 2012 09:06:13 +0200
Subject: [IPython-dev] Best approach for uploading files through the
	Notebook?
In-Reply-To: <CAH4pYpRErLQNcp4n_etP+S+4FV2Onfh=btR+r62xDnBXBapxbw@mail.gmail.com>
References: <CAP-uhDdo1H5UrK=Ne6_N7rSxsgT10UDwVk1o5bXjGHzPEBEgYQ@mail.gmail.com>
	<CAHAreOoaX6c9JuZk03-iPxx4_7qBhozDiPpB3oSrYPReVMv=Rw@mail.gmail.com>
	<CAH4pYpRErLQNcp4n_etP+S+4FV2Onfh=btR+r62xDnBXBapxbw@mail.gmail.com>
Message-ID: <A3C7C2B8-7E6A-475F-8930-44CA1A6BFB64@gmail.com>

> 
> But saving the file requires a server side handler.  We would have to
> make changes to both sides to do this.

If you want to upload on kernel CWD , couldn't you just use the widget <-> kernel API to send data to the kernel that write it to the disk, bypassing the server. 
something like 

%upload insert a function `foo_random_string` in current namespace and publish a JS upload widget.
upload widget have `foo_random_string` as callback to upload data.
once a file is uploaded `foo_random_string` send a signal to the widget, that changed to `file uploaded` and ask the kernel to del `foo_random_string`

The other things we might want to do is expose nb-uuidd/cwd/  as current **kernel** working directory.
-- 
Matthias



From bussonniermatthias at gmail.com  Wed Jun 27 03:24:30 2012
From: bussonniermatthias at gmail.com (Matthias BUSSONNIER)
Date: Wed, 27 Jun 2012 09:24:30 +0200
Subject: [IPython-dev] Notebook filename badness
In-Reply-To: <CAH4pYpTEiG1EzP5s4WMapKXW_D7BxPFhSvVBaHsV13d8nve1hg@mail.gmail.com>
References: <CAH4pYpSV3Gewh0nsS+j+nhe=xcgqRD7GOU=SkaciY43hujjOaQ@mail.gmail.com>
	<CAOvn4qj72UNzx9YWQd+=8pofbettzk99XOM3+eEV81A_JJ8zJw@mail.gmail.com>
	<CAH4pYpTEiG1EzP5s4WMapKXW_D7BxPFhSvVBaHsV13d8nve1hg@mail.gmail.com>
Message-ID: <19A14C1C-F2F3-4679-BD9F-AE310B71595E@gmail.com>


Le 27 juin 2012 ? 02:36, Thomas Kluyver a ?crit :

> "http://localhost:8888/my_notebook.ipynb"? Even if that simply
> redirects to a UUID-based URL, it would mean there's a predictable way
> to get to them.

I think this is a good trade-off if there is a redirection, that then rewrite to UUID.
People won't be able to bookmark or copy/paste without writing it by themselves 

Le 27 juin 2012 ? 02:17, Brian Granger a ?crit :

> I propose a simple fix to all of this:
> 
> * We create a new notebook manager that stores notebooks in a hidden
> .ipynb directory.  I guess we could also use a visible subdir as well.
> * In that directory, we use the notebook_id as the filename:
> [notebook_id].ipynb
I get the same idea when thinking about a git backend. i'mm name it with a ending D for directory
My concern was, with a git backend, do we want to keep a per directory or per file history.
if it's per file, we might want to consider cwd/.ipynbd/nb-uuid as a directory that can also contains a .git folder.

> * Each time the notebook server restarts, it reads the notebook_ids
> and notebook names.  This will ensure that the notebook_ids are always
> the same.

If you do it only at restart you might start to have complex logic to deal with rename/new notebook/ copy/paste ro-server running in the same directory.
Especially if we start having the server that can change cwd.

I would have gone for checking the content of the .ipynbd folder when there is a request on a specific file...

I'm not quite sure of how you'll resolve people that copy notebook with the file system, as they will get the same UUID in them, but I might have missed a detail.



From takowl at gmail.com  Wed Jun 27 07:17:31 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Wed, 27 Jun 2012 12:17:31 +0100
Subject: [IPython-dev] Notebook filename badness
In-Reply-To: <CAH4pYpTEiG1EzP5s4WMapKXW_D7BxPFhSvVBaHsV13d8nve1hg@mail.gmail.com>
References: <CAH4pYpSV3Gewh0nsS+j+nhe=xcgqRD7GOU=SkaciY43hujjOaQ@mail.gmail.com>
	<CAOvn4qj72UNzx9YWQd+=8pofbettzk99XOM3+eEV81A_JJ8zJw@mail.gmail.com>
	<CAH4pYpTEiG1EzP5s4WMapKXW_D7BxPFhSvVBaHsV13d8nve1hg@mail.gmail.com>
Message-ID: <CAOvn4qjhALLN7W2h+K+NPtZPYCVZWNkt9-hroa=+JCG4iNU1KQ@mail.gmail.com>

On 27 June 2012 02:10, Brian Granger <ellisonbg at gmail.com> wrote:
> What I am proposing would *improve* local use dramatically:
>
> * Persistent URLs that you can bookmark and reload across sessions.
> * No more worrying about accidentally renaming/uploading over an
> existing notebook.
> * A natural place for autosave files.

But as a local application, I expect it to work with regular files in
normal locations on my filesystem. Our intention was 'directory as
project' - you can have your notebook files alongside data files and
Python modules. Eventually, I'd like to be able to double click the
ipynb files in my file manager to load them, rather than having to
load up our 'notebook list' as a file manager.

This approach has lots of advantages that I don't think we want to
throw away. You can easily put a project in version control, or keep
it in Dropbox or similar services. You can quickly grab the file and
attach it to an email. You can easily back up the project folder.
Notebooks tucked away in a separate folder and named by meaningless
UUIDs would be much less convenient in many ways.

Perhaps I can suggest an alternative approach: in 'local application'
mode, we don't try to offer a notebook manager. It's never going to be
as good as native file managers, and we're not really interested in
reimplementing that functionality. If you want to copy notebooks,
delete them, etc., you do it in your file manager (or terminal, if you
prefer). It would still need to detect conflicts when you 'save as'
from the notebook interface, but I'm sure we can make that work.

Thanks,
Thomas


From takowl at gmail.com  Wed Jun 27 07:52:41 2012
From: takowl at gmail.com (Thomas Kluyver)
Date: Wed, 27 Jun 2012 12:52:41 +0100
Subject: [IPython-dev] Notebook filename badness
In-Reply-To: <CAOvn4qjhALLN7W2h+K+NPtZPYCVZWNkt9-hroa=+JCG4iNU1KQ@mail.gmail.com>
References: <CAH4pYpSV3Gewh0nsS+j+nhe=xcgqRD7GOU=SkaciY43hujjOaQ@mail.gmail.com>
	<CAOvn4qj72UNzx9YWQd+=8pofbettzk99XOM3+eEV81A_JJ8zJw@mail.gmail.com>
	<CAH4pYpTEiG1EzP5s4WMapKXW_D7BxPFhSvVBaHsV13d8nve1hg@mail.gmail.com>
	<CAOvn4qjhALLN7W2h+K+NPtZPYCVZWNkt9-hroa=+JCG4iNU1KQ@mail.gmail.com>
Message-ID: <CAOvn4qh6hxhjxFfVbP5QBiwZCB-NFcojB-sgOAY+7yrBm+JRwQ@mail.gmail.com>

Perhaps it will help to take a step back in this discussion.

At present, the notebook is useful either running locally or running
as a web application. People are using both, each has some
awkwardness, as you'd expect from something that was only released a
few months ago. On the local side, there are the problems with file
handling we've already discussed, while the web app lacks a proper
multi-user model for now.

As I understand it, what you're suggesting is that we steam ahead with
developing it as a web app, and give local users the choice of:
- Use files as we do already, but don't expect the problems to get fixed
- Use it like a web app running locally, and more or less ignore that
it creates files to store the notebooks (i.e. the hidden directory you
suggest)

My feeling is that the local app is an important but very different
use case, and we need to accommodate this properly. Ultimately, I
think we will need two different modes, or even two different
applications - perhaps "ipython notebook" and "ipython nbserver". It
will be a bit more code to maintain, but I think the benefit of
supporting both use cases well is worth the extra complexity.

Thanks,
Thomas


From dave.hirschfeld at gmail.com  Wed Jun 27 08:07:56 2012
From: dave.hirschfeld at gmail.com (Dave Hirschfeld)
Date: Wed, 27 Jun 2012 12:07:56 +0000 (UTC)
Subject: [IPython-dev] Notebook filename badness
References: <CAH4pYpSV3Gewh0nsS+j+nhe=xcgqRD7GOU=SkaciY43hujjOaQ@mail.gmail.com>
	<CAOvn4qj72UNzx9YWQd+=8pofbettzk99XOM3+eEV81A_JJ8zJw@mail.gmail.com>
	<CAH4pYpTEiG1EzP5s4WMapKXW_D7BxPFhSvVBaHsV13d8nve1hg@mail.gmail.com>
	<CAOvn4qjhALLN7W2h+K+NPtZPYCVZWNkt9-hroa=+JCG4iNU1KQ@mail.gmail.com>
Message-ID: <loom.20120627T134545-444@post.gmane.org>

Thomas Kluyver <takowl <at> gmail.com> writes:

> 
> On 27 June 2012 02:10, Brian Granger <ellisonbg <at> gmail.com> wrote:
> > What I am proposing would *improve* local use dramatically:
> >
> > * Persistent URLs that you can bookmark and reload across sessions.
> > * No more worrying about accidentally renaming/uploading over an
> > existing notebook.
> > * A natural place for autosave files.
> 
> But as a local application, I expect it to work with regular files in
> normal locations on my filesystem. Our intention was 'directory as
> project' - you can have your notebook files alongside data files and
> Python modules. Eventually, I'd like to be able to double click the
> ipynb files in my file manager to load them, rather than having to
> load up our 'notebook list' as a file manager.
>
> This approach has lots of advantages that I don't think we want to
> throw away. You can easily put a project in version control, or keep
> it in Dropbox or similar services. You can quickly grab the file and
> attach it to an email. You can easily back up the project folder.
> Notebooks tucked away in a separate folder and named by meaningless
> UUIDs would be much less convenient in many ways.
>
> Perhaps I can suggest an alternative approach: in 'local application'
> mode, we don't try to offer a notebook manager. It's never going to be
> as good as native file managers, and we're not really interested in
> reimplementing that functionality. If you want to copy notebooks,
> delete them, etc., you do it in your file manager (or terminal, if you
> prefer). It would still need to detect conflicts when you 'save as'
> from the notebook interface, but I'm sure we can make that work.

+1

Just a couple of comments from a user, take them as you will:

In our team we're quite often using notebooks to document our work on various
topics. Collaboration quite often takes the form of emailing the .ipynb
file to other team members so having it as a normal, sensibly named file is 
important so that we know which of dozens of notebooks is the correct one to 
send.

I think the guid from a full path name is sensible for this local working 
scenario - if you're silly enough to work on the same notebook in two 
different tabs after renaming the file in one then the pain of merging the 
divergent .ipynb files will be a salutory lesson for in future!

In this use case I'm also very interested in being able to open a .ipynb file 
locally without having to go through the file manager frontend. As Thomas 
mentioned, when it's local it's easy to manage the files in windows explorer (or 
equivalent) and when you've been sent a file it's (very marginally) easier to be 
able to open it directly rather than hunt for it in a list.


Regards,
Dave



From carl.input at gmail.com  Wed Jun 27 08:12:17 2012
From: carl.input at gmail.com (Carl Smith)
Date: Wed, 27 Jun 2012 13:12:17 +0100
Subject: [IPython-dev] Notebook filename badness
In-Reply-To: <CAOvn4qjhALLN7W2h+K+NPtZPYCVZWNkt9-hroa=+JCG4iNU1KQ@mail.gmail.com>
References: <CAH4pYpSV3Gewh0nsS+j+nhe=xcgqRD7GOU=SkaciY43hujjOaQ@mail.gmail.com>
	<CAOvn4qj72UNzx9YWQd+=8pofbettzk99XOM3+eEV81A_JJ8zJw@mail.gmail.com>
	<CAH4pYpTEiG1EzP5s4WMapKXW_D7BxPFhSvVBaHsV13d8nve1hg@mail.gmail.com>
	<CAOvn4qjhALLN7W2h+K+NPtZPYCVZWNkt9-hroa=+JCG4iNU1KQ@mail.gmail.com>
Message-ID: <CAP-uhDduubRFehV0vSh2-Nj9R0r86VZBr+gX-Lqi1p4Av_qFGw@mail.gmail.com>

Hi

I've been discussing similar issues on a different thread. My
impression is that IPython has issues with file management in general,
not just files to do with projects, but the whole persistency
abstraction is getting messy. I don't expect to ever see the IPython
File Manager, and I can't see how it'd solve many of the problems
anyway, but it does seem worthwhile exploring the broader issue of
file systems, cloud storage, working directories, and so on, and
evaluating what can be done.

Just my two pennies.

Carl

On 27 June 2012 12:17, Thomas Kluyver <takowl at gmail.com> wrote:
> On 27 June 2012 02:10, Brian Granger <ellisonbg at gmail.com> wrote:
>> What I am proposing would *improve* local use dramatically:
>>
>> * Persistent URLs that you can bookmark and reload across sessions.
>> * No more worrying about accidentally renaming/uploading over an
>> existing notebook.
>> * A natural place for autosave files.
>
> But as a local application, I expect it to work with regular files in
> normal locations on my filesystem. Our intention was 'directory as
> project' - you can have your notebook files alongside data files and
> Python modules. Eventually, I'd like to be able to double click the
> ipynb files in my file manager to load them, rather than having to
> load up our 'notebook list' as a file manager.
>
> This approach has lots of advantages that I don't think we want to
> throw away. You can easily put a project in version control, or keep
> it in Dropbox or similar services. You can quickly grab the file and
> attach it to an email. You can easily back up the project folder.
> Notebooks tucked away in a separate folder and named by meaningless
> UUIDs would be much less convenient in many ways.
>
> Perhaps I can suggest an alternative approach: in 'local application'
> mode, we don't try to offer a notebook manager. It's never going to be
> as good as native file managers, and we're not really interested in
> reimplementing that functionality. If you want to copy notebooks,
> delete them, etc., you do it in your file manager (or terminal, if you
> prefer). It would still need to detect conflicts when you 'save as'
> from the notebook interface, but I'm sure we can make that work.
>
> Thanks,
> Thomas
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev


From carl.input at gmail.com  Wed Jun 27 08:29:48 2012
From: carl.input at gmail.com (Carl Smith)
Date: Wed, 27 Jun 2012 13:29:48 +0100
Subject: [IPython-dev] Notebook filename badness
In-Reply-To: <CAP-uhDduubRFehV0vSh2-Nj9R0r86VZBr+gX-Lqi1p4Av_qFGw@mail.gmail.com>
References: <CAH4pYpSV3Gewh0nsS+j+nhe=xcgqRD7GOU=SkaciY43hujjOaQ@mail.gmail.com>
	<CAOvn4qj72UNzx9YWQd+=8pofbettzk99XOM3+eEV81A_JJ8zJw@mail.gmail.com>
	<CAH4pYpTEiG1EzP5s4WMapKXW_D7BxPFhSvVBaHsV13d8nve1hg@mail.gmail.com>
	<CAOvn4qjhALLN7W2h+K+NPtZPYCVZWNkt9-hroa=+JCG4iNU1KQ@mail.gmail.com>
	<CAP-uhDduubRFehV0vSh2-Nj9R0r86VZBr+gX-Lqi1p4Av_qFGw@mail.gmail.com>
Message-ID: <CAP-uhDczT_3pGW72Ff7Fv8woA_cUL5FCedyn3w4BLxxt+2asDA@mail.gmail.com>

I'm not suggesting IPython solve all these issues, just look at the bigger
picture a bit before trying to fix each issue one at a time.
On Jun 27, 2012 1:12 PM, "Carl Smith" <carl.input at gmail.com> wrote:

> Hi
>
> I've been discussing similar issues on a different thread. My
> impression is that IPython has issues with file management in general,
> not just files to do with projects, but the whole persistency
> abstraction is getting messy. I don't expect to ever see the IPython
> File Manager, and I can't see how it'd solve many of the problems
> anyway, but it does seem worthwhile exploring the broader issue of
> file systems, cloud storage, working directories, and so on, and
> evaluating what can be done.
>
> Just my two pennies.
>
> Carl
>
> On 27 June 2012 12:17, Thomas Kluyver <takowl at gmail.com> wrote:
> > On 27 June 2012 02:10, Brian Granger <ellisonbg at gmail.com> wrote:
> >> What I am proposing would *improve* local use dramatically:
> >>
> >> * Persistent URLs that you can bookmark and reload across sessions.
> >> * No more worrying about accidentally renaming/uploading over an
> >> existing notebook.
> >> * A natural place for autosave files.
> >
> > But as a local application, I expect it to work with regular files in
> > normal locations on my filesystem. Our intention was 'directory as
> > project' - you can have your notebook files alongside data files and
> > Python modules. Eventually, I'd like to be able to double click the
> > ipynb files in my file manager to load them, rather than having to
> > load up our 'notebook list' as a file manager.
> >
> > This approach has lots of advantages that I don't think we want to
> > throw away. You can easily put a project in version control, or keep
> > it in Dropbox or similar services. You can quickly grab the file and
> > attach it to an email. You can easily back up the project folder.
> > Notebooks tucked away in a separate folder and named by meaningless
> > UUIDs would be much less convenient in many ways.
> >
> > Perhaps I can suggest an alternative approach: in 'local application'
> > mode, we don't try to offer a notebook manager. It's never going to be
> > as good as native file managers, and we're not really interested in
> > reimplementing that functionality. If you want to copy notebooks,
> > delete them, etc., you do it in your file manager (or terminal, if you
> > prefer). It would still need to detect conflicts when you 'save as'
> > from the notebook interface, but I'm sure we can make that work.
> >
> > Thanks,
> > Thomas
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120627/2100edc0/attachment.html>

From mdroe at stsci.edu  Wed Jun 27 11:09:53 2012
From: mdroe at stsci.edu (Michael Droettboom)
Date: Wed, 27 Jun 2012 11:09:53 -0400
Subject: [IPython-dev] SVG figures status report
In-Reply-To: <CAH4pYpRwkHYnaQ7_Mpd9ahWV1XGp7+yePRMzd+NpLTqEwZgJSw@mail.gmail.com>
References: <20120624180123.GL6159@mcelrath.org>
	<CAHAreOr2_DfwJBoF1UskayXhVdWPykZ2z2zPjJ0Dvaj1CW6Hog@mail.gmail.com>
	<4FE96830.1080803@gmail.com>
	<CAH4pYpQJgoLJvEoqeQOyWrM+K094uCRe5X5yTO79PVKspjXxVA@mail.gmail.com>
	<4FE9DEF3.1060908@creativetrax.com> <4FE9F4F8.7010404@gmail.com>
	<4FEA1FDC.3030606@creativetrax.com>
	<CAH4pYpRwkHYnaQ7_Mpd9ahWV1XGp7+yePRMzd+NpLTqEwZgJSw@mail.gmail.com>
Message-ID: <4FEB2241.1030309@stsci.edu>

All,

I just read through this thread, and there's some really good findings 
and ideas here.  I agree it may make sense to move this over to the mpl 
list.

It's interesting to read about the slowdown when large amounts of SVG 
are on the page.  One of the advantages of SVG over Canvas is that it 
has persistent objects, so updates to the tree use less javascript 
computation or network bandwidth (depending on how things are done).  Of 
course, the downside is that there's lots of persistent DOM objects ;)  
I like the suggestion of "freezing/unfreezing" SVG on the fly -- that's 
definitely worth further investigation.

As stated elsewhere in this thread, one of the sticking points of 
getting interactive plotting features in IPython has been just around 
defining exactly we want out of interactivity.  In my experiments using 
SVG, I focused around panning and zooming and how all of the sometimes 
significant things that happen when you do that can both a) remain on 
the Python side for maximum flexibility and b) require minimal bandwidth 
between the kernel and the browser.  That proves to be rather tricky.  
Instead, as has been suggested in this thread, perhaps what we should do 
is focus on the easier aspects of interactivity, such as coordinate 
display and basic element picking first.  Or at least get some sort of 
prioritized list of what needs to happen.  With these easier things, 
it's also less relevant whether we're using PNG or SVG (or remains a 
user option).

Mike

On 06/26/2012 11:05 PM, Brian Granger wrote:
> I don't regularly subscribe to mpl-devel, but if there is a discussion
> there I could join for a while.
>
> Brian
>
> On Tue, Jun 26, 2012 at 1:47 PM, Jason Grout
> <jason-sage at creativetrax.com> wrote:
>> On 6/26/12 12:44 PM, Zolt?n V?r?s wrote:
>>> In that case, should we try to move this whole discussion to the
>>> mpl-devel list? Or do you think that the ideas here and at sage still
>>> need some ironing-out?
>> I think ironing the ideas out certainly needs to be done.  I don't have
>> an extremely clear idea of exactly what I want, for example, and others
>> have noted that we need to take a step back and see exactly what we
>> want.  For example, I agree that some sort of tracing/coordinate display
>> (no communication back to the server) would already be a huge help for Sage.
>>
>> I think it should move to mpl-developers anyway, as Brian alluded when
>> he said someone in mpl would have to spearhead it.  Brian, Fernando, or
>> Min, do you by chance happen to subscribe to mpl-dev?
>>
>> Jason
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>




From ellisonbg at gmail.com  Wed Jun 27 12:34:15 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Wed, 27 Jun 2012 09:34:15 -0700
Subject: [IPython-dev] Best approach for uploading files through the
	Notebook?
In-Reply-To: <A3C7C2B8-7E6A-475F-8930-44CA1A6BFB64@gmail.com>
References: <CAP-uhDdo1H5UrK=Ne6_N7rSxsgT10UDwVk1o5bXjGHzPEBEgYQ@mail.gmail.com>
	<CAHAreOoaX6c9JuZk03-iPxx4_7qBhozDiPpB3oSrYPReVMv=Rw@mail.gmail.com>
	<CAH4pYpRErLQNcp4n_etP+S+4FV2Onfh=btR+r62xDnBXBapxbw@mail.gmail.com>
	<A3C7C2B8-7E6A-475F-8930-44CA1A6BFB64@gmail.com>
Message-ID: <CAH4pYpTkq=LibD4s4ad_jmyA_Ex59VxbGCZe2QxeQu-_zt_Drg@mail.gmail.com>

On Wed, Jun 27, 2012 at 12:06 AM, Matthias BUSSONNIER
<bussonniermatthias at gmail.com> wrote:
>>
>> But saving the file requires a server side handler. ?We would have to
>> make changes to both sides to do this.
>
> If you want to upload on kernel CWD , couldn't you just use the widget <-> kernel API to send data to the kernel that write it to the disk, bypassing the server.
> something like

Yes, you are right that we could do this!  That would be fantastic!
For that call we should use silent=True.

> %upload insert a function `foo_random_string` in current namespace and publish a JS upload widget.
> upload widget have `foo_random_string` as callback to upload data.
> once a file is uploaded `foo_random_string` send a signal to the widget, that changed to `file uploaded` and ask the kernel to del `foo_random_string`



> The other things we might want to do is expose nb-uuidd/cwd/ ?as current **kernel** working directory.
> --
> Matthias
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



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


From cekees at gmail.com  Wed Jun 27 13:01:30 2012
From: cekees at gmail.com (Chris Kees)
Date: Wed, 27 Jun 2012 12:01:30 -0500
Subject: [IPython-dev] notebook examples for presentation
Message-ID: <CAOVFbFi-0soY_-9HSfUCL-U9WcWDEJSB2OW1m2q06sbL+r0Amg@mail.gmail.com>

Hi,

I'm looking for some presentable ipython notebooks that I can put on
my ipython sandbox to show off some of the following capabilities:

-Analysis  on data sets from  multiple (large) external databases
-Pulling in google earth imagery and doing something real with it like
overlaying additional information
-Machine learning applied to large databases
-Symbolic math supporting some kind of analysis

Apologies in advance for blatant crowd sourcing. I've got the opportunity to
present python and IPython as a core technology that my lab will
consider as a part of a larger computational modeling strategy. I have
my own examples of some of parallel models running in the notebooks
but am weak on the items above, which I think will continue to grow in
relevance to the kind of engineering analysis and R&D that is part of
my lab's core business.

Thanks,
Chris


From asmeurer at gmail.com  Wed Jun 27 13:36:24 2012
From: asmeurer at gmail.com (Aaron Meurer)
Date: Wed, 27 Jun 2012 11:36:24 -0600
Subject: [IPython-dev] notebook examples for presentation
In-Reply-To: <CAOVFbFi-0soY_-9HSfUCL-U9WcWDEJSB2OW1m2q06sbL+r0Amg@mail.gmail.com>
References: <CAOVFbFi-0soY_-9HSfUCL-U9WcWDEJSB2OW1m2q06sbL+r0Amg@mail.gmail.com>
Message-ID: <7255819951759720550@unknownmsgid>

On Jun 27, 2012, at 11:01 AM, Chris Kees <cekees at gmail.com> wrote:

> Hi,
>
> I'm looking for some presentable ipython notebooks that I can put on
> my ipython sandbox to show off some of the following capabilities:
>
> -Analysis  on data sets from  multiple (large) external databases
> -Pulling in google earth imagery and doing something real with it like
> overlaying additional information
> -Machine learning applied to large databases
> -Symbolic math supporting some kind of analysis

There are some notebooks in the SymPy git repository that might suit
your needs for this last point. They are in the examples directory.
They probably require the git version of SymPy, in case that's an
issue. One of the SymPy contributors also has a collection of
notebooks at https://github.com/raoulb/sympy_ipython_notebooks. These
may also require the git version of SymPy.

And I vaguely remember there being some example notebooks at ship with
IPython that may fit this and possibly some of your other bullet
points.

Aaron Meurer

>
> Apologies in advance for blatant crowd sourcing. I've got the opportunity to
> present python and IPython as a core technology that my lab will
> consider as a part of a larger computational modeling strategy. I have
> my own examples of some of parallel models running in the notebooks
> but am weak on the items above, which I think will continue to grow in
> relevance to the kind of engineering analysis and R&D that is part of
> my lab's core business.
>
> Thanks,
> Chris
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev


From bob+ipython at mcelrath.org  Wed Jun 27 15:33:09 2012
From: bob+ipython at mcelrath.org (Bob McElrath)
Date: Wed, 27 Jun 2012 19:33:09 +0000
Subject: [IPython-dev] SVG figures status report
In-Reply-To: <4FEB2241.1030309@stsci.edu>
References: <20120624180123.GL6159@mcelrath.org>
	<CAHAreOr2_DfwJBoF1UskayXhVdWPykZ2z2zPjJ0Dvaj1CW6Hog@mail.gmail.com>
	<4FE96830.1080803@gmail.com>
	<CAH4pYpQJgoLJvEoqeQOyWrM+K094uCRe5X5yTO79PVKspjXxVA@mail.gmail.com>
	<4FE9DEF3.1060908@creativetrax.com> <4FE9F4F8.7010404@gmail.com>
	<4FEA1FDC.3030606@creativetrax.com>
	<CAH4pYpRwkHYnaQ7_Mpd9ahWV1XGp7+yePRMzd+NpLTqEwZgJSw@mail.gmail.com>
	<4FEB2241.1030309@stsci.edu>
Message-ID: <20120627193309.GQ6159@mcelrath.org>

Michael Droettboom [mdroe at stsci.edu] wrote:
> I like the suggestion of "freezing/unfreezing" SVG on the fly -- that's 
> definitely worth further investigation.

On that point, I just found canvg: http://code.google.com/p/canvg/ which renders
SVG to a HTML Canvas using javascript, on the client side.  Anyone want to play
with it?

If this could be made to work, and as canvg advertises, animation even works, it
could allow a very smooth transition from Canvas to SVG for vector graphs,
when/if the browser support improves.  Or, as I suggested, "freezing/unfreezing"
too.  I wonder if simple things like coordinate reporting, if implemented in
SVG, could also work in the translated Canvas?

The advantage of Canvas is that it's a single DOM element per graph.  So
scrolling, selecting, executing cells, etc doesn't require the browser to
traverse all nodes in every SVG graph, or recalculate styles for every node.  (I
know that probably shouldn't be happening in the first place, but as far as I
can tell from Chrome's profiler, it is)

Don't forget that Matplotlib's SVG backend needs some work too.  It has
some rendering errors.  (and so does the svg output of the Cairo backend)

--
Cheers, Bob McElrath

"The individual has always had to struggle to keep from being overwhelmed by
the tribe.  If you try it, you will be lonely often, and sometimes frightened.
But no price is too high to pay for the privilege of owning yourself." 
    -- Friedrich Nietzsche


From jason-sage at creativetrax.com  Wed Jun 27 15:35:37 2012
From: jason-sage at creativetrax.com (Jason Grout)
Date: Wed, 27 Jun 2012 14:35:37 -0500
Subject: [IPython-dev] SVG figures status report
In-Reply-To: <4FEB2241.1030309@stsci.edu>
References: <20120624180123.GL6159@mcelrath.org>
	<CAHAreOr2_DfwJBoF1UskayXhVdWPykZ2z2zPjJ0Dvaj1CW6Hog@mail.gmail.com>
	<4FE96830.1080803@gmail.com>
	<CAH4pYpQJgoLJvEoqeQOyWrM+K094uCRe5X5yTO79PVKspjXxVA@mail.gmail.com>
	<4FE9DEF3.1060908@creativetrax.com> <4FE9F4F8.7010404@gmail.com>
	<4FEA1FDC.3030606@creativetrax.com>
	<CAH4pYpRwkHYnaQ7_Mpd9ahWV1XGp7+yePRMzd+NpLTqEwZgJSw@mail.gmail.com>
	<4FEB2241.1030309@stsci.edu>
Message-ID: <4FEB6089.4000606@creativetrax.com>

On 6/27/12 10:09 AM, Michael Droettboom wrote:
> With these easier things,
> it's also less relevant whether we're using PNG or SVG (or remains a
> user option).

True; you can implement coordinate display and picking (via image maps) 
for png just as well as svg.

Jason


From carl.input at gmail.com  Wed Jun 27 16:14:03 2012
From: carl.input at gmail.com (Carl Smith)
Date: Wed, 27 Jun 2012 21:14:03 +0100
Subject: [IPython-dev] Best approach for uploading files through the
	Notebook?
In-Reply-To: <CAH4pYpTkq=LibD4s4ad_jmyA_Ex59VxbGCZe2QxeQu-_zt_Drg@mail.gmail.com>
References: <CAP-uhDdo1H5UrK=Ne6_N7rSxsgT10UDwVk1o5bXjGHzPEBEgYQ@mail.gmail.com>
	<CAHAreOoaX6c9JuZk03-iPxx4_7qBhozDiPpB3oSrYPReVMv=Rw@mail.gmail.com>
	<CAH4pYpRErLQNcp4n_etP+S+4FV2Onfh=btR+r62xDnBXBapxbw@mail.gmail.com>
	<A3C7C2B8-7E6A-475F-8930-44CA1A6BFB64@gmail.com>
	<CAH4pYpTkq=LibD4s4ad_jmyA_Ex59VxbGCZe2QxeQu-_zt_Drg@mail.gmail.com>
Message-ID: <CAP-uhDeRc2CKPy_X_JmMwi3CCS_jQpictXUGYBHxXpJL+=vwmA@mail.gmail.com>

I want to have a go at doing what Matthius proposed, but need a few
pointers. I know I can use IPython.notebook.kernel.execute in the
JavaScript to control the kernel. Is this the only method for the
JavaScript to chat to the kernel?

I also don't know how to get the kernel to channel data back to the
JavaScript. I know Brian demonstrated that this can be done, but I
can't find any example code that covers it. I read somewhere that it
required some changes to the Notebook, and there was a PR for this, is
this still true, or does the current dev version support this stuff
out the box?

Thanks Matthius for your help on this issue, and to everyone on the
list for your patience, I do appreciate it very much.

Carl


From ellisonbg at gmail.com  Wed Jun 27 16:20:55 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Wed, 27 Jun 2012 13:20:55 -0700
Subject: [IPython-dev] Best approach for uploading files through the
	Notebook?
In-Reply-To: <CAP-uhDeRc2CKPy_X_JmMwi3CCS_jQpictXUGYBHxXpJL+=vwmA@mail.gmail.com>
References: <CAP-uhDdo1H5UrK=Ne6_N7rSxsgT10UDwVk1o5bXjGHzPEBEgYQ@mail.gmail.com>
	<CAHAreOoaX6c9JuZk03-iPxx4_7qBhozDiPpB3oSrYPReVMv=Rw@mail.gmail.com>
	<CAH4pYpRErLQNcp4n_etP+S+4FV2Onfh=btR+r62xDnBXBapxbw@mail.gmail.com>
	<A3C7C2B8-7E6A-475F-8930-44CA1A6BFB64@gmail.com>
	<CAH4pYpTkq=LibD4s4ad_jmyA_Ex59VxbGCZe2QxeQu-_zt_Drg@mail.gmail.com>
	<CAP-uhDeRc2CKPy_X_JmMwi3CCS_jQpictXUGYBHxXpJL+=vwmA@mail.gmail.com>
Message-ID: <CAH4pYpQT=XfrpqSsrJVWecxUVY5eXujR1LuD6W=8i-t6BcnSog@mail.gmail.com>

Let's say you want to create an %upload magic for this purpose.

1. First create a magic function using this approach:

http://ipython.org/ipython-doc/dev/interactive/reference.html#defining-your-own-magics

2. Your magic function should do something like this:

from IPython.core.display import display, Javascript

display(Javascript('your JS code goes here'))

3. Then you need to write the JS code to open the file browser, read
the file and send it back to the kernel using kernel.execute.

On Wed, Jun 27, 2012 at 1:14 PM, Carl Smith <carl.input at gmail.com> wrote:
> I want to have a go at doing what Matthius proposed, but need a few
> pointers. I know I can use IPython.notebook.kernel.execute in the
> JavaScript to control the kernel. Is this the only method for the
> JavaScript to chat to the kernel?

Yep, basically.

> I also don't know how to get the kernel to channel data back to the
> JavaScript. I know Brian demonstrated that this can be done, but I
> can't find any example code that covers it. I read somewhere that it
> required some changes to the Notebook, and there was a PR for this, is
> this still true, or does the current dev version support this stuff
> out the box?

The dev version supports everything you need.

Cheers,

Brian

> Thanks Matthius for your help on this issue, and to everyone on the
> list for your patience, I do appreciate it very much.
>
> Carl
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



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


From ellisonbg at gmail.com  Wed Jun 27 17:18:13 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Wed, 27 Jun 2012 14:18:13 -0700
Subject: [IPython-dev] Notebook filename badness
In-Reply-To: <CAOvn4qjhALLN7W2h+K+NPtZPYCVZWNkt9-hroa=+JCG4iNU1KQ@mail.gmail.com>
References: <CAH4pYpSV3Gewh0nsS+j+nhe=xcgqRD7GOU=SkaciY43hujjOaQ@mail.gmail.com>
	<CAOvn4qj72UNzx9YWQd+=8pofbettzk99XOM3+eEV81A_JJ8zJw@mail.gmail.com>
	<CAH4pYpTEiG1EzP5s4WMapKXW_D7BxPFhSvVBaHsV13d8nve1hg@mail.gmail.com>
	<CAOvn4qjhALLN7W2h+K+NPtZPYCVZWNkt9-hroa=+JCG4iNU1KQ@mail.gmail.com>
Message-ID: <CAH4pYpQh4WZE-VS5fb0cEe9BqVhO6ei+qvBFgTkTCoCx_2AQhg@mail.gmail.com>

On Wed, Jun 27, 2012 at 4:17 AM, Thomas Kluyver <takowl at gmail.com> wrote:
> On 27 June 2012 02:10, Brian Granger <ellisonbg at gmail.com> wrote:
>> What I am proposing would *improve* local use dramatically:
>>
>> * Persistent URLs that you can bookmark and reload across sessions.
>> * No more worrying about accidentally renaming/uploading over an
>> existing notebook.
>> * A natural place for autosave files.
>
> But as a local application, I expect it to work with regular files in
> normal locations on my filesystem. Our intention was 'directory as
> project' - you can have your notebook files alongside data files and
> Python modules. Eventually, I'd like to be able to double click the
> ipynb files in my file manager to load them, rather than having to
> load up our 'notebook list' as a file manager.
>
> This approach has lots of advantages that I don't think we want to
> throw away. You can easily put a project in version control, or keep
> it in Dropbox or similar services. You can quickly grab the file and
> attach it to an email. You can easily back up the project folder.
> Notebooks tucked away in a separate folder and named by meaningless
> UUIDs would be much less convenient in many ways.

I agree with this assessment completely.  We have to support the
current model because of this prime usage cases.

> Perhaps I can suggest an alternative approach: in 'local application'
> mode, we don't try to offer a notebook manager. It's never going to be
> as good as native file managers, and we're not really interested in
> reimplementing that functionality. If you want to copy notebooks,
> delete them, etc., you do it in your file manager (or terminal, if you
> prefer). It would still need to detect conflicts when you 'save as'
> from the notebook interface, but I'm sure we can make that work.

This is interesting.  There are some problems with this model, but I
think this is worth thinking about.

Brian

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



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


From carl.input at gmail.com  Wed Jun 27 17:42:08 2012
From: carl.input at gmail.com (Carl Smith)
Date: Wed, 27 Jun 2012 22:42:08 +0100
Subject: [IPython-dev] Best approach for uploading files through the
	Notebook?
In-Reply-To: <CAH4pYpQT=XfrpqSsrJVWecxUVY5eXujR1LuD6W=8i-t6BcnSog@mail.gmail.com>
References: <CAP-uhDdo1H5UrK=Ne6_N7rSxsgT10UDwVk1o5bXjGHzPEBEgYQ@mail.gmail.com>
	<CAHAreOoaX6c9JuZk03-iPxx4_7qBhozDiPpB3oSrYPReVMv=Rw@mail.gmail.com>
	<CAH4pYpRErLQNcp4n_etP+S+4FV2Onfh=btR+r62xDnBXBapxbw@mail.gmail.com>
	<A3C7C2B8-7E6A-475F-8930-44CA1A6BFB64@gmail.com>
	<CAH4pYpTkq=LibD4s4ad_jmyA_Ex59VxbGCZe2QxeQu-_zt_Drg@mail.gmail.com>
	<CAP-uhDeRc2CKPy_X_JmMwi3CCS_jQpictXUGYBHxXpJL+=vwmA@mail.gmail.com>
	<CAH4pYpQT=XfrpqSsrJVWecxUVY5eXujR1LuD6W=8i-t6BcnSog@mail.gmail.com>
Message-ID: <CAP-uhDeZWeVxQ-mq2BeNK0yUYqCFS2edVdYU_Fj08eNJ=6BrrQ@mail.gmail.com>

Thanks Brian. That's perfect. Nice one.
On Jun 27, 2012 9:21 PM, "Brian Granger" <ellisonbg at gmail.com> wrote:

> Let's say you want to create an %upload magic for this purpose.
>
> 1. First create a magic function using this approach:
>
>
> http://ipython.org/ipython-doc/dev/interactive/reference.html#defining-your-own-magics
>
> 2. Your magic function should do something like this:
>
> from IPython.core.display import display, Javascript
>
> display(Javascript('your JS code goes here'))
>
> 3. Then you need to write the JS code to open the file browser, read
> the file and send it back to the kernel using kernel.execute.
>
> On Wed, Jun 27, 2012 at 1:14 PM, Carl Smith <carl.input at gmail.com> wrote:
> > I want to have a go at doing what Matthius proposed, but need a few
> > pointers. I know I can use IPython.notebook.kernel.execute in the
> > JavaScript to control the kernel. Is this the only method for the
> > JavaScript to chat to the kernel?
>
> Yep, basically.
>
> > I also don't know how to get the kernel to channel data back to the
> > JavaScript. I know Brian demonstrated that this can be done, but I
> > can't find any example code that covers it. I read somewhere that it
> > required some changes to the Notebook, and there was a PR for this, is
> > this still true, or does the current dev version support this stuff
> > out the box?
>
> The dev version supports everything you need.
>
> Cheers,
>
> Brian
>
> > Thanks Matthius for your help on this issue, and to everyone on the
> > list for your patience, I do appreciate it very much.
> >
> > Carl
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu and ellisonbg at gmail.com
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120627/20de21ee/attachment.html>

From fperez.net at gmail.com  Wed Jun 27 18:58:53 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 27 Jun 2012 15:58:53 -0700
Subject: [IPython-dev] Weird, serious notebook bug on Windows
Message-ID: <CAHAreOr7eHqBpos5zx=JWp3ABVUcCBWN7Bdo9Z79-MDKxg0bLA@mail.gmail.com>

Hi all,

I just got out of a meeting with a colleague who was running beta1 on
windows, and we were getting the weirdest behavior:  every notebook
started would land on the *same* 8888 port. This is a beta1 added to
EPD on windows 7 on a fairly new laptop, and I simply don't understand
how the new notebook instances could be getting a connection to the
first port!  I'm pretty puzzled, but if this is reproducible then we
have a major blocker in our hands...

Can some of our Windows users report whether they see this behavior?
Simply start notebooks in several terminals, they should start getting
consecutive ports: 8888, 8889, 8890, ...  If they all land on 8888, we
have a problem.

In case it helps, this colleague was starting the notebook from a Git
bash shell window, not a windows console one (not that it should
matter).

Cheers,

f


From ellisonbg at gmail.com  Wed Jun 27 19:05:23 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Wed, 27 Jun 2012 16:05:23 -0700
Subject: [IPython-dev] Weird, serious notebook bug on Windows
In-Reply-To: <CAHAreOr7eHqBpos5zx=JWp3ABVUcCBWN7Bdo9Z79-MDKxg0bLA@mail.gmail.com>
References: <CAHAreOr7eHqBpos5zx=JWp3ABVUcCBWN7Bdo9Z79-MDKxg0bLA@mail.gmail.com>
Message-ID: <CAH4pYpT+aFyc6qfdO6WCRwiyLnbexXGVaVXi-X1wr1Gp69pBgQ@mail.gmail.com>

On Wed, Jun 27, 2012 at 3:58 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> Hi all,
>
> I just got out of a meeting with a colleague who was running beta1 on
> windows, and we were getting the weirdest behavior: ?every notebook
> started would land on the *same* 8888 port. This is a beta1 added to
> EPD on windows 7 on a fairly new laptop, and I simply don't understand
> how the new notebook instances could be getting a connection to the
> first port! ?I'm pretty puzzled, but if this is reproducible then we
> have a major blocker in our hands...
>
> Can some of our Windows users report whether they see this behavior?
> Simply start notebooks in several terminals, they should start getting
> consecutive ports: 8888, 8889, 8890, ... ?If they all land on 8888, we
> have a problem.
>
> In case it helps, this colleague was starting the notebook from a Git
> bash shell window, not a windows console one (not that it should
> matter).

I have seen weird things in git bash wrt IPython.  Can you have them
retry in the regular command prompt?

Brian

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



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


From fperez.net at gmail.com  Wed Jun 27 19:14:53 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 27 Jun 2012 16:14:53 -0700
Subject: [IPython-dev] Weird, serious notebook bug on Windows
In-Reply-To: <CAH4pYpT+aFyc6qfdO6WCRwiyLnbexXGVaVXi-X1wr1Gp69pBgQ@mail.gmail.com>
References: <CAHAreOr7eHqBpos5zx=JWp3ABVUcCBWN7Bdo9Z79-MDKxg0bLA@mail.gmail.com>
	<CAH4pYpT+aFyc6qfdO6WCRwiyLnbexXGVaVXi-X1wr1Gp69pBgQ@mail.gmail.com>
Message-ID: <CAHAreOr4tf7ioZz5Uy+JkSxsssLXc-hg4dorf0BC00-5Q2NkLA@mail.gmail.com>

On Wed, Jun 27, 2012 at 4:05 PM, Brian Granger <ellisonbg at gmail.com> wrote:
> I have seen weird things in git bash wrt IPython. ?Can you have them
> retry in the regular command prompt?

OK, good to know.  I just asked him to do that, I'll report.

f


From benjaminrk at gmail.com  Wed Jun 27 19:20:35 2012
From: benjaminrk at gmail.com (MinRK)
Date: Wed, 27 Jun 2012 16:20:35 -0700
Subject: [IPython-dev] Weird, serious notebook bug on Windows
In-Reply-To: <CAHAreOr4tf7ioZz5Uy+JkSxsssLXc-hg4dorf0BC00-5Q2NkLA@mail.gmail.com>
References: <CAHAreOr7eHqBpos5zx=JWp3ABVUcCBWN7Bdo9Z79-MDKxg0bLA@mail.gmail.com>
	<CAH4pYpT+aFyc6qfdO6WCRwiyLnbexXGVaVXi-X1wr1Gp69pBgQ@mail.gmail.com>
	<CAHAreOr4tf7ioZz5Uy+JkSxsssLXc-hg4dorf0BC00-5Q2NkLA@mail.gmail.com>
Message-ID: <CAHNn8BUo19oNxWsZ4SXYwNsw_HxcDR1om0yS1reBh7C6AHwr2w@mail.gmail.com>

I can reproduce this, actually with basic tornado hello world example -
listening on an in-use port does not raise on Windows.

This is because tornado sets:

sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1),

which on Windows prevents binding from raising an error. The second socket
will happily wait in line for the previous socket to let go of the port.

I see this as "not our problem," and if Windows users want to run multiple
notebooks, they have to set ports manually, which is easy.  This should be
clearly documented, though, as it is rather surprising.

I will bring it up as a tornado Issue.

-MinRK

On Wed, Jun 27, 2012 at 4:14 PM, Fernando Perez <fperez.net at gmail.com>wrote:

> On Wed, Jun 27, 2012 at 4:05 PM, Brian Granger <ellisonbg at gmail.com>
> wrote:
> > I have seen weird things in git bash wrt IPython.  Can you have them
> > retry in the regular command prompt?
>
> OK, good to know.  I just asked him to do that, I'll report.
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120627/d4c39dc1/attachment.html>

From fperez.net at gmail.com  Wed Jun 27 19:22:41 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 27 Jun 2012 16:22:41 -0700
Subject: [IPython-dev] Weird, serious notebook bug on Windows
In-Reply-To: <CAHNn8BUo19oNxWsZ4SXYwNsw_HxcDR1om0yS1reBh7C6AHwr2w@mail.gmail.com>
References: <CAHAreOr7eHqBpos5zx=JWp3ABVUcCBWN7Bdo9Z79-MDKxg0bLA@mail.gmail.com>
	<CAH4pYpT+aFyc6qfdO6WCRwiyLnbexXGVaVXi-X1wr1Gp69pBgQ@mail.gmail.com>
	<CAHAreOr4tf7ioZz5Uy+JkSxsssLXc-hg4dorf0BC00-5Q2NkLA@mail.gmail.com>
	<CAHNn8BUo19oNxWsZ4SXYwNsw_HxcDR1om0yS1reBh7C6AHwr2w@mail.gmail.com>
Message-ID: <CAHAreOoXdWMVzMVkF19JCCSW=Y4TNx-Jo11+8eW1og-Ph30Now@mail.gmail.com>

On Wed, Jun 27, 2012 at 4:20 PM, MinRK <benjaminrk at gmail.com> wrote:
> I see this as "not our problem," and if Windows users want to run multiple
> notebooks, they have to set ports manually, which is easy. ?This should be
> clearly documented, though, as it is rather surprising.

Ah, OK!  Well, at least I'm glad we caught this so we can explain the
issue to people and how to work around it.

> I will bring it up as a tornado Issue.

Great, thanks!


From mdroe at stsci.edu  Wed Jun 27 21:38:45 2012
From: mdroe at stsci.edu (Michael Droettboom)
Date: Wed, 27 Jun 2012 21:38:45 -0400
Subject: [IPython-dev] SVG figures status report
In-Reply-To: <20120627193309.GQ6159@mcelrath.org>
References: <20120624180123.GL6159@mcelrath.org>
	<CAHAreOr2_DfwJBoF1UskayXhVdWPykZ2z2zPjJ0Dvaj1CW6Hog@mail.gmail.com>
	<4FE96830.1080803@gmail.com>
	<CAH4pYpQJgoLJvEoqeQOyWrM+K094uCRe5X5yTO79PVKspjXxVA@mail.gmail.com>
	<4FE9DEF3.1060908@creativetrax.com> <4FE9F4F8.7010404@gmail.com>
	<4FEA1FDC.3030606@creativetrax.com>
	<CAH4pYpRwkHYnaQ7_Mpd9ahWV1XGp7+yePRMzd+NpLTqEwZgJSw@mail.gmail.com>
	<4FEB2241.1030309@stsci.edu> <20120627193309.GQ6159@mcelrath.org>
Message-ID: <4FEBB5A5.9030806@stsci.edu>

On 06/27/2012 03:33 PM, Bob McElrath wrote:
>
>
> Don't forget that Matplotlib's SVG backend needs some work too.  It has
> some rendering errors.  (and so does the svg output of the Cairo backend)
>
Report these bugs if you've got 'em.  There are no open bugs on the SVG 
backend at the moment -- only two feature requests.

Mike


From bob+ipython at mcelrath.org  Thu Jun 28 01:11:59 2012
From: bob+ipython at mcelrath.org (Bob McElrath)
Date: Thu, 28 Jun 2012 05:11:59 +0000
Subject: [IPython-dev] SVG figures status report
In-Reply-To: <4FEBB5A5.9030806@stsci.edu>
References: <CAHAreOr2_DfwJBoF1UskayXhVdWPykZ2z2zPjJ0Dvaj1CW6Hog@mail.gmail.com>
	<4FE96830.1080803@gmail.com>
	<CAH4pYpQJgoLJvEoqeQOyWrM+K094uCRe5X5yTO79PVKspjXxVA@mail.gmail.com>
	<4FE9DEF3.1060908@creativetrax.com> <4FE9F4F8.7010404@gmail.com>
	<4FEA1FDC.3030606@creativetrax.com>
	<CAH4pYpRwkHYnaQ7_Mpd9ahWV1XGp7+yePRMzd+NpLTqEwZgJSw@mail.gmail.com>
	<4FEB2241.1030309@stsci.edu> <20120627193309.GQ6159@mcelrath.org>
	<4FEBB5A5.9030806@stsci.edu>
Message-ID: <20120628051159.GV6159@mcelrath.org>

Michael Droettboom [mdroe at stsci.edu] wrote:
> On 06/27/2012 03:33 PM, Bob McElrath wrote:
> >
> >
> > Don't forget that Matplotlib's SVG backend needs some work too.  It has
> > some rendering errors.  (and so does the svg output of the Cairo backend)
> >
> Report these bugs if you've got 'em.  There are no open bugs on the SVG 
> backend at the moment -- only two feature requests.

I'll file some as soon as I have some reproducible test cases.  What I see all
the time are:
    1) histograms with bars extending below the horizontal axis
    2) pixelation of lines for some choices of figsize.
If you understand either of these I'd appreciate your comments.

Aha, I see you've done some work on mpl svg interactivity too.  Perhaps you
could tell us what you're doing on the mpl side with SVG interactivity?

--
Cheers, Bob McElrath

"The individual has always had to struggle to keep from being overwhelmed by
the tribe.  If you try it, you will be lonely often, and sometimes frightened.
But no price is too high to pay for the privilege of owning yourself." 
    -- Friedrich Nietzsche


From zvoros at gmail.com  Thu Jun 28 01:16:52 2012
From: zvoros at gmail.com (=?ISO-8859-1?Q?Zolt=E1n_V=F6r=F6s?=)
Date: Thu, 28 Jun 2012 07:16:52 +0200
Subject: [IPython-dev] SVG figures status report
In-Reply-To: <4FEB6089.4000606@creativetrax.com>
References: <20120624180123.GL6159@mcelrath.org>
	<CAHAreOr2_DfwJBoF1UskayXhVdWPykZ2z2zPjJ0Dvaj1CW6Hog@mail.gmail.com>
	<4FE96830.1080803@gmail.com>
	<CAH4pYpQJgoLJvEoqeQOyWrM+K094uCRe5X5yTO79PVKspjXxVA@mail.gmail.com>
	<4FE9DEF3.1060908@creativetrax.com> <4FE9F4F8.7010404@gmail.com>
	<4FEA1FDC.3030606@creativetrax.com>
	<CAH4pYpRwkHYnaQ7_Mpd9ahWV1XGp7+yePRMzd+NpLTqEwZgJSw@mail.gmail.com>
	<4FEB2241.1030309@stsci.edu> <4FEB6089.4000606@creativetrax.com>
Message-ID: <4FEBE8C4.2020208@gmail.com>



On 06/27/2012 09:35 PM, Jason Grout wrote:
> On 6/27/12 10:09 AM, Michael Droettboom wrote:
>> With these easier things,
>> it's also less relevant whether we're using PNG or SVG (or remains a
>> user option).
> True; you can implement coordinate display and picking (via image maps)
> for png just as well as svg.
>
> Jason
Coordinate reporting can be done with some hacking, but for picking, one 
needs access to the data. I have already suggested using PNGs in a 
container with some javascript code, but that would give only coordinate 
reporting, nothing more. You can perhaps put on cross-hairs, but grid 
toggling would already be impossible. However, the advantage of this 
approach would be that it would not bring up bandwidth issues. If 
coordinate reporting and cross-hairs are enough, then I would suggest 
that we insert this in the zmq backend, though, I feel that it would 
fall short of many people's expectations...

Cheers,
Zolt?n


From ellisonbg at gmail.com  Thu Jun 28 12:07:09 2012
From: ellisonbg at gmail.com (Brian Granger)
Date: Thu, 28 Jun 2012 09:07:09 -0700
Subject: [IPython-dev] Notebook filename badness
In-Reply-To: <CAOvn4qh6hxhjxFfVbP5QBiwZCB-NFcojB-sgOAY+7yrBm+JRwQ@mail.gmail.com>
References: <CAH4pYpSV3Gewh0nsS+j+nhe=xcgqRD7GOU=SkaciY43hujjOaQ@mail.gmail.com>
	<CAOvn4qj72UNzx9YWQd+=8pofbettzk99XOM3+eEV81A_JJ8zJw@mail.gmail.com>
	<CAH4pYpTEiG1EzP5s4WMapKXW_D7BxPFhSvVBaHsV13d8nve1hg@mail.gmail.com>
	<CAOvn4qjhALLN7W2h+K+NPtZPYCVZWNkt9-hroa=+JCG4iNU1KQ@mail.gmail.com>
	<CAOvn4qh6hxhjxFfVbP5QBiwZCB-NFcojB-sgOAY+7yrBm+JRwQ@mail.gmail.com>
Message-ID: <CAH4pYpTUUjP=Av6kygDVqh+cUgLphxNvNJBEP_xSV5szZTKh-A@mail.gmail.com>

On Wed, Jun 27, 2012 at 4:52 AM, Thomas Kluyver <takowl at gmail.com> wrote:
> Perhaps it will help to take a step back in this discussion.
>
> At present, the notebook is useful either running locally or running
> as a web application. People are using both, each has some
> awkwardness, as you'd expect from something that was only released a
> few months ago. On the local side, there are the problems with file
> handling we've already discussed, while the web app lacks a proper
> multi-user model for now.

I don't think the lines between local app and web app are very clear
for us.  Some things to consider:

* It *is* a web application.  It runs in the browser, it talks to a
server using HTTP+WebSockets, the client is written in
Javascript+HTML+CSS.
* The only thing different is that sometimes a user happens to have
console/GUI access to the computer that the server is running on.
That gives them "side channel" access to the files that the server
uses.  That side channel access does not, in any way change the nature
of the web application.  It just gives you other ways of interacting
with those files.  We do want that side channel access to be as
convenient as possible though.

Let me phrase this in a different manner.  I think we have the
opportunity to create a new category of app that is a hybrid "native"
and "web app".  Instead of segregating these two models, I think we
need to mash them up to accomplish something that is greater than
either.

> As I understand it, what you're suggesting is that we steam ahead with
> developing it as a web app, and give local users the choice of:
> - Use files as we do already, but don't expect the problems to get fixed
> - Use it like a web app running locally, and more or less ignore that
> it creates files to store the notebooks (i.e. the hidden directory you
> suggest)
>
> My feeling is that the local app is an important but very different
> use case, and we need to accommodate this properly. Ultimately, I
> think we will need two different modes, or even two different
> applications - perhaps "ipython notebook" and "ipython nbserver". It
> will be a bit more code to maintain, but I think the benefit of
> supporting both use cases well is worth the extra complexity.

If it was simply a matter of creating two different top level apps,
that wouldn't be too bad.  But doing this will require also two
different versions of the HTML templates, the JS code, the URL scheme.
 I have found that the subclassing model doesn't work very well for
all of these things.  If you change the URL scheme for example, you
have to more or less completely rewrite the handlers.  Last summer for
a short while I had two versions of the notebook and it was insanity.
I don't see us going in this direction with the current manpower.

I hope I am not coming across as thinking that the "local" aspects of
the notebook are not important.  I do think they are very important
and they were at the front of my mind when I wrote the first version
of the notebook.  I am not suggesting that we get rid of that.  I just
think we need to think carefully about what aspects of the local and
web app experiences are important.

Cheers,

Brian



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



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


From jason-sage at creativetrax.com  Thu Jun 28 15:12:54 2012
From: jason-sage at creativetrax.com (Jason Grout)
Date: Thu, 28 Jun 2012 14:12:54 -0500
Subject: [IPython-dev] metadata attribute for streams
Message-ID: <4FECACB6.5010604@creativetrax.com>



As you probably know from our many messages, we're implementing a sage 
frontend/backend using the IPython framework.  We'd like to attach some 
metadata to stdout and stderr messages, for example, indicating where 
the frontend should put the output.  It would be really convenient if 
sys.stdout and sys.stderr (which I think is 
IPython.zmq.iostream.OutStream, right?) had a 'metadata' attribute that 
could be set and would be added to each outgoing message.  This would 
also change the messaging spec to add a 'metadata' attribute to the 
content dict for stream messages (just like display_data messages 
already have).

We'd use it something like this (not tested...):

from contexlib import contexmanager
@contexmanager
def stream_metadata(metadata):
     old_metadata = (sys.stdout.metadata.copy(), sys.stderr.metadata.copy())
     sys.stdout.update(metadata)
     sys.stderr.update(metadata)
     try:
         yield None
     finally:
         sys.stdout.metadata, sys.stderr.metadata = old_metadata

with stream_metadata({'location': 4}):
     print 'hello world' # goes to location 4


I can submit a pull request, but thought I'd ask for comments first.

Thanks,

Jason


From jason-sage at creativetrax.com  Thu Jun 28 16:54:28 2012
From: jason-sage at creativetrax.com (Jason Grout)
Date: Thu, 28 Jun 2012 15:54:28 -0500
Subject: [IPython-dev] metadata attribute for streams
In-Reply-To: <4FECACB6.5010604@creativetrax.com>
References: <4FECACB6.5010604@creativetrax.com>
Message-ID: <4FECC484.50900@creativetrax.com>

On 6/28/12 2:12 PM, Jason Grout wrote:
> We'd like to attach some
> metadata to stdout and stderr messages, for example, indicating where
> the frontend should put the output.  It would be really convenient if
> sys.stdout and sys.stderr (which I think is
> IPython.zmq.iostream.OutStream, right?) had a 'metadata' attribute that
> could be set and would be added to each outgoing message.  This would
> also change the messaging spec to add a 'metadata' attribute to the
> content dict for stream messages (just like display_data messages
> already have).
>
> We'd use it something like this (not tested...):

I went ahead and submitted a small 6-line pull request for you to test 
out.  https://github.com/ipython/ipython/pull/2051

Of course, docs, tests, and possibly other places in the code need to be 
updated.  I want to make sure you guys are okay with the idea first, though.

Jason




From fperez.net at gmail.com  Fri Jun 29 16:01:58 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 29 Jun 2012 13:01:58 -0700
Subject: [IPython-dev] Heads-up: releasing 0.13 final today,
	please don't push to master
Message-ID: <CAHAreOoz79TNR946bK92+_DQTzmu0MrFVOXL9zZjZi7zLL4B0w@mail.gmail.com>

Hi all,

just a quick heads-up, Min and I are in my office pushing through the
work to release 0.13 today.  So for a few hours, please everybody
refrain from merging/committing *anything* into master.  We'll ping
when it opens up again.

Thanks everyone for all the hard work to make this possible!

Cheers,

f


From hans_meine at gmx.net  Sat Jun 30 04:36:38 2012
From: hans_meine at gmx.net (Hans Meine)
Date: Sat, 30 Jun 2012 10:36:38 +0200
Subject: [IPython-dev] Notebook filename badness
In-Reply-To: <CAH4pYpTUUjP=Av6kygDVqh+cUgLphxNvNJBEP_xSV5szZTKh-A@mail.gmail.com>
References: <CAH4pYpSV3Gewh0nsS+j+nhe=xcgqRD7GOU=SkaciY43hujjOaQ@mail.gmail.com>
	<CAOvn4qj72UNzx9YWQd+=8pofbettzk99XOM3+eEV81A_JJ8zJw@mail.gmail.com>
	<CAH4pYpTEiG1EzP5s4WMapKXW_D7BxPFhSvVBaHsV13d8nve1hg@mail.gmail.com>
	<CAOvn4qjhALLN7W2h+K+NPtZPYCVZWNkt9-hroa=+JCG4iNU1KQ@mail.gmail.com>
	<CAOvn4qh6hxhjxFfVbP5QBiwZCB-NFcojB-sgOAY+7yrBm+JRwQ@mail.gmail.com>
	<CAH4pYpTUUjP=Av6kygDVqh+cUgLphxNvNJBEP_xSV5szZTKh-A@mail.gmail.com>
Message-ID: <D96C592C-7079-4901-8F53-8C63FB01E785@gmx.net>

Hi Brian!

Am 28.06.2012 um 18:07 schrieb Brian Granger:

> On Wed, Jun 27, 2012 at 4:52 AM, Thomas Kluyver <takowl at gmail.com> wrote:
>> Perhaps it will help to take a step back in this discussion.
>> 
>> At present, the notebook is useful either running locally or running
>> as a web application. People are using both, each has some
>> awkwardness, as you'd expect from something that was only released a
>> few months ago. On the local side, there are the problems with file
>> handling we've already discussed, while the web app lacks a proper
>> multi-user model for now.
> 
> I don't think the lines between local app and web app are very clear
> for us.  Some things to consider:
> 
> * It *is* a web application.  It runs in the browser, it talks to a
> server using HTTP+WebSockets, the client is written in
> Javascript+HTML+CSS.

Technically, yes.  However, the main reason for this thread is that there are two mental models behind it.

One of the models is: "Oh, great!  Recent versions of the python-shell-on-steroids IPython I have grown to love support a "notebook mode".  Unfortunately, it is a little clumsy to start, because it opens in the browser, but this new mode rocks!"

In other words, the separation between client and server, and the access via the browser are technical details many users could (or even want to) live without.

In this mental model, filenames are what you care about, not URLs.  (I would argue that those users, and I count myself mostly among them, do not even notice the URLs.)

FWIW, I would love a pure Qt notebook, which could better match this mental model, but I know that this is among the things getting mentioned here and there, but lacking manpower so far.  (And unfortunately, QtWebKit is not on par yet with the technology we require for the notebook AFAIK.)

HTH,
  Hans

From fperez.net at gmail.com  Sat Jun 30 04:55:36 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 30 Jun 2012 01:55:36 -0700
Subject: [IPython-dev] [ANN] IPython 0.13 is officially out!
Message-ID: <CAHAreOqw8LX1tTaci7gObbQVNaoRob=esgzAyDRbo_Vqw-vgcQ@mail.gmail.com>

Hi all,

on behalf of the IPython development team, and just in time for the
imminent Debian freeze and SciPy 2012, I'm thrilled to announce, after
an intense 6 months of work, the official release of IPython 0.13.

This version contains several major new features, as well as a large
amount of bug and regression fixes. The previous version (0.12) was
released on December 19 2011, so in this development cycle we had:

- ~6 months of work.
- 373 pull requests merged.
- 742 issues closed (non-pull requests).
- contributions from 62 authors.
- 1760 commits.
- a diff of 114226 lines.

This means that we closed a total of 1115 issues over 6 months, for a
rate of almost 200 issues closed per month and almost 300 commits per
month. We are very grateful to all of you who have contributed so
enthusiastically to the project and have had the patience of pushing
your contributions through our often lengthy review process.

We've also welcomed several new members to the core IPython
development group: J?rgen Stenarson (@jstenar - this really was an
omission as J?rgen has been our Windows expert for a long time) and
Matthias Bussonier (@Carreau), who has been very active on all fronts
of the project.


*Highlights*

There is too much new work to write up here, so we refer you to our
full What's New document
(http://ipython.org/ipython-doc/rel-0.13/whatsnew/version0.13.html)
for the full details. But the main highlights of this release are:

* Brand new UI for the notebook, with major usability improvements
(real menus, toolbar, and much more)

* Manage all your parallel cluster configurations from the notebook
with push-button simplicity (cluster start/stop with one button).

* Cell magics: commands prefixed with %% apply to an entire cell. We
ship with many cell magics by default, including timing, profiling,
running cells under bash, Perl and Ruby as well as magics to interface
seamlessly with Cython, R and Octave.

* The IPython.parallel tools have received many fixes, optimizations,
and a number of API improvements to make writing, profiling and
debugging parallel codes with IPython much easier.

* We have unified our interactive kernels (the basic ipython object
you know and love) with the engines running in parallel, so that you
can now use all IPython special tricks in parallel too. And you can
connect a console or qtconsole to any parallel engine for direct,
interactive execution, plotting and debugging in a cluster.


*Downloads*

Download links and instructions are at: http://ipython.org/download.html
And IPython is also on PyPI: http://pypi.python.org/pypi/ipython

Those contain a built version of the HTML docs; if you want pure
source downloads with no docs, those are available on github:

Tarball: https://github.com/ipython/ipython/tarball/rel-0.13
Zipball: https://github.com/ipython/ipython/zipball/rel-0.13


Please see our release notes for the full details on everything about
this release:
http://ipython.org/ipython-doc/rel-0.13/whatsnew/version0.13.html

As usual, if you find any other problem, please file a ticket --or
even better, a pull request fixing it-- on our github issues site
(https://github.com/ipython/ipython/issues).

Many thanks to all who contributed!

Fernando, on behalf of the IPython development team.

http://ipython.org


From carl.input at gmail.com  Sat Jun 30 11:02:17 2012
From: carl.input at gmail.com (Carl Smith)
Date: Sat, 30 Jun 2012 16:02:17 +0100
Subject: [IPython-dev] IPython AWS Extension
Message-ID: <CAP-uhDfq-HKNRpdncpq1u9oV=jFapcACYmsFvwgtseXJkxvTzw@mail.gmail.com>

I've been looking at where to go with the NotebookCloud app I've been
working on and decided it would better to add new features to the user's
IPython setup, rather than NBC itself.

The AMI includes boto already, a Python AWS library, and it's very good,
but it can still often take a while to get anything done. Mounting a
dataset for example.

Now, I'm looking to write a library for the AMI that makes AWS easier to
use from the Notebook.

Does this sound like the best way to go?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120630/2a855e91/attachment.html>

From matthew.brett at gmail.com  Sat Jun 30 12:57:28 2012
From: matthew.brett at gmail.com (Matthew Brett)
Date: Sat, 30 Jun 2012 09:57:28 -0700
Subject: [IPython-dev] [ANN] IPython 0.13 is officially out!
In-Reply-To: <CAHAreOqw8LX1tTaci7gObbQVNaoRob=esgzAyDRbo_Vqw-vgcQ@mail.gmail.com>
References: <CAHAreOqw8LX1tTaci7gObbQVNaoRob=esgzAyDRbo_Vqw-vgcQ@mail.gmail.com>
Message-ID: <CAH6Pt5ryjVJPck_p2L0-R-wb3DaEYxf59DjuN_3QBp_vyetq8Q@mail.gmail.com>

Yo,

On Sat, Jun 30, 2012 at 1:55 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> Hi all,
>
> on behalf of the IPython development team, and just in time for the
> imminent Debian freeze and SciPy 2012, I'm thrilled to announce, after
> an intense 6 months of work, the official release of IPython 0.13.
>
> This version contains several major new features, as well as a large
> amount of bug and regression fixes. The previous version (0.12) was
> released on December 19 2011, so in this development cycle we had:
>
> - ~6 months of work.
> - 373 pull requests merged.
> - 742 issues closed (non-pull requests).
> - contributions from 62 authors.
> - 1760 commits.
> - a diff of 114226 lines.
>
> This means that we closed a total of 1115 issues over 6 months, for a
> rate of almost 200 issues closed per month and almost 300 commits per
> month. We are very grateful to all of you who have contributed so
> enthusiastically to the project and have had the patience of pushing
> your contributions through our often lengthy review process.
>
> We've also welcomed several new members to the core IPython
> development group: J?rgen Stenarson (@jstenar - this really was an
> omission as J?rgen has been our Windows expert for a long time) and
> Matthias Bussonier (@Carreau), who has been very active on all fronts
> of the project.
>
>
> *Highlights*
>
> There is too much new work to write up here, so we refer you to our
> full What's New document
> (http://ipython.org/ipython-doc/rel-0.13/whatsnew/version0.13.html)
> for the full details. But the main highlights of this release are:
>
> * Brand new UI for the notebook, with major usability improvements
> (real menus, toolbar, and much more)
>
> * Manage all your parallel cluster configurations from the notebook
> with push-button simplicity (cluster start/stop with one button).
>
> * Cell magics: commands prefixed with %% apply to an entire cell. We
> ship with many cell magics by default, including timing, profiling,
> running cells under bash, Perl and Ruby as well as magics to interface
> seamlessly with Cython, R and Octave.
>
> * The IPython.parallel tools have received many fixes, optimizations,
> and a number of API improvements to make writing, profiling and
> debugging parallel codes with IPython much easier.
>
> * We have unified our interactive kernels (the basic ipython object
> you know and love) with the engines running in parallel, so that you
> can now use all IPython special tricks in parallel too. And you can
> connect a console or qtconsole to any parallel engine for direct,
> interactive execution, plotting and debugging in a cluster.

Congratulations to all.  It has been a real inspiration to watch y'all
work together, and it's a great achievement.

See you,

Matthew


From fperez.net at gmail.com  Sat Jun 30 13:05:06 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 30 Jun 2012 10:05:06 -0700
Subject: [IPython-dev] [ANN] IPython 0.13 is officially out!
In-Reply-To: <CAH6Pt5ryjVJPck_p2L0-R-wb3DaEYxf59DjuN_3QBp_vyetq8Q@mail.gmail.com>
References: <CAHAreOqw8LX1tTaci7gObbQVNaoRob=esgzAyDRbo_Vqw-vgcQ@mail.gmail.com>
	<CAH6Pt5ryjVJPck_p2L0-R-wb3DaEYxf59DjuN_3QBp_vyetq8Q@mail.gmail.com>
Message-ID: <CAHAreOr_Vwimt1TN=N7WLN6F9YrYYjg_rxWdCVMMaJxCnMzhZw@mail.gmail.com>

On Sat, Jun 30, 2012 at 9:57 AM, Matthew Brett <matthew.brett at gmail.com> wrote:
> Congratulations to all. ?It has been a real inspiration to watch y'all
> work together, and it's a great achievement.

Thanks, Matthew!  Kind words much appreciated after all this work.
Pretty fried right now, but no rest for the wicked: 3 PRs already
merged for 0.14 :)

BTW, not that he needs any more praise, but I really want to thank Min
publicly: we wouldn't have done this in time for the Debian cutoff if
he hadn't pulled all the stops this week.  I've been a bit sick and
Min stepped in very hard to finish things off, and yesterday joined me
for a continuous noon-2am push to get this thing done.

And again, thanks to everyone else for all the recent review work and
polish PRs: we caught a ton of small but important bugs in the last 10
days or so, making this a really nice release.

I'm glad we got 0.13 into Debian, as it's a really much more solid
release than 0.12.1 in terms of features, and we'll work with Julian
Taylor to craft a polish 0.13.1 release that smooths any rough edges
left but is acceptable for inclusion in Debian in a month or two.

Now, back to work!

Cheers,

f


From fperez.net at gmail.com  Sat Jun 30 13:07:37 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 30 Jun 2012 10:07:37 -0700
Subject: [IPython-dev] IPython AWS Extension
In-Reply-To: <CAP-uhDfq-HKNRpdncpq1u9oV=jFapcACYmsFvwgtseXJkxvTzw@mail.gmail.com>
References: <CAP-uhDfq-HKNRpdncpq1u9oV=jFapcACYmsFvwgtseXJkxvTzw@mail.gmail.com>
Message-ID: <CAHAreOr+Vk83Y05z=Angmxy3h1LxCjk+ZcH6rY5Hy64XD_m3dQ@mail.gmail.com>

Hi Carl,

On Sat, Jun 30, 2012 at 8:02 AM, Carl Smith <carl.input at gmail.com> wrote:
> I've been looking at where to go with the NotebookCloud app I've been
> working on and decided it would better to add new features to the user's
> IPython setup, rather than NBC itself.
>
> The AMI includes boto already, a Python AWS library, and it's very good, but
> it can still often take a while to get anything done. Mounting a dataset for
> example.
>
> Now, I'm looking to write a library for the AMI that makes AWS easier to use
> from the Notebook.
>
> Does this sound like the best way to go?

That definitely sounds useful; I still think that easy, persistent
storage support for the user's notebooks at least, but home directory
ideally, would be good to have.

Cheers,

f


From benjaminrk at gmail.com  Sat Jun 30 14:00:40 2012
From: benjaminrk at gmail.com (MinRK)
Date: Sat, 30 Jun 2012 11:00:40 -0700
Subject: [IPython-dev] Weird, serious notebook bug on Windows
In-Reply-To: <CAHAreOoXdWMVzMVkF19JCCSW=Y4TNx-Jo11+8eW1og-Ph30Now@mail.gmail.com>
References: <CAHAreOr7eHqBpos5zx=JWp3ABVUcCBWN7Bdo9Z79-MDKxg0bLA@mail.gmail.com>
	<CAH4pYpT+aFyc6qfdO6WCRwiyLnbexXGVaVXi-X1wr1Gp69pBgQ@mail.gmail.com>
	<CAHAreOr4tf7ioZz5Uy+JkSxsssLXc-hg4dorf0BC00-5Q2NkLA@mail.gmail.com>
	<CAHNn8BUo19oNxWsZ4SXYwNsw_HxcDR1om0yS1reBh7C6AHwr2w@mail.gmail.com>
	<CAHAreOoXdWMVzMVkF19JCCSW=Y4TNx-Jo11+8eW1og-Ph30Now@mail.gmail.com>
Message-ID: <CAHNn8BWfks0f0jcHjBK+4k15+7sR4mDSdiR6LT45yxpnT3WYdg@mail.gmail.com>

On Wed, Jun 27, 2012 at 4:22 PM, Fernando Perez <fperez.net at gmail.com>wrote:

> On Wed, Jun 27, 2012 at 4:20 PM, MinRK <benjaminrk at gmail.com> wrote:
> > I see this as "not our problem," and if Windows users want to run
> multiple
> > notebooks, they have to set ports manually, which is easy.  This should
> be
> > clearly documented, though, as it is rather surprising.
>
> Ah, OK!  Well, at least I'm glad we caught this so we can explain the
> issue to people and how to work around it.
>
> > I will bring it up as a tornado Issue.
>
> Great, thanks!
>

Tornado issue opened as #550<https://github.com/facebook/tornado/issues/550>,
fixed in #551 <https://github.com/facebook/tornado/pull/551>, so this won't
come up after the next tornado release.


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

From fperez.net at gmail.com  Sat Jun 30 14:02:46 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 30 Jun 2012 11:02:46 -0700
Subject: [IPython-dev] Weird, serious notebook bug on Windows
In-Reply-To: <CAHNn8BWfks0f0jcHjBK+4k15+7sR4mDSdiR6LT45yxpnT3WYdg@mail.gmail.com>
References: <CAHAreOr7eHqBpos5zx=JWp3ABVUcCBWN7Bdo9Z79-MDKxg0bLA@mail.gmail.com>
	<CAH4pYpT+aFyc6qfdO6WCRwiyLnbexXGVaVXi-X1wr1Gp69pBgQ@mail.gmail.com>
	<CAHAreOr4tf7ioZz5Uy+JkSxsssLXc-hg4dorf0BC00-5Q2NkLA@mail.gmail.com>
	<CAHNn8BUo19oNxWsZ4SXYwNsw_HxcDR1om0yS1reBh7C6AHwr2w@mail.gmail.com>
	<CAHAreOoXdWMVzMVkF19JCCSW=Y4TNx-Jo11+8eW1og-Ph30Now@mail.gmail.com>
	<CAHNn8BWfks0f0jcHjBK+4k15+7sR4mDSdiR6LT45yxpnT3WYdg@mail.gmail.com>
Message-ID: <CAHAreOpg8ADOnYqexj-2gUDrdOsQAEYsDfT_+ZTiWptf26MhkA@mail.gmail.com>

On Sat, Jun 30, 2012 at 11:00 AM, MinRK <benjaminrk at gmail.com> wrote:
> Tornado issue opened as #550, fixed in #551, so this won't come up after the
> next tornado release.

Awesome, thanks!


From carl.input at gmail.com  Sat Jun 30 14:49:16 2012
From: carl.input at gmail.com (Carl Smith)
Date: Sat, 30 Jun 2012 19:49:16 +0100
Subject: [IPython-dev] IPython AWS Extension
In-Reply-To: <CAHAreOr+Vk83Y05z=Angmxy3h1LxCjk+ZcH6rY5Hy64XD_m3dQ@mail.gmail.com>
References: <CAP-uhDfq-HKNRpdncpq1u9oV=jFapcACYmsFvwgtseXJkxvTzw@mail.gmail.com>
	<CAHAreOr+Vk83Y05z=Angmxy3h1LxCjk+ZcH6rY5Hy64XD_m3dQ@mail.gmail.com>
Message-ID: <CAP-uhDc5eAUjQ6VtDUzECtMhth2VJYKPH6m_HtVRHNp2v2Bv0A@mail.gmail.com>

This is one of the things I'm looking at currently. I'm playing with having
an S2 based config that all instances for that user share. Then having a
magic for mounting volumes to the filesystem. On a new instance, you'd just
do something like

%aws -m myvol ~/carl

and it'd mount myvol and set it up to auto mount on reboot until/unless you
said not to.

This is going to be the approach for all new features I'm thinking.

This way users can edit the code and I can hopefully divide the feature set
into gists and get some help from IPython users that want low barrier to
entry, one file problems to play with.
On Jun 30, 2012 6:08 PM, "Fernando Perez" <fperez.net at gmail.com> wrote:

> Hi Carl,
>
> On Sat, Jun 30, 2012 at 8:02 AM, Carl Smith <carl.input at gmail.com> wrote:
> > I've been looking at where to go with the NotebookCloud app I've been
> > working on and decided it would better to add new features to the user's
> > IPython setup, rather than NBC itself.
> >
> > The AMI includes boto already, a Python AWS library, and it's very good,
> but
> > it can still often take a while to get anything done. Mounting a dataset
> for
> > example.
> >
> > Now, I'm looking to write a library for the AMI that makes AWS easier to
> use
> > from the Notebook.
> >
> > Does this sound like the best way to go?
>
> That definitely sounds useful; I still think that easy, persistent
> storage support for the user's notebooks at least, but home directory
> ideally, would be good to have.
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120630/fc43b534/attachment.html>

From fperez.net at gmail.com  Sat Jun 30 14:55:01 2012
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 30 Jun 2012 11:55:01 -0700
Subject: [IPython-dev] IPython AWS Extension
In-Reply-To: <CAP-uhDc5eAUjQ6VtDUzECtMhth2VJYKPH6m_HtVRHNp2v2Bv0A@mail.gmail.com>
References: <CAP-uhDfq-HKNRpdncpq1u9oV=jFapcACYmsFvwgtseXJkxvTzw@mail.gmail.com>
	<CAHAreOr+Vk83Y05z=Angmxy3h1LxCjk+ZcH6rY5Hy64XD_m3dQ@mail.gmail.com>
	<CAP-uhDc5eAUjQ6VtDUzECtMhth2VJYKPH6m_HtVRHNp2v2Bv0A@mail.gmail.com>
Message-ID: <CAHAreOp-fHjZ4xTTK12QSoRkAi3fiQj=XofhoM=zRsBE__-JrA@mail.gmail.com>

On Sat, Jun 30, 2012 at 11:49 AM, Carl Smith <carl.input at gmail.com> wrote:
> This is going to be the approach for all new features I'm thinking.

Sounds great, keep us posted!

Cheers,

f