From robert.kern at gmail.com  Thu Dec  1 09:23:05 2011
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 01 Dec 2011 14:23:05 +0000
Subject: [IPython-dev] Inprocess kernel for Qt frontend
Message-ID: <jb82k9$1jj$1@dough.gmane.org>

With a bit of hacking and code duplication, I managed to get the IPythonWidget 
Qt frontend to talk to an inprocess kernel.

   https://gist.github.com/1416977

I originally did this work against an older version of IPython (i.e. when we 
used names like XReqSocketChannel) but haven't been able to release it publicly 
until now. I have updated it to run off of master. I may have missed some 
necessary changes. I also may have missed some opportunities; could we use the 
BlockingKernelManager to do the same thing now?

I certainly don't want this code integrated into IPython as-is (hence a gist 
rather than a pull request), but it exists as a workaround for people who do 
want to embed an IPython interpreter into their Qt application. Is there a way 
we can extend the IPython API to support this more directly so one does not have 
to duplicate code the way I did?

-- 
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  Thu Dec  1 13:05:46 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 1 Dec 2011 10:05:46 -0800
Subject: [IPython-dev] Inprocess kernel for Qt frontend
In-Reply-To: <jb82k9$1jj$1@dough.gmane.org>
References: <jb82k9$1jj$1@dough.gmane.org>
Message-ID: <CAHAreOoGNykKo-ZPeMUxQJNcgU4ANk_Y=aMuS9YaDAit3gVsVw@mail.gmail.com>

Hey Robert,

On Thu, Dec 1, 2011 at 6:23 AM, Robert Kern <robert.kern at gmail.com> wrote:
> With a bit of hacking and code duplication, I managed to get the IPythonWidget
> Qt frontend to talk to an inprocess kernel.
>
> ? https://gist.github.com/1416977
>
> I originally did this work against an older version of IPython (i.e. when we
> used names like XReqSocketChannel) but haven't been able to release it publicly
> until now. I have updated it to run off of master. I may have missed some
> necessary changes. I also may have missed some opportunities; could we use the
> BlockingKernelManager to do the same thing now?
>
> I certainly don't want this code integrated into IPython as-is (hence a gist
> rather than a pull request), but it exists as a workaround for people who do
> want to embed an IPython interpreter into their Qt application. Is there a way
> we can extend the IPython API to support this more directly so one does not have
> to duplicate code the way I did?

That's certainly our intent, and I have a sketch in my head of how it
needs to be done, unfortunately no time right now to really work on it
(my available ipython time is fully consumed with keeping up with the
PR flow to get 0.12 released, sorry).  But I've made this an issue we
can track moving forward:

http://mail.scipy.org/pipermail/ipython-dev/2011-December/008456.html

hopefully soon we can clean this up, it would be great to get 0.13 out
with a solid implementation of this idea that can be shared by the qt
console and terminal ones without code duplication.  That is one of
the major milestones we need to achieve before considering ipython
1.0.  Yes, I've said it, there will eventually be a 1.0 :)

Thanks for getting this moving!

Cheers,

f


From fperez.net at gmail.com  Thu Dec  1 17:53:15 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 1 Dec 2011 14:53:15 -0800
Subject: [IPython-dev] Heads-up: test suite fails on Ubuntu 11.10 if system
 matplotlib is installed, it's an ubuntu bug.
Message-ID: <CAHAreOqdTkwWwY38LZAr=ukK4TOXH-mZX4kEFwR-2F1z5efE4g@mail.gmail.com>

Just so that none of you waste your time, if you install the system
matplotlib package, the test suite fails,  with KnownFailure tests
being reported as errors.  The fault is the ubuntu matplotlib package
(the *ubuntu* package, not matplotlib itself and not even the upstream
Debian one, the issue is specific to the ubuntu repackaging).  Bug
report here:

https://bugs.launchpad.net/ubuntu/+source/matplotlib/+bug/871176

The solution is to edit the file

/usr/share/pyshared/matplotlib-1.0.1.egg-info/entry_points.txt

and comment it out (it's only two lines).  You can also just empty it
out or remove it, I guess.

The bug is insanely hard to track down, and it happens even if you
completely override both the system matplotlib and nose with a
personal install of both, as this buggy global plugin is still  pulled
in.

Since both Stefan and I wasted hours on this one, I figured I'd warn people...

Cheers,

f


From fperez.net at gmail.com  Tue Dec  6 02:48:45 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 5 Dec 2011 23:48:45 -0800
Subject: [IPython-dev] Should we disable autocall by default from now on?
In-Reply-To: <CAHAreOp76zanWG9QioqO6Qb9gYuRCmSprJE_8M3onTjbxZCWGg@mail.gmail.com>
References: <CAHAreOp76zanWG9QioqO6Qb9gYuRCmSprJE_8M3onTjbxZCWGg@mail.gmail.com>
Message-ID: <CAHAreOrobr6P_JEoXKXk9-_6M6LxutNKYL7B2Jpr_P4etK8Pmg@mail.gmail.com>

Hi folks,

On Tue, Nov 29, 2011 at 11:07 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> So I'd like to hear some feedback, as we're getting ready to put 0.12
> out the door soon...

Despite the fact that I'm one of those people who think that autocall
is actually a very nice feature, I think we had very convincing
arguments about this being often confusing to newcomers.  I've changed
the default to off now:

https://github.com/ipython/ipython/commit/a7d609a4520a68856d255221ec57a24944700bce

and just committed more doc updates where autocall was mentioned to
reflect this.

Thomas, if you'd like the autocall-safe mode as well, it can certainly
be added, so feel free to put up a PR for that.

But it seems to me that Min, Thomas and I are better off simply
configuring this the way we want it in our personal profiles, so that
the new user experience leads to less surprises (and so we have less
of the weird bugs that do pop up every now and then due to this).

Thanks to everyone for the detailed feedback.  It may seem a bit silly
to obsess so much over such a small point, but I'm glad you guys care
enough to discuss it :)

Best,

f


From fperez.net at gmail.com  Tue Dec  6 06:25:35 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 6 Dec 2011 03:25:35 -0800
Subject: [IPython-dev] The homestretch for 0.12...
Message-ID: <CAHAreOpyCHakrcpsTbhnqv6Yi-EmD-k1T-J0UtRA-zMAsU6dtg@mail.gmail.com>

Hi folks,

we haven't had too many problem reports with the 0.12 beta, but we
have had a ton of recent small contributions.  This is is great, in
that we greatly appreciate new code, but now we need to spend a bit of
time stabilizing things and closing what we can, if we want a solid
0.12 release that also goes out real soon.

I've gone over the issues list and bumped to 0.13 everything that was
not likely to be doable soon (old issues, too complex, too delicate to
do now, etc).  This is what's left (only 12!):

https://github.com/ipython/ipython/issues/?milestone=6&sort=created&direction=desc&state=open

We also have a few PRs open, 9 at the moment:

https://github.com/ipython/ipython/pulls

At this point, anyone who can lend a hand with any of the above, it
would be very much appreciated.  In particular, we do have one very
nasty blocker and we're not quite sure what's going on or how to best
fix it:

https://github.com/ipython/ipython/issues/481

Major brownie points for anyone who helps us make progress with that.

So let's focus our energies on the remaining things, and we should be
able to cut an RC by week's end...

Cheers,

f

ps - to put things in perspective, the 0.11 release had 511 github
issues closed in ~16 months, and in the last 4 months since 0.11 we've
closed a total of 442! (214 pull requests and 228 regular ones).  It
seems our predictions of 0.11 really providing a more approachable
project were true :)


From fperez.net at gmail.com  Tue Dec  6 12:27:03 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 6 Dec 2011 09:27:03 -0800
Subject: [IPython-dev] Heads-up: little utility in tools/,
	'git mrb' for merging remote branches
Message-ID: <CAHAreOokcqCV8zWWSshV0+Te2f5OZBHS=c9-v0vT7Oaz_L0Z5Q@mail.gmail.com>

Hi all,

I committed this little utility I recently wrote and that others can
find useful:

https://github.com/ipython/ipython/blob/master/tools/git-mrb

I find myself very often testing remote branches from the same regular
contributors, so rather than copy/pasting github's instructions, I
made this that lets me simply highlight the branch name and type

git mrb remote:branchname  # this last part copy/pasted from the PR page

For example, since I have Carreau's fork as a remote, I can do for
https://github.com/ipython/ipython/pull/1108:

git mrb Carreau:completer-usability-2

and it automatically fetches, merges (steps 1-2 of the merge
instructions) and then  waits for me to test things out.  It asks
whether I want to delete the branch and go back to master or to leave
it alone.  I delete it if the tests don't pass, if there's a problem
or if I decide to do the merge with the github blue button (which
simplifies the editing of the merge commit message).

Possible enhancements:

- to support also working directly with a PR number
- auto-detecting that if I don't have a remote for the necessary
branch, it can go and fetch from github that one time, as right now
it's only useful for remotes you are already tracking (I've added the
remotes of frequent contributors for this reason).

But even as-is, I've found it to save me time as it makes the review
process quicker by pretty much automating the manual parts.  Probably
more than the time itself of the actions, it's the more fluid process
it enables that I like, as I don't have to stop to do clunky manual
operations.

Cheers,

f


From fperez.net at gmail.com  Tue Dec  6 15:18:58 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 6 Dec 2011 12:18:58 -0800
Subject: [IPython-dev] New console frontend, testing needed..
Message-ID: <CAHAreOpz=AmV8UJc--5E+9de841=JDYMHt5RjP0q=soCukUEXw@mail.gmail.com>

Hi all,

We have finally landed the two-process terminal frontend from

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

(which itself built on two previous PRs, #433 and #708).  This adds a
terminal-based frontend which you can start with

ipython console

it should feel pretty much like 'plain old' ipython, and supports
--pylab, profiles and all the same options.  But this one actually
runs the kernel in a separate process, which means it can attach to
kernels started by the Qt console or by the notebook.

If you're willing to test it and let us know of any problems, we'd
greatly appreciate it.  Those of you used to running from git need
only update master. If you want a static download, github conveniently
provides a download of master in zip and tar.gz formats:

https://github.com/ipython/ipython/zipball/master
https://github.com/ipython/ipython/tarball/master

A big thank you to those who put in all the effort to make this
happen, starting with Omar Zapata (this was the continuation of his
Summer of Code effort last year) and Paul Ivanov who built on top of
Omar's work.

Cheers,

f


From ellisonbg at gmail.com  Tue Dec  6 16:01:25 2011
From: ellisonbg at gmail.com (Brian Granger)
Date: Tue, 6 Dec 2011 13:01:25 -0800
Subject: [IPython-dev] New console frontend, testing needed..
In-Reply-To: <CAHAreOpz=AmV8UJc--5E+9de841=JDYMHt5RjP0q=soCukUEXw@mail.gmail.com>
References: <CAHAreOpz=AmV8UJc--5E+9de841=JDYMHt5RjP0q=soCukUEXw@mail.gmail.com>
Message-ID: <CAH4pYpTv5BxY6oV-0JRHrBB6JJjJdz806CkRkgDTtPAQomPJOA@mail.gmail.com>

Fantastic!  Great work everyone!

Cheers,

Brian

On Tue, Dec 6, 2011 at 12:18 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> Hi all,
>
> We have finally landed the two-process terminal frontend from
>
> https://github.com/ipython/ipython/pull/864
>
> (which itself built on two previous PRs, #433 and #708). ?This adds a
> terminal-based frontend which you can start with
>
> ipython console
>
> it should feel pretty much like 'plain old' ipython, and supports
> --pylab, profiles and all the same options. ?But this one actually
> runs the kernel in a separate process, which means it can attach to
> kernels started by the Qt console or by the notebook.
>
> If you're willing to test it and let us know of any problems, we'd
> greatly appreciate it. ?Those of you used to running from git need
> only update master. If you want a static download, github conveniently
> provides a download of master in zip and tar.gz formats:
>
> https://github.com/ipython/ipython/zipball/master
> https://github.com/ipython/ipython/tarball/master
>
> A big thank you to those who put in all the effort to make this
> happen, starting with Omar Zapata (this was the continuation of his
> Summer of Code effort last year) and Paul Ivanov who built on top of
> Omar's work.
>
> 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 benjaminrk at gmail.com  Tue Dec  6 16:07:51 2011
From: benjaminrk at gmail.com (MinRK)
Date: Tue, 6 Dec 2011 13:07:51 -0800
Subject: [IPython-dev] New console frontend, testing needed..
In-Reply-To: <CAHAreOpz=AmV8UJc--5E+9de841=JDYMHt5RjP0q=soCukUEXw@mail.gmail.com>
References: <CAHAreOpz=AmV8UJc--5E+9de841=JDYMHt5RjP0q=soCukUEXw@mail.gmail.com>
Message-ID: <CAHNn8BV9B7R-gz1D4HAuc4T3r9bjQoO7bOmDU5CA_PFaMxA9_A@mail.gmail.com>

On Tue, Dec 6, 2011 at 12:18, Fernando Perez <fperez.net at gmail.com> wrote:

> Hi all,
>
> We have finally landed the two-process terminal frontend from
>
> https://github.com/ipython/ipython/pull/864
>
> (which itself built on two previous PRs, #433 and #708).  This adds a
> terminal-based frontend which you can start with
>
> ipython console
>
> it should feel pretty much like 'plain old' ipython, and supports
> --pylab, profiles and all the same options.  But this one actually
> runs the kernel in a separate process, which means it can attach to
> kernels started by the Qt console or by the notebook.
>

I should note the principal shortcomings of this frontend (that I know of):

* Ctrl-C is wonky in pylab mode, because the sigint is still received in
the subprocess
* There is no shortcut for killing the kernel yet, but a simple
`os._exit(0)` works to restart the kernel.

-MiNRK


>
> If you're willing to test it and let us know of any problems, we'd
> greatly appreciate it.  Those of you used to running from git need
> only update master. If you want a static download, github conveniently
> provides a download of master in zip and tar.gz formats:
>
> https://github.com/ipython/ipython/zipball/master
> https://github.com/ipython/ipython/tarball/master
>
> A big thank you to those who put in all the effort to make this
> happen, starting with Omar Zapata (this was the continuation of his
> Summer of Code effort last year) and Paul Ivanov who built on top of
> Omar's work.
>
> 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/20111206/478eac92/attachment.html>

From kiranbkrishna at gmail.com  Thu Dec  8 00:11:10 2011
From: kiranbkrishna at gmail.com (Kiran Balakrishnan)
Date: Thu, 8 Dec 2011 10:41:10 +0530
Subject: [IPython-dev] (no subject)
Message-ID: <CAO1sCjUJw8BMZdAMn6GJzMXre1xwXj0QYu7b_Ou6wTa72MnW2A@mail.gmail.com>

Hi all ,
      I am a  new developer interested in IPython.
Last day I  tried out running Ipyhton from the Eclipse console.Eclipse
was set up  to execute python programs using the PyDev. But When i ran
IPython i found the output was in some unreadable format.(please see
the attached screenshot ).
Some characters where printed out as garbage values.Is it because
eclipse not supporting or using unicode encoding???? is there any way
to correct it.

I think Eclips ereally is a cool development environment , fixing this
issue may help  newbie developers (like me) to contribue more
effectively .

Regards
--
Kiran Balakrishnan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eclipse console.png
Type: image/png
Size: 58777 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20111208/d21b3bb3/attachment.png>

From benjaminrk at gmail.com  Thu Dec  8 00:28:54 2011
From: benjaminrk at gmail.com (MinRK)
Date: Wed, 7 Dec 2011 21:28:54 -0800
Subject: [IPython-dev] (no subject)
In-Reply-To: <CAO1sCjUJw8BMZdAMn6GJzMXre1xwXj0QYu7b_Ou6wTa72MnW2A@mail.gmail.com>
References: <CAO1sCjUJw8BMZdAMn6GJzMXre1xwXj0QYu7b_Ou6wTa72MnW2A@mail.gmail.com>
Message-ID: <CAHNn8BVe29WPjOPU15PuxVA3E-hChH4c0afBb+83evOqSZdEMQ@mail.gmail.com>

Those are the ANSI color escapes, which presumably your eclipse console
doesn't support.  Turning off the colors should solve the issue.

If you have control over startup args, then you can add `--colors=NoColor`

Or, you can set this as the default behavior in a config file.  In a shell:

    > ipython profile create

edit the ipython_profile.py that it created, and uncomment the line
containing 'TerminalInteractiveShell.colors', so it says:

c.TerminalInteractiveShell.colors = 'NoColor'

Or, in a pinch, you can to `%colors nocolor` after starting IPython to turn
off the coloring.

-MinRK

On Wed, Dec 7, 2011 at 21:11, Kiran Balakrishnan <kiranbkrishna at gmail.com>wrote:

> Hi all ,
>      I am a  new developer interested in IPython.
> Last day I  tried out running Ipyhton from the Eclipse console.Eclipse
> was set up  to execute python programs using the PyDev. But When i ran
> IPython i found the output was in some unreadable format.(please see
> the attached screenshot ).
> Some characters where printed out as garbage values.Is it because
> eclipse not supporting or using unicode encoding???? is there any way
> to correct it.
>
> I think Eclips ereally is a cool development environment , fixing this
> issue may help  newbie developers (like me) to contribue more
> effectively .
>
> Regards
> --
> Kiran Balakrishnan
>
> _______________________________________________
> 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/20111207/e1fd16bc/attachment.html>

From hans_meine at gmx.net  Thu Dec  8 04:29:21 2011
From: hans_meine at gmx.net (Hans Meine)
Date: Thu, 08 Dec 2011 10:29:21 +0100
Subject: [IPython-dev] Should we disable autocall by default from now on?
In-Reply-To: <CAOvn4qizBoa0gYz6W8uxZMi_Wi5hjD25SZ=uSuzYApAcaHeR=A@mail.gmail.com>
References: <CAHAreOp76zanWG9QioqO6Qb9gYuRCmSprJE_8M3onTjbxZCWGg@mail.gmail.com>
	<CAH4pYpRqBVe9+2J513UCfiUQfdW4z9Lv_MypDa_LtMH5PqpFnA@mail.gmail.com>
	<CAOvn4qizBoa0gYz6W8uxZMi_Wi5hjD25SZ=uSuzYApAcaHeR=A@mail.gmail.com>
Message-ID: <1620433.JRbgOOHdye@hmeine-pc>

Am Mittwoch, 30. November 2011, 22:56:05 schrieb Thomas Kluyver:
> [?] With the notebook, I imagine we
> could literally rewrite the cell to "plot(e1)". To my mind, that would
> clearly say "this is the right way to do it, but I knew what you meant."

That?s a really nice idea.  It also fixes one of autocall?s problem, namely 
that it becomes dangerous to copy-paste code into standard .py files.

My personal impression with autocall when I first heard about it was "wow - 
that?s useful", but over the years, I have only used it for very few use 
cases, i.e. for a small set of functions.  Some example were:

In [1]: ,execfile pythonic.py

In [1]: reload mymod

After some months, I was so used to this syntax, that I even started to think 
that the latter would call a %reload magic (yes, in spite of the line telling 
me about the expansion).

I guess the confusion would not have arised if I used autocall for more than 
this tiny set of functions.  However, even though I am a lazy typer, I believe 
I may be able to /type faster than I would have to think/ about whether the 
thing I want to achieve can be typed faster/shorter with autocall.
(Plus, I am now using the German "Neo" layout which has /all/ kinds of 
parentheses at your immediate fingertips. ;-p )

So, I would question the overall benefit of autocall not only for beginners, at 
least in a standard terminal.

Ciao,
  Hans


From hans_meine at gmx.net  Thu Dec  8 04:43:26 2011
From: hans_meine at gmx.net (Hans Meine)
Date: Thu, 08 Dec 2011 10:43:26 +0100
Subject: [IPython-dev] Should we disable autocall by default from now on?
In-Reply-To: <CAOvn4qizBoa0gYz6W8uxZMi_Wi5hjD25SZ=uSuzYApAcaHeR=A@mail.gmail.com>
References: <CAHAreOp76zanWG9QioqO6Qb9gYuRCmSprJE_8M3onTjbxZCWGg@mail.gmail.com>
	<CAH4pYpRqBVe9+2J513UCfiUQfdW4z9Lv_MypDa_LtMH5PqpFnA@mail.gmail.com>
	<CAOvn4qizBoa0gYz6W8uxZMi_Wi5hjD25SZ=uSuzYApAcaHeR=A@mail.gmail.com>
Message-ID: <3206869.ONNsygYv33@hmeine-pc>

I want to propose some changes (my previous mail got a little bit long, so I 
start over now):

Am Mittwoch, 30. November 2011, 22:56:05 schrieb Thomas Kluyver:
> I think this is a technical issue as much as anything. The terminal shell
> clearly shows the rewritten command, and it is sent as a payload over ZMQ,
> but AFAIK both of our frontends ignore it.

This should be fixed; indeed I do not see the expanded form anymore.

> With the notebook, I imagine we
> could literally rewrite the cell to "plot(e1)".

That would be great. In fact, I would propose to do this in all frontends:

- In graphical terminals (Qt, Notebook, Wx, ...), it should be
  rewritten in-place.
- In the standard terminal, /it should be rewritten in history/ at least.

Note that the latter can and should be done independent of other expansions 
(e.g. magics); I recall the discussion in which we (more or less) all agreed 
that history should give you the raw command (e.g. a magic) instead of 
revealing implementation details.

OTOH, I think with autocall, this could be better the other way round:

a) when copy-pasting from the history into .py files
b) when recalling and modifying the command into a more complex form
   not supported by autocall
c) with %recall or %macro and later copying into .py files

(Yes, c) is probably subsumed by a) )

What do you think?

Ciao,
  Hans


From takowl at gmail.com  Thu Dec  8 06:53:07 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Thu, 8 Dec 2011 11:53:07 +0000
Subject: [IPython-dev] Should we disable autocall by default from now on?
In-Reply-To: <3206869.ONNsygYv33@hmeine-pc>
References: <CAHAreOp76zanWG9QioqO6Qb9gYuRCmSprJE_8M3onTjbxZCWGg@mail.gmail.com>
	<CAH4pYpRqBVe9+2J513UCfiUQfdW4z9Lv_MypDa_LtMH5PqpFnA@mail.gmail.com>
	<CAOvn4qizBoa0gYz6W8uxZMi_Wi5hjD25SZ=uSuzYApAcaHeR=A@mail.gmail.com>
	<3206869.ONNsygYv33@hmeine-pc>
Message-ID: <CAOvn4qhBPtvrXzAGs7SOqgDY3Y9zHWfeSymg2qy6MVwg0+uHhw@mail.gmail.com>

On 8 December 2011 09:43, Hans Meine <hans_meine at gmx.net> wrote:

> - In the standard terminal, /it should be rewritten in history/ at least.
>
> Note that the latter can and should be done independent of other expansions
> (e.g. magics); I recall the discussion in which we (more or less) all
> agreed
> that history should give you the raw command (e.g. a magic) instead of
> revealing implementation details.
>

Just to summarise what currently happens with history: we store 'raw' and
'translated' history, where translated history should always be
syntactically valid Python code. Autocalling, magics, system commands and
aliases are all translated. Raw history is naturally exactly what the user
entered. For most things (%hist, %recall, %rerun, %pastebin and readline
history) we default to using the raw history. %macro, %edit and %save use
translated history.

What you're proposing would fit in as a sort of 'preferred' history,
picking raw or translated history depending on the contents. I can see how
that would be useful, but on the other hand I'm not sure that the benefits
merit the added complexity, especially now that autocall is off by default.

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

From kevin.buchs at gmail.com  Fri Dec  9 15:02:47 2011
From: kevin.buchs at gmail.com (Kevin Buchs)
Date: Fri, 9 Dec 2011 14:02:47 -0600
Subject: [IPython-dev] edit not executing on Windows
Message-ID: <CAKT9s6BkPfuxLx3tik3Ey6bV215w9pdo=HHFqf27UiNDp5b77Q@mail.gmail.com>

I have worked through the configuration so I might call emacs from a server
for my editor on MS Windows. However, I noted that the edited code is not
executed, though I have saved it. I am running the 0.12 beta. Here is the
snippet from my ipython_qtconsole_config.py:

import sys
if sys.platform == 'win32':
  c.IPythonWidget.editor = 'c:/apps/emacs/bin/emacsclient.exe -a
c:/apps/emacs/bin/runemacs.exe'
else:
  c.IPythonWidget.editor = 'emacsclient -a emacs'


There have been times in the past when I wished there was a way to invoke
the editor without executing the results, but now it seems to be behaving
that way all the time.

Have I missed something?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20111209/9ca5abaa/attachment.html>

From takowl at gmail.com  Fri Dec  9 15:06:33 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Fri, 9 Dec 2011 20:06:33 +0000
Subject: [IPython-dev] edit not executing on Windows
In-Reply-To: <CAKT9s6BkPfuxLx3tik3Ey6bV215w9pdo=HHFqf27UiNDp5b77Q@mail.gmail.com>
References: <CAKT9s6BkPfuxLx3tik3Ey6bV215w9pdo=HHFqf27UiNDp5b77Q@mail.gmail.com>
Message-ID: <CAOvn4qjY+7hoUFQhZXPQ3Z1RSkJOhiPWA7FjZ+kdQ9KkyHJtMQ@mail.gmail.com>

On 9 December 2011 20:02, Kevin Buchs <kevin.buchs at gmail.com> wrote:

> There have been times in the past when I wished there was a way to invoke
> the editor without executing the results, but now it seems to be behaving
> that way all the time.


Because of the slightly different model with a GUI editor (which often
won't block the parent process), we decided not to automatically execute
the code in the Qt console. There was some discussion about making this the
default in the terminal as well, but I don't think we changed that (yet).

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

From fperez.net at gmail.com  Sat Dec 10 17:27:53 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 10 Dec 2011 14:27:53 -0800
Subject: [IPython-dev] Victims of our own success,
	change of strategy needed to get 0.12 released...
Message-ID: <CAHAreOqXz0jDoby-4Z2ar4GkFq4-sNf2md=Dp0-yVYtKGfK4fg@mail.gmail.com>

Hi folks,

Since we have a fairly small team, I've always tried to avoid having
separate release branches, as that requires later merging those back
into the main development line and keeping for a while two truly
parallel lines of work.  Instead, we've tended to simply stabilize
master enough to release it and simply continue forward.

But that's just not going to work this time around: we're now victims
of our own success, and the stream of contributions is arriving faster
than we can safely merge them and see their impact for a release.
Serves us well for refactoring the code to be more modular, testable
and approachable, I guess :)

Now, I do *not* want to cut the enthusiastic contributions we're
getting, but we do need to have a period where we test a frozen
version on top of which we strictly apply *only fixes* and no actual
new code.  Basically we need to move to what many projects do already
with a release branch that is frozen while master continues evolving,
and 0.12 will released from that release branch.

So what I'd like to do is to triage, from our list of currently 16
open PRs, what do we actually want to go into 0.12.  After that list
is established, we'll try to merge *only those* and will create an
actual 0.12 branch to further stabilize them.  New PRs can be directed
to master, but those we'll either merge right away  (if they are done)
or we'll retarget them to a 0.12 branch we'll push to the main repo.

So let me know which ones you think are either nearly ready or
important enough to target them for 0.12, and we'll do this.

Cheers,

f


From benjaminrk at gmail.com  Sat Dec 10 19:02:25 2011
From: benjaminrk at gmail.com (MinRK)
Date: Sat, 10 Dec 2011 16:02:25 -0800
Subject: [IPython-dev] Victims of our own success,
 change of strategy needed to get 0.12 released...
In-Reply-To: <CAHAreOqXz0jDoby-4Z2ar4GkFq4-sNf2md=Dp0-yVYtKGfK4fg@mail.gmail.com>
References: <CAHAreOqXz0jDoby-4Z2ar4GkFq4-sNf2md=Dp0-yVYtKGfK4fg@mail.gmail.com>
Message-ID: <CAHNn8BWh+ZVtu7ORYrNwE=DVFJ4ReL3KGX9RFxN+zXJiw2uqqw@mail.gmail.com>

A summary of the ones currently outstanding:

General:
811 (OSError): incomplete, not to be merged
1073 (storemagic/default extensions):
    Proposes extra work to move extensions to Shell from App.  I suggest
letting the extra work wait until after release, and merge this one as-is.
1116 (shlex unicode): BLOCKER
    I believe this is ready as-is.  It needs a rebase, because it's based
on a branch that was already merged via cherry-pick, but that can easily be
done at merge time.  I'd be happy doing this right now.
1120 (vim-ipython):
    This is Paul's, and doesn't touch the core.  We should just merge it,
wherever it is, when we cut the RC, as Paul describes in the PR.
1128 (pylab start menu and profile): BLOCKER
    Minor issue and easy fix, a conversation is all we need. Since we ship
a broken button, it should be merged.
    I think based on Fernando's lates comment on the mailing list, the
recommendation is to remove the pylab profile
    that we ship altogether, and make the start menu item just do `--pylab`.
1129 (unified setup.py):
    Looks perfectly fine to me, but I am wary of a significant change to
setup.py immediately before release.  I would let this one slide, and merge
immediately after release.
1130 (arg_split / ValueError):
    I'd let this one slip.  %timeit is the principally improved magic, and
this particular fix could have unforeseen implications. The right answer
should probably be that some/all magics *do not* use arg_split, which is
really for something else, instead using their own function that behaves
appropriately.
1137 (MPIExec->MPI rename):
    Simple rename of a few launchers, so that the MPILauncher names are
more symmetrical with SGE/MPI/SSH/PBS/LSF.  I would like this in 0.12,
simply because it means the old names won't need to survive in a deprecated
form for as long.
1138 (symlink):
    One line fix in a test, I'll merge it now.
1140 (embed): BLOCKER
    This one is really important, because part of embedding just doesn't
work right now.  It could be ready as-is, I'm just not familiar enough with
the relevant code to be able to tell.

Notebook related:

873 (ReST): incomplete, not to be merged
1079 (login/logout buttons in the notebook):
    The principal issue this fixes is that no login button is drawn during
a read-only view, when login is possible.  You must explicitly visit
    notebook/login in order to login.
    It is incomplete at this point, and principally a convenience
improvement for an uncommon use case.  We need not block on it, but it
would be nice for users of read-only mode for following along.
1125 (notebook logo):
    Still ironing out alignment issues.  It's an aesthetic improvement, so
I wouldn't block on it.
1132 (name field):
    Principally aesthetic improvement to read-only mode.  Looks clean and
simple, should be ready for merge after a quick test.
1135 (custom settings to notebook webapp):
    I think this should be merged.  It's tiny and clean, but makes
customizing the notebook *much* easier, without requiring write access to
the IPython source dir, and is friendlier to environments where serving
static files from a source tree is inappropriate.
1139 (notification):
    Proof of concept, not meant to be merged.

In general, we can't wait for the notebook to be perfect, or we won't get
0.12 out for years.

QtConsole related:

1122 (IPythonWidget.execute_file):
    Fixes a quote-escape issue in IPythonWidget.execute_file, a method that
is used for nothing at all, as far as I can tell.  Looks fine to me, but I
don't know why we have the method at all.

My reading of the list:
blockers: 1116, 1128, 1140
I recommend: 1073, 1120, 1122, 1132, 1135, 1137
should go in if they are finished in time, but shouldn't block: 1079, 1125
recommend pushing to after release: 1129, 1130, 1139

-MinRK

On Sat, Dec 10, 2011 at 14:27, Fernando Perez <fperez.net at gmail.com> wrote:

> Hi folks,
>
> Since we have a fairly small team, I've always tried to avoid having
> separate release branches, as that requires later merging those back
> into the main development line and keeping for a while two truly
> parallel lines of work.  Instead, we've tended to simply stabilize
> master enough to release it and simply continue forward.
>
> But that's just not going to work this time around: we're now victims
> of our own success, and the stream of contributions is arriving faster
> than we can safely merge them and see their impact for a release.
> Serves us well for refactoring the code to be more modular, testable
> and approachable, I guess :)
>
> Now, I do *not* want to cut the enthusiastic contributions we're
> getting, but we do need to have a period where we test a frozen
> version on top of which we strictly apply *only fixes* and no actual
> new code.  Basically we need to move to what many projects do already
> with a release branch that is frozen while master continues evolving,
> and 0.12 will released from that release branch.
>
> So what I'd like to do is to triage, from our list of currently 16
> open PRs, what do we actually want to go into 0.12.  After that list
> is established, we'll try to merge *only those* and will create an
> actual 0.12 branch to further stabilize them.  New PRs can be directed
> to master, but those we'll either merge right away  (if they are done)
> or we'll retarget them to a 0.12 branch we'll push to the main repo.
>
> So let me know which ones you think are either nearly ready or
> important enough to target them for 0.12, and we'll do this.
>
> 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/20111210/08a1fcd0/attachment.html>

From takowl at gmail.com  Sat Dec 10 19:40:02 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Sun, 11 Dec 2011 00:40:02 +0000
Subject: [IPython-dev] Victims of our own success,
 change of strategy needed to get 0.12 released...
In-Reply-To: <CAHNn8BWh+ZVtu7ORYrNwE=DVFJ4ReL3KGX9RFxN+zXJiw2uqqw@mail.gmail.com>
References: <CAHAreOqXz0jDoby-4Z2ar4GkFq4-sNf2md=Dp0-yVYtKGfK4fg@mail.gmail.com>
	<CAHNn8BWh+ZVtu7ORYrNwE=DVFJ4ReL3KGX9RFxN+zXJiw2uqqw@mail.gmail.com>
Message-ID: <CAOvn4qgcoRhPu0XU9mcJW-wu5j5jX9brxbQH4QkrUH49ir1GCg@mail.gmail.com>

Commenting on a couple of my own PRs:

On 11 December 2011 00:02, MinRK <benjaminrk at gmail.com> wrote:

> 1073 (storemagic/default extensions):
>     Proposes extra work to move extensions to Shell from App.  I suggest
> letting the extra work wait until after release, and merge this one as-is.
>

That sounds fine to me. I'd like to add extensions to the shell so they can
be used for more default functionality (anything in the app isn't used when
IPython is embedded), but it's not a big deal at the moment.


> 1129 (unified setup.py):
>     Looks perfectly fine to me, but I am wary of a significant change to
> setup.py immediately before release.  I would let this one slide, and merge
> immediately after release.
>

Not a problem, but in that case I'd like to get a simpler fix for #1119
(start menu shortcuts in Python 3) into 0.12. I'll try to do a PR soon.

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

From benjaminrk at gmail.com  Sat Dec 10 20:38:37 2011
From: benjaminrk at gmail.com (MinRK)
Date: Sat, 10 Dec 2011 17:38:37 -0800
Subject: [IPython-dev] Victims of our own success,
 change of strategy needed to get 0.12 released...
In-Reply-To: <CAOvn4qgcoRhPu0XU9mcJW-wu5j5jX9brxbQH4QkrUH49ir1GCg@mail.gmail.com>
References: <CAHAreOqXz0jDoby-4Z2ar4GkFq4-sNf2md=Dp0-yVYtKGfK4fg@mail.gmail.com>
	<CAHNn8BWh+ZVtu7ORYrNwE=DVFJ4ReL3KGX9RFxN+zXJiw2uqqw@mail.gmail.com>
	<CAOvn4qgcoRhPu0XU9mcJW-wu5j5jX9brxbQH4QkrUH49ir1GCg@mail.gmail.com>
Message-ID: <CAHNn8BWdiSZtxcy_iRODLeWKp-MZLGCfQxOO+BAi1Eu7wjJvtg@mail.gmail.com>

Based on Thomas' sharp eyes on #1116, it turns out that it depends on my
#1130, which I previously recommended postponing.  I have adjusted #1130 to
be more conservative, so I am no longer concerned about side effects.
 Since #1116 is actually serious and depends on it, we should merge them
both.

-MinRK

On Sat, Dec 10, 2011 at 16:40, Thomas Kluyver <takowl at gmail.com> wrote:

> Commenting on a couple of my own PRs:
>
>
> On 11 December 2011 00:02, MinRK <benjaminrk at gmail.com> wrote:
>
>> 1073 (storemagic/default extensions):
>>     Proposes extra work to move extensions to Shell from App.  I suggest
>> letting the extra work wait until after release, and merge this one as-is.
>>
>
> That sounds fine to me. I'd like to add extensions to the shell so they
> can be used for more default functionality (anything in the app isn't used
> when IPython is embedded), but it's not a big deal at the moment.
>
>
>> 1129 (unified setup.py):
>>     Looks perfectly fine to me, but I am wary of a significant change to
>> setup.py immediately before release.  I would let this one slide, and merge
>> immediately after release.
>>
>
> Not a problem, but in that case I'd like to get a simpler fix for #1119
> (start menu shortcuts in Python 3) into 0.12. I'll try to do a PR soon.
>
> Thanks,
> Thomas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20111210/b75d3061/attachment.html>

From benjaminrk at gmail.com  Sat Dec 10 20:42:36 2011
From: benjaminrk at gmail.com (MinRK)
Date: Sat, 10 Dec 2011 17:42:36 -0800
Subject: [IPython-dev] Victims of our own success,
 change of strategy needed to get 0.12 released...
In-Reply-To: <CAOvn4qgcoRhPu0XU9mcJW-wu5j5jX9brxbQH4QkrUH49ir1GCg@mail.gmail.com>
References: <CAHAreOqXz0jDoby-4Z2ar4GkFq4-sNf2md=Dp0-yVYtKGfK4fg@mail.gmail.com>
	<CAHNn8BWh+ZVtu7ORYrNwE=DVFJ4ReL3KGX9RFxN+zXJiw2uqqw@mail.gmail.com>
	<CAOvn4qgcoRhPu0XU9mcJW-wu5j5jX9brxbQH4QkrUH49ir1GCg@mail.gmail.com>
Message-ID: <CAHNn8BVRbf0L6wVrQX_xyNmLtvEmy0yDMWx3D-iBe-gPhDiCjQ@mail.gmail.com>

On Sat, Dec 10, 2011 at 16:40, Thomas Kluyver <takowl at gmail.com> wrote:

> Commenting on a couple of my own PRs:
>
>
> On 11 December 2011 00:02, MinRK <benjaminrk at gmail.com> wrote:
>
>> 1073 (storemagic/default extensions):
>>     Proposes extra work to move extensions to Shell from App.  I suggest
>> letting the extra work wait until after release, and merge this one as-is.
>>
>
> That sounds fine to me. I'd like to add extensions to the shell so they
> can be used for more default functionality (anything in the app isn't used
> when IPython is embedded), but it's not a big deal at the moment.
>
>
>> 1129 (unified setup.py):
>>     Looks perfectly fine to me, but I am wary of a significant change to
>> setup.py immediately before release.  I would let this one slide, and merge
>> immediately after release.
>>
>
> Not a problem, but in that case I'd like to get a simpler fix for #1119
> (start menu shortcuts in Python 3) into 0.12. I'll try to do a PR soon.
>

Since the Start Menu shortcuts are for the Windows .exe installer only
(right?), I'm fine simply leaving them out of this release.  I don't think
they are particularly important to more advanced users, which I think is a
superset of those running Python 3.


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

From benjaminrk at gmail.com  Sat Dec 10 22:48:55 2011
From: benjaminrk at gmail.com (Min RK)
Date: Sat, 10 Dec 2011 19:48:55 -0800
Subject: [IPython-dev] Victims of our own success,
	change of strategy needed to get 0.12 released...
In-Reply-To: <CACJ8dbXOQruJVVJH2STLwbY-Pc2SQafp4C7YEq+MZ5eN6Rn4Og@mail.gmail.com>
References: <CAHAreOqXz0jDoby-4Z2ar4GkFq4-sNf2md=Dp0-yVYtKGfK4fg@mail.gmail.com>
	<CAHNn8BWh+ZVtu7ORYrNwE=DVFJ4ReL3KGX9RFxN+zXJiw2uqqw@mail.gmail.com>
	<CACJ8dbXOQruJVVJH2STLwbY-Pc2SQafp4C7YEq+MZ5eN6Rn4Og@mail.gmail.com>
Message-ID: <6C3006FF-6E75-4969-940D-F40ACC994A76@gmail.com>


On Dec 10, 2011, at 19:27, Jonathan March <jmarch at enthought.com> wrote:

> On Sat, Dec 10, 2011 at 6:02 PM, MinRK <benjaminrk at gmail.com> wrote:
> QtConsole related:
> 
> 1122 (IPythonWidget.execute_file):
>     Fixes a quote-escape issue in IPythonWidget.execute_file, a method that is used for nothing at all, as far as I can tell.  Looks fine to me, but I don't know why we have the method at all.
> 
> This *is* used in some applications which embed a qtconsole widget, though not in the ipython-qtconsole app itself.

Okay, that makes sense.

>   
> I recommend: ... 1122...
> 
> Thanks,
> Jonathan
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20111210/c28c0cda/attachment.html>

From takowl at gmail.com  Sun Dec 11 06:37:52 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Sun, 11 Dec 2011 11:37:52 +0000
Subject: [IPython-dev] Victims of our own success,
 change of strategy needed to get 0.12 released...
In-Reply-To: <CAHNn8BVRbf0L6wVrQX_xyNmLtvEmy0yDMWx3D-iBe-gPhDiCjQ@mail.gmail.com>
References: <CAHAreOqXz0jDoby-4Z2ar4GkFq4-sNf2md=Dp0-yVYtKGfK4fg@mail.gmail.com>
	<CAHNn8BWh+ZVtu7ORYrNwE=DVFJ4ReL3KGX9RFxN+zXJiw2uqqw@mail.gmail.com>
	<CAOvn4qgcoRhPu0XU9mcJW-wu5j5jX9brxbQH4QkrUH49ir1GCg@mail.gmail.com>
	<CAHNn8BVRbf0L6wVrQX_xyNmLtvEmy0yDMWx3D-iBe-gPhDiCjQ@mail.gmail.com>
Message-ID: <CAOvn4qgNw0U607q-bRCTFCW3EvFFHV99rSqwschxaCrqaia4=Q@mail.gmail.com>

On 11 December 2011 01:42, MinRK <benjaminrk at gmail.com> wrote:

> Since the Start Menu shortcuts are for the Windows .exe installer only
> (right?), I'm fine simply leaving them out of this release.  I don't think
> they are particularly important to more advanced users, which I think is a
> superset of those running Python 3.


I don't think it's necessarily only advanced users running Python 3. I see
a fair few questions from newcomers who've picked Python 3 to start off
with. Whether or not we think that's a good idea, I don't want to put
another hurdle in their way when it should be trivially fixable.

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

From kevin.buchs at gmail.com  Mon Dec 12 14:46:02 2011
From: kevin.buchs at gmail.com (Kevin Buchs)
Date: Mon, 12 Dec 2011 13:46:02 -0600
Subject: [IPython-dev] 0.12 testing: MS Windows terminal history editing
Message-ID: <CAKT9s6Cue6rVKNNeu6ubu3JN6owKMtkiuUmk09xA-o+bkDQB6Q@mail.gmail.com>

I've been working with ipython 0.12 development version for a bit. I just
updated my git clone to verify that this problem has not been fixed.

History editing in default mode (terminal) on Windows XP is misbehaving.
When recalling multi-line commands from history,
sometimes the cursor is placed in the middle vertically or at the top
vertically and cannot move any further to the right. Other times a line may
be chopped off, though it is actually there and when executing it does run.
Other problems exist with redrawing and text insertion.

See the attached screen shot, where I cut in beginning on a *history -n* output
and then *rep*(layed) entry 50 for "In [56]. You can see the underline
cursor appear on the top of three lines, out into space on the right side.

[image: ipython -pylab_2011-12-12_09-50-16.png]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20111212/4ad7d683/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipython -pylab_2011-12-12_09-50-16.png
Type: image/png
Size: 6024 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20111212/4ad7d683/attachment.png>

From jorgen.stenarson at bostream.nu  Mon Dec 12 17:49:36 2011
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Mon, 12 Dec 2011 23:49:36 +0100
Subject: [IPython-dev] 0.12 testing: MS Windows terminal history editing
In-Reply-To: <CAKT9s6Cue6rVKNNeu6ubu3JN6owKMtkiuUmk09xA-o+bkDQB6Q@mail.gmail.com>
References: <CAKT9s6Cue6rVKNNeu6ubu3JN6owKMtkiuUmk09xA-o+bkDQB6Q@mail.gmail.com>
Message-ID: <4EE68500.6040709@bostream.nu>

Kevin Buchs skrev 2011-12-12 20:46:
> I've been working with ipython 0.12 development version for a bit. I
> just updated my git clone to verify that this problem has not been fixed.
>
> History editing in default mode (terminal) on Windows XP is misbehaving.
> When recalling multi-line commands from history,
> sometimes the cursor is placed in the middle vertically or at the top
> vertically and cannot move any further to the right. Other times a line
> may be chopped off, though it is actually there and when executing it
> does run. Other problems exist with redrawing and text insertion.
>
> See the attached screen shot, where I cut in beginning on a *history
> -n* output and then *rep*(layed) entry 50 for "In [56]. You can see the
> underline cursor appear on the top of three lines, out into space on the
> right side.
>
> ipython -pylab_2011-12-12_09-50-16.png
>

Your problems are most likely because pyreadline is not designed to 
handle multiline edits. It is not something I'm personally interested in 
working on. So unless someone else submits a patch it is unlikely to be 
implemented in the near future.

/J?rgen


From benjaminrk at gmail.com  Mon Dec 12 18:45:54 2011
From: benjaminrk at gmail.com (MinRK)
Date: Mon, 12 Dec 2011 15:45:54 -0800
Subject: [IPython-dev] Victims of our own success,
 change of strategy needed to get 0.12 released...
In-Reply-To: <CAOvn4qgNw0U607q-bRCTFCW3EvFFHV99rSqwschxaCrqaia4=Q@mail.gmail.com>
References: <CAHAreOqXz0jDoby-4Z2ar4GkFq4-sNf2md=Dp0-yVYtKGfK4fg@mail.gmail.com>
	<CAHNn8BWh+ZVtu7ORYrNwE=DVFJ4ReL3KGX9RFxN+zXJiw2uqqw@mail.gmail.com>
	<CAOvn4qgcoRhPu0XU9mcJW-wu5j5jX9brxbQH4QkrUH49ir1GCg@mail.gmail.com>
	<CAHNn8BVRbf0L6wVrQX_xyNmLtvEmy0yDMWx3D-iBe-gPhDiCjQ@mail.gmail.com>
	<CAOvn4qgNw0U607q-bRCTFCW3EvFFHV99rSqwschxaCrqaia4=Q@mail.gmail.com>
Message-ID: <CAHNn8BUHexft-5Dpn6kZFq3yhZyO=L3PsZ=tF_YZ+L=Bi15Yug@mail.gmail.com>

After some helpful review, We've got all the serious ones merged, just
waiting on:

1140: fixes for embedding
1128: pylab start menu item

Both of which could already be finished, but are awaiting confirmation.

Then it's just merging Paul's vim-ipython PR wherever it is at the time of
RC, and we can merge Stefan's read-only login button improvements if they
are finished in time.

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

From takowl at gmail.com  Mon Dec 12 19:09:30 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Tue, 13 Dec 2011 00:09:30 +0000
Subject: [IPython-dev] Victims of our own success,
 change of strategy needed to get 0.12 released...
In-Reply-To: <CAHNn8BUHexft-5Dpn6kZFq3yhZyO=L3PsZ=tF_YZ+L=Bi15Yug@mail.gmail.com>
References: <CAHAreOqXz0jDoby-4Z2ar4GkFq4-sNf2md=Dp0-yVYtKGfK4fg@mail.gmail.com>
	<CAHNn8BWh+ZVtu7ORYrNwE=DVFJ4ReL3KGX9RFxN+zXJiw2uqqw@mail.gmail.com>
	<CAOvn4qgcoRhPu0XU9mcJW-wu5j5jX9brxbQH4QkrUH49ir1GCg@mail.gmail.com>
	<CAHNn8BVRbf0L6wVrQX_xyNmLtvEmy0yDMWx3D-iBe-gPhDiCjQ@mail.gmail.com>
	<CAOvn4qgNw0U607q-bRCTFCW3EvFFHV99rSqwschxaCrqaia4=Q@mail.gmail.com>
	<CAHNn8BUHexft-5Dpn6kZFq3yhZyO=L3PsZ=tF_YZ+L=Bi15Yug@mail.gmail.com>
Message-ID: <CAOvn4qhc9wBShj8L1KaKZvph6n10cYDozeas5acoy+ni2J6VbQ@mail.gmail.com>

On 12 December 2011 23:45, MinRK <benjaminrk at gmail.com> wrote:

> 1140: fixes for embedding


And I've just merged this one. Besides a bugfix, that restores the
backwards compatibility we needed for Debian/Ubuntu.

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

From fperez.net at gmail.com  Mon Dec 12 20:13:51 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 12 Dec 2011 17:13:51 -0800
Subject: [IPython-dev] 0.12 testing: MS Windows terminal history editing
In-Reply-To: <4EE68500.6040709@bostream.nu>
References: <CAKT9s6Cue6rVKNNeu6ubu3JN6owKMtkiuUmk09xA-o+bkDQB6Q@mail.gmail.com>
	<4EE68500.6040709@bostream.nu>
Message-ID: <CAHAreOphTBhD1OpQ9QujkVcdH8fF-F6CzEp1jaheRf=KErZk4w@mail.gmail.com>

On Mon, Dec 12, 2011 at 2:49 PM, J?rgen Stenarson
<jorgen.stenarson at bostream.nu> wrote:
> Your problems are most likely because pyreadline is not designed to
> handle multiline edits. It is not something I'm personally interested in
> working on. So unless someone else submits a patch it is unlikely to be
> implemented in the near future.

Then  we should probably change things to make multiline history false
by default on Windows, no?

Cheers,

f


From fperez.net at gmail.com  Mon Dec 12 21:02:34 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 12 Dec 2011 18:02:34 -0800
Subject: [IPython-dev] Victims of our own success,
 change of strategy needed to get 0.12 released...
In-Reply-To: <CAOvn4qhc9wBShj8L1KaKZvph6n10cYDozeas5acoy+ni2J6VbQ@mail.gmail.com>
References: <CAHAreOqXz0jDoby-4Z2ar4GkFq4-sNf2md=Dp0-yVYtKGfK4fg@mail.gmail.com>
	<CAHNn8BWh+ZVtu7ORYrNwE=DVFJ4ReL3KGX9RFxN+zXJiw2uqqw@mail.gmail.com>
	<CAOvn4qgcoRhPu0XU9mcJW-wu5j5jX9brxbQH4QkrUH49ir1GCg@mail.gmail.com>
	<CAHNn8BVRbf0L6wVrQX_xyNmLtvEmy0yDMWx3D-iBe-gPhDiCjQ@mail.gmail.com>
	<CAOvn4qgNw0U607q-bRCTFCW3EvFFHV99rSqwschxaCrqaia4=Q@mail.gmail.com>
	<CAHNn8BUHexft-5Dpn6kZFq3yhZyO=L3PsZ=tF_YZ+L=Bi15Yug@mail.gmail.com>
	<CAOvn4qhc9wBShj8L1KaKZvph6n10cYDozeas5acoy+ni2J6VbQ@mail.gmail.com>
Message-ID: <CAHAreOp2Nhb9ZjUcdibzqsV74gDH=EdAcWRAv9ubpNopp-KESw@mail.gmail.com>

On Mon, Dec 12, 2011 at 4:09 PM, Thomas Kluyver <takowl at gmail.com> wrote:
> And I've just merged this one. Besides a bugfix, that restores the backwards
> compatibility we needed for Debian/Ubuntu.

Thanks a lot everyone for this awesome work!  We're now very close, we
should be able to cut an RC very soon.

Cheers,

f


From fperez.net at gmail.com  Tue Dec 13 02:03:42 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 12 Dec 2011 23:03:42 -0800
Subject: [IPython-dev] Victims of our own success,
 change of strategy needed to get 0.12 released...
In-Reply-To: <CAHAreOp2Nhb9ZjUcdibzqsV74gDH=EdAcWRAv9ubpNopp-KESw@mail.gmail.com>
References: <CAHAreOqXz0jDoby-4Z2ar4GkFq4-sNf2md=Dp0-yVYtKGfK4fg@mail.gmail.com>
	<CAHNn8BWh+ZVtu7ORYrNwE=DVFJ4ReL3KGX9RFxN+zXJiw2uqqw@mail.gmail.com>
	<CAOvn4qgcoRhPu0XU9mcJW-wu5j5jX9brxbQH4QkrUH49ir1GCg@mail.gmail.com>
	<CAHNn8BVRbf0L6wVrQX_xyNmLtvEmy0yDMWx3D-iBe-gPhDiCjQ@mail.gmail.com>
	<CAOvn4qgNw0U607q-bRCTFCW3EvFFHV99rSqwschxaCrqaia4=Q@mail.gmail.com>
	<CAHNn8BUHexft-5Dpn6kZFq3yhZyO=L3PsZ=tF_YZ+L=Bi15Yug@mail.gmail.com>
	<CAOvn4qhc9wBShj8L1KaKZvph6n10cYDozeas5acoy+ni2J6VbQ@mail.gmail.com>
	<CAHAreOp2Nhb9ZjUcdibzqsV74gDH=EdAcWRAv9ubpNopp-KESw@mail.gmail.com>
Message-ID: <CAHAreOoe--rUqizDAg2cy7jAuC5rkr542gwhPkMx_JRt8aHEOQ@mail.gmail.com>

On Mon, Dec 12, 2011 at 6:02 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> Thanks a lot everyone for this awesome work! ?We're now very close, we
> should be able to cut an RC very soon.

OK, so looking at what we have, it seems we should be able to cut the
RC tomorrow.  Of things we can merge before the RC, we have:

# 1079: if Stefan can finish it up quickly, we can go ahead with it.
Otherwise it will go to post-0.12.

# 1120: it doesn't have any dependencies.  Paul, should  we just go
ahead and merge now?

# 1129: currently conflicted, but a quick rebase should take care of it.

If all goes well, we'll merge the three above and can cut the RC right
away.  The only blocker we have left tagged for 0.12 is our old
nemesis:

https://github.com/ipython/ipython/issues/481

Given that nobody seems to know how to fix it, we can't hold 0.12
indefinitely for it.

A medal awaits the brave hero who slays this particular dragon, but in
the meantime, we'll have to push 0.12 out without a fix if no solution
is found in the next few days.

Besides that, we only have three more issues that are of type 'bug'
and targeted for 0.12:

https://github.com/ipython/ipython/issues?labels=type-bug&sort=created&direction=desc&state=open&page=1&milestone=6

and I think we can live if it goes out without any of them fixed
(we'll move them to 0.13, obviously).

All in all, I think we're in pretty good shape!  Thanks everyone for
working so hard in the past few days to get us here.

Cheers,

f


From fperez.net at gmail.com  Tue Dec 13 22:15:39 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 13 Dec 2011 19:15:39 -0800
Subject: [IPython-dev] IPython 0.12.rc1 ready for testing!
Message-ID: <CAHAreOqextNncJaN4om8xX-v7cNB7b38shi4veMY_APfowe31w@mail.gmail.com>

Hi all,

I've just uploaded our first (and hopefully only) release candidate to
the download site:

http://archive.ipython.org/testing/0.12.rc1/

Please beat on it and let us know of anything that doesn't work.  At
this point we'll only commit critical bugfixes and
documentation/example updates (there's a fair bit of those still to
do).

If the RC period lingers for long and there's pressure to start moving
again on master, we'll make a separate branch for 0.12.  But it seems
after last weekend's blitz we may be able to just develop straight on
master for the next few days, since thanks to everyone's hard work all
the stuff that was in flight got landed.

So have at it, and hopefully before too long we can be confident
enough of it to call the final 0.12 out!  If possible I'd like to do
that this coming weekend, but we'll see both how everyone's schedule
and the RC work out.

Cheers,

f


From ischnell at enthought.com  Tue Dec 13 22:43:32 2011
From: ischnell at enthought.com (Ilan Schnell)
Date: Tue, 13 Dec 2011 21:43:32 -0600
Subject: [IPython-dev] IPython 0.12.rc1 ready for testing!
In-Reply-To: <CAHAreOqextNncJaN4om8xX-v7cNB7b38shi4veMY_APfowe31w@mail.gmail.com>
References: <CAHAreOqextNncJaN4om8xX-v7cNB7b38shi4veMY_APfowe31w@mail.gmail.com>
Message-ID: <CAAUn5q+WAdCcXBapFpvPmoNygkQ4v=f++mvLhSs=SMqcKCEUug@mail.gmail.com>

That's great news.  I'll start testing it tomorrow.

- Ilan


On Tue, Dec 13, 2011 at 9:15 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> Hi all,
>
> I've just uploaded our first (and hopefully only) release candidate to
> the download site:
>
> http://archive.ipython.org/testing/0.12.rc1/
>
> Please beat on it and let us know of anything that doesn't work. ?At
> this point we'll only commit critical bugfixes and
> documentation/example updates (there's a fair bit of those still to
> do).
>
> If the RC period lingers for long and there's pressure to start moving
> again on master, we'll make a separate branch for 0.12. ?But it seems
> after last weekend's blitz we may be able to just develop straight on
> master for the next few days, since thanks to everyone's hard work all
> the stuff that was in flight got landed.
>
> So have at it, and hopefully before too long we can be confident
> enough of it to call the final 0.12 out! ?If possible I'd like to do
> that this coming weekend, but we'll see both how everyone's schedule
> and the RC work out.
>
> 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  Wed Dec 14 15:57:27 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 14 Dec 2011 12:57:27 -0800
Subject: [IPython-dev] From the sage list: thinking about our messaging
	protocol
Message-ID: <CAHAreOq3Sb7oPzSRO-jCQ81nwxgdhGGoRSV=NFk7GGQXm=8ToQ@mail.gmail.com>

Hi folks,

this conversation started on the sage-dev list, but I'm moving part of
it over here b/c it's really about our messaging protocol...

It would be great if ultimately we have a set of protocol tests that
validate our spec, as others are beginning to rely on the spec and
it's pretty easy to drift if we have no tests telling us what is meant
to stay.  That doesn't mean we can never tweak the spec as we better
understand certain cases, but we'll do it explicitly and not by
accidental code drift.

Cheers,

f
---------- Forwarded message ----------
From: Jason Grout <jason-sage at creativetrax.com>
Date: Wed, Dec 14, 2011 at 12:43 PM
Subject: [sage-devel] Re: Questions about the single-cell server
To: sage-devel at googlegroups.com


On 12/14/11 1:57 PM, Fernando Perez wrote:
>
> At this point we have a spec in the document you
> pointed to, but precious little in the way of independent compliance
> testing, so there's a real danger of the actual implementation
> diverging from the specification simply by accident.



Already I see it's changed from what we implemented. ?For example,
your header now contains the msg_type, and the top-level contains the
msg_id, duplicating both pieces of information. ?To me, it makes sense
to keep things the way they were (msg_id in header, msg_type at the
top-level), and don't duplicate the information. ?This minimizes the
information that has to go back and forth (no need to send back the
msg_type in the parent_header, since the client could just store it,
though I suppose the argument could be made that msg_type really does
belong in the header).

What if the msg_id or msg_type between the header and the top-level is
inconsistent? ?Which takes precedence? I presume that the header
information takes precedence, but since the top-level fields are for
convenience, my guess is that in practice, the top-level fields take
precedence, since if you have to compare the top-level fields with the
header fields, you might as well just use the header fields.

A very simple wrapper function on the receiving end can add the
convenience fields if they really need to be at the top-level, and
that would guarantee consistency.

Feel free to CC this message over to the ipython list if you want to
take up the discussion there.

Thanks,

Jason


--
To post to this group, send an email to sage-devel at googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscribe at googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org


From benjaminrk at gmail.com  Wed Dec 14 17:17:40 2011
From: benjaminrk at gmail.com (MinRK)
Date: Wed, 14 Dec 2011 14:17:40 -0800
Subject: [IPython-dev] From the sage list: thinking about our messaging
	protocol
In-Reply-To: <CAHAreOq3Sb7oPzSRO-jCQ81nwxgdhGGoRSV=NFk7GGQXm=8ToQ@mail.gmail.com>
References: <CAHAreOq3Sb7oPzSRO-jCQ81nwxgdhGGoRSV=NFk7GGQXm=8ToQ@mail.gmail.com>
Message-ID: <CAHNn8BXTd2nsNv8q9vqtE0tJRteyBmc+2QS4A_UnsC6-p5Xb1A@mail.gmail.com>

Hello,

On Wed, Dec 14, 2011 at 12:57, Fernando Perez <fperez.net at gmail.com> wrote:
> Hi folks,
>
> this conversation started on the sage-dev list, but I'm moving part of
> it over here b/c it's really about our messaging protocol...
>
> It would be great if ultimately we have a set of protocol tests that
> validate our spec, as others are beginning to rely on the spec and
> it's pretty easy to drift if we have no tests telling us what is meant
> to stay. ?That doesn't mean we can never tweak the spec as we better
> understand certain cases, but we'll do it explicitly and not by
> accidental code drift.
>
> Cheers,
>
> f
> ---------- Forwarded message ----------
> From: Jason Grout <jason-sage at creativetrax.com>
> Date: Wed, Dec 14, 2011 at 12:43 PM
> Subject: [sage-devel] Re: Questions about the single-cell server
> To: sage-devel at googlegroups.com
>
>
> On 12/14/11 1:57 PM, Fernando Perez wrote:
>>
>> At this point we have a spec in the document you
>> pointed to, but precious little in the way of independent compliance
>> testing, so there's a real danger of the actual implementation
>> diverging from the specification simply by accident.
>
>
>
> Already I see it's changed from what we implemented. ?For example,
> your header now contains the msg_type, and the top-level contains the
> msg_id, duplicating both pieces of information. ?To me, it makes sense
> to keep things the way they were (msg_id in header, msg_type at the
> top-level), and don't duplicate the information. ?This minimizes the
> information that has to go back and forth (no need to send back the
> msg_type in the parent_header, since the client could just store it,
> though I suppose the argument could be made that msg_type really does
> belong in the header).

These changes were made because of IPython.parallel, specifically the
need to view headers *without* unserializing the potentially large
body of the message.  This means that the message must not be sent as
a single blob, but as a multipart message, and the
[header,parent_header, content] should be a complete representation of
the message. Nothing should be in the top-level except for copies for
convenience, because it is not required to be sent over the network.
Since they are strictly copies of the contents of the header (as the
spec defines them), top-level keys should be considered read-only, as
changing them directly would violate the protocol.

The header is really 'metadata about the message', and any/all
information about the message should go in there.  It seems
inconsistent for the header to be an incomplete description of the
message, which would be true if msg_id and/or msg_type were absent.

>
> What if the msg_id or msg_type between the header and the top-level is
> inconsistent? ?Which takes precedence? I presume that the header
> information takes precedence, but since the top-level fields are for
> convenience, my guess is that in practice, the top-level fields take
> precedence, since if you have to compare the top-level fields with the
> header fields, you might as well just use the header fields.

There is no priority, because there is no non-pathological way for
these two values to differ.  The top-level keys are *defined* as
convenient aliases to the header keys.  If they differ, then the
protocol has not been implemented, and it would be appropriate to
either raise an error, or set the top-level key from the header on
recv (IPython does the latter, because top-level aliases are not sent
over the network).

In IPython, the Session object, which is responsible for building
messages and sending them over the wire, copies the msg_type and
msg_id to the top-level from the header purely for convenience of
other code. The top-level copies are never sent over the network, so
any changes to them, or indeed any extra keys injected into the
message, would not be reflected on the receiving side.

We did briefly have a 'cleaned up' version after we cut 0.11, where
the top-level duplicates were removed, but found that the result was
actually much messier, given how frequently these values are accessed.

>
> A very simple wrapper function on the receiving end can add the
> convenience fields if they really need to be at the top-level, and
> that would guarantee consistency.

That's exactly what we do.  In IPython, *all* communication is managed
through Session objects, which make certain guarantees:

* A message has a header, parent_header, and content.
* The 'msg_id' and 'msg_type' keys of the header are copied to the
top-level for convenience.


This Session object also handles serialization, authentication, and
the use of buffers and pyzmq MessageTracker objects used in
IPython.parallel for non-copying operations, all of which are
*extensions* of the messaging spec.  This is what enables us to switch
between json, pickle, msgpack, and protobuf for serialization with a
line or two of config.

-MinRK

>
> Feel free to CC this message over to the ipython list if you want to
> take up the discussion there.
>
> Thanks,
>
> Jason
>
>
> --
> To post to this group, send an email to sage-devel at googlegroups.com
> To unsubscribe from this group, send an email to
> sage-devel+unsubscribe at googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev


From satra at mit.edu  Thu Dec 15 06:29:55 2011
From: satra at mit.edu (Satrajit Ghosh)
Date: Thu, 15 Dec 2011 12:29:55 +0100
Subject: [IPython-dev] pycharm now supports ipython 0.11
Message-ID: <CA+A4wOnDF9r-FwcLUUZWgaaWmO=nZhu3wTm2FN1DLuZmokSDtg@mail.gmail.com>

pycharm, a commercial ide (free for opensource projects) that i've grown to
like a fair bit just released a new version with ipython 0.11 support.

http://www.jetbrains.com/pycharm/whatsnew/

cheers,

satra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20111215/5cb7a503/attachment.html>

From fperez.net at gmail.com  Thu Dec 15 15:29:25 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 15 Dec 2011 12:29:25 -0800
Subject: [IPython-dev] pycharm now supports ipython 0.11
In-Reply-To: <CA+A4wOnDF9r-FwcLUUZWgaaWmO=nZhu3wTm2FN1DLuZmokSDtg@mail.gmail.com>
References: <CA+A4wOnDF9r-FwcLUUZWgaaWmO=nZhu3wTm2FN1DLuZmokSDtg@mail.gmail.com>
Message-ID: <CAHAreOqSw_QVJy5nmCGztRh51tYf7wnA_oPd3D0MPR=2k40jLQ@mail.gmail.com>

On Thu, Dec 15, 2011 at 3:29 AM, Satrajit Ghosh <satra at mit.edu> wrote:
> pycharm, a commercial ide (free for opensource projects) that i've grown to
> like a fair bit just released a new version with ipython 0.11 support.
>
> http://www.jetbrains.com/pycharm/whatsnew/

Great!  Do you know if it works with current master as well?  And what
specific ipython support does it provide?

Cheers,

f


From cekees at gmail.com  Fri Dec 16 20:46:41 2011
From: cekees at gmail.com (Chris Kees)
Date: Fri, 16 Dec 2011 19:46:41 -0600
Subject: [IPython-dev] display protocol: animation and video
Message-ID: <CAOVFbFikkX2C6nMuCvWM-=+c26Q3tRsAMX3xsX8T0WJfvyTWew@mail.gmail.com>

I'd like to include animations in the notebook and am trying to think
through the options for connecting to the display protocol.  The case I'm
targeting is one with a small number of high-resolution frames (e.g. 50 to
500 frames). Each frame is generated by compositing portions of the frame
rendered on (possibly many) mpi engines.  At the moment I generate a png or
svg of the composite image on the root engine and just bring the last image
in the sequence over to the client, which I can display with something like

c = Client()
view = c[:]
view.activate()
Image(view['imageSequence'][rootEngine][-1])

All I want to do now is make the whole sequence of images available with
"VCR buttons" (rewind, pause, play, fast forward, maybe a slider to look at
specific frames).  Should I 1) generate a single SVG of the entire
animation on the root engine, 2) use ffmpeg via matplotlib or some other
wrapper to ffmpeg to generate a video on the root engine, or 3) continue
bringing over the entire image sequence and do the  conversion to animated
SVG or mpeg on the client.

On 1: I've tried including the SVG for the animation here
http://srufaculty.sru.edu/david.dailey/svg/ovaling.svg using
SVG(data="""..."""), but it doesn't show up in the notebook.    Maybe SVG
animations aren't fully supported in the notebook yet?

On 2: How do I bring the mpeg over? Just read the mpeg file on the root
engine, write it back out on the client, and display using
HTML(file="filename.mp4")?

Thanks for any suggestions.

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

From ellisonbg at gmail.com  Fri Dec 16 23:18:12 2011
From: ellisonbg at gmail.com (Brian Granger)
Date: Fri, 16 Dec 2011 20:18:12 -0800
Subject: [IPython-dev] display protocol: animation and video
In-Reply-To: <CAOVFbFikkX2C6nMuCvWM-=+c26Q3tRsAMX3xsX8T0WJfvyTWew@mail.gmail.com>
References: <CAOVFbFikkX2C6nMuCvWM-=+c26Q3tRsAMX3xsX8T0WJfvyTWew@mail.gmail.com>
Message-ID: <CAH4pYpReH1ppVvHfgQxsyyQ0MQgAccs_m4bZ9L3YQYt9Pz-Stg@mail.gmail.com>

On Fri, Dec 16, 2011 at 5:46 PM, Chris Kees <cekees at gmail.com> wrote:
> I'd like to include animations in the notebook and am trying to think
> through the options for connecting to the display protocol. ?The case I'm
> targeting is one with a small number of high-resolution frames (e.g. 50 to
> 500 frames). Each frame is generated by compositing portions of the frame
> rendered on (possibly many) mpi engines. ?At the moment I generate a png or
> svg of the composite image on the root engine and just bring the last image
> in the sequence over to the client, which I can display with something like

So we have not thought about animiation in the display protocol yet.
Definitely room for improvement.

> c = Client()
> view = c[:]
> view.activate()
> Image(view['imageSequence'][rootEngine][-1])
>
> All I want to do now is make the whole sequence of images available with
> "VCR buttons" (rewind, pause, play, fast forward, maybe a slider to look at
> specific frames). ?Should I 1) generate a single SVG of the entire animation
> on the root engine, 2) use ffmpeg via matplotlib or some other wrapper to
> ffmpeg to generate a video on the root engine, or 3) continue bringing over
> the entire image sequence and do the ?conversion to animated SVG or mpeg on
> the client.
>
> On 1: I've tried including the SVG for the animation here
> http://srufaculty.sru.edu/david.dailey/svg/ovaling.svg using
> SVG(data="""..."""), but it doesn't show up in the notebook. ? ?Maybe SVG
> animations aren't fully supported in the notebook yet?

What is the MIME type for animated SVGs?  Our current implementation
assumes the standard SVG image MIME type when we construct the data
URI in the browser.

> On 2: How do I bring the mpeg over? Just read the mpeg file on the root
> engine, write it back out on the client, and display using
> HTML(file="filename.mp4")?

I think you will need to encode the image and put it into the HTML
using a data URI:

http://en.wikipedia.org/wiki/Data_URI_scheme

Using this approach you should be able to embed any media type.

Cheers,

Brian

> Thanks for any suggestions.
>
> Chris
>
> _______________________________________________
> 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  Sat Dec 17 16:44:57 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 17 Dec 2011 13:44:57 -0800
Subject: [IPython-dev] Last call: 0.12 this weekend?
Message-ID: <CAHAreOr1BB9p42e1cD0Lrb_p=vo-RaR4xemiKYAu-dBjqux78Q@mail.gmail.com>

Hi all,

we haven't had too many scares since the RC went out, so I'd like to
cut 0.12 this weekend (time permitting, I have some work things I must
take care of first).  The only thing left I'd like to see go in is

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

which is just adding a convenience flag for an existing feature.  Once
that gets reviewed, I think we're good to go code-wise.  I'll do some
final doc and example touch-ups, including finishing up a sample
notebook that people can use to get started.  But I won't touch the
core code further (there's often at release time minor tweaks to make
to the files in tools/ or to the release.py file, but that should be
it).

Anyone have any objection or see any glaring problems?  I know we
still haven't fixed

https://github.com/ipython/ipython/issues/481

but given nobody is quite sure what to do here, we can't hold the
release forever on account of one issue.  This and the other few
issues left that were targeted for 0.12 will simply be retargeted for
0.13.

Cheers,

f


From fperez.net at gmail.com  Sat Dec 17 17:29:11 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 17 Dec 2011 14:29:11 -0800
Subject: [IPython-dev] display protocol: animation and video
In-Reply-To: <CAH4pYpReH1ppVvHfgQxsyyQ0MQgAccs_m4bZ9L3YQYt9Pz-Stg@mail.gmail.com>
References: <CAOVFbFikkX2C6nMuCvWM-=+c26Q3tRsAMX3xsX8T0WJfvyTWew@mail.gmail.com>
	<CAH4pYpReH1ppVvHfgQxsyyQ0MQgAccs_m4bZ9L3YQYt9Pz-Stg@mail.gmail.com>
Message-ID: <CAHAreOp6VvNOar_3SeuhB6xS+7w-3TxaqVCG55WQ73K8df4d4g@mail.gmail.com>

On Fri, Dec 16, 2011 at 8:18 PM, Brian Granger <ellisonbg at gmail.com> wrote:
> So we have not thought about animiation in the display protocol yet.
> Definitely room for improvement.

I tried to hack up something quick for Chris using the html5 video tag
with an mp4 file, but it's not easy to make it work b/c the notebook
doesn't expose access to the local filesystem for html tags (that's
why we encode inline the image data in the Image() object).

Which got me thinking about that issue in a more general sense.  I
think we should offer a way for users to refer to local files in the
starting directory of the notebook, so that they could expose them to
the browser in situations like this one.  I know there are a few
important caveats to keep in mind, namely:

Caveat 1: in the most general case, we must not assume that the
notebook server and the kernel reside on the same host.  Just
yesterday chatting with Titus Brown he had a good use case for running
the notebook server locally on a laptop but accessing kernels living
in a remote Amazon EC2 instance.  This would let him save notebooks
locally and would eliminate upstream traffic of images while letting
him work on large, amazon-hosted datasets.

Still, I think that for the common case where the notebook server and
the kernels do reside on the same filesystem, offering an easy
solution is worthwhile.  It won't apply to scenarios such as Titus'
above, but it will be very useful in many cases.

Caveat 2: the working directory of the kernel can vary at runtime (the
user can run %cd/os.chdir() at any time). So the filesystem served by
the notebook over http would be rooted where it started the kernel.
If that kernel later moves to a different working directory, so be it.
 It's up to the user to keep track of this and adjust his/her code
accordingly.

Caveat 3: security.  The notebook server needs to sanitize paths to
avoid accessing remote paths, which means always checking that a
requested path is below the starting point via abspath().

Caveat 4..n: everything else I haven't thought of yet.



But even given those, I think it would be very useful to offer a
handler that would allow people to return objects whose repr includes
things like:

<video src="file/movie.webm" poster="file/movie.jpg" controls>
       Text for non-video browsers.
</video>

or using the Markdown image syntax to show local images in Markdown
cells.  We'd write a handler for the 'file/' URL that would simply
search the rest of that URL as a local file in the directory where the
notebook started a local kernel.  For remote kernels, it would default
to the server's filesystem since the server can't access the kernel FS
(this would be useful in a scenario such as Titus', for showing local
files like images or video in Markdown areas).

Thoughts?

Cheers,

f


From cekees at gmail.com  Sat Dec 17 20:03:05 2011
From: cekees at gmail.com (Chris Kees)
Date: Sat, 17 Dec 2011 19:03:05 -0600
Subject: [IPython-dev] display protocol: animation and video
In-Reply-To: <CAHAreOp6VvNOar_3SeuhB6xS+7w-3TxaqVCG55WQ73K8df4d4g@mail.gmail.com>
References: <CAOVFbFikkX2C6nMuCvWM-=+c26Q3tRsAMX3xsX8T0WJfvyTWew@mail.gmail.com>
	<CAH4pYpReH1ppVvHfgQxsyyQ0MQgAccs_m4bZ9L3YQYt9Pz-Stg@mail.gmail.com>
	<CAHAreOp6VvNOar_3SeuhB6xS+7w-3TxaqVCG55WQ73K8df4d4g@mail.gmail.com>
Message-ID: <CAOVFbFjV9DqeF=D0mr7HU7KvufxQSUBL5-07y2QG5Y7=iHLaLg@mail.gmail.com>

On Sat, Dec 17, 2011 at 4:29 PM, Fernando Perez <fperez.net at gmail.com>wrote:

> On Fri, Dec 16, 2011 at 8:18 PM, Brian Granger <ellisonbg at gmail.com>
> wrote:
> > So we have not thought about animiation in the display protocol yet.
> > Definitely room for improvement.
>
> I tried to hack up something quick for Chris using the html5 video tag
> with an mp4 file, but it's not easy to make it work b/c the notebook
> doesn't expose access to the local filesystem for html tags (that's
> why we encode inline the image data in the Image() object).
>
> Which got me thinking about that issue in a more general sense.  I
> think we should offer a way for users to refer to local files in the
> starting directory of the notebook, so that they could expose them to
> the browser in situations like this one.  I know there are a few
> important caveats to keep in mind, namely:
>
> Caveat 1: in the most general case, we must not assume that the
> notebook server and the kernel reside on the same host.  Just
> yesterday chatting with Titus Brown he had a good use case for running
> the notebook server locally on a laptop but accessing kernels living
> in a remote Amazon EC2 instance.  This would let him save notebooks
> locally and would eliminate upstream traffic of images while letting
> him work on large, amazon-hosted datasets.
>
>
I agree that this case is worth planning for. The HPCMP "utility servers"
may make this kind of scenario useful for us as well. The  notebook server
would run on the login nodes, the kernels on large memory nodes accessed
through a queue, and the engines on another large cluster---I need to check
on how the filesystems are mounted.  I've been working towards rendering
'in situ' on the engines but given the capabilities of the utility server
nodes it may be feasible and more efficient in some cases to bring the
geometry and solution/field data over to the kernel and render it there
(that's what my initial example did with matplotlib).


> Still, I think that for the common case where the notebook server and
> the kernels do reside on the same filesystem, offering an easy
> solution is worthwhile.  It won't apply to scenarios such as Titus'
> above, but it will be very useful in many cases.
>
> Caveat 2: the working directory of the kernel can vary at runtime (the
> user can run %cd/os.chdir() at any time). So the filesystem served by
> the notebook over http would be rooted where it started the kernel.
> If that kernel later moves to a different working directory, so be it.
>  It's up to the user to keep track of this and adjust his/her code
> accordingly.
>
> Caveat 3: security.  The notebook server needs to sanitize paths to
> avoid accessing remote paths, which means always checking that a
> requested path is below the starting point via abspath().
>
> Caveat 4..n: everything else I haven't thought of yet.
>
>
>
> But even given those, I think it would be very useful to offer a
> handler that would allow people to return objects whose repr includes
> things like:
>
> <video src="file/movie.webm" poster="file/movie.jpg" controls>
>       Text for non-video browsers.
> </video>
>
>
I can say at least that as a newbie my expectation was that I could access
the filesystem from html so you'll probably save yourself some headaches on
the mailing list if you provide it.

It occurs to me that storing images in the notebook directory and
displaying images in the markdown cells could also be a useful verification
and/or teaching tool ("This notebook solves u_{xx} = f. The solution is
shown below").


> or using the Markdown image syntax to show local images in Markdown
> cells.  We'd write a handler for the 'file/' URL that would simply
> search the rest of that URL as a local file in the directory where the
> notebook started a local kernel.  For remote kernels, it would default
> to the server's filesystem since the server can't access the kernel FS
> (this would be useful in a scenario such as Titus', for showing local
> files like images or video in Markdown areas).
>
> Thoughts?
>
> Cheers,
>
> f
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20111217/c6af8673/attachment.html>

From fperez.net at gmail.com  Sat Dec 17 20:12:17 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 17 Dec 2011 17:12:17 -0800
Subject: [IPython-dev] display protocol: animation and video
In-Reply-To: <CAOVFbFjV9DqeF=D0mr7HU7KvufxQSUBL5-07y2QG5Y7=iHLaLg@mail.gmail.com>
References: <CAOVFbFikkX2C6nMuCvWM-=+c26Q3tRsAMX3xsX8T0WJfvyTWew@mail.gmail.com>
	<CAH4pYpReH1ppVvHfgQxsyyQ0MQgAccs_m4bZ9L3YQYt9Pz-Stg@mail.gmail.com>
	<CAHAreOp6VvNOar_3SeuhB6xS+7w-3TxaqVCG55WQ73K8df4d4g@mail.gmail.com>
	<CAOVFbFjV9DqeF=D0mr7HU7KvufxQSUBL5-07y2QG5Y7=iHLaLg@mail.gmail.com>
Message-ID: <CAHAreOq2xKccEG0e0GWqAm30Ot+WZKoe6r2OMrWGF6HKdN3Aag@mail.gmail.com>

On Sat, Dec 17, 2011 at 5:03 PM, Chris Kees <cekees at gmail.com> wrote:
> I can say at least that as a newbie my expectation was that I could access
> the filesystem from html so you'll probably save yourself some headaches on
> the mailing list if you provide it.

Yes, in fact the first time I noticed it not working, it took me a
minute to realize why not, and I don't think it would be immediately
obvious to a user who isn't familiar with how the internal pieces fit
together (who sees what data, who serves http vs executing code, etc).

> It occurs to me that storing images in the notebook directory and displaying
> images in the markdown cells could also be a useful verification and/or
> teaching tool ("This notebook solves u_{xx} = f. The solution is shown
> below").

Great, thanks for the feedback.  I think it's indeed possible and
useful, and I don't see any major hurdles to implementing it.  It's
just an extra URL handler to write in the app.  Let's see if anyone
notices any reason why we should absolutely not do this, and otherwise
we'll put it in the todo list for 0.13.

Cheers,

f


From tomspur at fedoraproject.org  Sun Dec 18 08:05:40 2011
From: tomspur at fedoraproject.org (Thomas Spura)
Date: Sun, 18 Dec 2011 14:05:40 +0100
Subject: [IPython-dev] Last call: 0.12 this weekend?
In-Reply-To: <CAHAreOr1BB9p42e1cD0Lrb_p=vo-RaR4xemiKYAu-dBjqux78Q@mail.gmail.com>
References: <CAHAreOr1BB9p42e1cD0Lrb_p=vo-RaR4xemiKYAu-dBjqux78Q@mail.gmail.com>
Message-ID: <CAE4GLstn6-iUyqQ8yPX6hJKbOuam1MFk3AtDJc2hZ2ybtCfz4w@mail.gmail.com>

On Sat, Dec 17, 2011 at 10:44 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> Anyone have any objection or see any glaring problems?


When running rm -rf ~/.config/ipython and doing
%install_default_config, this results in a crash:
Installing default config file in: /home/tom/.config/ipython/profile_default
---------------------------------------------------------------------------
IOError                                   Traceback (most recent call last)
/home/tom/src/ipython.git/<ipython-input-1-57560e033eac> in <module>()
----> 1 get_ipython().magic(u'install_default_config')

/home/tom/src/ipython.git/IPython/core/interactiveshell.pyc in
magic(self, arg_s, next_input)
   1996                 self._magic_locals = sys._getframe(1).f_locals
   1997             with self.builtin_trap:
-> 1998                 result = fn(magic_args)
   1999             # Ensure we're not keeping object references around:

   2000             self._magic_locals = {}

/home/tom/src/ipython.git/IPython/core/magic.pyc in
magic_install_default_config(self, s)
   3403         pd = self.shell.profile_dir
   3404         print "Installing default config file in: %s" % pd.location
-> 3405         pd.copy_config_file('ipython_config.py', overwrite=overwrite)
   3406
   3407     # Pylab support: simple wrappers that activate pylab, load gui input


/home/tom/src/ipython.git/IPython/core/profiledir.pyc in
copy_config_file(self, config_file, path, overwrite)
    149             path = os.path.join(get_ipython_package_dir(),
u'config', u'profile', u'default')
    150         src = os.path.join(path, config_file)
--> 151         shutil.copy(src, dst)
    152         return True
    153

/usr/lib64/python2.7/shutil.pyc in copy(src, dst)
    114     if os.path.isdir(dst):
    115         dst = os.path.join(dst, os.path.basename(src))
--> 116     copyfile(src, dst)
    117     copymode(src, dst)
    118

/usr/lib64/python2.7/shutil.pyc in copyfile(src, dst)
     79                 raise SpecialFileError("`%s` is a named pipe" % fn)
     80
---> 81     with open(src, 'rb') as fsrc:
     82         with open(dst, 'wb') as fdst:
     83             copyfileobj(fsrc, fdst)

IOError: [Errno 2] No such file or directory:
u'./IPython/config/profile/default/ipython_config.py'


Also see this bug report for that:
https://bugzilla.redhat.com/show_bug.cgi?id=751146

All I could find in the github issues is this:
https://github.com/ipython/ipython/issues/467
but that was with the old config system...

Greetings,
   Tom


From takowl at gmail.com  Sun Dec 18 08:15:22 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Sun, 18 Dec 2011 13:15:22 +0000
Subject: [IPython-dev] Last call: 0.12 this weekend?
In-Reply-To: <CAE4GLstn6-iUyqQ8yPX6hJKbOuam1MFk3AtDJc2hZ2ybtCfz4w@mail.gmail.com>
References: <CAHAreOr1BB9p42e1cD0Lrb_p=vo-RaR4xemiKYAu-dBjqux78Q@mail.gmail.com>
	<CAE4GLstn6-iUyqQ8yPX6hJKbOuam1MFk3AtDJc2hZ2ybtCfz4w@mail.gmail.com>
Message-ID: <CAOvn4qjVfh2bRKR3U+A2dJjs2CqjEQ8si6FTk2=xBLeX3P3_5w@mail.gmail.com>

On 18 December 2011 13:05, Thomas Spura <tomspur at fedoraproject.org> wrote:

> IOError: [Errno 2] No such file or directory:
> u'./IPython/config/profile/default/ipython_config.py'
>

The default profile now has the config file auto-generated when you do
"ipython profile create", so there's nothing to copy. I guess this wasn't
updated when we changed that.

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

From tomspur at fedoraproject.org  Sun Dec 18 08:24:46 2011
From: tomspur at fedoraproject.org (Thomas Spura)
Date: Sun, 18 Dec 2011 14:24:46 +0100
Subject: [IPython-dev] Last call: 0.12 this weekend?
In-Reply-To: <CAOvn4qjVfh2bRKR3U+A2dJjs2CqjEQ8si6FTk2=xBLeX3P3_5w@mail.gmail.com>
References: <CAHAreOr1BB9p42e1cD0Lrb_p=vo-RaR4xemiKYAu-dBjqux78Q@mail.gmail.com>
	<CAE4GLstn6-iUyqQ8yPX6hJKbOuam1MFk3AtDJc2hZ2ybtCfz4w@mail.gmail.com>
	<CAOvn4qjVfh2bRKR3U+A2dJjs2CqjEQ8si6FTk2=xBLeX3P3_5w@mail.gmail.com>
Message-ID: <CAE4GLsuwVGSxfiDJ30RT1S2ZkDWbu-Gt5+StJ4gJq9xXSYo8mg@mail.gmail.com>

On Sun, Dec 18, 2011 at 2:15 PM, Thomas Kluyver <takowl at gmail.com> wrote:
> On 18 December 2011 13:05, Thomas Spura <tomspur at fedoraproject.org> wrote:
>>
>> IOError: [Errno 2] No such file or directory:
>> u'./IPython/config/profile/default/ipython_config.py'
>
>
> The default profile now has the config file auto-generated when you do
> "ipython profile create", so there's nothing to copy. I guess this wasn't
> updated when we changed that.

Hmm, can %install_default_config then be changed to eigther:

* be removed totally or
* link to "ipython profile create" or
* do the same like "ipython profile create" ?

(I would prefer the first or second...)

Greetings,
  Tom


From takowl at gmail.com  Sun Dec 18 08:30:18 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Sun, 18 Dec 2011 13:30:18 +0000
Subject: [IPython-dev] Last call: 0.12 this weekend?
In-Reply-To: <CAE4GLsuwVGSxfiDJ30RT1S2ZkDWbu-Gt5+StJ4gJq9xXSYo8mg@mail.gmail.com>
References: <CAHAreOr1BB9p42e1cD0Lrb_p=vo-RaR4xemiKYAu-dBjqux78Q@mail.gmail.com>
	<CAE4GLstn6-iUyqQ8yPX6hJKbOuam1MFk3AtDJc2hZ2ybtCfz4w@mail.gmail.com>
	<CAOvn4qjVfh2bRKR3U+A2dJjs2CqjEQ8si6FTk2=xBLeX3P3_5w@mail.gmail.com>
	<CAE4GLsuwVGSxfiDJ30RT1S2ZkDWbu-Gt5+StJ4gJq9xXSYo8mg@mail.gmail.com>
Message-ID: <CAOvn4qi+7KZaH6RoZ6uEjwt1XJnYLUf9U3b=wSOwVdEuVY_VSg@mail.gmail.com>

On 18 December 2011 13:24, Thomas Spura <tomspur at fedoraproject.org> wrote:

> Hmm, can %install_default_config then be changed to eigther:


I'm quite sure it can, but I don't know the best way to do it. I think Min
knows these things best, hopefully he'll be online later.

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

From benjaminrk at gmail.com  Sun Dec 18 13:33:13 2011
From: benjaminrk at gmail.com (MinRK)
Date: Sun, 18 Dec 2011 10:33:13 -0800
Subject: [IPython-dev] Last call: 0.12 this weekend?
In-Reply-To: <CAOvn4qi+7KZaH6RoZ6uEjwt1XJnYLUf9U3b=wSOwVdEuVY_VSg@mail.gmail.com>
References: <CAHAreOr1BB9p42e1cD0Lrb_p=vo-RaR4xemiKYAu-dBjqux78Q@mail.gmail.com>
	<CAE4GLstn6-iUyqQ8yPX6hJKbOuam1MFk3AtDJc2hZ2ybtCfz4w@mail.gmail.com>
	<CAOvn4qjVfh2bRKR3U+A2dJjs2CqjEQ8si6FTk2=xBLeX3P3_5w@mail.gmail.com>
	<CAE4GLsuwVGSxfiDJ30RT1S2ZkDWbu-Gt5+StJ4gJq9xXSYo8mg@mail.gmail.com>
	<CAOvn4qi+7KZaH6RoZ6uEjwt1XJnYLUf9U3b=wSOwVdEuVY_VSg@mail.gmail.com>
Message-ID: <CAHNn8BX9d03CmTixm-waYAMz5HzAM6Myzt25zEyBcYQTCSmMsw@mail.gmail.com>

On Sun, Dec 18, 2011 at 05:30, Thomas Kluyver <takowl at gmail.com> wrote:
> On 18 December 2011 13:24, Thomas Spura <tomspur at fedoraproject.org> wrote:
>>
>> Hmm, can %install_default_config then be changed to eigther:
>
>
> I'm quite sure it can, but I don't know the best way to do it. I think Min
> knows these things best, hopefully he'll be online later.

Sure, it can.  I'd vote for removing it altogether, in favor of just
*calling* `!ipython profile create <name>`

-MinRK


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


From tomspur at fedoraproject.org  Sun Dec 18 13:59:50 2011
From: tomspur at fedoraproject.org (Thomas Spura)
Date: Sun, 18 Dec 2011 19:59:50 +0100
Subject: [IPython-dev] Last call: 0.12 this weekend?
In-Reply-To: <CAHNn8BX9d03CmTixm-waYAMz5HzAM6Myzt25zEyBcYQTCSmMsw@mail.gmail.com>
References: <CAHAreOr1BB9p42e1cD0Lrb_p=vo-RaR4xemiKYAu-dBjqux78Q@mail.gmail.com>
	<CAE4GLstn6-iUyqQ8yPX6hJKbOuam1MFk3AtDJc2hZ2ybtCfz4w@mail.gmail.com>
	<CAOvn4qjVfh2bRKR3U+A2dJjs2CqjEQ8si6FTk2=xBLeX3P3_5w@mail.gmail.com>
	<CAE4GLsuwVGSxfiDJ30RT1S2ZkDWbu-Gt5+StJ4gJq9xXSYo8mg@mail.gmail.com>
	<CAOvn4qi+7KZaH6RoZ6uEjwt1XJnYLUf9U3b=wSOwVdEuVY_VSg@mail.gmail.com>
	<CAHNn8BX9d03CmTixm-waYAMz5HzAM6Myzt25zEyBcYQTCSmMsw@mail.gmail.com>
Message-ID: <CAE4GLstCJp3WociH0pqkctGwwaxFvOm79YdooveWPzxd3XG_WA@mail.gmail.com>

On Sun, Dec 18, 2011 at 7:33 PM, MinRK <benjaminrk at gmail.com> wrote:
> On Sun, Dec 18, 2011 at 05:30, Thomas Kluyver <takowl at gmail.com> wrote:
>> On 18 December 2011 13:24, Thomas Spura <tomspur at fedoraproject.org> wrote:
>>>
>>> Hmm, can %install_default_config then be changed to eigther:
>>
>>
>> I'm quite sure it can, but I don't know the best way to do it. I think Min
>> knows these things best, hopefully he'll be online later.
>
> Sure, it can. ?I'd vote for removing it altogether, in favor of just
> *calling* `!ipython profile create <name>`

+1 :)

%install_profiles should be dead too...

Both done in PR 1174

Thanks,
  Tom


From fperez.net at gmail.com  Mon Dec 19 04:49:07 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 19 Dec 2011 01:49:07 -0800
Subject: [IPython-dev] [ANN] IPython 0.12 is out!
Message-ID: <CAHAreOpNXyVUamHWe_A6=4SoBeAiRWw_xMcN8s6=YrU6LopJjQ@mail.gmail.com>

Hi all,

on behalf of the IPython development team, I'm thrilled to announce,
after an intense 4 1/2 months of work, the official release of IPython
0.12.

This is a very important release for IPython, for several reasons.
First and foremost, we have a major new feature, our interactive
web-based notebook, that has been in our sights for a very long time.
We tried to build one years ago (with WX) as a Google SoC project in
2005, had other prototypes later on, but things never quite worked.
Finally the refactoring effort started two years ago, the
communications architecture we built in 2010, and the advances of
modern browsers, gave us all the necessary pieces.

With this foundation in place, while part of the team worked on the
0.11 release, Brian Granger had already started quietly building the
web notebook, which we demoed in early-alpha mode at the SciPy 2011
conference (http://www.archive.org/details/Wednesday-203-6-IpythonANewArchitectureForInteractiveAndParallel).
 By the EuroScipy conference in August we had merged Brian's amazing
effort into our master branch, and after that multiple people (old and
new) jumped in to make all kinds of improvements, leaving us today
with something that is an excellent foundation.  It's still the first
release of the notebook, and as such we know it has a number of rough
edges, but several of us have been using it as a daily research tool
for the last few months.  Do not hesitate to file issues for any
problems you encounter with it, and we even have an 'open issue' for
general discussion of ideas and features for the notebook at:
https://github.com/ipython/ipython/issues/977.

Furthermore, it is clear that our big refactoring work, combined with
the amazing facilities at Github, are paying off.  The 0.11 series was
a major amount of work, with 511 issues closed over almost two years.
But that pales in comparison to this cycle: in only 4 1/2 months we
closed 515 issues, with 50% being Pull Requests. And very importantly,
our list of contributors includes many new faces (see the credits
section in our release notes for full details), which is the best
thing that can happen to an open source project.

We hope you will find the new features (the notebook isn't the only
one! see below) compelling, and that many more will not only use
IPython but will join the project; there's plenty to do and now there
are tasks for many different skill sets (web, javascript, gui work,
low-level networking, parallel machinery, console apps, etc).

*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.12
Zipball: https://github.com/ipython/ipython/zipball/rel-0.12


* Features *
Here is a quick listing of the major new features:

- An interactive browser-based Notebook with rich media support
- Two-process terminal console
- Tabbed QtConsole
- Full Python 3 compatibility
- Standalone Kernel
- PyPy support

And many more...

We closed over 500 tickets, merged over 200 pull requests, and more
than 45 people contributed commits for the final release.

Please see our release notes for the full details on everything about
this release:
http://ipython.org/ipython-doc/stable/whatsnew/version0.12.html

* IPython tutorial at PyCon 2012 *

Those of you attending (or planning on it) PyCon 2012 in Santa Clara,
CA, may be interested in attending a hands-on tutorial we will be
presenting on the many faces of IPython.  See
https://us.pycon.org/2012/schedule/presentation/121/ for full details.

* Errata *
This was caught by Matthias Bussionnier's (one of our great new
contributors) sharp eyes while I was writing these release notes: In
the example notebook called display_protocol, the first cell starts
with:

from IPython.lib.pylabtools import print_figure

which should instead be:

from IPython.core.pylabtools import print_figure

This has already been fixed on master, but since the final 0.12 files
have been uploaded to github and PyPI, we'll let them be.

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 jason-sage at creativetrax.com  Mon Dec 19 09:36:09 2011
From: jason-sage at creativetrax.com (Jason Grout)
Date: Mon, 19 Dec 2011 08:36:09 -0600
Subject: [IPython-dev] From the sage list: thinking about our messaging
 protocol
In-Reply-To: <CAHNn8BXTd2nsNv8q9vqtE0tJRteyBmc+2QS4A_UnsC6-p5Xb1A@mail.gmail.com>
References: <CAHAreOq3Sb7oPzSRO-jCQ81nwxgdhGGoRSV=NFk7GGQXm=8ToQ@mail.gmail.com>
	<CAHNn8BXTd2nsNv8q9vqtE0tJRteyBmc+2QS4A_UnsC6-p5Xb1A@mail.gmail.com>
Message-ID: <4EEF4BD9.9050305@creativetrax.com>

On 12/14/11 4:17 PM, MinRK wrote:
> These changes were made because of IPython.parallel, specifically the
> need to view headers*without*  unserializing the potentially large
> body of the message.

It just occurred to me: would it be okay to add version numbers to the 
messaging protocol to prevent confusion?  You could even match the 
version numbers to ipython releases (i.e., version 0.11, 0.12, etc.), if 
you wanted to tie it that closely to ipython.

Thanks,

Jason



From benjaminrk at gmail.com  Mon Dec 19 13:48:31 2011
From: benjaminrk at gmail.com (Min RK)
Date: Mon, 19 Dec 2011 10:48:31 -0800
Subject: [IPython-dev] From the sage list: thinking about our messaging
	protocol
In-Reply-To: <4EEF4BD9.9050305@creativetrax.com>
References: <CAHAreOq3Sb7oPzSRO-jCQ81nwxgdhGGoRSV=NFk7GGQXm=8ToQ@mail.gmail.com>
	<CAHNn8BXTd2nsNv8q9vqtE0tJRteyBmc+2QS4A_UnsC6-p5Xb1A@mail.gmail.com>
	<4EEF4BD9.9050305@creativetrax.com>
Message-ID: <F04681B8-A8C0-4E88-92E4-6F290A36DAAD@gmail.com>


On Dec 19, 2011, at 6:36, Jason Grout <jason-sage at creativetrax.com> wrote:

> On 12/14/11 4:17 PM, MinRK wrote:
>> These changes were made because of IPython.parallel, specifically the
>> need to view headers*without*  unserializing the potentially large
>> body of the message.
> 
> It just occurred to me: would it be okay to add version numbers to the messaging protocol to prevent confusion?  You could even match the version numbers to ipython releases (i.e., version 0.11, 0.12, etc.), if you wanted to tie it that closely to ipython.
> 

Yes, that makes sense, we should probably do so.  So far there has only been one version in released code, because we made the changes discussed here prior to 0.11, so any changes should mark version 2.

> Thanks,
> 
> Jason
> 


From fperez.net at gmail.com  Tue Dec 20 04:19:03 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 20 Dec 2011 01:19:03 -0800
Subject: [IPython-dev] [IPython-User] [SciPy-User] [ANN] IPython 0.12 is
	out!
In-Reply-To: <CAJPUwMDHjsE1=dgJLkxU4uNiK+CqNwhUOj5ty-E=kpRnr6+buA@mail.gmail.com>
References: <CAHAreOpNXyVUamHWe_A6=4SoBeAiRWw_xMcN8s6=YrU6LopJjQ@mail.gmail.com>
	<CAJPUwMDHjsE1=dgJLkxU4uNiK+CqNwhUOj5ty-E=kpRnr6+buA@mail.gmail.com>
Message-ID: <CAHAreOr6-uzWbtrLBoAP4WYm9Xc0wsco50w4x4fRG9U==FNGAg@mail.gmail.com>

On Mon, Dec 19, 2011 at 7:39 AM, Wes McKinney <wesmckinn at gmail.com> wrote:
> My sincere congratulations to the IPython team! You set an amazingly
> high standard that we should all strive to emulate. I never seem to
> run out of good things to say about the work that you are doing--
> looking forward to an even more productive 2012!

Well, your kind words are very much appreciated, but I actually wanted
to thank you  for saying those good things, as you've actually already
helped us by doing so...

A few days ago on the nipy list someone posted a link to Titus Brown's
blog post:

http://ivory.idyll.org/blog/dec-11/data-intensive-science-and-workflows

as I was reading I kept thinking 'well, the ipython notebook could be
useful there...', and then I read further down that he had tried the
notebook.  Eventually on Friday I had a very nice chat with Titus
about this and related matters, that hopefully will lead to
interesting things down the road.

And as it turns out, I owe it to you!  He mentioned how a chance
meeting on a train where his next-seat neighbor turned out to be a
scientific python guy (you) led to a conversation about the notebook.
 So thanks!!

Best,

f


From benjaminrk at gmail.com  Tue Dec 20 15:50:48 2011
From: benjaminrk at gmail.com (MinRK)
Date: Tue, 20 Dec 2011 12:50:48 -0800
Subject: [IPython-dev] [IPython-User] [SciPy-User] [ANN] IPython 0.12 is
	out!
In-Reply-To: <CAHAreOr6-uzWbtrLBoAP4WYm9Xc0wsco50w4x4fRG9U==FNGAg@mail.gmail.com>
References: <CAHAreOpNXyVUamHWe_A6=4SoBeAiRWw_xMcN8s6=YrU6LopJjQ@mail.gmail.com>
	<CAJPUwMDHjsE1=dgJLkxU4uNiK+CqNwhUOj5ty-E=kpRnr6+buA@mail.gmail.com>
	<CAHAreOr6-uzWbtrLBoAP4WYm9Xc0wsco50w4x4fRG9U==FNGAg@mail.gmail.com>
Message-ID: <CAHNn8BXRWcaGeCypXW=pgiEacGDYF4WOpyX5H+4xLPaXDnck6g@mail.gmail.com>

Related to this, I wanted to post a quick dev question:

I know we plan to continue the short release cycle with at least two
more significant releases in 2012, but do we want to have a 'bugfix'
branch for possible 0.12.1?  We were bitten pretty hard by the pyzmq
version-check bug, and we probably should have cut  0.11.1 with the
fix, which we had in master two months before the issue came up.

I suppose we don't have to make a decision until we make our first
change that shouldn't go into an incremental release, but I thought I
would float the idea.  I don't think we have to make such a release
unless we find a potential bug that justifies one, but I think the
cost of making 0.11.1 would have been lower than the time we spent
saying "duplicate of #XYZ, fixed in master" on GitHub.

-MinRK


From fperez.net at gmail.com  Tue Dec 20 18:02:27 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 20 Dec 2011 15:02:27 -0800
Subject: [IPython-dev] [IPython-User] [SciPy-User] [ANN] IPython 0.12 is
	out!
In-Reply-To: <CAHNn8BXRWcaGeCypXW=pgiEacGDYF4WOpyX5H+4xLPaXDnck6g@mail.gmail.com>
References: <CAHAreOpNXyVUamHWe_A6=4SoBeAiRWw_xMcN8s6=YrU6LopJjQ@mail.gmail.com>
	<CAJPUwMDHjsE1=dgJLkxU4uNiK+CqNwhUOj5ty-E=kpRnr6+buA@mail.gmail.com>
	<CAHAreOr6-uzWbtrLBoAP4WYm9Xc0wsco50w4x4fRG9U==FNGAg@mail.gmail.com>
	<CAHNn8BXRWcaGeCypXW=pgiEacGDYF4WOpyX5H+4xLPaXDnck6g@mail.gmail.com>
Message-ID: <CAHAreOr3jc0tys1C=k97E5wMmfGe7raKPHhhgrD_V1un+vtyBA@mail.gmail.com>

On Tue, Dec 20, 2011 at 12:50 PM, MinRK <benjaminrk at gmail.com> wrote:
> I know we plan to continue the short release cycle with at least two
> more significant releases in 2012, but do we want to have a 'bugfix'
> branch for possible 0.12.1? ?We were bitten pretty hard by the pyzmq
> version-check bug, and we probably should have cut ?0.11.1 with the
> fix, which we had in master two months before the issue came up.
>
> I suppose we don't have to make a decision until we make our first
> change that shouldn't go into an incremental release, but I thought I
> would float the idea. ?I don't think we have to make such a release
> unless we find a potential bug that justifies one, but I think the
> cost of making 0.11.1 would have been lower than the time we spent
> saying "duplicate of #XYZ, fixed in master" on GitHub.

Agreed.  It's easy enough to make such a branch after the fact, if it
proves to be necessary, and to cherry pick anything from master we'd
like to see in there.  I agree that we probably should have cut a
0.11.1 for that silly bug :)

In this case there's an added incentive to a bugfix branch: while
we'll most likely get 0.12 included in ubuntu 12.04, they won't do a
version upgrade to 0.13.  But I think they do push minor bugfix-only
updates, so it would help anyone in an environment that sticks to the
default ubuntu LTS policies get at least the most critical fixes.

Cheers

f


From fperez.net at gmail.com  Tue Dec 20 18:15:56 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 20 Dec 2011 15:15:56 -0800
Subject: [IPython-dev] Offline for a week
Message-ID: <CAHAreOoRmcKpC5YqeQo105r-ffT+oM2cx34tODgqPVg_YaS2qQ@mail.gmail.com>

Hi folks,

Just a note that as of tomorrow I'll be offline for roughly a week.  I
know the rest of the team does a great job of manning the fort when
one of us is unavailable, but in case someone expects a direct reply
from me, it won't happen for a few days.

Happy Holidays and a great 2012 for everyone, hopefully with lots of
IPython in it :)

f


From tomspur at fedoraproject.org  Wed Dec 21 04:02:18 2011
From: tomspur at fedoraproject.org (Thomas Spura)
Date: Wed, 21 Dec 2011 10:02:18 +0100
Subject: [IPython-dev] [IPython-User] [SciPy-User] [ANN] IPython 0.12 is
	out!
In-Reply-To: <CAHAreOr3jc0tys1C=k97E5wMmfGe7raKPHhhgrD_V1un+vtyBA@mail.gmail.com>
References: <CAHAreOpNXyVUamHWe_A6=4SoBeAiRWw_xMcN8s6=YrU6LopJjQ@mail.gmail.com>
	<CAJPUwMDHjsE1=dgJLkxU4uNiK+CqNwhUOj5ty-E=kpRnr6+buA@mail.gmail.com>
	<CAHAreOr6-uzWbtrLBoAP4WYm9Xc0wsco50w4x4fRG9U==FNGAg@mail.gmail.com>
	<CAHNn8BXRWcaGeCypXW=pgiEacGDYF4WOpyX5H+4xLPaXDnck6g@mail.gmail.com>
	<CAHAreOr3jc0tys1C=k97E5wMmfGe7raKPHhhgrD_V1un+vtyBA@mail.gmail.com>
Message-ID: <CAE4GLssHuOfS9CiigWvpWKV+EYLDz3VV_zhryrhY=B=-iYCu3w@mail.gmail.com>

On Wed, Dec 21, 2011 at 12:02 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Tue, Dec 20, 2011 at 12:50 PM, MinRK <benjaminrk at gmail.com> wrote:
>> I know we plan to continue the short release cycle with at least two
>> more significant releases in 2012, but do we want to have a 'bugfix'
>> branch for possible 0.12.1? ?We were bitten pretty hard by the pyzmq
>> version-check bug, and we probably should have cut ?0.11.1 with the
>> fix, which we had in master two months before the issue came up.
>>
>> I suppose we don't have to make a decision until we make our first
>> change that shouldn't go into an incremental release, but I thought I
>> would float the idea. ?I don't think we have to make such a release
>> unless we find a potential bug that justifies one, but I think the
>> cost of making 0.11.1 would have been lower than the time we spent
>> saying "duplicate of #XYZ, fixed in master" on GitHub.
>
> Agreed. ?It's easy enough to make such a branch after the fact, if it
> proves to be necessary, and to cherry pick anything from master we'd
> like to see in there. ?I agree that we probably should have cut a
> 0.11.1 for that silly bug :)
>
> In this case there's an added incentive to a bugfix branch: while
> we'll most likely get 0.12 included in ubuntu 12.04, they won't do a
> version upgrade to 0.13. ?But I think they do push minor bugfix-only
> updates, so it would help anyone in an environment that sticks to the
> default ubuntu LTS policies get at least the most critical fixes.

Hmm, and why not?
I can understand, that nobody wants to do the switch to 0.11 in a
released distribution, because anything changes, e.g. configuration
all modules... So when you plan something similar with the next
release, a bugfix release would be great. When the next release
includes the feature set of the old one (only adds more feature) and
has the bugfixes of the old one, I don't see a problem, to not do an
extra bugfix release...

Greetings,
   Tom


From fperez.net at gmail.com  Wed Dec 21 04:38:06 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 21 Dec 2011 01:38:06 -0800
Subject: [IPython-dev] [IPython-User] [SciPy-User] [ANN] IPython 0.12 is
	out!
In-Reply-To: <CAE4GLssHuOfS9CiigWvpWKV+EYLDz3VV_zhryrhY=B=-iYCu3w@mail.gmail.com>
References: <CAHAreOpNXyVUamHWe_A6=4SoBeAiRWw_xMcN8s6=YrU6LopJjQ@mail.gmail.com>
	<CAJPUwMDHjsE1=dgJLkxU4uNiK+CqNwhUOj5ty-E=kpRnr6+buA@mail.gmail.com>
	<CAHAreOr6-uzWbtrLBoAP4WYm9Xc0wsco50w4x4fRG9U==FNGAg@mail.gmail.com>
	<CAHNn8BXRWcaGeCypXW=pgiEacGDYF4WOpyX5H+4xLPaXDnck6g@mail.gmail.com>
	<CAHAreOr3jc0tys1C=k97E5wMmfGe7raKPHhhgrD_V1un+vtyBA@mail.gmail.com>
	<CAE4GLssHuOfS9CiigWvpWKV+EYLDz3VV_zhryrhY=B=-iYCu3w@mail.gmail.com>
Message-ID: <CAHAreOqfBzPrxpQPHwwrm8AxDZtKpM2mOwLGVxhLNSn-LTVZ5Q@mail.gmail.com>

On Wed, Dec 21, 2011 at 1:02 AM, Thomas Spura <tomspur at fedoraproject.org> wrote:
> I don't see a problem, to not do an
> extra bugfix release...

My understanding is that ubuntu won't do a 0.12 -> 0.13 update during
the LTS release cycle, but that they would apply a 0.12.1 'small
fixes' update.  Since the burden on us is not that large,  I don't
mind doing it...

Cheers,

f


From nicolas.chauvat at logilab.fr  Wed Dec 21 05:06:49 2011
From: nicolas.chauvat at logilab.fr (Nicolas Chauvat)
Date: Wed, 21 Dec 2011 11:06:49 +0100
Subject: [IPython-dev] [IPython-User] [SciPy-User] [ANN] IPython 0.12 is
 out!
In-Reply-To: <CAHAreOr3jc0tys1C=k97E5wMmfGe7raKPHhhgrD_V1un+vtyBA@mail.gmail.com>
References: <CAHAreOpNXyVUamHWe_A6=4SoBeAiRWw_xMcN8s6=YrU6LopJjQ@mail.gmail.com>
	<CAJPUwMDHjsE1=dgJLkxU4uNiK+CqNwhUOj5ty-E=kpRnr6+buA@mail.gmail.com>
	<CAHAreOr6-uzWbtrLBoAP4WYm9Xc0wsco50w4x4fRG9U==FNGAg@mail.gmail.com>
	<CAHNn8BXRWcaGeCypXW=pgiEacGDYF4WOpyX5H+4xLPaXDnck6g@mail.gmail.com>
	<CAHAreOr3jc0tys1C=k97E5wMmfGe7raKPHhhgrD_V1un+vtyBA@mail.gmail.com>
Message-ID: <20111221100649.GA17767@volans.logilab.fr>

On Tue, Dec 20, 2011 at 03:02:27PM -0800, Fernando Perez wrote:
> > cost of making 0.11.1 would have been lower than the time we spent
> > saying "duplicate of #XYZ, fixed in master" on GitHub.
> 
> Agreed.  It's easy enough to make such a branch after the fact, if it
> proves to be necessary, and to cherry pick anything from master we'd
> like to see in there.  I agree that we probably should have cut a
> 0.11.1 for that silly bug :)

+1 having a stable branch where only fixes can enter and a development
branch for the rest is a very common good practice.

> In this case there's an added incentive to a bugfix branch: while
> we'll most likely get 0.12 included in ubuntu 12.04, they won't do a
> version upgrade to 0.13.  But I think they do push minor bugfix-only
> updates, so it would help anyone in an environment that sticks to the
> default ubuntu LTS policies get at least the most critical fixes.

True. Distributions have their dev/stable phases too :)

-- 
Nicolas Chauvat

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


From benjaminrk at gmail.com  Wed Dec 21 05:35:56 2011
From: benjaminrk at gmail.com (MinRK)
Date: Wed, 21 Dec 2011 02:35:56 -0800
Subject: [IPython-dev] [IPython-User] [SciPy-User] [ANN] IPython 0.12 is
	out!
In-Reply-To: <20111221100649.GA17767@volans.logilab.fr>
References: <CAHAreOpNXyVUamHWe_A6=4SoBeAiRWw_xMcN8s6=YrU6LopJjQ@mail.gmail.com>
	<CAJPUwMDHjsE1=dgJLkxU4uNiK+CqNwhUOj5ty-E=kpRnr6+buA@mail.gmail.com>
	<CAHAreOr6-uzWbtrLBoAP4WYm9Xc0wsco50w4x4fRG9U==FNGAg@mail.gmail.com>
	<CAHNn8BXRWcaGeCypXW=pgiEacGDYF4WOpyX5H+4xLPaXDnck6g@mail.gmail.com>
	<CAHAreOr3jc0tys1C=k97E5wMmfGe7raKPHhhgrD_V1un+vtyBA@mail.gmail.com>
	<20111221100649.GA17767@volans.logilab.fr>
Message-ID: <CAHNn8BXyN2Y71pzOfiPFKwW7ma6t95OqEp6+EfL0cnZ25b6BZQ@mail.gmail.com>

On Wed, Dec 21, 2011 at 02:06, Nicolas Chauvat
<nicolas.chauvat at logilab.fr> wrote:
> On Tue, Dec 20, 2011 at 03:02:27PM -0800, Fernando Perez wrote:
>> > cost of making 0.11.1 would have been lower than the time we spent
>> > saying "duplicate of #XYZ, fixed in master" on GitHub.
>>
>> Agreed. ?It's easy enough to make such a branch after the fact, if it
>> proves to be necessary, and to cherry pick anything from master we'd
>> like to see in there. ?I agree that we probably should have cut a
>> 0.11.1 for that silly bug :)
>
> +1 having a stable branch where only fixes can enter and a development
> branch for the rest is a very common good practice.

It certainly is, and the reason we did not do so for 0.11, and would
consider not doing so for 0.12 is that we have planned a very short
release cycle (3-6 months per release) while recently introduced
features (zmq, qt, notebook) get settled.  In that situation bugfix
releases are of limited value, and our precious little dev time is
better put towards finishing each 'real' release.  But if we do find
any *critical* bugs like the zmq-version detection one, we should cut
a bugfix release to prevent perpetual reports of a long-fixed bug.

>
>> In this case there's an added incentive to a bugfix branch: while
>> we'll most likely get 0.12 included in ubuntu 12.04, they won't do a
>> version upgrade to 0.13. ?But I think they do push minor bugfix-only
>> updates, so it would help anyone in an environment that sticks to the
>> default ubuntu LTS policies get at least the most critical fixes.
>
> True. Distributions have their dev/stable phases too :)
>
> --
> Nicolas Chauvat
>
> logilab.fr - services en informatique scientifique et gestion de connaissances


From stefan at sun.ac.za  Wed Dec 21 12:04:12 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 21 Dec 2011 09:04:12 -0800
Subject: [IPython-dev] Notebook configuration defaults
Message-ID: <CABDkGQ=izFwD8w8PB9QP9nT9eO3v9wj-TcOg72NrM44246DB0w@mail.gmail.com>

Hi all,

I just did a demo of a fresh install of the IPython notebook for a
colleague.  Some comments:

- Not having "inline" as the default pylab mode is pretty confusing
and un-notebook-like.
- The notebook profile configuration file doesn't clearly indicate
that "inline" is an option for the pylab variable.
- Having configuration (such as the tab completer config) in the
side-bar is not ideal (especially if we're going to be adding more).
- Being able to launch "ipython notebook myfile.ipy" would be useful.

Cheers
St?fan


From fperez.net at gmail.com  Thu Dec 22 13:20:29 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 22 Dec 2011 10:20:29 -0800
Subject: [IPython-dev] You can help ipython: port the faq to the new wiki
Message-ID: <CAHAreOpmna4JOmEVDzfJZOEoWQiNW07zSdFnQi8G4eZaBkreXQ@mail.gmail.com>

Hi all,

here's something an enterprising user could give us a hand with, if
you'd like to contribute to the project.  When we moved our wiki from
the old moin instance to our new website, it seems we missed the FAQ
and possibly other similar pages.

The old one is here:

http://ipython.scipy.org/Wiki/FAQ

and I've made a placeholder here:

http://wiki.ipython.org/FrequentlyAskedQuestions

If you could help us in porting that old page over, it would be
awesome.  Some syntax conversions may be necessary, I set the
placeholder to use reST so that we can more easily move information
back and forth from the manual into the faq.

Bonus points for any other pages you may find out that we missed and
that you can help us with porting.

Best

f


From Nicolas.Rougier at inria.fr  Thu Dec 22 14:31:02 2011
From: Nicolas.Rougier at inria.fr (Nicolas Rougier)
Date: Thu, 22 Dec 2011 20:31:02 +0100
Subject: [IPython-dev] You can help ipython: port the faq to the new wiki
In-Reply-To: <CAHAreOpmna4JOmEVDzfJZOEoWQiNW07zSdFnQi8G4eZaBkreXQ@mail.gmail.com>
References: <CAHAreOpmna4JOmEVDzfJZOEoWQiNW07zSdFnQi8G4eZaBkreXQ@mail.gmail.com>
Message-ID: <FAE84992-C79D-4C9E-89F3-6DCCEB2B89E4@inria.fr>


Just did the port. Hope it's ok.

(It lacks the IpythonOnWindows link & page, I will try to work on it too).

By the way, last question may require some update.


Nicolas


On Dec 22, 2011, at 19:20 , Fernando Perez wrote:

> Hi all,
> 
> here's something an enterprising user could give us a hand with, if
> you'd like to contribute to the project.  When we moved our wiki from
> the old moin instance to our new website, it seems we missed the FAQ
> and possibly other similar pages.
> 
> The old one is here:
> 
> http://ipython.scipy.org/Wiki/FAQ
> 
> and I've made a placeholder here:
> 
> http://wiki.ipython.org/FrequentlyAskedQuestions
> 
> If you could help us in porting that old page over, it would be
> awesome.  Some syntax conversions may be necessary, I set the
> placeholder to use reST so that we can more easily move information
> back and forth from the manual into the faq.
> 
> Bonus points for any other pages you may find out that we missed and
> that you can help us with porting.
> 
> Best
> 
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



From ischnell at enthought.com  Fri Dec 23 11:55:48 2011
From: ischnell at enthought.com (Ilan Schnell)
Date: Fri, 23 Dec 2011 10:55:48 -0600
Subject: [IPython-dev] EPD 7.2 released
Message-ID: <CAAUn5qJbKJjk__g-O-T_sNRR3H2VMfP8_ppxxLO7JT1-S=EcZQ@mail.gmail.com>

Hello,

I am pleased to announce the release of Enthought Python Distribution, EPD
version 7.2, along with its "EPD Free" counterpart.  The highlights of this
release are: the addition of GDAL and updates to over 30 packages, including
SciPy, matplotlib and IPython.  The new IPython 0.12 includes the HTML
notebook, which caused the Tornado web-server also to be added to EPD.
To see which libraries are included in the free vs. full version, please see:

        http://www.enthought.com/products/epdlibraries.php

The complete list of additions, updates and fixes is in the change log:

        http://www.enthought.com/products/changelog.php

About EPD
---------
The Enthought Python Distribution (EPD) is a "kitchen-sink-included"
distribution of the Python programming language, including over 90
additional tools and libraries. The EPD bundle includes NumPy, SciPy,
IPython, 2D and 3D visualization tools, and many other tools.

EPD is currently available as a single-click installer for Windows XP,
Vista and 7, MacOS (10.5 and 10.6), RedHat 3, 4, 5 and 6, as well as
Solaris 10 (x86 and x86_64/amd64 on all platforms).

All versions of EPD (32 and 64-bit) are free for academic use.  An
annual subscription including installation support is available for
individual and commercial use.  Additional support options, including
customization, bug fixes and training classes are also available:

        http://www.enthought.com/products/epd_sublevels.php

- Ilan


From takowl at gmail.com  Fri Dec 23 13:04:32 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Fri, 23 Dec 2011 18:04:32 +0000
Subject: [IPython-dev] You can help ipython: port the faq to the new wiki
In-Reply-To: <FAE84992-C79D-4C9E-89F3-6DCCEB2B89E4@inria.fr>
References: <CAHAreOpmna4JOmEVDzfJZOEoWQiNW07zSdFnQi8G4eZaBkreXQ@mail.gmail.com>
	<FAE84992-C79D-4C9E-89F3-6DCCEB2B89E4@inria.fr>
Message-ID: <CAOvn4qgywozFkyBbhkVk-gRxXPdsB7Dp_Dq70NVfG9dQbiG+cA@mail.gmail.com>

When I was rearranging content, I thought the FAQ deserved to be on the
main website, which is why they weren't on the new wiki:

http://ipython.org/faq.html

Note that these have been updated a bit since then, although there's
probably more that could be done - e.g. we shouldn't mention Python 2.4 and
2.5, as it implies IPython still works there. Pull requests welcome at
https://github.com/ipython/ipython-website

Sorry I wasn't online sooner to point this out.

Thomas

On 22 December 2011 19:31, Nicolas Rougier <Nicolas.Rougier at inria.fr> wrote:

>
> Just did the port. Hope it's ok.
>
> (It lacks the IpythonOnWindows link & page, I will try to work on it too).
>
> By the way, last question may require some update.
>
>
> Nicolas
>
>
> On Dec 22, 2011, at 19:20 , Fernando Perez wrote:
>
> > Hi all,
> >
> > here's something an enterprising user could give us a hand with, if
> > you'd like to contribute to the project.  When we moved our wiki from
> > the old moin instance to our new website, it seems we missed the FAQ
> > and possibly other similar pages.
> >
> > The old one is here:
> >
> > http://ipython.scipy.org/Wiki/FAQ
> >
> > and I've made a placeholder here:
> >
> > http://wiki.ipython.org/FrequentlyAskedQuestions
> >
> > If you could help us in porting that old page over, it would be
> > awesome.  Some syntax conversions may be necessary, I set the
> > placeholder to use reST so that we can more easily move information
> > back and forth from the manual into the faq.
> >
> > Bonus points for any other pages you may find out that we missed and
> > that you can help us with porting.
> >
> > Best
> >
> > 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/20111223/1016338a/attachment.html>

From satra at mit.edu  Sat Dec 24 12:12:46 2011
From: satra at mit.edu (Satrajit Ghosh)
Date: Sat, 24 Dec 2011 18:12:46 +0100
Subject: [IPython-dev] pycharm now supports ipython 0.11
In-Reply-To: <CAHAreOqSw_QVJy5nmCGztRh51tYf7wnA_oPd3D0MPR=2k40jLQ@mail.gmail.com>
References: <CA+A4wOnDF9r-FwcLUUZWgaaWmO=nZhu3wTm2FN1DLuZmokSDtg@mail.gmail.com>
	<CAHAreOqSw_QVJy5nmCGztRh51tYf7wnA_oPd3D0MPR=2k40jLQ@mail.gmail.com>
Message-ID: <CA+A4wOkuS6FUW0RyFBFRPz=SDNGko4Xo7SsJEoRmgaq3o0GUZw@mail.gmail.com>

>
> Great!  Do you know if it works with current master as well?  And what
>  specific ipython support does it provide?
>

it looks like they included 0.11 and probably in the terminal mode (not the
two process kernel mode - anyway to quickly test?)

cheers,

satra

here are some outputs

---
/software/virtualenvs.EPD/7.1/devpype/bin/python -u
/Applications/PyCharm.app/helpers/pydev/pydevconsole.py 49830 49831
PyDev console: using IPython 0.11
import sys; print('Python %s on %s' % (sys.version, sys.platform))
Python 2.7.2 |CUSTOM| (default, Jul  3 2011, 15:56:02)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
sys.path.extend(['/Applications/PyCharm.app/helpers',
'/software/nipy-repo/scikit-learn'])
>>> %magic

IPython's 'magic' functions
===========================
---

another place:
---
>>> a = dict(foo=1, goo=2)
>>> a.keys()
Out[1]: ['goo', 'foo']
>>> _1
Out[1]: ['goo', 'foo']
---
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20111224/35078d78/attachment.html>

From satra at mit.edu  Sat Dec 24 12:13:28 2011
From: satra at mit.edu (Satrajit Ghosh)
Date: Sat, 24 Dec 2011 18:13:28 +0100
Subject: [IPython-dev] pycharm now supports ipython 0.11
In-Reply-To: <CA+A4wOkuS6FUW0RyFBFRPz=SDNGko4Xo7SsJEoRmgaq3o0GUZw@mail.gmail.com>
References: <CA+A4wOnDF9r-FwcLUUZWgaaWmO=nZhu3wTm2FN1DLuZmokSDtg@mail.gmail.com>
	<CAHAreOqSw_QVJy5nmCGztRh51tYf7wnA_oPd3D0MPR=2k40jLQ@mail.gmail.com>
	<CA+A4wOkuS6FUW0RyFBFRPz=SDNGko4Xo7SsJEoRmgaq3o0GUZw@mail.gmail.com>
Message-ID: <CA+A4wOk6Neo92gt+ntnHj=PygdPkgSnXj5ohFiR04LG5KvB_-Q@mail.gmail.com>

sorry 0.11 didn't have the two process mode anyway!

cheers,

satra

On Sat, Dec 24, 2011 at 6:12 PM, Satrajit Ghosh <satra at mit.edu> wrote:

> Great!  Do you know if it works with current master as well?  And what
>>  specific ipython support does it provide?
>>
>
> it looks like they included 0.11 and probably in the terminal mode (not
> the two process kernel mode - anyway to quickly test?)
>
> cheers,
>
> satra
>
> here are some outputs
>
> ---
> /software/virtualenvs.EPD/7.1/devpype/bin/python -u
> /Applications/PyCharm.app/helpers/pydev/pydevconsole.py 49830 49831
> PyDev console: using IPython 0.11
> import sys; print('Python %s on %s' % (sys.version, sys.platform))
> Python 2.7.2 |CUSTOM| (default, Jul  3 2011, 15:56:02)
> [GCC 4.0.1 (Apple Inc. build 5493)] on darwin
> sys.path.extend(['/Applications/PyCharm.app/helpers',
> '/software/nipy-repo/scikit-learn'])
> >>> %magic
>
> IPython's 'magic' functions
> ===========================
> ---
>
> another place:
> ---
> >>> a = dict(foo=1, goo=2)
> >>> a.keys()
> Out[1]: ['goo', 'foo']
> >>> _1
> Out[1]: ['goo', 'foo']
> ---
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20111224/897deda7/attachment.html>

From takowl at gmail.com  Sat Dec 24 12:47:04 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Sat, 24 Dec 2011 17:47:04 +0000
Subject: [IPython-dev] pycharm now supports ipython 0.11
In-Reply-To: <CA+A4wOk6Neo92gt+ntnHj=PygdPkgSnXj5ohFiR04LG5KvB_-Q@mail.gmail.com>
References: <CA+A4wOnDF9r-FwcLUUZWgaaWmO=nZhu3wTm2FN1DLuZmokSDtg@mail.gmail.com>
	<CAHAreOqSw_QVJy5nmCGztRh51tYf7wnA_oPd3D0MPR=2k40jLQ@mail.gmail.com>
	<CA+A4wOkuS6FUW0RyFBFRPz=SDNGko4Xo7SsJEoRmgaq3o0GUZw@mail.gmail.com>
	<CA+A4wOk6Neo92gt+ntnHj=PygdPkgSnXj5ohFiR04LG5KvB_-Q@mail.gmail.com>
Message-ID: <CAOvn4qhKoY4H7qF0e-rCg=Vj1AyfC=PWiamzEMqwK9EkHcdgTw@mail.gmail.com>

On 24 December 2011 17:13, Satrajit Ghosh <satra at mit.edu> wrote:

> sorry 0.11 didn't have the two process mode anyway!


It did, that's how the Qt console works. One easy way to check what it's
using:

import sys
sys.stdout

If the repr() of stdout looks like "<open file '<stdout>', mode 'w' at
0xb787a078>", it's just running in a terminal. If it mentions an OutStream
object (IIRC), it's ZMQ based.

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

From satra at mit.edu  Sat Dec 24 12:58:27 2011
From: satra at mit.edu (Satrajit Ghosh)
Date: Sat, 24 Dec 2011 18:58:27 +0100
Subject: [IPython-dev] pycharm now supports ipython 0.11
In-Reply-To: <CAOvn4qhKoY4H7qF0e-rCg=Vj1AyfC=PWiamzEMqwK9EkHcdgTw@mail.gmail.com>
References: <CA+A4wOnDF9r-FwcLUUZWgaaWmO=nZhu3wTm2FN1DLuZmokSDtg@mail.gmail.com>
	<CAHAreOqSw_QVJy5nmCGztRh51tYf7wnA_oPd3D0MPR=2k40jLQ@mail.gmail.com>
	<CA+A4wOkuS6FUW0RyFBFRPz=SDNGko4Xo7SsJEoRmgaq3o0GUZw@mail.gmail.com>
	<CA+A4wOk6Neo92gt+ntnHj=PygdPkgSnXj5ohFiR04LG5KvB_-Q@mail.gmail.com>
	<CAOvn4qhKoY4H7qF0e-rCg=Vj1AyfC=PWiamzEMqwK9EkHcdgTw@mail.gmail.com>
Message-ID: <CA+A4wOnf=t0+sUm6MMq+__tBbHAzMy_baXgvEdmmrFGf6rxsJw@mail.gmail.com>

>
>
> It did, that's how the Qt console works.

hi thomas,

sorry. should have been a little more precise. the terminal didn't have the
two process option. :)


> One easy way to check what it's using:
>
> import sys
> sys.stdout
>

thanks

>>> sys.stdout
Out[1]: <open file '<stdout>', mode 'w' at 0x10028a1e0>

so terminal based.

cheers,

satra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20111224/487e7f05/attachment.html>