From fperez.net at gmail.com  Fri Jul  1 22:26:51 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 1 Jul 2011 19:26:51 -0700
Subject: [IPython-dev] New wiki up for IPython
Message-ID: <BANLkTikSvNG5X1s5CbzTWXS+MqjqHr7+Pg@mail.gmail.com>

Hi folks,

we now have

http://wiki.ipython.org

as a mediawiki installation for IPython.

There's no content there yet, over the next few days we'll try to
migrate old content that wasn't in the docs, installing the mediawiki
reST extension so we can continue editing with reST (for ease of
transfer to the docs).

I hope this change will make the wiki experience a smoother one.

Cheers,

f


From benjaminrk at gmail.com  Sat Jul  2 17:21:21 2011
From: benjaminrk at gmail.com (MinRK)
Date: Sat, 2 Jul 2011 14:21:21 -0700
Subject: [IPython-dev] Ubuntu ppa for pyzmq
Message-ID: <CAHNn8BVqs+L+QUt+WDUoouq5-ou2iEiO-qa7UB1dnFFM1sxzcg@mail.gmail.com>

pyzmq doesn't have Linux binaries, because we don't want to maintain
eggs that should work on all flavors of Linux.

However, Ubuntu users are in luck, because Chris Lea has a zeromq ppa,
which as of today includes up to date pyzmq:
https://launchpad.net/~chris-lea/+archive/zeromq

Once you add the ppa to your sources, you should be able to just do:

apt-get install python-zeromq

-MinRK


From takowl at gmail.com  Sat Jul  2 17:30:31 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Sat, 2 Jul 2011 22:30:31 +0100
Subject: [IPython-dev] Ubuntu ppa for pyzmq
In-Reply-To: <CAHNn8BVqs+L+QUt+WDUoouq5-ou2iEiO-qa7UB1dnFFM1sxzcg@mail.gmail.com>
References: <CAHNn8BVqs+L+QUt+WDUoouq5-ou2iEiO-qa7UB1dnFFM1sxzcg@mail.gmail.com>
Message-ID: <CAOvn4qj1B461sbCGv6+zPqUozPP+=o7J=722ZftHbd=OV28ZcQ@mail.gmail.com>

Would it make more sense to call the package ipython-zmq, as it is in
Ubuntu's repositories, so that package managers see it as a newer version of
the same package?

Thomas

On 2 July 2011 22:21, MinRK <benjaminrk at gmail.com> wrote:

> pyzmq doesn't have Linux binaries, because we don't want to maintain
> eggs that should work on all flavors of Linux.
>
> However, Ubuntu users are in luck, because Chris Lea has a zeromq ppa,
> which as of today includes up to date pyzmq:
> https://launchpad.net/~chris-lea/+archive/zeromq<https://launchpad.net/%7Echris-lea/+archive/zeromq>
>
> Once you add the ppa to your sources, you should be able to just do:
>
> apt-get install python-zeromq
>
> -MinRK
> _______________________________________________
> 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/20110702/3755034b/attachment.html>

From benjaminrk at gmail.com  Sat Jul  2 17:45:53 2011
From: benjaminrk at gmail.com (MinRK)
Date: Sat, 2 Jul 2011 14:45:53 -0700
Subject: [IPython-dev] Ubuntu ppa for pyzmq
In-Reply-To: <CAOvn4qj1B461sbCGv6+zPqUozPP+=o7J=722ZftHbd=OV28ZcQ@mail.gmail.com>
References: <CAHNn8BVqs+L+QUt+WDUoouq5-ou2iEiO-qa7UB1dnFFM1sxzcg@mail.gmail.com>
	<CAOvn4qj1B461sbCGv6+zPqUozPP+=o7J=722ZftHbd=OV28ZcQ@mail.gmail.com>
Message-ID: <CAHNn8BXM58qnX9SKwkOsk2SFEeQBia3kiyhD7+Q3b-Hw3c7MWg@mail.gmail.com>

On Sat, Jul 2, 2011 at 14:30, Thomas Kluyver <takowl at gmail.com> wrote:
> Would it make more sense to call the package ipython-zmq, as it is in
> Ubuntu's repositories, so that package managers see it as a newer version of
> the same package?

That would be logical (assuming you mean python-zmq).  I should also
note that the 11.10 release is tracking pyzmq 2.1.7, so this fills
only a temporary need, while Ubuntu is behind the stable version.

-MinRK

>
> Thomas
>
> On 2 July 2011 22:21, MinRK <benjaminrk at gmail.com> wrote:
>>
>> pyzmq doesn't have Linux binaries, because we don't want to maintain
>> eggs that should work on all flavors of Linux.
>>
>> However, Ubuntu users are in luck, because Chris Lea has a zeromq ppa,
>> which as of today includes up to date pyzmq:
>> https://launchpad.net/~chris-lea/+archive/zeromq
>>
>> Once you add the ppa to your sources, you should be able to just do:
>>
>> apt-get install python-zeromq
>>
>> -MinRK
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>


From jtaylor.debian at googlemail.com  Sat Jul  2 18:05:01 2011
From: jtaylor.debian at googlemail.com (Julian Taylor)
Date: Sun, 03 Jul 2011 00:05:01 +0200
Subject: [IPython-dev] Ubuntu ppa for pyzmq
In-Reply-To: <CAHNn8BVqs+L+QUt+WDUoouq5-ou2iEiO-qa7UB1dnFFM1sxzcg@mail.gmail.com>
References: <CAHNn8BVqs+L+QUt+WDUoouq5-ou2iEiO-qa7UB1dnFFM1sxzcg@mail.gmail.com>
Message-ID: <4E0F960D.2060202@googlemail.com>

On 07/02/2011 11:21 PM, MinRK wrote:
> pyzmq doesn't have Linux binaries, because we don't want to maintain
> eggs that should work on all flavors of Linux.
> 
> However, Ubuntu users are in luck, because Chris Lea has a zeromq ppa,
> which as of today includes up to date pyzmq:
> https://launchpad.net/~chris-lea/+archive/zeromq
> 
> Once you add the ppa to your sources, you should be able to just do:
> 
> apt-get install python-zeromq
> 

Hi,
it would be better when the ppa mirrors the version in debian:
http://packages.qa.debian.org/p/pyzmq.html
This version is already available in debian testing and ubuntu oneiric
(11.10)
I was planning on requesting an official backport of zmq to natty soon.
Having two different packages of the same software will be confusing.

PS: The debian version is available in my experimental ppa
https://launchpad.net/~jtaylor/+archive/jtaylor
(*experimental* ppa use at own risk, for ipython you only need zeromq
and libpgm)

Best Regards,
Julian Taylor - debian/ubuntu ipython package maintainer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110703/3899cd9c/attachment.sig>

From fperez.net at gmail.com  Sun Jul  3 21:44:43 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 3 Jul 2011 18:44:43 -0700
Subject: [IPython-dev] IPython 0.11 RC1 is ready for download... now we're
 actually getting close to a real release!
Message-ID: <CAHAreOpaRPJS1KGWmwcV_gQnfdcmUw4np=8ZBHqQcZA-zUQp8g@mail.gmail.com>

Hello all,

We have just finished putting together the first Release Candidate for
IPython 0.11.  For users who have not followed development, this
brings *a lot* of changes to the innards of IPython, and the code is
much nicer to work on, and configuration more robust.  We ask that you
check out the RC, and make sure that it installs properly on your
system, and report any glaring bugs you see back to us.

You can download the files at:

http://archive.ipython.org/testing

Up to date documentation is at:

http://ipython.org/ipython-doc/dev/index.html

including more details on everything that is new here:

http://ipython.org/ipython-doc/dev/whatsnew/version0.11.html

We would very much appreciate it if you can take this for a spin, and
let us know what does NOT work.  Barring any major blockers, we'll
make the final release in ~ 1 week.

Note: there are some known regressions and the configuration system is
completely different.  But in everyday use, all the 'normal' things
you expect should work; most of us in the dev team have been using
this as our production IPython for months now.


Extra special thanks to all those who have contributed to this work,
particularly the recently added core devs, Evan Patterson and Thomas
Kluyver.  They have been an amazingly productive addition to our team.

Thanks,
-The IPython team


From ischnell at enthought.com  Sun Jul  3 22:37:00 2011
From: ischnell at enthought.com (Ilan Schnell)
Date: Sun, 3 Jul 2011 21:37:00 -0500
Subject: [IPython-dev] IPython 0.11 RC1 is ready for download... now
 we're actually getting close to a real release!
In-Reply-To: <CAHAreOpaRPJS1KGWmwcV_gQnfdcmUw4np=8ZBHqQcZA-zUQp8g@mail.gmail.com>
References: <CAHAreOpaRPJS1KGWmwcV_gQnfdcmUw4np=8ZBHqQcZA-zUQp8g@mail.gmail.com>
Message-ID: <CAAUn5q+YR4-7P5uEN1tvQgMn5SRJG=ALWPdBp8LGWhcAJXKjzA@mail.gmail.com>

Thanks great news.  IPython 0.11 is going into EPD 7.1 which we
want to release on Thursday, July 7.  So probably the rc1 will be
the version in EPD.  If there is an EPD 7.1 bug-fix release, we'll
update to 0.11 final in a few weeks.

- Ilan


On Sun, Jul 3, 2011 at 8:44 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> Hello all,
>
> We have just finished putting together the first Release Candidate for
> IPython 0.11. ?For users who have not followed development, this
> brings *a lot* of changes to the innards of IPython, and the code is
> much nicer to work on, and configuration more robust. ?We ask that you
> check out the RC, and make sure that it installs properly on your
> system, and report any glaring bugs you see back to us.
>
> You can download the files at:
>
> http://archive.ipython.org/testing
>
> Up to date documentation is at:
>
> http://ipython.org/ipython-doc/dev/index.html
>
> including more details on everything that is new here:
>
> http://ipython.org/ipython-doc/dev/whatsnew/version0.11.html
>
> We would very much appreciate it if you can take this for a spin, and
> let us know what does NOT work. ?Barring any major blockers, we'll
> make the final release in ~ 1 week.
>
> Note: there are some known regressions and the configuration system is
> completely different. ?But in everyday use, all the 'normal' things
> you expect should work; most of us in the dev team have been using
> this as our production IPython for months now.
>
>
> Extra special thanks to all those who have contributed to this work,
> particularly the recently added core devs, Evan Patterson and Thomas
> Kluyver. ?They have been an amazingly productive addition to our team.
>
> Thanks,
> -The IPython team
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>


From fperez.net at gmail.com  Sun Jul  3 22:43:32 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 3 Jul 2011 19:43:32 -0700
Subject: [IPython-dev] IPython 0.11 RC1 is ready for download... now
 we're actually getting close to a real release!
In-Reply-To: <CAAUn5q+YR4-7P5uEN1tvQgMn5SRJG=ALWPdBp8LGWhcAJXKjzA@mail.gmail.com>
References: <CAHAreOpaRPJS1KGWmwcV_gQnfdcmUw4np=8ZBHqQcZA-zUQp8g@mail.gmail.com>
	<CAAUn5q+YR4-7P5uEN1tvQgMn5SRJG=ALWPdBp8LGWhcAJXKjzA@mail.gmail.com>
Message-ID: <CAHAreOrXMXV-z-vw_VYuk_WSdYP45evEfLmuU4+Hp6Y9koEQxQ@mail.gmail.com>

On Sun, Jul 3, 2011 at 7:37 PM, Ilan Schnell <ischnell at enthought.com> wrote:
> Thanks great news. ?IPython 0.11 is going into EPD 7.1 which we
> want to release on Thursday, July 7. ?So probably the rc1 will be
> the version in EPD. ?If there is an EPD 7.1 bug-fix release, we'll
> update to 0.11 final in a few weeks.

That's great to hear, thanks Ilan!  But please test it first ;)

Cheers,

f


From ischnell at enthought.com  Mon Jul  4 00:39:43 2011
From: ischnell at enthought.com (Ilan Schnell)
Date: Sun, 3 Jul 2011 23:39:43 -0500
Subject: [IPython-dev] IPython 0.11 RC1 is ready for download... now
 we're actually getting close to a real release!
In-Reply-To: <CAHAreOrXMXV-z-vw_VYuk_WSdYP45evEfLmuU4+Hp6Y9koEQxQ@mail.gmail.com>
References: <CAHAreOpaRPJS1KGWmwcV_gQnfdcmUw4np=8ZBHqQcZA-zUQp8g@mail.gmail.com>
	<CAAUn5q+YR4-7P5uEN1tvQgMn5SRJG=ALWPdBp8LGWhcAJXKjzA@mail.gmail.com>
	<CAHAreOrXMXV-z-vw_VYuk_WSdYP45evEfLmuU4+Hp6Y9koEQxQ@mail.gmail.com>
Message-ID: <CAAUn5q+5+8F3jxPon66QtpTYvcY4Mak1LyPgzsYxCHi3YMkc4w@mail.gmail.com>

I already stated some testing with the current master, it
looks good so for.  Everything in EPD is tested, but the
real test is the one do out in the wild (as we all know).

- Ilan

On Sun, Jul 3, 2011 at 9:43 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Sun, Jul 3, 2011 at 7:37 PM, Ilan Schnell <ischnell at enthought.com> wrote:
>> Thanks great news. ?IPython 0.11 is going into EPD 7.1 which we
>> want to release on Thursday, July 7. ?So probably the rc1 will be
>> the version in EPD. ?If there is an EPD 7.1 bug-fix release, we'll
>> update to 0.11 final in a few weeks.
>
> That's great to hear, thanks Ilan! ?But please test it first ;)
>
> Cheers,
>
> f
>


From fperez.net at gmail.com  Mon Jul  4 01:47:53 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 3 Jul 2011 22:47:53 -0700
Subject: [IPython-dev] IPython 0.11 RC1 is ready for download... now
 we're actually getting close to a real release!
In-Reply-To: <CAAUn5q+5+8F3jxPon66QtpTYvcY4Mak1LyPgzsYxCHi3YMkc4w@mail.gmail.com>
References: <CAHAreOpaRPJS1KGWmwcV_gQnfdcmUw4np=8ZBHqQcZA-zUQp8g@mail.gmail.com>
	<CAAUn5q+YR4-7P5uEN1tvQgMn5SRJG=ALWPdBp8LGWhcAJXKjzA@mail.gmail.com>
	<CAHAreOrXMXV-z-vw_VYuk_WSdYP45evEfLmuU4+Hp6Y9koEQxQ@mail.gmail.com>
	<CAAUn5q+5+8F3jxPon66QtpTYvcY4Mak1LyPgzsYxCHi3YMkc4w@mail.gmail.com>
Message-ID: <CAHAreOq1B5F-VqkD2FUuY0S35A6YeeF470iE4XGAf2i_cGTS5Q@mail.gmail.com>

On Sun, Jul 3, 2011 at 9:39 PM, Ilan Schnell <ischnell at enthought.com> wrote:
> I already stated some testing with the current master, it
> looks good so for.

Glad to hear that; keep us posted if you see anything amiss, in
particular on Windows where the testing has been much lighter from our
side...

Cheers,

f


From tomspur at fedoraproject.org  Mon Jul  4 04:51:40 2011
From: tomspur at fedoraproject.org (Thomas Spura)
Date: Mon, 4 Jul 2011 10:51:40 +0200
Subject: [IPython-dev] IPython 0.11 RC1 is ready for download... now
 we're actually getting close to a real release!
In-Reply-To: <CAHAreOpaRPJS1KGWmwcV_gQnfdcmUw4np=8ZBHqQcZA-zUQp8g@mail.gmail.com>
References: <CAHAreOpaRPJS1KGWmwcV_gQnfdcmUw4np=8ZBHqQcZA-zUQp8g@mail.gmail.com>
Message-ID: <20110704105140.1f40bbc0@leonidas>

On Sun, 3 Jul 2011 18:44:43 -0700
Fernando Perez wrote:
> Note: there are some known regressions and the configuration system is
> completely different.  But in everyday use, all the 'normal' things
> you expect should work; most of us in the dev team have been using
> this as our production IPython for months now.

What does that mean in detail?
Are the old configuration files migrated to the new layout (so ipython
can be pushed out as an update to existing releases) or is it necessary
to do some manual tweaking?

Greetings,
   Thomas


From takowl at gmail.com  Mon Jul  4 05:58:23 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 4 Jul 2011 10:58:23 +0100
Subject: [IPython-dev] IPython 0.11 RC1 is ready for download... now
 we're actually getting close to a real release!
In-Reply-To: <20110704105140.1f40bbc0@leonidas>
References: <CAHAreOpaRPJS1KGWmwcV_gQnfdcmUw4np=8ZBHqQcZA-zUQp8g@mail.gmail.com>
	<20110704105140.1f40bbc0@leonidas>
Message-ID: <CAOvn4qhbFRDSDh6jfnz48A0yjw0=gPTCP_kieRzja9016dMUHA@mail.gmail.com>

On 4 July 2011 09:51, Thomas Spura <tomspur at fedoraproject.org> wrote:

> What does that mean in detail?
> Are the old configuration files migrated to the new layout (so ipython
> can be pushed out as an update to existing releases) or is it necessary
> to do some manual tweaking?
>

No, the configuration system is completely redesigned. It uses a different
file in a different location with a different format. We've not made any
attempt to convert the old files - it would probably be impractical. We do
offer a warning if the old config files are there, to show the user it's
changed.

Fernando et al: I think we should actually have another look at this warning
message. When we were discussing the config system, I remember that we
wanted to avoid creating the config files unless the user asks for them. But
all upgrading users will see a loud warning message every time they start
ipython, and at a glance it looks like the path of least resistance to get
rid of it is to create the new config. It's also not a great user
experience, if the first thing they see is a warning message that probably
95% can safely ignore.

We should consider:
- Making the warning message a lot quieter. The old config has no harmful
effects, it's just that it no longer works.
- Renaming the old config files automatically (most users will simply be
upgrading, and won't need to run the two versions side by side)
- Deleting the old config files only if they match the unmodified default
config from 0.10 (i.e. user never changed them)
- Adding comments at the top of the old config files like "This config file
will not affect IPython 0.11 or above. Please see..."

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

From jtaylor.debian at googlemail.com  Mon Jul  4 06:50:33 2011
From: jtaylor.debian at googlemail.com (Julian Taylor)
Date: Mon, 04 Jul 2011 12:50:33 +0200
Subject: [IPython-dev] IPython 0.11 RC1 is ready for download... now
 we're actually getting close to a real release!
In-Reply-To: <CAHAreOpaRPJS1KGWmwcV_gQnfdcmUw4np=8ZBHqQcZA-zUQp8g@mail.gmail.com>
References: <CAHAreOpaRPJS1KGWmwcV_gQnfdcmUw4np=8ZBHqQcZA-zUQp8g@mail.gmail.com>
Message-ID: <4E119AF9.6010409@googlemail.com>

On 07/04/2011 03:44 AM, Fernando Perez wrote:
> Hello all,
> 

Is there a way you can release a pure source tarball without the
pregenerated documentation?
It would save quite a few megabytes and I would not have to repackage
the source to comply with debian rules.

> 
> We would very much appreciate it if you can take this for a spin, and
> let us know what does NOT work.  Barring any major blockers, we'll
> make the final release in ~ 1 week.

building the rc1 source does not work as the parallel scripts are
missing in the rc1 tarball:

python setup.py build
running build_scripts
error: file
'/home/jtaylor/Downloads/ipython-0.11.rc1/IPython/parallel/scripts/ipengine'
does not exist

if you copy them from git it builds.


But there are still random crashes in the testsuite (~ every tenth time).
This might be a zmq bug. I'm using the current debian version 2.1.7-1.

test graceful handling of engine death (direct) ... *** glibc detected
*** /usr/bin/python2.7: free(): invalid pointer: 0x0000000003b38d30 ***
ok

======================================================================
ERROR: test_purge_results (IPython.parallel.tests.test_client.TestClient)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/media/Linux-data/home/Packages/ipython/pkg/build-area/ipython-0.11~rc1+ds1/IPython/parallel/tests/test_client.py",
line 253, in test_purge_results
    self.client.purge_results(hist[-1])
  File "<string>", line 2, in purge_results
  File
"/media/Linux-data/home/Packages/ipython/pkg/build-area/ipython-0.11~rc1+ds1/IPython/parallel/client/client.py",
line 65, in spin_first
    return f(self, *args, **kwargs)
  File
"/media/Linux-data/home/Packages/ipython/pkg/build-area/ipython-0.11~rc1+ds1/IPython/parallel/client/client.py",
line 1354, in purge_results
    raise self._unwrap_exception(content)
RemoteError: IndexError(msg pending: 'c3fb3002-ce81-40d2-b453-f7752c7fc949')
Traceback (most recent call last):
  File
"/media/Linux-data/home/Packages/ipython/pkg/build-area/ipython-0.11~rc1+ds1/IPython/parallel/controller/hub.py",
line 1081, in purge_results
    raise IndexError("msg pending: %r"%pending[0])
IndexError: msg pending: 'c3fb3002-ce81-40d2-b453-f7752c7fc949'

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110704/102bc378/attachment.sig>

From walter at livinglogic.de  Mon Jul  4 07:27:25 2011
From: walter at livinglogic.de (=?UTF-8?B?V2FsdGVyIETDtnJ3YWxk?=)
Date: Mon, 04 Jul 2011 13:27:25 +0200
Subject: [IPython-dev] IPython 0.11 RC1 is ready for download... now
 we're actually getting close to a real release!
In-Reply-To: <CAHAreOpaRPJS1KGWmwcV_gQnfdcmUw4np=8ZBHqQcZA-zUQp8g@mail.gmail.com>
References: <CAHAreOpaRPJS1KGWmwcV_gQnfdcmUw4np=8ZBHqQcZA-zUQp8g@mail.gmail.com>
Message-ID: <4E11A39D.7080301@livinglogic.de>

On 04.07.11 03:44, Fernando Perez wrote:

> Hello all,
> 
> We have just finished putting together the first Release Candidate for
> IPython 0.11.  For users who have not followed development, this
> brings *a lot* of changes to the innards of IPython, and the code is
> much nicer to work on, and configuration more robust.  We ask that you
> check out the RC, and make sure that it installs properly on your
> system, and report any glaring bugs you see back to us.
> 
> You can download the files at:
> 
> http://archive.ipython.org/testing
> 
> Up to date documentation is at:
> 
> http://ipython.org/ipython-doc/dev/index.html
> 
> including more details on everything that is new here:
> 
> http://ipython.org/ipython-doc/dev/whatsnew/version0.11.html
> 
> We would very much appreciate it if you can take this for a spin, and
> let us know what does NOT work.  Barring any major blockers, we'll
> make the final release in ~ 1 week.
> 
> Note: there are some known regressions and the configuration system is
> completely different.  But in everyday use, all the 'normal' things
> you expect should work; most of us in the dev team have been using
> this as our production IPython for months now.

I'm trying to update my old configuration. How can I find the IPython
version number, i.e. what's the equivalent of

from IPython import Release
print Release.version

Servus,
   Walter




From johann.cohentanugi at gmail.com  Mon Jul  4 07:48:59 2011
From: johann.cohentanugi at gmail.com (Johann Cohen-Tanugi)
Date: Mon, 04 Jul 2011 13:48:59 +0200
Subject: [IPython-dev] IPython 0.11 RC1 is ready for download... now
 we're actually getting close to a real release!
In-Reply-To: <4E11A39D.7080301@livinglogic.de>
References: <CAHAreOpaRPJS1KGWmwcV_gQnfdcmUw4np=8ZBHqQcZA-zUQp8g@mail.gmail.com>
	<4E11A39D.7080301@livinglogic.de>
Message-ID: <4E11A8AB.1020804@gmail.com>

In [4]: import IPython

In [5]: IPython.__version__
Out[5]: '0.11.dev'

but I am not sure it is going to be informative enough for you....

Johann

On 07/04/2011 01:27 PM, Walter D?rwald wrote:
> On 04.07.11 03:44, Fernando Perez wrote:
>
>> Hello all,
>>
>> We have just finished putting together the first Release Candidate for
>> IPython 0.11.  For users who have not followed development, this
>> brings *a lot* of changes to the innards of IPython, and the code is
>> much nicer to work on, and configuration more robust.  We ask that you
>> check out the RC, and make sure that it installs properly on your
>> system, and report any glaring bugs you see back to us.
>>
>> You can download the files at:
>>
>> http://archive.ipython.org/testing
>>
>> Up to date documentation is at:
>>
>> http://ipython.org/ipython-doc/dev/index.html
>>
>> including more details on everything that is new here:
>>
>> http://ipython.org/ipython-doc/dev/whatsnew/version0.11.html
>>
>> We would very much appreciate it if you can take this for a spin, and
>> let us know what does NOT work.  Barring any major blockers, we'll
>> make the final release in ~ 1 week.
>>
>> Note: there are some known regressions and the configuration system is
>> completely different.  But in everyday use, all the 'normal' things
>> you expect should work; most of us in the dev team have been using
>> this as our production IPython for months now.
> I'm trying to update my old configuration. How can I find the IPython
> version number, i.e. what's the equivalent of
>
> from IPython import Release
> print Release.version
>
> Servus,
>     Walter
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>


From walter at livinglogic.de  Mon Jul  4 08:46:32 2011
From: walter at livinglogic.de (=?UTF-8?B?V2FsdGVyIETDtnJ3YWxk?=)
Date: Mon, 04 Jul 2011 14:46:32 +0200
Subject: [IPython-dev] IPython 0.11 RC1 is ready for download... now
 we're actually getting close to a real release!
In-Reply-To: <4E11A8AB.1020804@gmail.com>
References: <CAHAreOpaRPJS1KGWmwcV_gQnfdcmUw4np=8ZBHqQcZA-zUQp8g@mail.gmail.com>
	<4E11A39D.7080301@livinglogic.de> <4E11A8AB.1020804@gmail.com>
Message-ID: <4E11B628.90500@livinglogic.de>

On 04.07.11 13:48, Johann Cohen-Tanugi wrote:

> In [4]: import IPython
> 
> In [5]: IPython.__version__
> Out[5]: '0.11.dev'
> 
> but I am not sure it is going to be informative enough for you....

Thanks, that does the trick.

Servus,
   Walter

> On 07/04/2011 01:27 PM, Walter D?rwald wrote:
>> On 04.07.11 03:44, Fernando Perez wrote:
>>
>>> Hello all,
>>>
>>> We have just finished putting together the first Release Candidate for
>>> IPython 0.11.  For users who have not followed development, this
>>> brings *a lot* of changes to the innards of IPython, and the code is
>>> much nicer to work on, and configuration more robust.  We ask that you
>>> check out the RC, and make sure that it installs properly on your
>>> system, and report any glaring bugs you see back to us.
>>>
>>> You can download the files at:
>>>
>>> http://archive.ipython.org/testing
>>>
>>> Up to date documentation is at:
>>>
>>> http://ipython.org/ipython-doc/dev/index.html
>>>
>>> including more details on everything that is new here:
>>>
>>> http://ipython.org/ipython-doc/dev/whatsnew/version0.11.html
>>>
>>> We would very much appreciate it if you can take this for a spin, and
>>> let us know what does NOT work.  Barring any major blockers, we'll
>>> make the final release in ~ 1 week.
>>>
>>> Note: there are some known regressions and the configuration system is
>>> completely different.  But in everyday use, all the 'normal' things
>>> you expect should work; most of us in the dev team have been using
>>> this as our production IPython for months now.
>> I'm trying to update my old configuration. How can I find the IPython
>> version number, i.e. what's the equivalent of
>>
>> from IPython import Release
>> print Release.version
>>
>> Servus,
>>     Walter
>>
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
> 



From johann.cohentanugi at gmail.com  Mon Jul  4 11:07:33 2011
From: johann.cohentanugi at gmail.com (Johann Cohen-Tanugi)
Date: Mon, 04 Jul 2011 17:07:33 +0200
Subject: [IPython-dev] 0.11rc1 : problem with tutorial for PBS in
	http://ipython.org/ipython-doc/dev/parallel/parallel_process.html
Message-ID: <4E11D735.9080909@gmail.com>

hi there, my problem is in the fact that a line seems to be added to the 
template I am defining following the tutorial :
the template proposed in the tutorial is modified at runtime as :

#!/bin/sh
#PBS -t 1-4 <----------------- incorrect?
#PBS -V
#PBS -N ipengine
/usr/local/bin/python 
/sps/glast/users/cohen/IPYDEV/ipython/IPython/parallel/apps/ipengineapp.py 
profile_dir=/afs/in2p3.fr/home/t/tanugi/\
.ipython/profile_pbs


The problem I believe is in the job_array_template in  :

class PBSLauncher(BatchSystemLauncher):
     """A BatchSystemLauncher subclass for PBS."""

     submit_command = List(['qsub'], config=True,
         help="The PBS submit command ['qsub']")
     delete_command = List(['qdel'], config=True,
         help="The PBS delete command ['qsub']")
     job_id_regexp = Unicode(r'\d+', config=True,
         help="Regular expresion for identifying the job ID [r'\d+']")

     batch_file = Unicode(u'')
     job_array_regexp = Unicode('#PBS\W+-t\W+[\w\d\-\$]+')
     job_array_template = Unicode('#PBS -t 1-{n}')
     queue_regexp = Unicode('#PBS\W+-q\W+\$?\w+')
     queue_template = Unicode('#PBS -q {queue}')


I looked at the PBS doc for version 10 and 11 and I did not see any '-t' 
option. When I try to run, I get :
[tanugi at ccali28 test_directory]$ ipcluster start profile=pbs n=4
[IPClusterStart] Using existing profile dir: 
u'/afs/in2p3.fr/home/t/tanugi/.ipython/profile_pbs'
[IPClusterStart] Starting ipcluster with [daemon=False]
[IPClusterStart] Creating pid file: 
/afs/in2p3.fr/home/t/tanugi/.ipython/profile_pbs/pid/ipcluster.pid
[IPClusterStart] Starting PBSControllerLauncher: ['qsub', 
u'/afs/in2p3.fr/home/t/tanugi/.ipython/profile_pbs/pbs_controller']
[IPClusterStart] adding job array settings to batch script
[IPClusterStart] Writing instantiated batch script: 
/afs/in2p3.fr/home/t/tanugi/.ipython/profile_pbs/pbs_controller
unknown -t option
ERROR:root:Error in periodic callback
Traceback (most recent call last):
   File 
"/sps/glast/users/cohen/IPYDEV/local/lib/python2.6/site-packages/zmq/eventloop/ioloop.py", 
line 432, in _run
     self.callback()
   File 
"/sps/glast/users/cohen/IPYDEV/ipython/IPython/parallel/apps/ipclusterapp.py", 
line 364, in start_controller
     self.profile_dir.location
   File 
"/sps/glast/users/cohen/IPYDEV/ipython/IPython/parallel/apps/launcher.py", 
line 943, in start
     return super(PBSControllerLauncher, self).start(1, profile_dir)
   File 
"/sps/glast/users/cohen/IPYDEV/ipython/IPython/parallel/apps/launcher.py", 
line 902, in start
     job_id = self.parse_job_id(output)
   File 
"/sps/glast/users/cohen/IPYDEV/ipython/IPython/parallel/apps/launcher.py", 
line 854, in parse_job_id
     raise LauncherError("Job id couldn't be determined: %s" % output)
LauncherError: Job id couldn't be determined:

Not sure yet about the traceback, but the "unknown -t option" is clear. 
Furthermore, I wonder if it is really what we want to add lines to a 
template file provided by the user?

best,
Johann


From matthew.brett at gmail.com  Mon Jul  4 12:01:21 2011
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 4 Jul 2011 17:01:21 +0100
Subject: [IPython-dev] IPython 0.11 RC1 is ready for download... now
 we're actually getting close to a real release!
In-Reply-To: <CAH6Pt5p1PGDhAjHTJP9Kt2=QOtX2OZtg_7huS1+_iwWJcCD_-Q@mail.gmail.com>
References: <CAHAreOpaRPJS1KGWmwcV_gQnfdcmUw4np=8ZBHqQcZA-zUQp8g@mail.gmail.com>
	<CAH6Pt5p1PGDhAjHTJP9Kt2=QOtX2OZtg_7huS1+_iwWJcCD_-Q@mail.gmail.com>
Message-ID: <CAH6Pt5oNiOdwLC+gHWcuNXQtCPAKft+o4oYJT0WsLL0c+EYv8A@mail.gmail.com>

Hi,

On Mon, Jul 4, 2011 at 2:44 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> Hello all,
>
> We have just finished putting together the first Release Candidate for
> IPython 0.11. ?For users who have not followed development, this
> brings *a lot* of changes to the innards of IPython, and the code is
> much nicer to work on, and configuration more robust. ?We ask that you
> check out the RC, and make sure that it installs properly on your
> system, and report any glaring bugs you see back to us.

Just some notes on OSX.

easy_install of pyzmq failed - needing zmq.h - I made an issue for
pyzmq in case that was a bug.
I got a bit bored trying trying to compile universal binaries for zmq
and gave up.
I downloaded and easy_installed the pyzmq python 2.6 egg from pypi;
this gave an error as it appeared to believe that pyzmq had a
dependency on pyzmq and then tried downloading the pypi file again
with the same error as above. ?However, despite this, the egg install
appeared to work (import zmq).

python setup.py install of ipython worked fine

I see 'Exit' has gone and 'exit' just exits - I think this is not in
'What's new' but I may have missed it.  Maybe deprecated alias Exit?

I tried:

from IPython import embed
embed()

and got:

Traceback (most recent call last):
...
IOError: File u'ipython_config.py' does not exist in any of the search
paths: (u'/Users/mb312/.ipython/profile_default',)

I was surprised that I could start ipython without this error, but the
embed() shell raised it. ?Obviously:

ipython profile create

solved that one, but maybe it would be worth documenting.

Thanks for the release RC, looking forward to it...

Matthew


From takowl at gmail.com  Mon Jul  4 12:17:31 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 4 Jul 2011 17:17:31 +0100
Subject: [IPython-dev] IPython 0.11 RC1 is ready for download... now
 we're actually getting close to a real release!
In-Reply-To: <CAH6Pt5oNiOdwLC+gHWcuNXQtCPAKft+o4oYJT0WsLL0c+EYv8A@mail.gmail.com>
References: <CAHAreOpaRPJS1KGWmwcV_gQnfdcmUw4np=8ZBHqQcZA-zUQp8g@mail.gmail.com>
	<CAH6Pt5p1PGDhAjHTJP9Kt2=QOtX2OZtg_7huS1+_iwWJcCD_-Q@mail.gmail.com>
	<CAH6Pt5oNiOdwLC+gHWcuNXQtCPAKft+o4oYJT0WsLL0c+EYv8A@mail.gmail.com>
Message-ID: <CAOvn4qi0nYQoJOSV9vf4hx-27BDS47pBsAFv6TY+ZqD-1RSs7g@mail.gmail.com>

On 4 July 2011 17:01, Matthew Brett <matthew.brett at gmail.com> wrote:

> I see 'Exit' has gone and 'exit' just exits - I think this is not in
> 'What's new' but I may have missed it.  Maybe deprecated alias Exit?
>

Oh yes, Exit is gone. I'll add a note to the What's New docs.


>  I tried:
>
> from IPython import embed
> embed()
>
<snip>

That sounds like a bug. I've filed an issue for it:

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

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

From jorgen.stenarson at bostream.nu  Mon Jul  4 12:47:13 2011
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Mon, 04 Jul 2011 18:47:13 +0200
Subject: [IPython-dev] IPython 0.11 RC1 is ready for download... now
 we're actually getting close to a real release!
In-Reply-To: <CAHAreOpaRPJS1KGWmwcV_gQnfdcmUw4np=8ZBHqQcZA-zUQp8g@mail.gmail.com>
References: <CAHAreOpaRPJS1KGWmwcV_gQnfdcmUw4np=8ZBHqQcZA-zUQp8g@mail.gmail.com>
Message-ID: <4E11EE91.7070306@bostream.nu>

Fernando Perez skrev 2011-07-04 03:44:
> Hello all,
>
> We have just finished putting together the first Release Candidate for
> IPython 0.11.  For users who have not followed development, this
> brings *a lot* of changes to the innards of IPython, and the code is
> much nicer to work on, and configuration more robust.  We ask that you
> check out the RC, and make sure that it installs properly on your
> system, and report any glaring bugs you see back to us.
>
> You can download the files at:
>
> http://archive.ipython.org/testing
>
> Up to date documentation is at:
>
> http://ipython.org/ipython-doc/dev/index.html
>
> including more details on everything that is new here:
>
> http://ipython.org/ipython-doc/dev/whatsnew/version0.11.html
>
> We would very much appreciate it if you can take this for a spin, and
> let us know what does NOT work.  Barring any major blockers, we'll
> make the final release in ~ 1 week.
>
> Note: there are some known regressions and the configuration system is
> completely different.  But in everyday use, all the 'normal' things
> you expect should work; most of us in the dev team have been using
> this as our production IPython for months now.
>
>
> Extra special thanks to all those who have contributed to this work,
> particularly the recently added core devs, Evan Patterson and Thomas
> Kluyver.  They have been an amazingly productive addition to our team.
>
> Thanks,
> -The IPython team
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev

Some results for testing on windows using python2.7-32bit windows 7 64-bit.

I get an import error when trying to launch qtconsole if pygments is not 
installed

Traceback (most recent call last):
   File "<string>", line 1, in <module>
NameError: name 'lanuch_new_instance' is not defined
C:\python27> .\python.exe -c "from IPython.frontend.terminal.ipapp 
import launch_new_instance;launch_new_instance()" qtc
onsole
Traceback (most recent call last):
   File "<string>", line 1, in <module>
   File 
"C:\python27\lib\site-packages\IPython\frontend\terminal\ipapp.py", line 
353, in launch_new_instance
     app.initialize()
   File 
"C:\python27\lib\site-packages\IPython\frontend\terminal\ipapp.py", line 
261, in initialize
     super(TerminalIPythonApp, self).initialize(argv)
   File "C:\python27\lib\site-packages\IPython\core\application.py", 
line 296, in initialize
     self.parse_command_line(argv)
   File 
"C:\python27\lib\site-packages\IPython\frontend\terminal\ipapp.py", line 
257, in parse_command_line
     return super(TerminalIPythonApp, self).parse_command_line(argv)
   File "C:\python27\lib\site-packages\IPython\config\application.py", 
line 319, in parse_command_line
     return self.initialize_subcommand(subc, subargv)
   File "C:\python27\lib\site-packages\IPython\config\application.py", 
line 301, in initialize_subcommand
     subapp = import_item(subapp)
   File "C:\python27\lib\site-packages\IPython\utils\importstring.py", 
line 40, in import_item
     module = __import__(package,fromlist=[obj])
   File 
"C:\python27\lib\site-packages\IPython\frontend\qt\console\qtconsoleapp.py", 
line 26, in <module>
     from pygments.styles import get_all_styles
ImportError: No module named pygments.styles

For me "ipython-qtconsole.exe --pylab inline" does not work. I get the 
figure in a qt window instead.


The pypi page will have to be updated with dependencies (pyzmq, pygments...)

/J?rgen





From songofacandy at gmail.com  Mon Jul  4 13:05:44 2011
From: songofacandy at gmail.com (INADA Naoki)
Date: Tue, 5 Jul 2011 02:05:44 +0900
Subject: [IPython-dev] IPython 0.11 RC1 is ready for download... now
 we're actually getting close to a real release!
In-Reply-To: <4E11EE91.7070306@bostream.nu>
References: <CAHAreOpaRPJS1KGWmwcV_gQnfdcmUw4np=8ZBHqQcZA-zUQp8g@mail.gmail.com>
	<4E11EE91.7070306@bostream.nu>
Message-ID: <CAEfz+TwEBk8avTyY7pz+FSfPsSWd3KBzfvjaY7F6O3PDivPBEw@mail.gmail.com>

> The pypi page will have to be updated with dependencies (pyzmq, pygments...)

I'm using IPython on some platform including linux console and Windows desktop.
I don't need pyzmq and pygments to use IPython on console and Windows
command prompt.
So I vote -1 to add dependency.

On Tue, Jul 5, 2011 at 1:47 AM, J?rgen Stenarson
<jorgen.stenarson at bostream.nu> wrote:
> Fernando Perez skrev 2011-07-04 03:44:
>> Hello all,
>>
>> We have just finished putting together the first Release Candidate for
>> IPython 0.11. ?For users who have not followed development, this
>> brings *a lot* of changes to the innards of IPython, and the code is
>> much nicer to work on, and configuration more robust. ?We ask that you
>> check out the RC, and make sure that it installs properly on your
>> system, and report any glaring bugs you see back to us.
>>
>> You can download the files at:
>>
>> http://archive.ipython.org/testing
>>
>> Up to date documentation is at:
>>
>> http://ipython.org/ipython-doc/dev/index.html
>>
>> including more details on everything that is new here:
>>
>> http://ipython.org/ipython-doc/dev/whatsnew/version0.11.html
>>
>> We would very much appreciate it if you can take this for a spin, and
>> let us know what does NOT work. ?Barring any major blockers, we'll
>> make the final release in ~ 1 week.
>>
>> Note: there are some known regressions and the configuration system is
>> completely different. ?But in everyday use, all the 'normal' things
>> you expect should work; most of us in the dev team have been using
>> this as our production IPython for months now.
>>
>>
>> Extra special thanks to all those who have contributed to this work,
>> particularly the recently added core devs, Evan Patterson and Thomas
>> Kluyver. ?They have been an amazingly productive addition to our team.
>>
>> Thanks,
>> -The IPython team
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
> Some results for testing on windows using python2.7-32bit windows 7 64-bit.
>
> I get an import error when trying to launch qtconsole if pygments is not
> installed
>
> Traceback (most recent call last):
> ? File "<string>", line 1, in <module>
> NameError: name 'lanuch_new_instance' is not defined
> C:\python27> .\python.exe -c "from IPython.frontend.terminal.ipapp
> import launch_new_instance;launch_new_instance()" qtc
> onsole
> Traceback (most recent call last):
> ? File "<string>", line 1, in <module>
> ? File
> "C:\python27\lib\site-packages\IPython\frontend\terminal\ipapp.py", line
> 353, in launch_new_instance
> ? ? app.initialize()
> ? File
> "C:\python27\lib\site-packages\IPython\frontend\terminal\ipapp.py", line
> 261, in initialize
> ? ? super(TerminalIPythonApp, self).initialize(argv)
> ? File "C:\python27\lib\site-packages\IPython\core\application.py",
> line 296, in initialize
> ? ? self.parse_command_line(argv)
> ? File
> "C:\python27\lib\site-packages\IPython\frontend\terminal\ipapp.py", line
> 257, in parse_command_line
> ? ? return super(TerminalIPythonApp, self).parse_command_line(argv)
> ? File "C:\python27\lib\site-packages\IPython\config\application.py",
> line 319, in parse_command_line
> ? ? return self.initialize_subcommand(subc, subargv)
> ? File "C:\python27\lib\site-packages\IPython\config\application.py",
> line 301, in initialize_subcommand
> ? ? subapp = import_item(subapp)
> ? File "C:\python27\lib\site-packages\IPython\utils\importstring.py",
> line 40, in import_item
> ? ? module = __import__(package,fromlist=[obj])
> ? File
> "C:\python27\lib\site-packages\IPython\frontend\qt\console\qtconsoleapp.py",
> line 26, in <module>
> ? ? from pygments.styles import get_all_styles
> ImportError: No module named pygments.styles
>
> For me "ipython-qtconsole.exe --pylab inline" does not work. I get the
> figure in a qt window instead.
>
>
> The pypi page will have to be updated with dependencies (pyzmq, pygments...)
>
> /J?rgen
>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
INADA Naoki? <songofacandy at gmail.com>


From benjaminrk at gmail.com  Mon Jul  4 13:19:42 2011
From: benjaminrk at gmail.com (MinRK)
Date: Mon, 4 Jul 2011 10:19:42 -0700
Subject: [IPython-dev] IPython 0.11 RC1 is ready for download... now
 we're actually getting close to a real release!
In-Reply-To: <CAEfz+TwEBk8avTyY7pz+FSfPsSWd3KBzfvjaY7F6O3PDivPBEw@mail.gmail.com>
References: <CAHAreOpaRPJS1KGWmwcV_gQnfdcmUw4np=8ZBHqQcZA-zUQp8g@mail.gmail.com>
	<4E11EE91.7070306@bostream.nu>
	<CAEfz+TwEBk8avTyY7pz+FSfPsSWd3KBzfvjaY7F6O3PDivPBEw@mail.gmail.com>
Message-ID: <CAHNn8BVSnGuoiXko6DJW5GePO18z+uJGKbYjFB1tE3Txz-3yYg@mail.gmail.com>

Hi all,

Thanks for the feedback!

I've fixed the embed() issue, and also updated the MANIFEST, so it
should include all the scripts properly in the sdist (I *definitely*
should have checked this one more thoroughly).

As for the pyzmq/pygments dependencies, they are *optional*
dependencies just like we have always had, so will never be added as
hard install dependencies, but they should probably be described on
the pypi page, as they are on the install page in the docs:

http://ipython.org/ipython-doc/dev/install/install.html#basic-optional-dependencies

-MinRK

On Mon, Jul 4, 2011 at 10:05, INADA Naoki <songofacandy at gmail.com> wrote:
>> The pypi page will have to be updated with dependencies (pyzmq, pygments...)
>
> I'm using IPython on some platform including linux console and Windows desktop.
> I don't need pyzmq and pygments to use IPython on console and Windows
> command prompt.
> So I vote -1 to add dependency.
>
> On Tue, Jul 5, 2011 at 1:47 AM, J?rgen Stenarson
> <jorgen.stenarson at bostream.nu> wrote:
>> Fernando Perez skrev 2011-07-04 03:44:
>>> Hello all,
>>>
>>> We have just finished putting together the first Release Candidate for
>>> IPython 0.11. ?For users who have not followed development, this
>>> brings *a lot* of changes to the innards of IPython, and the code is
>>> much nicer to work on, and configuration more robust. ?We ask that you
>>> check out the RC, and make sure that it installs properly on your
>>> system, and report any glaring bugs you see back to us.
>>>
>>> You can download the files at:
>>>
>>> http://archive.ipython.org/testing
>>>
>>> Up to date documentation is at:
>>>
>>> http://ipython.org/ipython-doc/dev/index.html
>>>
>>> including more details on everything that is new here:
>>>
>>> http://ipython.org/ipython-doc/dev/whatsnew/version0.11.html
>>>
>>> We would very much appreciate it if you can take this for a spin, and
>>> let us know what does NOT work. ?Barring any major blockers, we'll
>>> make the final release in ~ 1 week.
>>>
>>> Note: there are some known regressions and the configuration system is
>>> completely different. ?But in everyday use, all the 'normal' things
>>> you expect should work; most of us in the dev team have been using
>>> this as our production IPython for months now.
>>>
>>>
>>> Extra special thanks to all those who have contributed to this work,
>>> particularly the recently added core devs, Evan Patterson and Thomas
>>> Kluyver. ?They have been an amazingly productive addition to our team.
>>>
>>> Thanks,
>>> -The IPython team
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>> Some results for testing on windows using python2.7-32bit windows 7 64-bit.
>>
>> I get an import error when trying to launch qtconsole if pygments is not
>> installed
>>
>> Traceback (most recent call last):
>> ? File "<string>", line 1, in <module>
>> NameError: name 'lanuch_new_instance' is not defined
>> C:\python27> .\python.exe -c "from IPython.frontend.terminal.ipapp
>> import launch_new_instance;launch_new_instance()" qtc
>> onsole
>> Traceback (most recent call last):
>> ? File "<string>", line 1, in <module>
>> ? File
>> "C:\python27\lib\site-packages\IPython\frontend\terminal\ipapp.py", line
>> 353, in launch_new_instance
>> ? ? app.initialize()
>> ? File
>> "C:\python27\lib\site-packages\IPython\frontend\terminal\ipapp.py", line
>> 261, in initialize
>> ? ? super(TerminalIPythonApp, self).initialize(argv)
>> ? File "C:\python27\lib\site-packages\IPython\core\application.py",
>> line 296, in initialize
>> ? ? self.parse_command_line(argv)
>> ? File
>> "C:\python27\lib\site-packages\IPython\frontend\terminal\ipapp.py", line
>> 257, in parse_command_line
>> ? ? return super(TerminalIPythonApp, self).parse_command_line(argv)
>> ? File "C:\python27\lib\site-packages\IPython\config\application.py",
>> line 319, in parse_command_line
>> ? ? return self.initialize_subcommand(subc, subargv)
>> ? File "C:\python27\lib\site-packages\IPython\config\application.py",
>> line 301, in initialize_subcommand
>> ? ? subapp = import_item(subapp)
>> ? File "C:\python27\lib\site-packages\IPython\utils\importstring.py",
>> line 40, in import_item
>> ? ? module = __import__(package,fromlist=[obj])
>> ? File
>> "C:\python27\lib\site-packages\IPython\frontend\qt\console\qtconsoleapp.py",
>> line 26, in <module>
>> ? ? from pygments.styles import get_all_styles
>> ImportError: No module named pygments.styles
>>
>> For me "ipython-qtconsole.exe --pylab inline" does not work. I get the
>> figure in a qt window instead.
>>
>>
>> The pypi page will have to be updated with dependencies (pyzmq, pygments...)
>>
>> /J?rgen
>>
>>
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>
>
>
> --
> INADA Naoki? <songofacandy at gmail.com>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>


From takowl at gmail.com  Mon Jul  4 13:52:51 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 4 Jul 2011 18:52:51 +0100
Subject: [IPython-dev] IPython 0.11 RC1 is ready for download... now
 we're actually getting close to a real release!
In-Reply-To: <CAHNn8BVSnGuoiXko6DJW5GePO18z+uJGKbYjFB1tE3Txz-3yYg@mail.gmail.com>
References: <CAHAreOpaRPJS1KGWmwcV_gQnfdcmUw4np=8ZBHqQcZA-zUQp8g@mail.gmail.com>
	<4E11EE91.7070306@bostream.nu>
	<CAEfz+TwEBk8avTyY7pz+FSfPsSWd3KBzfvjaY7F6O3PDivPBEw@mail.gmail.com>
	<CAHNn8BVSnGuoiXko6DJW5GePO18z+uJGKbYjFB1tE3Txz-3yYg@mail.gmail.com>
Message-ID: <CAOvn4qh5LhAh0Z+0awUdD378W7jxuDB7dE_9ozYBvkqhTDZvvA@mail.gmail.com>

On 4 July 2011 18:19, MinRK <benjaminrk at gmail.com> wrote:

> As for the pyzmq/pygments dependencies, they are *optional*
> dependencies just like we have always had, so will never be added as
> hard install dependencies, but they should probably be described on
> the pypi page, as they are on the install page in the docs:
>

I think that Debian packaging may well split IPython up into >= 2 distinct
packages: a core package with minimal dependencies, and a qtconsole package
which depends on the core package, pyzmq, pyqt and pygments. This reflects
the reality - they are hard dependencies, but only for the Qt console.

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

From benjaminrk at gmail.com  Mon Jul  4 14:00:34 2011
From: benjaminrk at gmail.com (MinRK)
Date: Mon, 4 Jul 2011 11:00:34 -0700
Subject: [IPython-dev] IPython 0.11 RC1 is ready for download... now
 we're actually getting close to a real release!
In-Reply-To: <CAOvn4qh5LhAh0Z+0awUdD378W7jxuDB7dE_9ozYBvkqhTDZvvA@mail.gmail.com>
References: <CAHAreOpaRPJS1KGWmwcV_gQnfdcmUw4np=8ZBHqQcZA-zUQp8g@mail.gmail.com>
	<4E11EE91.7070306@bostream.nu>
	<CAEfz+TwEBk8avTyY7pz+FSfPsSWd3KBzfvjaY7F6O3PDivPBEw@mail.gmail.com>
	<CAHNn8BVSnGuoiXko6DJW5GePO18z+uJGKbYjFB1tE3Txz-3yYg@mail.gmail.com>
	<CAOvn4qh5LhAh0Z+0awUdD378W7jxuDB7dE_9ozYBvkqhTDZvvA@mail.gmail.com>
Message-ID: <CAHNn8BUNoVi0or+p8c-FusgrtAQKsCRuPKxponbBZdVUKwao+A@mail.gmail.com>

On Mon, Jul 4, 2011 at 10:52, Thomas Kluyver <takowl at gmail.com> wrote:
> On 4 July 2011 18:19, MinRK <benjaminrk at gmail.com> wrote:
>>
>> As for the pyzmq/pygments dependencies, they are *optional*
>> dependencies just like we have always had, so will never be added as
>> hard install dependencies, but they should probably be described on
>> the pypi page, as they are on the install page in the docs:
>
> I think that Debian packaging may well split IPython up into >= 2 distinct
> packages: a core package with minimal dependencies, and a qtconsole package
> which depends on the core package, pyzmq, pyqt and pygments. This reflects
> the reality - they are hard dependencies, but only for the Qt console.

Yes, but it's PyPI/setuptools that is being discussed here.  We don't
ever want `easy_install ipython` to install anything (except
readline/pyreadline on OSX/Windows).

>
> Thomas
>


From fperez.net at gmail.com  Mon Jul  4 15:16:49 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 4 Jul 2011 12:16:49 -0700
Subject: [IPython-dev] IPython 0.11 RC1 is ready for download... now
 we're actually getting close to a real release!
In-Reply-To: <4E119AF9.6010409@googlemail.com>
References: <CAHAreOpaRPJS1KGWmwcV_gQnfdcmUw4np=8ZBHqQcZA-zUQp8g@mail.gmail.com>
	<4E119AF9.6010409@googlemail.com>
Message-ID: <CAHAreOozhzktCOscN7_frd3pSN7fOs8jLxkDQp-BYNmBAnjQsw@mail.gmail.com>

Hi Julian,

On Mon, Jul 4, 2011 at 3:50 AM, Julian Taylor
<jtaylor.debian at googlemail.com> wrote:
> Is there a way you can release a pure source tarball without the
> pregenerated documentation?
> It would save quite a few megabytes and I would not have to repackage
> the source to comply with debian rules.

I now realize we forgot to mention that pure source (no docs, nothing)
download archives are made automatically available by github, because
we did make a tag for the RC:

https://github.com/ipython/ipython/archives/master

Github will always have these pure source downloads available. The
reason for including the docs is that they aren't completely trivial
to build (sphinx, other dependencies for full api coverage, etc), and
it's useful for users to have docs for offline use.  In particular, as
our non-terminal interfaces improve (qt, web), then it makes even more
sense for IPython to actually know for sure where its own docs are,
since then it can call up help and information directly for the user
from within the interface.  We don't have any such features
implemented yet, but I think it would greatly enhance the usability of
the system if we could pull up dynamically relevant html help for
users.

However, if for debian/distro reasons the github downloads aren't
sufficient/convenient, we can certainly look into building 'bare' and
'with-docs' versions of the tarballs at release time, it's easy enough
to adjust our release script to create both kinds.

Regards,

f


From efiring at hawaii.edu  Mon Jul  4 15:51:47 2011
From: efiring at hawaii.edu (Eric Firing)
Date: Mon, 04 Jul 2011 09:51:47 -1000
Subject: [IPython-dev] IPython 0.11 RC1 is ready for download... now
 we're actually getting close to a real release!
In-Reply-To: <CAHAreOpaRPJS1KGWmwcV_gQnfdcmUw4np=8ZBHqQcZA-zUQp8g@mail.gmail.com>
References: <CAHAreOpaRPJS1KGWmwcV_gQnfdcmUw4np=8ZBHqQcZA-zUQp8g@mail.gmail.com>
Message-ID: <4E1219D3.9090601@hawaii.edu>

On 07/03/2011 03:44 PM, Fernando Perez wrote:
> Hello all,
>
> We have just finished putting together the first Release Candidate for
> IPython 0.11.  For users who have not followed development, this
> brings *a lot* of changes to the innards of IPython, and the code is
> much nicer to work on, and configuration more robust.  We ask that you
> check out the RC, and make sure that it installs properly on your
> system, and report any glaring bugs you see back to us.

Fernando et al.,

The installation docs refer to ipython-qtconsole; this tripped me up 
because I still had such a script from an earlier development version.

Also in the ipython qtconsole dependencies section, you might make the 
dependency more explicit by replacing

"a new GUI...launched with ipython-qtconsole.  The GUI is built on..."

with

"a new GUI, launched with 'ipython qtconsole', was added.  In addition 
to its pyzmq dependency, the GUI requires..."

When you do make a release announcement, I suggest you emphasize the 
necessity of a completely clean installation for anyone who has been 
following the development. We all know this is good practice, but it is 
easy to forget something like cleaning out /usr/local/bin/ipython*

Eric

>
> You can download the files at:
>
> http://archive.ipython.org/testing
>
> Up to date documentation is at:
>
> http://ipython.org/ipython-doc/dev/index.html
>
> including more details on everything that is new here:
>
> http://ipython.org/ipython-doc/dev/whatsnew/version0.11.html
>
> We would very much appreciate it if you can take this for a spin, and
> let us know what does NOT work.  Barring any major blockers, we'll
> make the final release in ~ 1 week.
>
> Note: there are some known regressions and the configuration system is
> completely different.  But in everyday use, all the 'normal' things
> you expect should work; most of us in the dev team have been using
> this as our production IPython for months now.
>
>
> Extra special thanks to all those who have contributed to this work,
> particularly the recently added core devs, Evan Patterson and Thomas
> Kluyver.  They have been an amazingly productive addition to our team.
>
> Thanks,
> -The IPython team
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



From johann.cohentanugi at gmail.com  Mon Jul  4 16:01:33 2011
From: johann.cohentanugi at gmail.com (Johann Cohen-Tanugi)
Date: Mon, 04 Jul 2011 22:01:33 +0200
Subject: [IPython-dev] 0.11rc1 : problem with tutorial for PBS
	in	http://ipython.org/ipython-doc/dev/parallel/parallel_process.html
In-Reply-To: <4E11D735.9080909@gmail.com>
References: <4E11D735.9080909@gmail.com>
Message-ID: <4E121C1D.2040103@gmail.com>

good evening.... still trying to make the PBS batch parallel code work. 
I had to comment the "-t" line in launcher.py, but I am still puzzled by 
the fact that there is no loop over n to start n different engines. Is 
that because the '-t' was precisely there to create an array of subjobs?

Second question, more general : assuming the use of ipcluster, a 
controller and several engines are created; following the tutorial, all 
would actually run in batch, which seems strange to me for the 
controller : batch queues usually have time limits, and it is 
unavoidable that engines would die when the cpu time is exceeded, but I 
do not see why the controller should suffer from this. What would be the 
rational to execute the controller in batch rather than locally? Second 
question, once the engines run in batch, I presume that they listen to 
commands sent from any ipython session that I would interactively start, 
providing I use the Client() with the correct permissions in terms of 
ports,ssh etc.... Is that correct, id est is that indeed the idea?

sorry to be dense about all that... I think it would be useful if the 
batch doc page was supplemented with the final step which amounts to 
starting an interactive ipython session and connecting to the batch engines.

will continue digging,
best.
Johann

On 07/04/2011 05:07 PM, Johann Cohen-Tanugi wrote:
> hi there, my problem is in the fact that a line seems to be added to the
> template I am defining following the tutorial :
> the template proposed in the tutorial is modified at runtime as :
>
> #!/bin/sh
> #PBS -t 1-4<----------------- incorrect?
> #PBS -V
> #PBS -N ipengine
> /usr/local/bin/python
> /sps/glast/users/cohen/IPYDEV/ipython/IPython/parallel/apps/ipengineapp.py
> profile_dir=/afs/in2p3.fr/home/t/tanugi/\
> .ipython/profile_pbs
>
>
> The problem I believe is in the job_array_template in  :
>
> class PBSLauncher(BatchSystemLauncher):
>       """A BatchSystemLauncher subclass for PBS."""
>
>       submit_command = List(['qsub'], config=True,
>           help="The PBS submit command ['qsub']")
>       delete_command = List(['qdel'], config=True,
>           help="The PBS delete command ['qsub']")
>       job_id_regexp = Unicode(r'\d+', config=True,
>           help="Regular expresion for identifying the job ID [r'\d+']")
>
>       batch_file = Unicode(u'')
>       job_array_regexp = Unicode('#PBS\W+-t\W+[\w\d\-\$]+')
>       job_array_template = Unicode('#PBS -t 1-{n}')
>       queue_regexp = Unicode('#PBS\W+-q\W+\$?\w+')
>       queue_template = Unicode('#PBS -q {queue}')
>
>
> I looked at the PBS doc for version 10 and 11 and I did not see any '-t'
> option. When I try to run, I get :
> [tanugi at ccali28 test_directory]$ ipcluster start profile=pbs n=4
> [IPClusterStart] Using existing profile dir:
> u'/afs/in2p3.fr/home/t/tanugi/.ipython/profile_pbs'
> [IPClusterStart] Starting ipcluster with [daemon=False]
> [IPClusterStart] Creating pid file:
> /afs/in2p3.fr/home/t/tanugi/.ipython/profile_pbs/pid/ipcluster.pid
> [IPClusterStart] Starting PBSControllerLauncher: ['qsub',
> u'/afs/in2p3.fr/home/t/tanugi/.ipython/profile_pbs/pbs_controller']
> [IPClusterStart] adding job array settings to batch script
> [IPClusterStart] Writing instantiated batch script:
> /afs/in2p3.fr/home/t/tanugi/.ipython/profile_pbs/pbs_controller
> unknown -t option
> ERROR:root:Error in periodic callback
> Traceback (most recent call last):
>     File
> "/sps/glast/users/cohen/IPYDEV/local/lib/python2.6/site-packages/zmq/eventloop/ioloop.py",
> line 432, in _run
>       self.callback()
>     File
> "/sps/glast/users/cohen/IPYDEV/ipython/IPython/parallel/apps/ipclusterapp.py",
> line 364, in start_controller
>       self.profile_dir.location
>     File
> "/sps/glast/users/cohen/IPYDEV/ipython/IPython/parallel/apps/launcher.py",
> line 943, in start
>       return super(PBSControllerLauncher, self).start(1, profile_dir)
>     File
> "/sps/glast/users/cohen/IPYDEV/ipython/IPython/parallel/apps/launcher.py",
> line 902, in start
>       job_id = self.parse_job_id(output)
>     File
> "/sps/glast/users/cohen/IPYDEV/ipython/IPython/parallel/apps/launcher.py",
> line 854, in parse_job_id
>       raise LauncherError("Job id couldn't be determined: %s" % output)
> LauncherError: Job id couldn't be determined:
>
> Not sure yet about the traceback, but the "unknown -t option" is clear.
> Furthermore, I wonder if it is really what we want to add lines to a
> template file provided by the user?
>
> best,
> Johann
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>


From fperez.net at gmail.com  Mon Jul  4 16:06:58 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 4 Jul 2011 13:06:58 -0700
Subject: [IPython-dev] IPython 0.11 RC1 is ready for download... now
 we're actually getting close to a real release!
In-Reply-To: <4E1219D3.9090601@hawaii.edu>
References: <CAHAreOpaRPJS1KGWmwcV_gQnfdcmUw4np=8ZBHqQcZA-zUQp8g@mail.gmail.com>
	<4E1219D3.9090601@hawaii.edu>
Message-ID: <CAHAreOoVFR_zc5SuOGo6fm49aHiLPjbk0v4PkMDkeFWPpnmBeg@mail.gmail.com>

Hi Eric,

On Mon, Jul 4, 2011 at 12:51 PM, Eric Firing <efiring at hawaii.edu> wrote:
>
> The installation docs refer to ipython-qtconsole; this tripped me up
> because I still had such a script from an earlier development version.

[...]

Many thanks, filed:

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

This way we can keep a clear todo list for the actual release and not
forget these things.

Cheers,

f


From benjaminrk at gmail.com  Mon Jul  4 16:11:53 2011
From: benjaminrk at gmail.com (MinRK)
Date: Mon, 4 Jul 2011 13:11:53 -0700
Subject: [IPython-dev] IPython 0.11 RC1 is ready for download... now
 we're actually getting close to a real release!
In-Reply-To: <4E1219D3.9090601@hawaii.edu>
References: <CAHAreOpaRPJS1KGWmwcV_gQnfdcmUw4np=8ZBHqQcZA-zUQp8g@mail.gmail.com>
	<4E1219D3.9090601@hawaii.edu>
Message-ID: <CAHNn8BXUyK8o-UYRyC994wOhsHW193mM+zBLVGD-4wJTqAityg@mail.gmail.com>

On Mon, Jul 4, 2011 at 12:51, Eric Firing <efiring at hawaii.edu> wrote:
> On 07/03/2011 03:44 PM, Fernando Perez wrote:
>> Hello all,
>>
>> We have just finished putting together the first Release Candidate for
>> IPython 0.11. ?For users who have not followed development, this
>> brings *a lot* of changes to the innards of IPython, and the code is
>> much nicer to work on, and configuration more robust. ?We ask that you
>> check out the RC, and make sure that it installs properly on your
>> system, and report any glaring bugs you see back to us.
>
> Fernando et al.,
>
> The installation docs refer to ipython-qtconsole; this tripped me up
> because I still had such a script from an earlier development version.
>
> Also in the ipython qtconsole dependencies section, you might make the
> dependency more explicit by replacing
>
> "a new GUI...launched with ipython-qtconsole. ?The GUI is built on..."
>
> with
>
> "a new GUI, launched with 'ipython qtconsole', was added. ?In addition
> to its pyzmq dependency, the GUI requires..."

I thought I had caught all of these. Fixed in master, thanks!

>
> When you do make a release announcement, I suggest you emphasize the
> necessity of a completely clean installation for anyone who has been
> following the development. We all know this is good practice, but it is
> easy to forget something like cleaning out /usr/local/bin/ipython*
>
> Eric
>
>>
>> You can download the files at:
>>
>> http://archive.ipython.org/testing
>>
>> Up to date documentation is at:
>>
>> http://ipython.org/ipython-doc/dev/index.html
>>
>> including more details on everything that is new here:
>>
>> http://ipython.org/ipython-doc/dev/whatsnew/version0.11.html
>>
>> We would very much appreciate it if you can take this for a spin, and
>> let us know what does NOT work. ?Barring any major blockers, we'll
>> make the final release in ~ 1 week.
>>
>> Note: there are some known regressions and the configuration system is
>> completely different. ?But in everyday use, all the 'normal' things
>> you expect should work; most of us in the dev team have been using
>> this as our production IPython for months now.
>>
>>
>> Extra special thanks to all those who have contributed to this work,
>> particularly the recently added core devs, Evan Patterson and Thomas
>> Kluyver. ?They have been an amazingly productive addition to our team.
>>
>> Thanks,
>> -The IPython team
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>


From benjaminrk at gmail.com  Mon Jul  4 19:56:13 2011
From: benjaminrk at gmail.com (MinRK)
Date: Mon, 4 Jul 2011 16:56:13 -0700
Subject: [IPython-dev] 0.11rc1 : problem with tutorial for PBS in
	http://ipython.org/ipython-doc/dev/parallel/parallel_process.html
In-Reply-To: <4E121C1D.2040103@gmail.com>
References: <4E11D735.9080909@gmail.com> <4E121C1D.2040103@gmail.com>
Message-ID: <CAHNn8BWcf4789EJ-zf3yJa8oYjPRjWjJMRz-Porf=1HuPAQj+g@mail.gmail.com>

On Mon, Jul 4, 2011 at 13:01, Johann Cohen-Tanugi
<johann.cohentanugi at gmail.com> wrote:
> good evening.... still trying to make the PBS batch parallel code work.
> I had to comment the "-t" line in launcher.py, but I am still puzzled by
> the fact that there is no loop over n to start n different engines. Is
> that because the '-t' was precisely there to create an array of subjobs?

Sorry about this, I was testing against Linux with Torque, which
supports job arrays via '-t'.  How to start a collection of jobs is
going to vary from one PBS to another.

For instance, on some systems the default will be to use *no* job
array, and run multiple engines via aprun or mpiexec.  I just looked,
and the addition of the jobarray line is unconditional, which is
definitely wrong. I just pushed a fix for that, so if you specify your
own template, it should not be changed at all by IPython.

A possible example:

#PBS -N ipython
#PBS -j oe
#PBS -l walltime=00:10:00
#PBS -l nodes={n/4}:ppn=4 # assumes 4-CPU nodes
#PBS -q {queue}

cd $PBS_O_WORKDIR

aprun -n {n} ipengine profile_dir={profile_dir}

This is if your system uses aprun, though mpiexec may be more
appropriate for you.  Note that if you have PBS but no parallel
environments like mpi or ap, then you may have to do something like a
simple loop:

for i in {{ 1..{n} }}; do
    ipengine profile_dir={profile_dir}
done

# note the double-brace.  The templates use string.format, so to
escape braces you need to double them, so:
for i in {{ 1..{n} }}
becomes
for i in { 1..4 }

which in bash expands to 1 2 3 4

The templating should support any of these.

>
> Second question, more general : assuming the use of ipcluster, a
> controller and several engines are created; following the tutorial, all
> would actually run in batch, which seems strange to me for the
> controller : batch queues usually have time limits, and it is
> unavoidable that engines would die when the cpu time is exceeded, but I
> do not see why the controller should suffer from this. What would be the
> rational to execute the controller in batch rather than locally? Second
> question, once the engines run in batch, I presume that they listen to
> commands sent from any ipython session that I would interactively start,
> providing I use the Client() with the correct permissions in terms of
> ports,ssh etc.... Is that correct, id est is that indeed the idea?

You can choose to start the controller with batch or not, that's up to
you.  There is no coupling at all between which launcher you choose
for the Controller and which you choose for the Engines.  If you want
the controller to live longer than the batch system will allow, then
using the batch launcher for the controller is obviously the wrong
choice.

It does sometimes make sense to launch the controller with batch,
because you could have an entire job with controller, engines, and
clients *all* submitted via the batch system.  I do this sometimes
with SGE for scaling tests using starcluster. It also helps
load-balancing for shared-node systems, since the controller should
take up a work slot.  If you have a high throughput workload, you
don't want to run n engines + a controller on an n-cpu node, because
they will be fighting over resources.

Two more reasons to start the controller with batch: it will be
faster, and you can turn off your local machine.  You can submit a
million jobs, turn off your local machine altogether, then connect
again later and retrieve your results.  It will be faster, because the
majority of communication happens between the controller and the
engines, rather than the client and the controller.

-MinRK

>
> sorry to be dense about all that... I think it would be useful if the
> batch doc page was supplemented with the final step which amounts to
> starting an interactive ipython session and connecting to the batch engines.

Sure, I can add this, though it's not different from any method of
connecting to a controller from another machine.

If you are on the same system (e.g. in batch script or on a login
node), it will amount to:

ipython
In [1]: from IPython.parallel import Client
In [2]: rc = Client(profile='clusterprofile')

And if you are not, you will have to get the ipcontroller-client.json
file from profile_dir/security with scp, and do:
In [2]: rc = Client('/path/to/ipcontroller-client.json' )

possibly adding `sshserver='loginnode.example.com'` if you didn't
specify the ssh server for tunneling when starting the Controller.

-MinRK

>
> will continue digging,
> best.
> Johann
>
> On 07/04/2011 05:07 PM, Johann Cohen-Tanugi wrote:
>> hi there, my problem is in the fact that a line seems to be added to the
>> template I am defining following the tutorial :
>> the template proposed in the tutorial is modified at runtime as :
>>
>> #!/bin/sh
>> #PBS -t 1-4<----------------- incorrect?
>> #PBS -V
>> #PBS -N ipengine
>> /usr/local/bin/python
>> /sps/glast/users/cohen/IPYDEV/ipython/IPython/parallel/apps/ipengineapp.py
>> profile_dir=/afs/in2p3.fr/home/t/tanugi/\
>> .ipython/profile_pbs
>>
>>
>> The problem I believe is in the job_array_template in ?:
>>
>> class PBSLauncher(BatchSystemLauncher):
>> ? ? ? """A BatchSystemLauncher subclass for PBS."""
>>
>> ? ? ? submit_command = List(['qsub'], config=True,
>> ? ? ? ? ? help="The PBS submit command ['qsub']")
>> ? ? ? delete_command = List(['qdel'], config=True,
>> ? ? ? ? ? help="The PBS delete command ['qsub']")
>> ? ? ? job_id_regexp = Unicode(r'\d+', config=True,
>> ? ? ? ? ? help="Regular expresion for identifying the job ID [r'\d+']")
>>
>> ? ? ? batch_file = Unicode(u'')
>> ? ? ? job_array_regexp = Unicode('#PBS\W+-t\W+[\w\d\-\$]+')
>> ? ? ? job_array_template = Unicode('#PBS -t 1-{n}')
>> ? ? ? queue_regexp = Unicode('#PBS\W+-q\W+\$?\w+')
>> ? ? ? queue_template = Unicode('#PBS -q {queue}')
>>
>>
>> I looked at the PBS doc for version 10 and 11 and I did not see any '-t'
>> option. When I try to run, I get :
>> [tanugi at ccali28 test_directory]$ ipcluster start profile=pbs n=4
>> [IPClusterStart] Using existing profile dir:
>> u'/afs/in2p3.fr/home/t/tanugi/.ipython/profile_pbs'
>> [IPClusterStart] Starting ipcluster with [daemon=False]
>> [IPClusterStart] Creating pid file:
>> /afs/in2p3.fr/home/t/tanugi/.ipython/profile_pbs/pid/ipcluster.pid
>> [IPClusterStart] Starting PBSControllerLauncher: ['qsub',
>> u'/afs/in2p3.fr/home/t/tanugi/.ipython/profile_pbs/pbs_controller']
>> [IPClusterStart] adding job array settings to batch script
>> [IPClusterStart] Writing instantiated batch script:
>> /afs/in2p3.fr/home/t/tanugi/.ipython/profile_pbs/pbs_controller
>> unknown -t option
>> ERROR:root:Error in periodic callback
>> Traceback (most recent call last):
>> ? ? File
>> "/sps/glast/users/cohen/IPYDEV/local/lib/python2.6/site-packages/zmq/eventloop/ioloop.py",
>> line 432, in _run
>> ? ? ? self.callback()
>> ? ? File
>> "/sps/glast/users/cohen/IPYDEV/ipython/IPython/parallel/apps/ipclusterapp.py",
>> line 364, in start_controller
>> ? ? ? self.profile_dir.location
>> ? ? File
>> "/sps/glast/users/cohen/IPYDEV/ipython/IPython/parallel/apps/launcher.py",
>> line 943, in start
>> ? ? ? return super(PBSControllerLauncher, self).start(1, profile_dir)
>> ? ? File
>> "/sps/glast/users/cohen/IPYDEV/ipython/IPython/parallel/apps/launcher.py",
>> line 902, in start
>> ? ? ? job_id = self.parse_job_id(output)
>> ? ? File
>> "/sps/glast/users/cohen/IPYDEV/ipython/IPython/parallel/apps/launcher.py",
>> line 854, in parse_job_id
>> ? ? ? raise LauncherError("Job id couldn't be determined: %s" % output)
>> LauncherError: Job id couldn't be determined:
>>
>> Not sure yet about the traceback, but the "unknown -t option" is clear.
>> Furthermore, I wonder if it is really what we want to add lines to a
>> template file provided by the user?
>>
>> best,
>> Johann
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>


From fperez.net at gmail.com  Mon Jul  4 21:17:40 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 4 Jul 2011 18:17:40 -0700
Subject: [IPython-dev] Qt api selection re. ipython and matplotlib
Message-ID: <CAHAreOoMSsD8UYCPHKT_RcESpCWAFuM0VcBWN3t+KR1MZ4ZGnQ@mail.gmail.com>

Hi folks,

Eric Firing, Darren Dale and others in the MPL team are trying to work
out the Qt API selection issues after our own updates, but there are
some technical questions in there that require more knowledge about Qt
than I have.  The MPL pull request is:

https://github.com/matplotlib/matplotlib/pull/390

which follows our own recent changes:

https://github.com/ipython/ipython/pull/550#issuecomment-1490217

Evan has already done the lion's share of the work on this topic, but
I figured I'd ping the list in case someone else can also jump in,
since I myself am kind of useless on the details of Qt itself.

Thanks!

f


From wardefar at iro.umontreal.ca  Mon Jul  4 21:53:39 2011
From: wardefar at iro.umontreal.ca (David Warde-Farley)
Date: Mon, 4 Jul 2011 21:53:39 -0400
Subject: [IPython-dev] default colorscheme
Message-ID: <13B4CAB7-2FE6-497A-B182-EA7F2BD186AF@iro.umontreal.ca>

Hey guys, I'm playing with the rc1.

Maybe this has been covered before, but is there a reason for the switch to LightBG being the default on the console? Are most terminals white by default nowadays? I just notice because the syntax highlighting fails in interesting ways on dark terminals with the default setup (ideally pygments, if that's what's doing it, would just not color stuff meant to be the normal foreground text color, but that's asking a bit much).

David

From benjaminrk at gmail.com  Mon Jul  4 22:09:59 2011
From: benjaminrk at gmail.com (Min RK)
Date: Mon, 4 Jul 2011 19:09:59 -0700
Subject: [IPython-dev] default colorscheme
In-Reply-To: <13B4CAB7-2FE6-497A-B182-EA7F2BD186AF@iro.umontreal.ca>
References: <13B4CAB7-2FE6-497A-B182-EA7F2BD186AF@iro.umontreal.ca>
Message-ID: <292E55EB-E5CB-44AA-B7DA-9C7F54B92614@gmail.com>

LightBG is the default on OSX, because the default terminal is black on white there.  If there's a good way to determine the actual background color, we could use that to make a more informed default decision.

-MinRK

On Jul 4, 2011, at 18:53, David Warde-Farley <wardefar at iro.umontreal.ca> wrote:

> Hey guys, I'm playing with the rc1.
> 
> Maybe this has been covered before, but is there a reason for the switch to LightBG being the default on the console? Are most terminals white by default nowadays? I just notice because the syntax highlighting fails in interesting ways on dark terminals with the default setup (ideally pygments, if that's what's doing it, would just not color stuff meant to be the normal foreground text color, but that's asking a bit much).
> 
> David
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev


From dsdale24 at gmail.com  Mon Jul  4 22:26:08 2011
From: dsdale24 at gmail.com (Darren Dale)
Date: Mon, 4 Jul 2011 22:26:08 -0400
Subject: [IPython-dev] Qt api selection re. ipython and matplotlib
In-Reply-To: <CAHAreOoMSsD8UYCPHKT_RcESpCWAFuM0VcBWN3t+KR1MZ4ZGnQ@mail.gmail.com>
References: <CAHAreOoMSsD8UYCPHKT_RcESpCWAFuM0VcBWN3t+KR1MZ4ZGnQ@mail.gmail.com>
Message-ID: <CAK6O52kGTchAcsxH6mt9GRxZ==yhxdX=f+8o3e+XZHujCi17=g@mail.gmail.com>

On Mon, Jul 4, 2011 at 9:17 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> Hi folks,
>
> Eric Firing, Darren Dale and others in the MPL team are trying to work
> out the Qt API selection issues after our own updates, but there are
> some technical questions in there that require more knowledge about Qt
> than I have. ?The MPL pull request is:
>
> https://github.com/matplotlib/matplotlib/pull/390
>
> which follows our own recent changes:
>
> https://github.com/ipython/ipython/pull/550#issuecomment-1490217
>
> Evan has already done the lion's share of the work on this topic, but
> I figured I'd ping the list in case someone else can also jump in,
> since I myself am kind of useless on the details of Qt itself.

Note that this is probably not specific to matplotlib, but rather
IPython's qt gui support. IPython.external.qt is setting the sip api
level for PyQt4 to api version 2. Version 2 is not the default for
python-2, which means that ipython would not be able to run PyQt4 apps
or scripts that use QString or QVariant, both of which are officially
supported in the default PyQt4 api. It will impact a lot of users and
a lot of projects.


From benjaminrk at gmail.com  Mon Jul  4 22:42:30 2011
From: benjaminrk at gmail.com (Min RK)
Date: Mon, 4 Jul 2011 19:42:30 -0700
Subject: [IPython-dev] Qt api selection re. ipython and matplotlib
In-Reply-To: <CAK6O52kGTchAcsxH6mt9GRxZ==yhxdX=f+8o3e+XZHujCi17=g@mail.gmail.com>
References: <CAHAreOoMSsD8UYCPHKT_RcESpCWAFuM0VcBWN3t+KR1MZ4ZGnQ@mail.gmail.com>
	<CAK6O52kGTchAcsxH6mt9GRxZ==yhxdX=f+8o3e+XZHujCi17=g@mail.gmail.com>
Message-ID: <980A6877-0A2D-4F99-81A9-85FF18DC4262@gmail.com>

That sounds like we should reverse the default. Rather than using v2 unless old matplotlib is detected, use v1 unless ETS 4 is detected, or some configurable is set.

-MinRK

On Jul 4, 2011, at 19:26, Darren Dale <dsdale24 at gmail.com> wrote:

> On Mon, Jul 4, 2011 at 9:17 PM, Fernando Perez <fperez.net at gmail.com> wrote:
>> Hi folks,
>> 
>> Eric Firing, Darren Dale and others in the MPL team are trying to work
>> out the Qt API selection issues after our own updates, but there are
>> some technical questions in there that require more knowledge about Qt
>> than I have.  The MPL pull request is:
>> 
>> https://github.com/matplotlib/matplotlib/pull/390
>> 
>> which follows our own recent changes:
>> 
>> https://github.com/ipython/ipython/pull/550#issuecomment-1490217
>> 
>> Evan has already done the lion's share of the work on this topic, but
>> I figured I'd ping the list in case someone else can also jump in,
>> since I myself am kind of useless on the details of Qt itself.
> 
> Note that this is probably not specific to matplotlib, but rather
> IPython's qt gui support. IPython.external.qt is setting the sip api
> level for PyQt4 to api version 2. Version 2 is not the default for
> python-2, which means that ipython would not be able to run PyQt4 apps
> or scripts that use QString or QVariant, both of which are officially
> supported in the default PyQt4 api. It will impact a lot of users and
> a lot of projects.
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev


From efiring at hawaii.edu  Mon Jul  4 23:57:24 2011
From: efiring at hawaii.edu (Eric Firing)
Date: Mon, 04 Jul 2011 17:57:24 -1000
Subject: [IPython-dev] Qt api selection re. ipython and matplotlib
In-Reply-To: <CAK6O52kGTchAcsxH6mt9GRxZ==yhxdX=f+8o3e+XZHujCi17=g@mail.gmail.com>
References: <CAHAreOoMSsD8UYCPHKT_RcESpCWAFuM0VcBWN3t+KR1MZ4ZGnQ@mail.gmail.com>
	<CAK6O52kGTchAcsxH6mt9GRxZ==yhxdX=f+8o3e+XZHujCi17=g@mail.gmail.com>
Message-ID: <4E128BA4.8090308@hawaii.edu>

On 07/04/2011 04:26 PM, Darren Dale wrote:
> On Mon, Jul 4, 2011 at 9:17 PM, Fernando Perez<fperez.net at gmail.com>  wrote:
>> Hi folks,
>>
>> Eric Firing, Darren Dale and others in the MPL team are trying to work
>> out the Qt API selection issues after our own updates, but there are
>> some technical questions in there that require more knowledge about Qt
>> than I have.  The MPL pull request is:
>>
>> https://github.com/matplotlib/matplotlib/pull/390
>>
>> which follows our own recent changes:
>>
>> https://github.com/ipython/ipython/pull/550#issuecomment-1490217
>>
>> Evan has already done the lion's share of the work on this topic, but
>> I figured I'd ping the list in case someone else can also jump in,
>> since I myself am kind of useless on the details of Qt itself.
>
> Note that this is probably not specific to matplotlib, but rather
> IPython's qt gui support. IPython.external.qt is setting the sip api
> level for PyQt4 to api version 2. Version 2 is not the default for
> python-2, which means that ipython would not be able to run PyQt4 apps
> or scripts that use QString or QVariant, both of which are officially
> supported in the default PyQt4 api. It will impact a lot of users and
> a lot of projects.

Reference:

http://developer.qt.nokia.com/wiki/Differences_Between_PySide_and_PyQt

It seems that the mpl qt4 backend works with Version 1 or 2 (and with 
PyQt4 or PySide) given just a little bit of compatibility shimming.  If 
ipython can similarly get by with a few shims, so that it does not need 
to set the Version, then the problem is solved once those shims are 
identified and installed.

If I remove the version-setting from qt.py, then ipython still works 
with mpl and PyQt4 via "ipython pylab=qt", but it does not work with 
qtconsole or with PySide.

Eric


From benjaminrk at gmail.com  Tue Jul  5 00:51:39 2011
From: benjaminrk at gmail.com (MinRK)
Date: Mon, 4 Jul 2011 21:51:39 -0700
Subject: [IPython-dev] Qt api selection re. ipython and matplotlib
In-Reply-To: <4E128BA4.8090308@hawaii.edu>
References: <CAHAreOoMSsD8UYCPHKT_RcESpCWAFuM0VcBWN3t+KR1MZ4ZGnQ@mail.gmail.com>
	<CAK6O52kGTchAcsxH6mt9GRxZ==yhxdX=f+8o3e+XZHujCi17=g@mail.gmail.com>
	<4E128BA4.8090308@hawaii.edu>
Message-ID: <CAHNn8BWfZur_5f0Cm7NNfkg+jyAmvOXcfnD3Yj3yAOzea7XVdw@mail.gmail.com>

On Mon, Jul 4, 2011 at 20:57, Eric Firing <efiring at hawaii.edu> wrote:
> On 07/04/2011 04:26 PM, Darren Dale wrote:
>> On Mon, Jul 4, 2011 at 9:17 PM, Fernando Perez<fperez.net at gmail.com> ?wrote:
>>> Hi folks,
>>>
>>> Eric Firing, Darren Dale and others in the MPL team are trying to work
>>> out the Qt API selection issues after our own updates, but there are
>>> some technical questions in there that require more knowledge about Qt
>>> than I have. ?The MPL pull request is:
>>>
>>> https://github.com/matplotlib/matplotlib/pull/390
>>>
>>> which follows our own recent changes:
>>>
>>> https://github.com/ipython/ipython/pull/550#issuecomment-1490217
>>>
>>> Evan has already done the lion's share of the work on this topic, but
>>> I figured I'd ping the list in case someone else can also jump in,
>>> since I myself am kind of useless on the details of Qt itself.
>>
>> Note that this is probably not specific to matplotlib, but rather
>> IPython's qt gui support. IPython.external.qt is setting the sip api
>> level for PyQt4 to api version 2. Version 2 is not the default for
>> python-2, which means that ipython would not be able to run PyQt4 apps
>> or scripts that use QString or QVariant, both of which are officially
>> supported in the default PyQt4 api. It will impact a lot of users and
>> a lot of projects.
>
> Reference:
>
> http://developer.qt.nokia.com/wiki/Differences_Between_PySide_and_PyQt
>
> It seems that the mpl qt4 backend works with Version 1 or 2 (and with
> PyQt4 or PySide) given just a little bit of compatibility shimming. ?If
> ipython can similarly get by with a few shims, so that it does not need
> to set the Version, then the problem is solved once those shims are
> identified and installed.
>
> If I remove the version-setting from qt.py, then ipython still works
> with mpl and PyQt4 via "ipython pylab=qt", but it does not work with
> qtconsole or with PySide.

I don't think we are going to rewrite the whole qtconsole to support
version 1 for 0.11 this week.  What we can do is change the default
behavior in qt_for_kernel,
(https://github.com/ipython/ipython/blob/master/IPython/external/qt_for_kernel.py)
which is where code that interacts with other applications gets
imported.  Currently, we use our v2 import unless matplotlib <= 1.0.1
is detected.  However, we can change that default to be more
conservative.  User code (e.g. matplotlib code, integration with other
apps) is not in the same process as the QtConsole, so we can have v1
code in the kernel with v2 in the frontend.

-MinRK

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


From johann.cohentanugi at gmail.com  Tue Jul  5 01:49:27 2011
From: johann.cohentanugi at gmail.com (Johann Cohen-Tanugi)
Date: Tue, 05 Jul 2011 07:49:27 +0200
Subject: [IPython-dev] 0.11rc1 : problem with tutorial for PBS in
	http://ipython.org/ipython-doc/dev/parallel/parallel_process.html
In-Reply-To: <CAHNn8BWcf4789EJ-zf3yJa8oYjPRjWjJMRz-Porf=1HuPAQj+g@mail.gmail.com>
References: <4E11D735.9080909@gmail.com> <4E121C1D.2040103@gmail.com>
	<CAHNn8BWcf4789EJ-zf3yJa8oYjPRjWjJMRz-Porf=1HuPAQj+g@mail.gmail.com>
Message-ID: <4E12A5E7.7000202@gmail.com>

Thanks  a lot for all your help Min.
I will check your fix today. I think that for PBS -t should be replaced 
by -J, but I cannot test it as I realized yesterday that the batch 
system I put my hands on is derived from PBS, but is not PBS, and does 
not seem to honor -J. I will switch to SGE, then back to LSF with my 
updated launcher.py once I am sure I understand the SGE code that is 
already shipped with ipython and that you were able to test.

best,
Johann


On 07/05/2011 01:56 AM, MinRK wrote:
> On Mon, Jul 4, 2011 at 13:01, Johann Cohen-Tanugi
> <johann.cohentanugi at gmail.com>  wrote:
>> good evening.... still trying to make the PBS batch parallel code work.
>> I had to comment the "-t" line in launcher.py, but I am still puzzled by
>> the fact that there is no loop over n to start n different engines. Is
>> that because the '-t' was precisely there to create an array of subjobs?
> Sorry about this, I was testing against Linux with Torque, which
> supports job arrays via '-t'.  How to start a collection of jobs is
> going to vary from one PBS to another.
>
> For instance, on some systems the default will be to use *no* job
> array, and run multiple engines via aprun or mpiexec.  I just looked,
> and the addition of the jobarray line is unconditional, which is
> definitely wrong. I just pushed a fix for that, so if you specify your
> own template, it should not be changed at all by IPython.
>
> A possible example:
>
> #PBS -N ipython
> #PBS -j oe
> #PBS -l walltime=00:10:00
> #PBS -l nodes={n/4}:ppn=4 # assumes 4-CPU nodes
> #PBS -q {queue}
>
> cd $PBS_O_WORKDIR
>
> aprun -n {n} ipengine profile_dir={profile_dir}
>
> This is if your system uses aprun, though mpiexec may be more
> appropriate for you.  Note that if you have PBS but no parallel
> environments like mpi or ap, then you may have to do something like a
> simple loop:
>
> for i in {{ 1..{n} }}; do
>      ipengine profile_dir={profile_dir}
> done
>
> # note the double-brace.  The templates use string.format, so to
> escape braces you need to double them, so:
> for i in {{ 1..{n} }}
> becomes
> for i in { 1..4 }
>
> which in bash expands to 1 2 3 4
>
> The templating should support any of these.
>
>> Second question, more general : assuming the use of ipcluster, a
>> controller and several engines are created; following the tutorial, all
>> would actually run in batch, which seems strange to me for the
>> controller : batch queues usually have time limits, and it is
>> unavoidable that engines would die when the cpu time is exceeded, but I
>> do not see why the controller should suffer from this. What would be the
>> rational to execute the controller in batch rather than locally? Second
>> question, once the engines run in batch, I presume that they listen to
>> commands sent from any ipython session that I would interactively start,
>> providing I use the Client() with the correct permissions in terms of
>> ports,ssh etc.... Is that correct, id est is that indeed the idea?
> You can choose to start the controller with batch or not, that's up to
> you.  There is no coupling at all between which launcher you choose
> for the Controller and which you choose for the Engines.  If you want
> the controller to live longer than the batch system will allow, then
> using the batch launcher for the controller is obviously the wrong
> choice.
>
> It does sometimes make sense to launch the controller with batch,
> because you could have an entire job with controller, engines, and
> clients *all* submitted via the batch system.  I do this sometimes
> with SGE for scaling tests using starcluster. It also helps
> load-balancing for shared-node systems, since the controller should
> take up a work slot.  If you have a high throughput workload, you
> don't want to run n engines + a controller on an n-cpu node, because
> they will be fighting over resources.
>
> Two more reasons to start the controller with batch: it will be
> faster, and you can turn off your local machine.  You can submit a
> million jobs, turn off your local machine altogether, then connect
> again later and retrieve your results.  It will be faster, because the
> majority of communication happens between the controller and the
> engines, rather than the client and the controller.
>
> -MinRK
>
>> sorry to be dense about all that... I think it would be useful if the
>> batch doc page was supplemented with the final step which amounts to
>> starting an interactive ipython session and connecting to the batch engines.
> Sure, I can add this, though it's not different from any method of
> connecting to a controller from another machine.
>
> If you are on the same system (e.g. in batch script or on a login
> node), it will amount to:
>
> ipython
> In [1]: from IPython.parallel import Client
> In [2]: rc = Client(profile='clusterprofile')
>
> And if you are not, you will have to get the ipcontroller-client.json
> file from profile_dir/security with scp, and do:
> In [2]: rc = Client('/path/to/ipcontroller-client.json' )
>
> possibly adding `sshserver='loginnode.example.com'` if you didn't
> specify the ssh server for tunneling when starting the Controller.
>
> -MinRK
>
>> will continue digging,
>> best.
>> Johann
>>
>> On 07/04/2011 05:07 PM, Johann Cohen-Tanugi wrote:
>>> hi there, my problem is in the fact that a line seems to be added to the
>>> template I am defining following the tutorial :
>>> the template proposed in the tutorial is modified at runtime as :
>>>
>>> #!/bin/sh
>>> #PBS -t 1-4<----------------- incorrect?
>>> #PBS -V
>>> #PBS -N ipengine
>>> /usr/local/bin/python
>>> /sps/glast/users/cohen/IPYDEV/ipython/IPython/parallel/apps/ipengineapp.py
>>> profile_dir=/afs/in2p3.fr/home/t/tanugi/\
>>> .ipython/profile_pbs
>>>
>>>
>>> The problem I believe is in the job_array_template in  :
>>>
>>> class PBSLauncher(BatchSystemLauncher):
>>>        """A BatchSystemLauncher subclass for PBS."""
>>>
>>>        submit_command = List(['qsub'], config=True,
>>>            help="The PBS submit command ['qsub']")
>>>        delete_command = List(['qdel'], config=True,
>>>            help="The PBS delete command ['qsub']")
>>>        job_id_regexp = Unicode(r'\d+', config=True,
>>>            help="Regular expresion for identifying the job ID [r'\d+']")
>>>
>>>        batch_file = Unicode(u'')
>>>        job_array_regexp = Unicode('#PBS\W+-t\W+[\w\d\-\$]+')
>>>        job_array_template = Unicode('#PBS -t 1-{n}')
>>>        queue_regexp = Unicode('#PBS\W+-q\W+\$?\w+')
>>>        queue_template = Unicode('#PBS -q {queue}')
>>>
>>>
>>> I looked at the PBS doc for version 10 and 11 and I did not see any '-t'
>>> option. When I try to run, I get :
>>> [tanugi at ccali28 test_directory]$ ipcluster start profile=pbs n=4
>>> [IPClusterStart] Using existing profile dir:
>>> u'/afs/in2p3.fr/home/t/tanugi/.ipython/profile_pbs'
>>> [IPClusterStart] Starting ipcluster with [daemon=False]
>>> [IPClusterStart] Creating pid file:
>>> /afs/in2p3.fr/home/t/tanugi/.ipython/profile_pbs/pid/ipcluster.pid
>>> [IPClusterStart] Starting PBSControllerLauncher: ['qsub',
>>> u'/afs/in2p3.fr/home/t/tanugi/.ipython/profile_pbs/pbs_controller']
>>> [IPClusterStart] adding job array settings to batch script
>>> [IPClusterStart] Writing instantiated batch script:
>>> /afs/in2p3.fr/home/t/tanugi/.ipython/profile_pbs/pbs_controller
>>> unknown -t option
>>> ERROR:root:Error in periodic callback
>>> Traceback (most recent call last):
>>>      File
>>> "/sps/glast/users/cohen/IPYDEV/local/lib/python2.6/site-packages/zmq/eventloop/ioloop.py",
>>> line 432, in _run
>>>        self.callback()
>>>      File
>>> "/sps/glast/users/cohen/IPYDEV/ipython/IPython/parallel/apps/ipclusterapp.py",
>>> line 364, in start_controller
>>>        self.profile_dir.location
>>>      File
>>> "/sps/glast/users/cohen/IPYDEV/ipython/IPython/parallel/apps/launcher.py",
>>> line 943, in start
>>>        return super(PBSControllerLauncher, self).start(1, profile_dir)
>>>      File
>>> "/sps/glast/users/cohen/IPYDEV/ipython/IPython/parallel/apps/launcher.py",
>>> line 902, in start
>>>        job_id = self.parse_job_id(output)
>>>      File
>>> "/sps/glast/users/cohen/IPYDEV/ipython/IPython/parallel/apps/launcher.py",
>>> line 854, in parse_job_id
>>>        raise LauncherError("Job id couldn't be determined: %s" % output)
>>> LauncherError: Job id couldn't be determined:
>>>
>>> Not sure yet about the traceback, but the "unknown -t option" is clear.
>>> Furthermore, I wonder if it is really what we want to add lines to a
>>> template file provided by the user?
>>>
>>> best,
>>> Johann
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>


From efiring at hawaii.edu  Tue Jul  5 02:22:11 2011
From: efiring at hawaii.edu (Eric Firing)
Date: Mon, 04 Jul 2011 20:22:11 -1000
Subject: [IPython-dev] Qt api selection re. ipython and matplotlib
In-Reply-To: <CAHNn8BWfZur_5f0Cm7NNfkg+jyAmvOXcfnD3Yj3yAOzea7XVdw@mail.gmail.com>
References: <CAHAreOoMSsD8UYCPHKT_RcESpCWAFuM0VcBWN3t+KR1MZ4ZGnQ@mail.gmail.com>
	<CAK6O52kGTchAcsxH6mt9GRxZ==yhxdX=f+8o3e+XZHujCi17=g@mail.gmail.com>
	<4E128BA4.8090308@hawaii.edu>
	<CAHNn8BWfZur_5f0Cm7NNfkg+jyAmvOXcfnD3Yj3yAOzea7XVdw@mail.gmail.com>
Message-ID: <4E12AD93.4080901@hawaii.edu>

On 07/04/2011 06:51 PM, MinRK wrote:
> On Mon, Jul 4, 2011 at 20:57, Eric Firing<efiring at hawaii.edu>  wrote:
>> On 07/04/2011 04:26 PM, Darren Dale wrote:
>>> On Mon, Jul 4, 2011 at 9:17 PM, Fernando Perez<fperez.net at gmail.com>    wrote:
>>>> Hi folks,
>>>>
>>>> Eric Firing, Darren Dale and others in the MPL team are trying to work
>>>> out the Qt API selection issues after our own updates, but there are
>>>> some technical questions in there that require more knowledge about Qt
>>>> than I have.  The MPL pull request is:
>>>>
>>>> https://github.com/matplotlib/matplotlib/pull/390
>>>>
>>>> which follows our own recent changes:
>>>>
>>>> https://github.com/ipython/ipython/pull/550#issuecomment-1490217
>>>>
>>>> Evan has already done the lion's share of the work on this topic, but
>>>> I figured I'd ping the list in case someone else can also jump in,
>>>> since I myself am kind of useless on the details of Qt itself.
>>>
>>> Note that this is probably not specific to matplotlib, but rather
>>> IPython's qt gui support. IPython.external.qt is setting the sip api
>>> level for PyQt4 to api version 2. Version 2 is not the default for
>>> python-2, which means that ipython would not be able to run PyQt4 apps
>>> or scripts that use QString or QVariant, both of which are officially
>>> supported in the default PyQt4 api. It will impact a lot of users and
>>> a lot of projects.
>>
>> Reference:
>>
>> http://developer.qt.nokia.com/wiki/Differences_Between_PySide_and_PyQt
>>
>> It seems that the mpl qt4 backend works with Version 1 or 2 (and with
>> PyQt4 or PySide) given just a little bit of compatibility shimming.  If
>> ipython can similarly get by with a few shims, so that it does not need
>> to set the Version, then the problem is solved once those shims are
>> identified and installed.
>>
>> If I remove the version-setting from qt.py, then ipython still works
>> with mpl and PyQt4 via "ipython pylab=qt", but it does not work with
>> qtconsole or with PySide.
>
> I don't think we are going to rewrite the whole qtconsole to support
> version 1 for 0.11 this week.  What we can do is change the default
> behavior in qt_for_kernel,
> (https://github.com/ipython/ipython/blob/master/IPython/external/qt_for_kernel.py)
> which is where code that interacts with other applications gets
> imported.  Currently, we use our v2 import unless matplotlib<= 1.0.1
> is detected.  However, we can change that default to be more
> conservative.  User code (e.g. matplotlib code, integration with other
> apps) is not in the same process as the QtConsole, so we can have v1
> code in the kernel with v2 in the frontend.

If ipython and mpl have to be synchronized, and if we want to be able to 
choose to use pyside or pyqt4, then I think we need more than a change 
in the ipython default.  It looks like this calls for yet another pesky 
rcParams entry in mpl.  Then that can be used for figuring out what to 
import in both matplotlib and ipython.  The default, if there is no 
rcParams entry, would be PyQt4 with the platform default API version.

Darren, does this sound like a solution that would work for you?

Eric

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



From efiring at hawaii.edu  Tue Jul  5 03:42:18 2011
From: efiring at hawaii.edu (Eric Firing)
Date: Mon, 04 Jul 2011 21:42:18 -1000
Subject: [IPython-dev] Qt api selection re. ipython and matplotlib
In-Reply-To: <CAHNn8BWfZur_5f0Cm7NNfkg+jyAmvOXcfnD3Yj3yAOzea7XVdw@mail.gmail.com>
References: <CAHAreOoMSsD8UYCPHKT_RcESpCWAFuM0VcBWN3t+KR1MZ4ZGnQ@mail.gmail.com>
	<CAK6O52kGTchAcsxH6mt9GRxZ==yhxdX=f+8o3e+XZHujCi17=g@mail.gmail.com>
	<4E128BA4.8090308@hawaii.edu>
	<CAHNn8BWfZur_5f0Cm7NNfkg+jyAmvOXcfnD3Yj3yAOzea7XVdw@mail.gmail.com>
Message-ID: <4E12C05A.90604@hawaii.edu>

On 07/04/2011 06:51 PM, MinRK wrote:
> On Mon, Jul 4, 2011 at 20:57, Eric Firing<efiring at hawaii.edu>  wrote:
>> On 07/04/2011 04:26 PM, Darren Dale wrote:
>>> On Mon, Jul 4, 2011 at 9:17 PM, Fernando Perez<fperez.net at gmail.com>    wrote:
>>>> Hi folks,
>>>>
>>>> Eric Firing, Darren Dale and others in the MPL team are trying to work
>>>> out the Qt API selection issues after our own updates, but there are
>>>> some technical questions in there that require more knowledge about Qt
>>>> than I have.  The MPL pull request is:
>>>>
>>>> https://github.com/matplotlib/matplotlib/pull/390
>>>>
>>>> which follows our own recent changes:
>>>>
>>>> https://github.com/ipython/ipython/pull/550#issuecomment-1490217
>>>>
>>>> Evan has already done the lion's share of the work on this topic, but
>>>> I figured I'd ping the list in case someone else can also jump in,
>>>> since I myself am kind of useless on the details of Qt itself.
>>>
>>> Note that this is probably not specific to matplotlib, but rather
>>> IPython's qt gui support. IPython.external.qt is setting the sip api
>>> level for PyQt4 to api version 2. Version 2 is not the default for
>>> python-2, which means that ipython would not be able to run PyQt4 apps
>>> or scripts that use QString or QVariant, both of which are officially
>>> supported in the default PyQt4 api. It will impact a lot of users and
>>> a lot of projects.
>>
>> Reference:
>>
>> http://developer.qt.nokia.com/wiki/Differences_Between_PySide_and_PyQt
>>
>> It seems that the mpl qt4 backend works with Version 1 or 2 (and with
>> PyQt4 or PySide) given just a little bit of compatibility shimming.  If
>> ipython can similarly get by with a few shims, so that it does not need
>> to set the Version, then the problem is solved once those shims are
>> identified and installed.
>>
>> If I remove the version-setting from qt.py, then ipython still works
>> with mpl and PyQt4 via "ipython pylab=qt", but it does not work with
>> qtconsole or with PySide.
>
> I don't think we are going to rewrite the whole qtconsole to support
> version 1 for 0.11 this week.  What we can do is change the default
> behavior in qt_for_kernel,
> (https://github.com/ipython/ipython/blob/master/IPython/external/qt_for_kernel.py)
> which is where code that interacts with other applications gets
> imported.  Currently, we use our v2 import unless matplotlib<= 1.0.1
> is detected.  However, we can change that default to be more
> conservative.  User code (e.g. matplotlib code, integration with other
> apps) is not in the same process as the QtConsole, so we can have v1
> code in the kernel with v2 in the frontend.

I updated mpl pull request #390 and added ipython pull request #550 with 
a strawman plan based on mpl rcParams.  A quick test indicates that it 
makes qtconsole work with pylab=qt with either PyQt4 or PySide selected 
in mpl, and it also works with the ipython console with PyQt4, but not 
with PySide.  I don't know why the latter does not work.

Eric


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



From efiring at hawaii.edu  Tue Jul  5 03:47:03 2011
From: efiring at hawaii.edu (Eric Firing)
Date: Mon, 04 Jul 2011 21:47:03 -1000
Subject: [IPython-dev] Qt api selection re. ipython and matplotlib
In-Reply-To: <4E12C05A.90604@hawaii.edu>
References: <CAHAreOoMSsD8UYCPHKT_RcESpCWAFuM0VcBWN3t+KR1MZ4ZGnQ@mail.gmail.com>
	<CAK6O52kGTchAcsxH6mt9GRxZ==yhxdX=f+8o3e+XZHujCi17=g@mail.gmail.com>
	<4E128BA4.8090308@hawaii.edu>
	<CAHNn8BWfZur_5f0Cm7NNfkg+jyAmvOXcfnD3Yj3yAOzea7XVdw@mail.gmail.com>
	<4E12C05A.90604@hawaii.edu>
Message-ID: <4E12C177.6020306@hawaii.edu>

On 07/04/2011 09:42 PM, Eric Firing wrote:

>
> I updated mpl pull request #390 and added ipython pull request #550 with

That should have been ipython pull request #556.

Eric


From dsdale24 at gmail.com  Tue Jul  5 07:36:14 2011
From: dsdale24 at gmail.com (Darren Dale)
Date: Tue, 5 Jul 2011 07:36:14 -0400
Subject: [IPython-dev] Qt api selection re. ipython and matplotlib
In-Reply-To: <4E12AD93.4080901@hawaii.edu>
References: <CAHAreOoMSsD8UYCPHKT_RcESpCWAFuM0VcBWN3t+KR1MZ4ZGnQ@mail.gmail.com>
	<CAK6O52kGTchAcsxH6mt9GRxZ==yhxdX=f+8o3e+XZHujCi17=g@mail.gmail.com>
	<4E128BA4.8090308@hawaii.edu>
	<CAHNn8BWfZur_5f0Cm7NNfkg+jyAmvOXcfnD3Yj3yAOzea7XVdw@mail.gmail.com>
	<4E12AD93.4080901@hawaii.edu>
Message-ID: <CAK6O52=EhM9_-h8nK-j2vHg_puF7kE=z_2JM0v58WeCsGh59HA@mail.gmail.com>

On Tue, Jul 5, 2011 at 2:22 AM, Eric Firing <efiring at hawaii.edu> wrote:
> On 07/04/2011 06:51 PM, MinRK wrote:
>>
>> On Mon, Jul 4, 2011 at 20:57, Eric Firing<efiring at hawaii.edu> ?wrote:
>>> If I remove the version-setting from qt.py, then ipython still works
>>> with mpl and PyQt4 via "ipython pylab=qt", but it does not work with
>>> qtconsole or with PySide.
>>
>> I don't think we are going to rewrite the whole qtconsole to support
>> version 1 for 0.11 this week. ?What we can do is change the default
>> behavior in qt_for_kernel,
>>
>> (https://github.com/ipython/ipython/blob/master/IPython/external/qt_for_kernel.py)
>> which is where code that interacts with other applications gets
>> imported. ?Currently, we use our v2 import unless matplotlib<= 1.0.1
>> is detected. ?However, we can change that default to be more
>> conservative. ?User code (e.g. matplotlib code, integration with other
>> apps) is not in the same process as the QtConsole, so we can have v1
>> code in the kernel with v2 in the frontend.

Good point.

> If ipython and mpl have to be synchronized, and if we want to be able to
> choose to use pyside or pyqt4, then I think we need more than a change in
> the ipython default. ?It looks like this calls for yet another pesky
> rcParams entry in mpl. ?Then that can be used for figuring out what to
> import in both matplotlib and ipython. ?The default, if there is no rcParams
> entry, would be PyQt4 with the platform default API version.
>
> Darren, does this sound like a solution that would work for you?

If ipython changes its qt_for_kernel to not set the api level, then it
seems to me that either the environment variable approach or the
rcParams approach will work for pylab/pyplot. The rcParams approach is
a little awkward for folks using the OO interface, but it looks like
it would work. You mentioned that it does not work with the ipython
console and pyside though, what doesn't work?


From efiring at hawaii.edu  Tue Jul  5 12:45:55 2011
From: efiring at hawaii.edu (Eric Firing)
Date: Tue, 05 Jul 2011 06:45:55 -1000
Subject: [IPython-dev] Qt api selection re. ipython and matplotlib
In-Reply-To: <CAK6O52=EhM9_-h8nK-j2vHg_puF7kE=z_2JM0v58WeCsGh59HA@mail.gmail.com>
References: <CAHAreOoMSsD8UYCPHKT_RcESpCWAFuM0VcBWN3t+KR1MZ4ZGnQ@mail.gmail.com>
	<CAK6O52kGTchAcsxH6mt9GRxZ==yhxdX=f+8o3e+XZHujCi17=g@mail.gmail.com>
	<4E128BA4.8090308@hawaii.edu>
	<CAHNn8BWfZur_5f0Cm7NNfkg+jyAmvOXcfnD3Yj3yAOzea7XVdw@mail.gmail.com>
	<4E12AD93.4080901@hawaii.edu>
	<CAK6O52=EhM9_-h8nK-j2vHg_puF7kE=z_2JM0v58WeCsGh59HA@mail.gmail.com>
Message-ID: <4E133FC3.1090108@hawaii.edu>

On 07/05/2011 01:36 AM, Darren Dale wrote:
> On Tue, Jul 5, 2011 at 2:22 AM, Eric Firing<efiring at hawaii.edu>  wrote:
>> On 07/04/2011 06:51 PM, MinRK wrote:
>>>
>>> On Mon, Jul 4, 2011 at 20:57, Eric Firing<efiring at hawaii.edu>    wrote:
>>>> If I remove the version-setting from qt.py, then ipython still works
>>>> with mpl and PyQt4 via "ipython pylab=qt", but it does not work with
>>>> qtconsole or with PySide.
>>>
>>> I don't think we are going to rewrite the whole qtconsole to support
>>> version 1 for 0.11 this week.  What we can do is change the default
>>> behavior in qt_for_kernel,
>>>
>>> (https://github.com/ipython/ipython/blob/master/IPython/external/qt_for_kernel.py)
>>> which is where code that interacts with other applications gets
>>> imported.  Currently, we use our v2 import unless matplotlib<= 1.0.1
>>> is detected.  However, we can change that default to be more
>>> conservative.  User code (e.g. matplotlib code, integration with other
>>> apps) is not in the same process as the QtConsole, so we can have v1
>>> code in the kernel with v2 in the frontend.
>
> Good point.
>
>> If ipython and mpl have to be synchronized, and if we want to be able to
>> choose to use pyside or pyqt4, then I think we need more than a change in
>> the ipython default.  It looks like this calls for yet another pesky
>> rcParams entry in mpl.  Then that can be used for figuring out what to
>> import in both matplotlib and ipython.  The default, if there is no rcParams
>> entry, would be PyQt4 with the platform default API version.
>>
>> Darren, does this sound like a solution that would work for you?
>
> If ipython changes its qt_for_kernel to not set the api level, then it
> seems to me that either the environment variable approach or the
> rcParams approach will work for pylab/pyplot. The rcParams approach is
> a little awkward for folks using the OO interface, but it looks like
> it would work. You mentioned that it does not work with the ipython
> console and pyside though, what doesn't work?

No figure is displayed after plotting, and then there is an error upon 
exiting ipython if the figure (which was never displayed) is not closed.

Eric



From ellisonbg at gmail.com  Tue Jul  5 13:20:40 2011
From: ellisonbg at gmail.com (Brian Granger)
Date: Tue, 5 Jul 2011 10:20:40 -0700
Subject: [IPython-dev] Ubuntu ppa for pyzmq
In-Reply-To: <CAHNn8BVqs+L+QUt+WDUoouq5-ou2iEiO-qa7UB1dnFFM1sxzcg@mail.gmail.com>
References: <CAHNn8BVqs+L+QUt+WDUoouq5-ou2iEiO-qa7UB1dnFFM1sxzcg@mail.gmail.com>
Message-ID: <CAH4pYpTx+nd5HDsCqGAS+g+vPv+hUq5vRPzYinUtiifNfxnzww@mail.gmail.com>

Great!

Brian

On Sat, Jul 2, 2011 at 2:21 PM, MinRK <benjaminrk at gmail.com> wrote:
> pyzmq doesn't have Linux binaries, because we don't want to maintain
> eggs that should work on all flavors of Linux.
>
> However, Ubuntu users are in luck, because Chris Lea has a zeromq ppa,
> which as of today includes up to date pyzmq:
> https://launchpad.net/~chris-lea/+archive/zeromq
>
> Once you add the ppa to your sources, you should be able to just do:
>
> apt-get install python-zeromq
>
> -MinRK
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



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


From benjaminrk at gmail.com  Tue Jul  5 20:39:46 2011
From: benjaminrk at gmail.com (MinRK)
Date: Tue, 5 Jul 2011 17:39:46 -0700
Subject: [IPython-dev] Qt api selection re. ipython and matplotlib
In-Reply-To: <4E133FC3.1090108@hawaii.edu>
References: <CAHAreOoMSsD8UYCPHKT_RcESpCWAFuM0VcBWN3t+KR1MZ4ZGnQ@mail.gmail.com>
	<CAK6O52kGTchAcsxH6mt9GRxZ==yhxdX=f+8o3e+XZHujCi17=g@mail.gmail.com>
	<4E128BA4.8090308@hawaii.edu>
	<CAHNn8BWfZur_5f0Cm7NNfkg+jyAmvOXcfnD3Yj3yAOzea7XVdw@mail.gmail.com>
	<4E12AD93.4080901@hawaii.edu>
	<CAK6O52=EhM9_-h8nK-j2vHg_puF7kE=z_2JM0v58WeCsGh59HA@mail.gmail.com>
	<4E133FC3.1090108@hawaii.edu>
Message-ID: <CAHNn8BV6M+6GSouOe48JtE6xhmsWBCgkZVNg_DBbZONdSS-o3w@mail.gmail.com>

On Tue, Jul 5, 2011 at 09:45, Eric Firing <efiring at hawaii.edu> wrote:
> On 07/05/2011 01:36 AM, Darren Dale wrote:
>>
>> On Tue, Jul 5, 2011 at 2:22 AM, Eric Firing<efiring at hawaii.edu> ?wrote:
>>>
>>> On 07/04/2011 06:51 PM, MinRK wrote:
>>>>
>>>> On Mon, Jul 4, 2011 at 20:57, Eric Firing<efiring at hawaii.edu> ? ?wrote:
>>>>>
>>>>> If I remove the version-setting from qt.py, then ipython still works
>>>>> with mpl and PyQt4 via "ipython pylab=qt", but it does not work with
>>>>> qtconsole or with PySide.
>>>>
>>>> I don't think we are going to rewrite the whole qtconsole to support
>>>> version 1 for 0.11 this week. ?What we can do is change the default
>>>> behavior in qt_for_kernel,
>>>>
>>>>
>>>> (https://github.com/ipython/ipython/blob/master/IPython/external/qt_for_kernel.py)
>>>> which is where code that interacts with other applications gets
>>>> imported. ?Currently, we use our v2 import unless matplotlib<= 1.0.1
>>>> is detected. ?However, we can change that default to be more
>>>> conservative. ?User code (e.g. matplotlib code, integration with other
>>>> apps) is not in the same process as the QtConsole, so we can have v1
>>>> code in the kernel with v2 in the frontend.
>>
>> Good point.
>>
>>> If ipython and mpl have to be synchronized, and if we want to be able to
>>> choose to use pyside or pyqt4, then I think we need more than a change in
>>> the ipython default. ?It looks like this calls for yet another pesky
>>> rcParams entry in mpl. ?Then that can be used for figuring out what to
>>> import in both matplotlib and ipython. ?The default, if there is no
>>> rcParams
>>> entry, would be PyQt4 with the platform default API version.
>>>
>>> Darren, does this sound like a solution that would work for you?
>>
>> If ipython changes its qt_for_kernel to not set the api level, then it
>> seems to me that either the environment variable approach or the
>> rcParams approach will work for pylab/pyplot. The rcParams approach is
>> a little awkward for folks using the OO interface, but it looks like
>> it would work. You mentioned that it does not work with the ipython
>> console and pyside though, what doesn't work?
>
> No figure is displayed after plotting, and then there is an error upon
> exiting ipython if the figure (which was never displayed) is not closed.
>
> Eric
>
>

I think the logic should be something along the lines of:

if matplotlib:
    if matplotlib <= 1.0.1:
         use PyQt+v1 # old matplotlib can't support v2, if I
understand correctly
    else:
         ask matplotlib
if no answer or no matplotlib:
    if QT_API defined:
        if QT_API=pyqt:
                use PyQt+v2 #because this is an ETS env variable, and
ETS requires v2
        elif QT_API=pyside:
           use pyside
    else:
        try pyqt+v1
        if no pyqt:
             try pyside

gist: QT_API should be respected if set, and use v2 unless matplotlib
is too old to allow it.  If nothing is specified, the default is
pyqt+v1, the safest option, but PySide should still be chosen if it's
the only Qt installed.

Does this make sense?

-MinRK


From dsdale24 at gmail.com  Tue Jul  5 21:32:36 2011
From: dsdale24 at gmail.com (Darren Dale)
Date: Tue, 5 Jul 2011 21:32:36 -0400
Subject: [IPython-dev] Qt api selection re. ipython and matplotlib
In-Reply-To: <CAHNn8BV6M+6GSouOe48JtE6xhmsWBCgkZVNg_DBbZONdSS-o3w@mail.gmail.com>
References: <CAHAreOoMSsD8UYCPHKT_RcESpCWAFuM0VcBWN3t+KR1MZ4ZGnQ@mail.gmail.com>
	<CAK6O52kGTchAcsxH6mt9GRxZ==yhxdX=f+8o3e+XZHujCi17=g@mail.gmail.com>
	<4E128BA4.8090308@hawaii.edu>
	<CAHNn8BWfZur_5f0Cm7NNfkg+jyAmvOXcfnD3Yj3yAOzea7XVdw@mail.gmail.com>
	<4E12AD93.4080901@hawaii.edu>
	<CAK6O52=EhM9_-h8nK-j2vHg_puF7kE=z_2JM0v58WeCsGh59HA@mail.gmail.com>
	<4E133FC3.1090108@hawaii.edu>
	<CAHNn8BV6M+6GSouOe48JtE6xhmsWBCgkZVNg_DBbZONdSS-o3w@mail.gmail.com>
Message-ID: <CAK6O52m0R3ugOkV9gznHmGgMRXAF+yij3PWnisVS8N_98ti+6w@mail.gmail.com>

On Tue, Jul 5, 2011 at 8:39 PM, MinRK <benjaminrk at gmail.com> wrote:
> On Tue, Jul 5, 2011 at 09:45, Eric Firing <efiring at hawaii.edu> wrote:
>> On 07/05/2011 01:36 AM, Darren Dale wrote:
>>>
>>> On Tue, Jul 5, 2011 at 2:22 AM, Eric Firing<efiring at hawaii.edu> ?wrote:
>>>>
>>>> On 07/04/2011 06:51 PM, MinRK wrote:
>>>>>
>>>>> On Mon, Jul 4, 2011 at 20:57, Eric Firing<efiring at hawaii.edu> ? ?wrote:
>>>>>>
>>>>>> If I remove the version-setting from qt.py, then ipython still works
>>>>>> with mpl and PyQt4 via "ipython pylab=qt", but it does not work with
>>>>>> qtconsole or with PySide.
>>>>>
>>>>> I don't think we are going to rewrite the whole qtconsole to support
>>>>> version 1 for 0.11 this week. ?What we can do is change the default
>>>>> behavior in qt_for_kernel,
>>>>>
>>>>>
>>>>> (https://github.com/ipython/ipython/blob/master/IPython/external/qt_for_kernel.py)
>>>>> which is where code that interacts with other applications gets
>>>>> imported. ?Currently, we use our v2 import unless matplotlib<= 1.0.1
>>>>> is detected. ?However, we can change that default to be more
>>>>> conservative. ?User code (e.g. matplotlib code, integration with other
>>>>> apps) is not in the same process as the QtConsole, so we can have v1
>>>>> code in the kernel with v2 in the frontend.
>>>
>>> Good point.
>>>
>>>> If ipython and mpl have to be synchronized, and if we want to be able to
>>>> choose to use pyside or pyqt4, then I think we need more than a change in
>>>> the ipython default. ?It looks like this calls for yet another pesky
>>>> rcParams entry in mpl. ?Then that can be used for figuring out what to
>>>> import in both matplotlib and ipython. ?The default, if there is no
>>>> rcParams
>>>> entry, would be PyQt4 with the platform default API version.
>>>>
>>>> Darren, does this sound like a solution that would work for you?
>>>
>>> If ipython changes its qt_for_kernel to not set the api level, then it
>>> seems to me that either the environment variable approach or the
>>> rcParams approach will work for pylab/pyplot. The rcParams approach is
>>> a little awkward for folks using the OO interface, but it looks like
>>> it would work. You mentioned that it does not work with the ipython
>>> console and pyside though, what doesn't work?
>>
>> No figure is displayed after plotting, and then there is an error upon
>> exiting ipython if the figure (which was never displayed) is not closed.
>>
>> Eric
>>
>>
>
> I think the logic should be something along the lines of:
>
> if matplotlib:
> ? ?if matplotlib <= 1.0.1:
> ? ? ? ? use PyQt+v1 # old matplotlib can't support v2, if I
> understand correctly
> ? ?else:
> ? ? ? ? ask matplotlib
> if no answer or no matplotlib:
> ? ?if QT_API defined:
> ? ? ? ?if QT_API=pyqt:
> ? ? ? ? ? ? ? ?use PyQt+v2 #because this is an ETS env variable, and
> ETS requires v2
> ? ? ? ?elif QT_API=pyside:
> ? ? ? ? ? use pyside
> ? ?else:
> ? ? ? ?try pyqt+v1
> ? ? ? ?if no pyqt:
> ? ? ? ? ? ? try pyside
>
> gist: QT_API should be respected if set, and use v2 unless matplotlib
> is too old to allow it. ?If nothing is specified, the default is
> pyqt+v1, the safest option, but PySide should still be chosen if it's
> the only Qt installed.
>
> Does this make sense?

You won't be able to tell what PyQt API to use from matplotlib. I
think the default api (version 1) would be the appropriate choice
unless QT_API is set, since as you say this is an ETS environment
variable and ETS is the only python2 library I am aware of that
actually requires PyQt4's v2 API. It would be useful to document this
somewhere, perhaps at
http://ipython.org/ipython-doc/dev/interactive/reference.html#gui-event-loop-support-support

By the way, I find the new ipython's new argument parsing really
non-intuitive. It took me 5 attempts to figure out how to do "ipython
gui=qt", even after skimming the output of "ipython -h". What's wrong
with "ipython --gui=qt"? Does ipython really need to put its own
unique spin on argument parsing?


From wardefar at iro.umontreal.ca  Wed Jul  6 01:10:58 2011
From: wardefar at iro.umontreal.ca (David Warde-Farley)
Date: Wed, 6 Jul 2011 01:10:58 -0400
Subject: [IPython-dev] default colorscheme
In-Reply-To: <292E55EB-E5CB-44AA-B7DA-9C7F54B92614@gmail.com>
References: <13B4CAB7-2FE6-497A-B182-EA7F2BD186AF@iro.umontreal.ca>
	<292E55EB-E5CB-44AA-B7DA-9C7F54B92614@gmail.com>
Message-ID: <B89C0493-2653-4175-9418-645DCA9EC29D@iro.umontreal.ca>

On 2011-07-04, at 10:09 PM, Min RK wrote:

> LightBG is the default on OSX, because the default terminal is black on white there.  If there's a good way to determine the actual background color, we could use that to make a more informed default decision.

Well, this is ugly as sin since it involves both spawning a subprocess and the unholy AppleScript, but it's an idea:

To retrieve the default background color for a Terminal.app session,

dwf at strafe:~/src$ osascript
tell application "Terminal"
    set thing to background color of default settings
end tell
<Ctrl-D>
0, 0, 0

To retrieve the default background color for the frontmost window of Terminal.app:

dwf at strafe:~/src$ osascript
tell application "Terminal"
    set thing to name of window 0
end tell
<Ctrl-D>
0, 0, 0

To do the same thing in iTerm:

dwf at strafe:~/src$ osascript
tell application "iTerm"
    set thing to background color of current session of current terminal
end tell
<Ctrl-D>
0, 0, 0

In fact, iTerm sets an "COLORFGBG" environment variable, which makes it slightly easier I guess.

Finally, to differentiate between the two:

dwf at strafe:~$ echo $TERM_PROGRAM
Apple_Terminal

dwf at strafe:~$ echo $TERM_PROGRAM
iTerm.app

Terminal.app and iTerm account for the vast majority of users on OS X, I'd say.

Incidentally, 'xterm' just doesn't set the TERM_PROGRAM variable (unless you launch an xterm from one of those terminals, and it inherits the environment of the parent process, but that's a sufficiently bizarro thing to do...)

What do you think?

David

From wardefar at iro.umontreal.ca  Wed Jul  6 01:12:51 2011
From: wardefar at iro.umontreal.ca (David Warde-Farley)
Date: Wed, 6 Jul 2011 01:12:51 -0400
Subject: [IPython-dev] default colorscheme
In-Reply-To: <B89C0493-2653-4175-9418-645DCA9EC29D@iro.umontreal.ca>
References: <13B4CAB7-2FE6-497A-B182-EA7F2BD186AF@iro.umontreal.ca>
	<292E55EB-E5CB-44AA-B7DA-9C7F54B92614@gmail.com>
	<B89C0493-2653-4175-9418-645DCA9EC29D@iro.umontreal.ca>
Message-ID: <90258F31-1B6B-4ABB-85BD-0DFC0E943034@iro.umontreal.ca>

On 2011-07-06, at 1:10 AM, David Warde-Farley wrote:

> To retrieve the default background color for the frontmost window of Terminal.app:
> 
> dwf at strafe:~/src$ osascript
> tell application "Terminal"
>    set thing to name of window 0
> end tell
> <Ctrl-D>
> 0, 0, 0

Oops. "name" above should obviously read "background color". 

From benjaminrk at gmail.com  Wed Jul  6 01:50:16 2011
From: benjaminrk at gmail.com (MinRK)
Date: Tue, 5 Jul 2011 22:50:16 -0700
Subject: [IPython-dev] default colorscheme
In-Reply-To: <90258F31-1B6B-4ABB-85BD-0DFC0E943034@iro.umontreal.ca>
References: <13B4CAB7-2FE6-497A-B182-EA7F2BD186AF@iro.umontreal.ca>
	<292E55EB-E5CB-44AA-B7DA-9C7F54B92614@gmail.com>
	<B89C0493-2653-4175-9418-645DCA9EC29D@iro.umontreal.ca>
	<90258F31-1B6B-4ABB-85BD-0DFC0E943034@iro.umontreal.ca>
Message-ID: <CAHNn8BUuGqfuAHYf26H0JrMWVkCpH2wWT_+Epu-qUL9VYxYNww@mail.gmail.com>

Thanks for tracking it down!

That looks pretty rough.  I'm not sure it's worth adding all that,
since it doesn't technically get the current window, only the default
profile, but it's closer than nothing.  Also, what's the best way to
evaluate whether an rgb value is 'light' or 'dark'?

-MinRK


On Tue, Jul 5, 2011 at 22:12, David Warde-Farley
<wardefar at iro.umontreal.ca> wrote:
> On 2011-07-06, at 1:10 AM, David Warde-Farley wrote:
>
>> To retrieve the default background color for the frontmost window of Terminal.app:
>>
>> dwf at strafe:~/src$ osascript
>> tell application "Terminal"
>> ? ?set thing to name of window 0
>> end tell
>> <Ctrl-D>
>> 0, 0, 0
>
> Oops. "name" above should obviously read "background color".


From benjaminrk at gmail.com  Wed Jul  6 02:06:16 2011
From: benjaminrk at gmail.com (MinRK)
Date: Tue, 5 Jul 2011 23:06:16 -0700
Subject: [IPython-dev] Qt api selection re. ipython and matplotlib
In-Reply-To: <CAK6O52m0R3ugOkV9gznHmGgMRXAF+yij3PWnisVS8N_98ti+6w@mail.gmail.com>
References: <CAHAreOoMSsD8UYCPHKT_RcESpCWAFuM0VcBWN3t+KR1MZ4ZGnQ@mail.gmail.com>
	<CAK6O52kGTchAcsxH6mt9GRxZ==yhxdX=f+8o3e+XZHujCi17=g@mail.gmail.com>
	<4E128BA4.8090308@hawaii.edu>
	<CAHNn8BWfZur_5f0Cm7NNfkg+jyAmvOXcfnD3Yj3yAOzea7XVdw@mail.gmail.com>
	<4E12AD93.4080901@hawaii.edu>
	<CAK6O52=EhM9_-h8nK-j2vHg_puF7kE=z_2JM0v58WeCsGh59HA@mail.gmail.com>
	<4E133FC3.1090108@hawaii.edu>
	<CAHNn8BV6M+6GSouOe48JtE6xhmsWBCgkZVNg_DBbZONdSS-o3w@mail.gmail.com>
	<CAK6O52m0R3ugOkV9gznHmGgMRXAF+yij3PWnisVS8N_98ti+6w@mail.gmail.com>
Message-ID: <CAHNn8BU1Zh4Nu=-jgZCNMCEs4m_sZdYzB1e1C_LuNvO=Mdxh+A@mail.gmail.com>

On Jul 5, 2011, at 18:32, Darren Dale <dsdale24 at gmail.com> wrote:

> On Tue, Jul 5, 2011 at 8:39 PM, MinRK <benjaminrk at gmail.com> wrote:
>> On Tue, Jul 5, 2011 at 09:45, Eric Firing <efiring at hawaii.edu> wrote:
>>> On 07/05/2011 01:36 AM, Darren Dale wrote:
>>>>
>>>> On Tue, Jul 5, 2011 at 2:22 AM, Eric Firing<efiring at hawaii.edu>  wrote:
>>>>>
>>>>> On 07/04/2011 06:51 PM, MinRK wrote:
>>>>>>
>>>>>> On Mon, Jul 4, 2011 at 20:57, Eric Firing<efiring at hawaii.edu>    wrote:
>>>>>>>
>>>>>>> If I remove the version-setting from qt.py, then ipython still works
>>>>>>> with mpl and PyQt4 via "ipython pylab=qt", but it does not work with
>>>>>>> qtconsole or with PySide.
>>>>>>
>>>>>> I don't think we are going to rewrite the whole qtconsole to support
>>>>>> version 1 for 0.11 this week.  What we can do is change the default
>>>>>> behavior in qt_for_kernel,
>>>>>>
>>>>>>
>>>>>> (https://github.com/ipython/ipython/blob/master/IPython/external/qt_for_kernel.py)
>>>>>> which is where code that interacts with other applications gets
>>>>>> imported.  Currently, we use our v2 import unless matplotlib<= 1.0.1
>>>>>> is detected.  However, we can change that default to be more
>>>>>> conservative.  User code (e.g. matplotlib code, integration with other
>>>>>> apps) is not in the same process as the QtConsole, so we can have v1
>>>>>> code in the kernel with v2 in the frontend.
>>>>
>>>> Good point.
>>>>
>>>>> If ipython and mpl have to be synchronized, and if we want to be able to
>>>>> choose to use pyside or pyqt4, then I think we need more than a change in
>>>>> the ipython default.  It looks like this calls for yet another pesky
>>>>> rcParams entry in mpl.  Then that can be used for figuring out what to
>>>>> import in both matplotlib and ipython.  The default, if there is no
>>>>> rcParams
>>>>> entry, would be PyQt4 with the platform default API version.
>>>>>
>>>>> Darren, does this sound like a solution that would work for you?
>>>>
>>>> If ipython changes its qt_for_kernel to not set the api level, then it
>>>> seems to me that either the environment variable approach or the
>>>> rcParams approach will work for pylab/pyplot. The rcParams approach is
>>>> a little awkward for folks using the OO interface, but it looks like
>>>> it would work. You mentioned that it does not work with the ipython
>>>> console and pyside though, what doesn't work?
>>>
>>> No figure is displayed after plotting, and then there is an error upon
>>> exiting ipython if the figure (which was never displayed) is not closed.
>>>
>>> Eric
>>>
>>>
>>
>> I think the logic should be something along the lines of:
>>
>> if matplotlib:
>>    if matplotlib <= 1.0.1:
>>         use PyQt+v1 # old matplotlib can't support v2, if I
>> understand correctly
>>    else:
>>         ask matplotlib
>> if no answer or no matplotlib:
>>    if QT_API defined:
>>        if QT_API=pyqt:
>>                use PyQt+v2 #because this is an ETS env variable, and
>> ETS requires v2
>>        elif QT_API=pyside:
>>           use pyside
>>    else:
>>        try pyqt+v1
>>        if no pyqt:
>>             try pyside
>>
>> gist: QT_API should be respected if set, and use v2 unless matplotlib
>> is too old to allow it.  If nothing is specified, the default is
>> pyqt+v1, the safest option, but PySide should still be chosen if it's
>> the only Qt installed.
>>
>> Does this make sense?
>
> You won't be able to tell what PyQt API to use from matplotlib. I
> think the default api (version 1) would be the appropriate choice
> unless QT_API is set, since as you say this is an ETS environment
> variable and ETS is the only python2 library I am aware of that
> actually requires PyQt4's v2 API. It would be useful to document this
> somewhere, perhaps at
> http://ipython.org/ipython-doc/dev/interactive/reference.html#gui-event-loop-support-support

I didn't mean that it would ask matplotlib what PyQt API to use, only
whether to use PyQt or PySide.  Eric issues a PR that suggested such
an option was incoming.

I've issued another pull request based on Eric's that handles various
cases, and also tries to explain some of this mess in the docs as you
suggested.

PyQt4 unmolested will happen most of the time, but PySide when
requested will still be used, and PySide will be a fallback for
``gui=qt`` if PyQt isn't installed.

The *only* way PyQt4 will be using v2 is if the ETS env variable is
set as QT_API=pyqt, *and* matplotlib had nothing to say about PyQt vs
PySide (matplotlib being <= 1.0.1 also prevents PyQt with v2).  If we
gathered from matplotlib that we should use PyQt, it will not be
patched to v2.

This places matplotlib / PyQt v1 code at the highest priority, but
also allows ETS, and code that uses modern interfaces, to work via
QT_API.

>
> By the way, I find the new ipython's new argument parsing really
> non-intuitive. It took me 5 attempts to figure out how to do "ipython
> gui=qt", even after skimming the output of "ipython -h". What's wrong
> with "ipython --gui=qt"? Does ipython really need to put its own
> unique spin on argument parsing?

The reason for Brian's design here is that now the command line args
are coupled with the config system.  Specifying a value on the command
line is now identical to specifying it in a config file, so it looks
like a Python assignment (because it is).  It also means that 100% of
IPython is configurable from the command-line.


-MinRK


From ellisonbg at gmail.com  Wed Jul  6 02:19:37 2011
From: ellisonbg at gmail.com (Brian Granger)
Date: Tue, 5 Jul 2011 23:19:37 -0700
Subject: [IPython-dev] Qt api selection re. ipython and matplotlib
In-Reply-To: <CAHNn8BU1Zh4Nu=-jgZCNMCEs4m_sZdYzB1e1C_LuNvO=Mdxh+A@mail.gmail.com>
References: <CAHAreOoMSsD8UYCPHKT_RcESpCWAFuM0VcBWN3t+KR1MZ4ZGnQ@mail.gmail.com>
	<CAK6O52kGTchAcsxH6mt9GRxZ==yhxdX=f+8o3e+XZHujCi17=g@mail.gmail.com>
	<4E128BA4.8090308@hawaii.edu>
	<CAHNn8BWfZur_5f0Cm7NNfkg+jyAmvOXcfnD3Yj3yAOzea7XVdw@mail.gmail.com>
	<4E12AD93.4080901@hawaii.edu>
	<CAK6O52=EhM9_-h8nK-j2vHg_puF7kE=z_2JM0v58WeCsGh59HA@mail.gmail.com>
	<4E133FC3.1090108@hawaii.edu>
	<CAHNn8BV6M+6GSouOe48JtE6xhmsWBCgkZVNg_DBbZONdSS-o3w@mail.gmail.com>
	<CAK6O52m0R3ugOkV9gznHmGgMRXAF+yij3PWnisVS8N_98ti+6w@mail.gmail.com>
	<CAHNn8BU1Zh4Nu=-jgZCNMCEs4m_sZdYzB1e1C_LuNvO=Mdxh+A@mail.gmail.com>
Message-ID: <CAH4pYpSHo_MvhYGLNOPrwUW0jeHF9RuVCMWg_dnBvXeXcAKGFw@mail.gmail.com>

On Tue, Jul 5, 2011 at 11:06 PM, MinRK <benjaminrk at gmail.com> wrote:
> On Jul 5, 2011, at 18:32, Darren Dale <dsdale24 at gmail.com> wrote:
>
>> On Tue, Jul 5, 2011 at 8:39 PM, MinRK <benjaminrk at gmail.com> wrote:
>>> On Tue, Jul 5, 2011 at 09:45, Eric Firing <efiring at hawaii.edu> wrote:
>>>> On 07/05/2011 01:36 AM, Darren Dale wrote:
>>>>>
>>>>> On Tue, Jul 5, 2011 at 2:22 AM, Eric Firing<efiring at hawaii.edu> ?wrote:
>>>>>>
>>>>>> On 07/04/2011 06:51 PM, MinRK wrote:
>>>>>>>
>>>>>>> On Mon, Jul 4, 2011 at 20:57, Eric Firing<efiring at hawaii.edu> ? ?wrote:
>>>>>>>>
>>>>>>>> If I remove the version-setting from qt.py, then ipython still works
>>>>>>>> with mpl and PyQt4 via "ipython pylab=qt", but it does not work with
>>>>>>>> qtconsole or with PySide.
>>>>>>>
>>>>>>> I don't think we are going to rewrite the whole qtconsole to support
>>>>>>> version 1 for 0.11 this week. ?What we can do is change the default
>>>>>>> behavior in qt_for_kernel,
>>>>>>>
>>>>>>>
>>>>>>> (https://github.com/ipython/ipython/blob/master/IPython/external/qt_for_kernel.py)
>>>>>>> which is where code that interacts with other applications gets
>>>>>>> imported. ?Currently, we use our v2 import unless matplotlib<= 1.0.1
>>>>>>> is detected. ?However, we can change that default to be more
>>>>>>> conservative. ?User code (e.g. matplotlib code, integration with other
>>>>>>> apps) is not in the same process as the QtConsole, so we can have v1
>>>>>>> code in the kernel with v2 in the frontend.
>>>>>
>>>>> Good point.
>>>>>
>>>>>> If ipython and mpl have to be synchronized, and if we want to be able to
>>>>>> choose to use pyside or pyqt4, then I think we need more than a change in
>>>>>> the ipython default. ?It looks like this calls for yet another pesky
>>>>>> rcParams entry in mpl. ?Then that can be used for figuring out what to
>>>>>> import in both matplotlib and ipython. ?The default, if there is no
>>>>>> rcParams
>>>>>> entry, would be PyQt4 with the platform default API version.
>>>>>>
>>>>>> Darren, does this sound like a solution that would work for you?
>>>>>
>>>>> If ipython changes its qt_for_kernel to not set the api level, then it
>>>>> seems to me that either the environment variable approach or the
>>>>> rcParams approach will work for pylab/pyplot. The rcParams approach is
>>>>> a little awkward for folks using the OO interface, but it looks like
>>>>> it would work. You mentioned that it does not work with the ipython
>>>>> console and pyside though, what doesn't work?
>>>>
>>>> No figure is displayed after plotting, and then there is an error upon
>>>> exiting ipython if the figure (which was never displayed) is not closed.
>>>>
>>>> Eric
>>>>
>>>>
>>>
>>> I think the logic should be something along the lines of:
>>>
>>> if matplotlib:
>>> ? ?if matplotlib <= 1.0.1:
>>> ? ? ? ? use PyQt+v1 # old matplotlib can't support v2, if I
>>> understand correctly
>>> ? ?else:
>>> ? ? ? ? ask matplotlib
>>> if no answer or no matplotlib:
>>> ? ?if QT_API defined:
>>> ? ? ? ?if QT_API=pyqt:
>>> ? ? ? ? ? ? ? ?use PyQt+v2 #because this is an ETS env variable, and
>>> ETS requires v2
>>> ? ? ? ?elif QT_API=pyside:
>>> ? ? ? ? ? use pyside
>>> ? ?else:
>>> ? ? ? ?try pyqt+v1
>>> ? ? ? ?if no pyqt:
>>> ? ? ? ? ? ? try pyside
>>>
>>> gist: QT_API should be respected if set, and use v2 unless matplotlib
>>> is too old to allow it. ?If nothing is specified, the default is
>>> pyqt+v1, the safest option, but PySide should still be chosen if it's
>>> the only Qt installed.
>>>
>>> Does this make sense?
>>
>> You won't be able to tell what PyQt API to use from matplotlib. I
>> think the default api (version 1) would be the appropriate choice
>> unless QT_API is set, since as you say this is an ETS environment
>> variable and ETS is the only python2 library I am aware of that
>> actually requires PyQt4's v2 API. It would be useful to document this
>> somewhere, perhaps at
>> http://ipython.org/ipython-doc/dev/interactive/reference.html#gui-event-loop-support-support
>
> I didn't mean that it would ask matplotlib what PyQt API to use, only
> whether to use PyQt or PySide. ?Eric issues a PR that suggested such
> an option was incoming.
>
> I've issued another pull request based on Eric's that handles various
> cases, and also tries to explain some of this mess in the docs as you
> suggested.
>
> PyQt4 unmolested will happen most of the time, but PySide when
> requested will still be used, and PySide will be a fallback for
> ``gui=qt`` if PyQt isn't installed.
>
> The *only* way PyQt4 will be using v2 is if the ETS env variable is
> set as QT_API=pyqt, *and* matplotlib had nothing to say about PyQt vs
> PySide (matplotlib being <= 1.0.1 also prevents PyQt with v2). ?If we
> gathered from matplotlib that we should use PyQt, it will not be
> patched to v2.
>
> This places matplotlib / PyQt v1 code at the highest priority, but
> also allows ETS, and code that uses modern interfaces, to work via
> QT_API.
>
>>
>> By the way, I find the new ipython's new argument parsing really
>> non-intuitive. It took me 5 attempts to figure out how to do "ipython
>> gui=qt", even after skimming the output of "ipython -h". What's wrong
>> with "ipython --gui=qt"? Does ipython really need to put its own
>> unique spin on argument parsing?
>
> The reason for Brian's design here is that now the command line args
> are coupled with the config system. ?Specifying a value on the command
> line is now identical to specifying it in a config file, so it looks
> like a Python assignment (because it is). ?It also means that 100% of
> IPython is configurable from the command-line.

As Min mentions, the config system syntax *is* Python and we wanted to
use a syntax that reflected that.  When you do:

Foo.bar=10

At the command line, we parse that as Python code and run it through
the traits machinery.  Making this:

--Foo.bar=10

Only obscures the fact that it is parsed as Python.  This approach
also allows us to do things like the following at the command line:

Foo.bar=[0,1,2]

or even:

Foo.bar=range(3)

Which is then validated by traits as a list of ints.  We do realize
that there is going to be an adjustment period for users and we do
need to continue to improve documentation to point out these important
changes.

Cheers,

Brian

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



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


From fperez.net at gmail.com  Wed Jul  6 03:10:04 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 6 Jul 2011 00:10:04 -0700
Subject: [IPython-dev] default colorscheme
In-Reply-To: <CAHNn8BUuGqfuAHYf26H0JrMWVkCpH2wWT_+Epu-qUL9VYxYNww@mail.gmail.com>
References: <13B4CAB7-2FE6-497A-B182-EA7F2BD186AF@iro.umontreal.ca>
	<292E55EB-E5CB-44AA-B7DA-9C7F54B92614@gmail.com>
	<B89C0493-2653-4175-9418-645DCA9EC29D@iro.umontreal.ca>
	<90258F31-1B6B-4ABB-85BD-0DFC0E943034@iro.umontreal.ca>
	<CAHNn8BUuGqfuAHYf26H0JrMWVkCpH2wWT_+Epu-qUL9VYxYNww@mail.gmail.com>
Message-ID: <CAHAreOrSZJ=Q022xVC195Nf89uHYqH-UXs8hKZ7Gq4ePQJVg8A@mail.gmail.com>

On Tue, Jul 5, 2011 at 10:50 PM, MinRK <benjaminrk at gmail.com> wrote:
> what's the best way to
> evaluate whether an rgb value is 'light' or 'dark'?

Quick and dirty:

light = (r+g+b)/3.0 > 0.5

assuming (r,g,b) normalized to 0-1, adjust accordingly if they're in 0-255.

Cheers,

f


From benjaminrk at gmail.com  Wed Jul  6 03:30:54 2011
From: benjaminrk at gmail.com (Min RK)
Date: Wed, 6 Jul 2011 00:30:54 -0700
Subject: [IPython-dev] default colorscheme
In-Reply-To: <CAHAreOrSZJ=Q022xVC195Nf89uHYqH-UXs8hKZ7Gq4ePQJVg8A@mail.gmail.com>
References: <13B4CAB7-2FE6-497A-B182-EA7F2BD186AF@iro.umontreal.ca>
	<292E55EB-E5CB-44AA-B7DA-9C7F54B92614@gmail.com>
	<B89C0493-2653-4175-9418-645DCA9EC29D@iro.umontreal.ca>
	<90258F31-1B6B-4ABB-85BD-0DFC0E943034@iro.umontreal.ca>
	<CAHNn8BUuGqfuAHYf26H0JrMWVkCpH2wWT_+Epu-qUL9VYxYNww@mail.gmail.com>
	<CAHAreOrSZJ=Q022xVC195Nf89uHYqH-UXs8hKZ7Gq4ePQJVg8A@mail.gmail.com>
Message-ID: <84F9303D-85E4-4C57-964E-4D37F78E99E8@gmail.com>



On Jul 6, 2011, at 0:10, Fernando Perez <fperez.net at gmail.com> wrote:

> On Tue, Jul 5, 2011 at 10:50 PM, MinRK <benjaminrk at gmail.com> wrote:
>> what's the best way to
>> evaluate whether an rgb value is 'light' or 'dark'?
> 
> Quick and dirty:
> 
> light = (r+g+b)/3.0 > 0.5
> 
> assuming (r,g,b) normalized to 0-1, adjust accordingly if they're in 0-255.

That should cover just about everything people will actually use, but just for fun is green 255 dark, as that formula would suggest?

By that formula, rgb(60,255,60) is also dark, which is pretty far from true. It's also pretty hideous, so not a specific edge case we should worry about.

(I'm not suggesting that we use a more precise formula, just noting that the average doesn't always get the right answer).

-MinRK

> 
> Cheers,
> 
> f


From wardefar at iro.umontreal.ca  Wed Jul  6 03:43:19 2011
From: wardefar at iro.umontreal.ca (David Warde-Farley)
Date: Wed, 6 Jul 2011 03:43:19 -0400
Subject: [IPython-dev] default colorscheme
In-Reply-To: <CAHNn8BUuGqfuAHYf26H0JrMWVkCpH2wWT_+Epu-qUL9VYxYNww@mail.gmail.com>
References: <13B4CAB7-2FE6-497A-B182-EA7F2BD186AF@iro.umontreal.ca>
	<292E55EB-E5CB-44AA-B7DA-9C7F54B92614@gmail.com>
	<B89C0493-2653-4175-9418-645DCA9EC29D@iro.umontreal.ca>
	<90258F31-1B6B-4ABB-85BD-0DFC0E943034@iro.umontreal.ca>
	<CAHNn8BUuGqfuAHYf26H0JrMWVkCpH2wWT_+Epu-qUL9VYxYNww@mail.gmail.com>
Message-ID: <DF5D59BC-1E57-40C0-9BAE-EEDDAF5E7A4F@iro.umontreal.ca>


On 2011-07-06, at 1:50 AM, MinRK wrote:

> Thanks for tracking it down!
> 
> That looks pretty rough.  I'm not sure it's worth adding all that,
> since it doesn't technically get the current window, only the default
> profile, but it's closer than nothing.  Also, what's the best way to
> evaluate whether an rgb value is 'light' or 'dark'?

Well, the default profile can be retrieved, but "window 0" for Terminal.app is the frontmost window, apparently:

>> tell application "Terminal"
>>    set thing to background color of window 0
>> end tell

will do the trick.

(The reason it was "name" in the first one was to test if this actually did get the current window, without mucking with my color settings.)

David

From fperez.net at gmail.com  Wed Jul  6 03:43:41 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 6 Jul 2011 00:43:41 -0700
Subject: [IPython-dev] default colorscheme
In-Reply-To: <84F9303D-85E4-4C57-964E-4D37F78E99E8@gmail.com>
References: <13B4CAB7-2FE6-497A-B182-EA7F2BD186AF@iro.umontreal.ca>
	<292E55EB-E5CB-44AA-B7DA-9C7F54B92614@gmail.com>
	<B89C0493-2653-4175-9418-645DCA9EC29D@iro.umontreal.ca>
	<90258F31-1B6B-4ABB-85BD-0DFC0E943034@iro.umontreal.ca>
	<CAHNn8BUuGqfuAHYf26H0JrMWVkCpH2wWT_+Epu-qUL9VYxYNww@mail.gmail.com>
	<CAHAreOrSZJ=Q022xVC195Nf89uHYqH-UXs8hKZ7Gq4ePQJVg8A@mail.gmail.com>
	<84F9303D-85E4-4C57-964E-4D37F78E99E8@gmail.com>
Message-ID: <CAHAreOphXO3wQtJN71EtSznTFOz6GHqssQ3yojh4pH9Mk0TKiw@mail.gmail.com>

On Wed, Jul 6, 2011 at 12:30 AM, Min RK <benjaminrk at gmail.com> wrote:
> That should cover just about everything people will actually use, but just for fun is green 255 dark, as that formula would suggest?
>
> By that formula, rgb(60,255,60) is also dark, which is pretty far from true. It's also pretty hideous, so not a specific edge case we should worry about.
>
> (I'm not suggesting that we use a more precise formula, just noting that the average doesn't always get the right answer).

That's why I said 'quick and dirty' :)  It's the crudest possible
cutoff, bisecting the luminosity range, and it doesn't take into
account any of the (valid) visual complexities you allude to.  But it
will separate between very light and really dark reasonably well,
messing up other wonky cases.

Cheers,

f


From efiring at hawaii.edu  Wed Jul  6 04:15:41 2011
From: efiring at hawaii.edu (Eric Firing)
Date: Tue, 05 Jul 2011 22:15:41 -1000
Subject: [IPython-dev] Qt api selection re. ipython and matplotlib
In-Reply-To: <CAHNn8BU1Zh4Nu=-jgZCNMCEs4m_sZdYzB1e1C_LuNvO=Mdxh+A@mail.gmail.com>
References: <CAHAreOoMSsD8UYCPHKT_RcESpCWAFuM0VcBWN3t+KR1MZ4ZGnQ@mail.gmail.com>
	<CAK6O52kGTchAcsxH6mt9GRxZ==yhxdX=f+8o3e+XZHujCi17=g@mail.gmail.com>
	<4E128BA4.8090308@hawaii.edu>
	<CAHNn8BWfZur_5f0Cm7NNfkg+jyAmvOXcfnD3Yj3yAOzea7XVdw@mail.gmail.com>
	<4E12AD93.4080901@hawaii.edu>
	<CAK6O52=EhM9_-h8nK-j2vHg_puF7kE=z_2JM0v58WeCsGh59HA@mail.gmail.com>
	<4E133FC3.1090108@hawaii.edu>
	<CAHNn8BV6M+6GSouOe48JtE6xhmsWBCgkZVNg_DBbZONdSS-o3w@mail.gmail.com>
	<CAK6O52m0R3ugOkV9gznHmGgMRXAF+yij3PWnisVS8N_98ti+6w@mail.gmail.com>
	<CAHNn8BU1Zh4Nu=-jgZCNMCEs4m_sZdYzB1e1C_LuNvO=Mdxh+A@mail.gmail.com>
Message-ID: <4E1419AD.4010003@hawaii.edu>

On 07/05/2011 08:06 PM, MinRK wrote:
> On Jul 5, 2011, at 18:32, Darren Dale<dsdale24 at gmail.com>  wrote:
>
>> On Tue, Jul 5, 2011 at 8:39 PM, MinRK<benjaminrk at gmail.com>  wrote:
>>> On Tue, Jul 5, 2011 at 09:45, Eric Firing<efiring at hawaii.edu>  wrote:
>>>> On 07/05/2011 01:36 AM, Darren Dale wrote:
>>>>>
>>>>> On Tue, Jul 5, 2011 at 2:22 AM, Eric Firing<efiring at hawaii.edu>   wrote:
>>>>>>
>>>>>> On 07/04/2011 06:51 PM, MinRK wrote:
>>>>>>>
>>>>>>> On Mon, Jul 4, 2011 at 20:57, Eric Firing<efiring at hawaii.edu>     wrote:
>>>>>>>>
>>>>>>>> If I remove the version-setting from qt.py, then ipython still works
>>>>>>>> with mpl and PyQt4 via "ipython pylab=qt", but it does not work with
>>>>>>>> qtconsole or with PySide.
>>>>>>>
>>>>>>> I don't think we are going to rewrite the whole qtconsole to support
>>>>>>> version 1 for 0.11 this week.  What we can do is change the default
>>>>>>> behavior in qt_for_kernel,
>>>>>>>
>>>>>>>
>>>>>>> (https://github.com/ipython/ipython/blob/master/IPython/external/qt_for_kernel.py)
>>>>>>> which is where code that interacts with other applications gets
>>>>>>> imported.  Currently, we use our v2 import unless matplotlib<= 1.0.1
>>>>>>> is detected.  However, we can change that default to be more
>>>>>>> conservative.  User code (e.g. matplotlib code, integration with other
>>>>>>> apps) is not in the same process as the QtConsole, so we can have v1
>>>>>>> code in the kernel with v2 in the frontend.
>>>>>
>>>>> Good point.
>>>>>
>>>>>> If ipython and mpl have to be synchronized, and if we want to be able to
>>>>>> choose to use pyside or pyqt4, then I think we need more than a change in
>>>>>> the ipython default.  It looks like this calls for yet another pesky
>>>>>> rcParams entry in mpl.  Then that can be used for figuring out what to
>>>>>> import in both matplotlib and ipython.  The default, if there is no
>>>>>> rcParams
>>>>>> entry, would be PyQt4 with the platform default API version.
>>>>>>
>>>>>> Darren, does this sound like a solution that would work for you?
>>>>>
>>>>> If ipython changes its qt_for_kernel to not set the api level, then it
>>>>> seems to me that either the environment variable approach or the
>>>>> rcParams approach will work for pylab/pyplot. The rcParams approach is
>>>>> a little awkward for folks using the OO interface, but it looks like
>>>>> it would work. You mentioned that it does not work with the ipython
>>>>> console and pyside though, what doesn't work?
>>>>
>>>> No figure is displayed after plotting, and then there is an error upon
>>>> exiting ipython if the figure (which was never displayed) is not closed.
>>>>
>>>> Eric
>>>>
>>>>
>>>
>>> I think the logic should be something along the lines of:
>>>
>>> if matplotlib:
>>>     if matplotlib<= 1.0.1:
>>>          use PyQt+v1 # old matplotlib can't support v2, if I
>>> understand correctly
>>>     else:
>>>          ask matplotlib
>>> if no answer or no matplotlib:
>>>     if QT_API defined:
>>>         if QT_API=pyqt:
>>>                 use PyQt+v2 #because this is an ETS env variable, and
>>> ETS requires v2
>>>         elif QT_API=pyside:
>>>            use pyside
>>>     else:
>>>         try pyqt+v1
>>>         if no pyqt:
>>>              try pyside
>>>
>>> gist: QT_API should be respected if set, and use v2 unless matplotlib
>>> is too old to allow it.  If nothing is specified, the default is
>>> pyqt+v1, the safest option, but PySide should still be chosen if it's
>>> the only Qt installed.
>>>
>>> Does this make sense?
>>
>> You won't be able to tell what PyQt API to use from matplotlib. I
>> think the default api (version 1) would be the appropriate choice
>> unless QT_API is set, since as you say this is an ETS environment
>> variable and ETS is the only python2 library I am aware of that
>> actually requires PyQt4's v2 API. It would be useful to document this
>> somewhere, perhaps at
>> http://ipython.org/ipython-doc/dev/interactive/reference.html#gui-event-loop-support-support
>
> I didn't mean that it would ask matplotlib what PyQt API to use, only
> whether to use PyQt or PySide.  Eric issues a PR that suggested such
> an option was incoming.
>
> I've issued another pull request based on Eric's that handles various
> cases, and also tries to explain some of this mess in the docs as you
> suggested.
>
> PyQt4 unmolested will happen most of the time, but PySide when
> requested will still be used, and PySide will be a fallback for
> ``gui=qt`` if PyQt isn't installed.
>
> The *only* way PyQt4 will be using v2 is if the ETS env variable is
> set as QT_API=pyqt, *and* matplotlib had nothing to say about PyQt vs
> PySide (matplotlib being<= 1.0.1 also prevents PyQt with v2).  If we
> gathered from matplotlib that we should use PyQt, it will not be
> patched to v2.
>
> This places matplotlib / PyQt v1 code at the highest priority, but
> also allows ETS, and code that uses modern interfaces, to work via
> QT_API.

Darren et al.,

Is all this good from your mpl/qt standpoint?  We could make mpl pay 
attention to the ETS QT_API environment variable, if present, while 
retaining the rcParam.  For example, QT_API could simply override the 
rcParam, with the additional effect of forcing v2 in the PyQt4 case.  In 
other words, if QT_API is defined, we would follow the original ETS 
strategy; otherwise the rcParams strategy as in my last mpl pull 
request.  I think that although this is a bit more complicated, and 
would require one more iteration on the ipython side as well as on the 
mpl side, it might last longer as a way to handle just about all 
situations, including mpl mixed with ETS things.

Regarding PySide: I actually can't get it to work in interactive mode 
(that is, display a plot) even from the straight python prompt; it is 
working in interactive mode at present only in the ipython qtconsole. 
As of April, PySide apparently did not use the input hook:

http://lists.pyside.org/pipermail/pyside/2011-April/002362.html

Google didn't turn up anything more recent.  So how is it that pylab 
with PySide is working in qtconsole?

Eric




>
>>
>> By the way, I find the new ipython's new argument parsing really
>> non-intuitive. It took me 5 attempts to figure out how to do "ipython
>> gui=qt", even after skimming the output of "ipython -h". What's wrong
>> with "ipython --gui=qt"? Does ipython really need to put its own
>> unique spin on argument parsing?
>
> The reason for Brian's design here is that now the command line args
> are coupled with the config system.  Specifying a value on the command
> line is now identical to specifying it in a config file, so it looks
> like a Python assignment (because it is).  It also means that 100% of
> IPython is configurable from the command-line.
>
>
> -MinRK



From dave.hirschfeld at gmail.com  Wed Jul  6 04:59:25 2011
From: dave.hirschfeld at gmail.com (David Hirschfeld)
Date: Wed, 6 Jul 2011 09:59:25 +0100
Subject: [IPython-dev] default colorscheme
In-Reply-To: <CAHAreOphXO3wQtJN71EtSznTFOz6GHqssQ3yojh4pH9Mk0TKiw@mail.gmail.com>
References: <13B4CAB7-2FE6-497A-B182-EA7F2BD186AF@iro.umontreal.ca>
	<292E55EB-E5CB-44AA-B7DA-9C7F54B92614@gmail.com>
	<B89C0493-2653-4175-9418-645DCA9EC29D@iro.umontreal.ca>
	<90258F31-1B6B-4ABB-85BD-0DFC0E943034@iro.umontreal.ca>
	<CAHNn8BUuGqfuAHYf26H0JrMWVkCpH2wWT_+Epu-qUL9VYxYNww@mail.gmail.com>
	<CAHAreOrSZJ=Q022xVC195Nf89uHYqH-UXs8hKZ7Gq4ePQJVg8A@mail.gmail.com>
	<84F9303D-85E4-4C57-964E-4D37F78E99E8@gmail.com>
	<CAHAreOphXO3wQtJN71EtSznTFOz6GHqssQ3yojh4pH9Mk0TKiw@mail.gmail.com>
Message-ID: <CACGp2_NBtxN++a7qNTsEe-r_SnbtaqP5CM6oXDmtm4QF4XiMTA@mail.gmail.com>

On Wed, Jul 6, 2011 at 8:43 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Wed, Jul 6, 2011 at 12:30 AM, Min RK <benjaminrk at gmail.com> wrote:
>> That should cover just about everything people will actually use, but just for fun is green 255 dark, as that formula would suggest?
>>
>> By that formula, rgb(60,255,60) is also dark, which is pretty far from true. It's also pretty hideous, so not a specific edge case we should worry about.
>>
>> (I'm not suggesting that we use a more precise formula, just noting that the average doesn't always get the right answer).
>
> That's why I said 'quick and dirty' :) ?It's the crudest possible
> cutoff, bisecting the luminosity range, and it doesn't take into
> account any of the (valid) visual complexities you allude to. ?But it
> will separate between very light and really dark reasonably well,
> messing up other wonky cases.
>
> Cheers,
>
> f

Not sure if this helps at all but over on the numpy list Chris Barker suggested
the ITU-R 601-2 luma transform:

Christopher Barker <Chris.Barker <at> noaa.gov> writes:
>
> you also might want to get a bit fancier than simply scaling linearly
> R,G, and B don't necessarily all contribute equally to our sense of
> "whiteness"
>
> For instance, PIL uses:
>
> """
> When from a colour image to black and white, the library uses the ITU-R
> 601-2 luma transform:
>
>      L = R * 299/1000 + G * 587/1000 + B * 114/1000
> """
>
> which would be easy enough to do with numpy.
>
> -Chris
>


From walter at livinglogic.de  Wed Jul  6 08:08:43 2011
From: walter at livinglogic.de (=?UTF-8?B?V2FsdGVyIETDtnJ3YWxk?=)
Date: Wed, 06 Jul 2011 14:08:43 +0200
Subject: [IPython-dev] default colorscheme
In-Reply-To: <CACGp2_NBtxN++a7qNTsEe-r_SnbtaqP5CM6oXDmtm4QF4XiMTA@mail.gmail.com>
References: <13B4CAB7-2FE6-497A-B182-EA7F2BD186AF@iro.umontreal.ca>
	<292E55EB-E5CB-44AA-B7DA-9C7F54B92614@gmail.com>
	<B89C0493-2653-4175-9418-645DCA9EC29D@iro.umontreal.ca>
	<90258F31-1B6B-4ABB-85BD-0DFC0E943034@iro.umontreal.ca>
	<CAHNn8BUuGqfuAHYf26H0JrMWVkCpH2wWT_+Epu-qUL9VYxYNww@mail.gmail.com>
	<CAHAreOrSZJ=Q022xVC195Nf89uHYqH-UXs8hKZ7Gq4ePQJVg8A@mail.gmail.com>
	<84F9303D-85E4-4C57-964E-4D37F78E99E8@gmail.com>
	<CAHAreOphXO3wQtJN71EtSznTFOz6GHqssQ3yojh4pH9Mk0TKiw@mail.gmail.com>
	<CACGp2_NBtxN++a7qNTsEe-r_SnbtaqP5CM6oXDmtm4QF4XiMTA@mail.gmail.com>
Message-ID: <4E14504B.6090907@livinglogic.de>

On 06.07.11 10:59, David Hirschfeld wrote:

> [...]
> Christopher Barker <Chris.Barker <at> noaa.gov> writes:
>>
>> you also might want to get a bit fancier than simply scaling linearly
>> R,G, and B don't necessarily all contribute equally to our sense of
>> "whiteness"
>>
>> For instance, PIL uses:
>>
>> """
>> When from a colour image to black and white, the library uses the ITU-R
>> 601-2 luma transform:
>>
>>      L = R * 299/1000 + G * 587/1000 + B * 114/1000
>> """
>>
>> which would be easy enough to do with numpy.

Or simply use colorsys:

>>> import colorsys
>>> colorsys.rgb_to_hsv(60/255.,255/255.,60/255.)[2] >= 0.5

Servus,
   Walter



From johann.cohentanugi at gmail.com  Wed Jul  6 08:33:36 2011
From: johann.cohentanugi at gmail.com (Johann Cohen-Tanugi)
Date: Wed, 06 Jul 2011 14:33:36 +0200
Subject: [IPython-dev] 0.11rc1 : problem with tutorial for PBS
	in	http://ipython.org/ipython-doc/dev/parallel/parallel_process.html
In-Reply-To: <4E12A5E7.7000202@gmail.com>
References: <4E11D735.9080909@gmail.com>
	<4E121C1D.2040103@gmail.com>	<CAHNn8BWcf4789EJ-zf3yJa8oYjPRjWjJMRz-Porf=1HuPAQj+g@mail.gmail.com>
	<4E12A5E7.7000202@gmail.com>
Message-ID: <4E145620.5090200@gmail.com>

hi Min, so your fix worked, thanks. I managed to connect to SGE running 
engines within an ipython session, and thus started to clone the code 
for LSF. But I have the following issue : with the LSF farm I have at 
hand, I am forced to use "bsub < batch_script" rather than "bsub 
batch_script". I asked the admins about this and hope to have an answer 
tonight. Note that in 
https://github.com/ipython/ipython/blob/0.10.2/IPython/kernel/scripts/ipcluster.py 
, the same issue seems to have been encountered as I can see :

bsub_wrapper="""#!/bin/sh
bsub < $1

So I tried
class LSFLauncher(BatchSystemLauncher):
     """A BatchSystemLauncher subclass for LSF."""

     submit_command = List(['bsub >'], config=True,<....>

but this results in a crash :
-bash-3.2$ ipcluster start n=4 profile=lsf
[IPClusterStart] Using existing profile dir: 
u'/u/ec/cohen/.config/ipython/profile_lsf'
[IPClusterStart] Starting ipcluster with [daemon=False]
[IPClusterStart] Creating pid file: 
/u/ec/cohen/.config/ipython/profile_lsf/pid/ipcluster.pid
[IPClusterStart] Starting LocalControllerLauncher: 
['/afs/slac/g/glast/ground/GLAST_EXT/redhat5-x86_64-64bit-gcc41/python/2.6.5/gcc41/bin/python', 
u'/a/wain006/g.glast.u54/cohen/IPYDEV/ipython/IPython/parallel/apps/ipcontrollerapp.py', 
'--log-to-file', 'log_level=20', 
u'profile_dir=/u/ec/cohen/.config/ipython/profile_lsf']
[IPClusterStart] Process 
'/afs/slac/g/glast/ground/GLAST_EXT/redhat5-x86_64-64bit-gcc41/python/2.6.5/gcc41/bin/python' 
started: 16921
[IPClusterStart] Starting 4 engines
[IPClusterStart] Starting 4 engines with LSFEngineSetLauncher: ['bsub 
\\<', u'/u/ec/cohen/.config/ipython/profile_lsf/lsf_engines']
[IPClusterStart] adding job array settings to batch script
[IPClusterStart] Writing instantiated batch script: 
/u/ec/cohen/.config/ipython/profile_lsf/lsf_engines
ERROR:root:Error in periodic callback
Traceback (most recent call last):
   File 
"/afs/slac/g/glast/users/cohen/IPYDEV/local/lib/python2.6/site-packages/zmq/eventloop/ioloop.py", 
line 432, in _run
     self.callback()
   File 
"/a/wain006/g.glast.u54/cohen/IPYDEV/ipython/IPython/parallel/apps/ipclusterapp.py", 
line 258, in start_engines
     self.profile_dir.location
   File 
"/a/wain006/g.glast.u54/cohen/IPYDEV/ipython/IPython/parallel/apps/launcher.py", 
line 1049, in start
     return super(LSFEngineSetLauncher, self).start(n, profile_dir)
   File 
"/a/wain006/g.glast.u54/cohen/IPYDEV/ipython/IPython/parallel/apps/launcher.py", 
line 902, in start
     output = check_output(self.args, env=os.environ)
   File 
"/a/wain006/g.glast.u54/cohen/IPYDEV/ipython/IPython/parallel/apps/launcher.py", 
line 51, in check_output
     p = Popen(*args, **kwargs)
   File 
"/afs/slac/g/glast/ground/GLAST_EXT/redhat5-x86_64-64bit-gcc41/python/2.6.5/gcc41/lib/python2.6/subprocess.py", 
line 633, in __init__
     errread, errwrite)
   File 
"/afs/slac/g/glast/ground/GLAST_EXT/redhat5-x86_64-64bit-gcc41/python/2.6.5/gcc41/lib/python2.6/subprocess.py", 
line 1139, in _execute_child
     raise child_exception
OSError: [Errno 2] No such file or directory
[IPClusterStart] [IPControllerApp] Using existing profile dir: 
u'/u/ec/cohen/.config/ipython/profile_lsf'
ERROR:IPClusterStart:[IPControllerApp] Using existing profile dir: 
u'/u/ec/cohen/.config/ipython/profile_lsf'
[IPClusterStart] Scheduler started [leastload]
ERROR:IPClusterStart:Scheduler started [leastload]

and the engines are not started in the batch....

thoughts?
Johann


On 07/05/2011 07:49 AM, Johann Cohen-Tanugi wrote:
> Thanks  a lot for all your help Min.
> I will check your fix today. I think that for PBS -t should be replaced
> by -J, but I cannot test it as I realized yesterday that the batch
> system I put my hands on is derived from PBS, but is not PBS, and does
> not seem to honor -J. I will switch to SGE, then back to LSF with my
> updated launcher.py once I am sure I understand the SGE code that is
> already shipped with ipython and that you were able to test.
>
> best,
> Johann
>
>
> On 07/05/2011 01:56 AM, MinRK wrote:
>> On Mon, Jul 4, 2011 at 13:01, Johann Cohen-Tanugi
>> <johann.cohentanugi at gmail.com>   wrote:
>>> good evening.... still trying to make the PBS batch parallel code work.
>>> I had to comment the "-t" line in launcher.py, but I am still puzzled by
>>> the fact that there is no loop over n to start n different engines. Is
>>> that because the '-t' was precisely there to create an array of subjobs?
>> Sorry about this, I was testing against Linux with Torque, which
>> supports job arrays via '-t'.  How to start a collection of jobs is
>> going to vary from one PBS to another.
>>
>> For instance, on some systems the default will be to use *no* job
>> array, and run multiple engines via aprun or mpiexec.  I just looked,
>> and the addition of the jobarray line is unconditional, which is
>> definitely wrong. I just pushed a fix for that, so if you specify your
>> own template, it should not be changed at all by IPython.
>>
>> A possible example:
>>
>> #PBS -N ipython
>> #PBS -j oe
>> #PBS -l walltime=00:10:00
>> #PBS -l nodes={n/4}:ppn=4 # assumes 4-CPU nodes
>> #PBS -q {queue}
>>
>> cd $PBS_O_WORKDIR
>>
>> aprun -n {n} ipengine profile_dir={profile_dir}
>>
>> This is if your system uses aprun, though mpiexec may be more
>> appropriate for you.  Note that if you have PBS but no parallel
>> environments like mpi or ap, then you may have to do something like a
>> simple loop:
>>
>> for i in {{ 1..{n} }}; do
>>       ipengine profile_dir={profile_dir}
>> done
>>
>> # note the double-brace.  The templates use string.format, so to
>> escape braces you need to double them, so:
>> for i in {{ 1..{n} }}
>> becomes
>> for i in { 1..4 }
>>
>> which in bash expands to 1 2 3 4
>>
>> The templating should support any of these.
>>
>>> Second question, more general : assuming the use of ipcluster, a
>>> controller and several engines are created; following the tutorial, all
>>> would actually run in batch, which seems strange to me for the
>>> controller : batch queues usually have time limits, and it is
>>> unavoidable that engines would die when the cpu time is exceeded, but I
>>> do not see why the controller should suffer from this. What would be the
>>> rational to execute the controller in batch rather than locally? Second
>>> question, once the engines run in batch, I presume that they listen to
>>> commands sent from any ipython session that I would interactively start,
>>> providing I use the Client() with the correct permissions in terms of
>>> ports,ssh etc.... Is that correct, id est is that indeed the idea?
>> You can choose to start the controller with batch or not, that's up to
>> you.  There is no coupling at all between which launcher you choose
>> for the Controller and which you choose for the Engines.  If you want
>> the controller to live longer than the batch system will allow, then
>> using the batch launcher for the controller is obviously the wrong
>> choice.
>>
>> It does sometimes make sense to launch the controller with batch,
>> because you could have an entire job with controller, engines, and
>> clients *all* submitted via the batch system.  I do this sometimes
>> with SGE for scaling tests using starcluster. It also helps
>> load-balancing for shared-node systems, since the controller should
>> take up a work slot.  If you have a high throughput workload, you
>> don't want to run n engines + a controller on an n-cpu node, because
>> they will be fighting over resources.
>>
>> Two more reasons to start the controller with batch: it will be
>> faster, and you can turn off your local machine.  You can submit a
>> million jobs, turn off your local machine altogether, then connect
>> again later and retrieve your results.  It will be faster, because the
>> majority of communication happens between the controller and the
>> engines, rather than the client and the controller.
>>
>> -MinRK
>>
>>> sorry to be dense about all that... I think it would be useful if the
>>> batch doc page was supplemented with the final step which amounts to
>>> starting an interactive ipython session and connecting to the batch engines.
>> Sure, I can add this, though it's not different from any method of
>> connecting to a controller from another machine.
>>
>> If you are on the same system (e.g. in batch script or on a login
>> node), it will amount to:
>>
>> ipython
>> In [1]: from IPython.parallel import Client
>> In [2]: rc = Client(profile='clusterprofile')
>>
>> And if you are not, you will have to get the ipcontroller-client.json
>> file from profile_dir/security with scp, and do:
>> In [2]: rc = Client('/path/to/ipcontroller-client.json' )
>>
>> possibly adding `sshserver='loginnode.example.com'` if you didn't
>> specify the ssh server for tunneling when starting the Controller.
>>
>> -MinRK
>>
>>> will continue digging,
>>> best.
>>> Johann
>>>
>>> On 07/04/2011 05:07 PM, Johann Cohen-Tanugi wrote:
>>>> hi there, my problem is in the fact that a line seems to be added to the
>>>> template I am defining following the tutorial :
>>>> the template proposed in the tutorial is modified at runtime as :
>>>>
>>>> #!/bin/sh
>>>> #PBS -t 1-4<----------------- incorrect?
>>>> #PBS -V
>>>> #PBS -N ipengine
>>>> /usr/local/bin/python
>>>> /sps/glast/users/cohen/IPYDEV/ipython/IPython/parallel/apps/ipengineapp.py
>>>> profile_dir=/afs/in2p3.fr/home/t/tanugi/\
>>>> .ipython/profile_pbs
>>>>
>>>>
>>>> The problem I believe is in the job_array_template in  :
>>>>
>>>> class PBSLauncher(BatchSystemLauncher):
>>>>         """A BatchSystemLauncher subclass for PBS."""
>>>>
>>>>         submit_command = List(['qsub'], config=True,
>>>>             help="The PBS submit command ['qsub']")
>>>>         delete_command = List(['qdel'], config=True,
>>>>             help="The PBS delete command ['qsub']")
>>>>         job_id_regexp = Unicode(r'\d+', config=True,
>>>>             help="Regular expresion for identifying the job ID [r'\d+']")
>>>>
>>>>         batch_file = Unicode(u'')
>>>>         job_array_regexp = Unicode('#PBS\W+-t\W+[\w\d\-\$]+')
>>>>         job_array_template = Unicode('#PBS -t 1-{n}')
>>>>         queue_regexp = Unicode('#PBS\W+-q\W+\$?\w+')
>>>>         queue_template = Unicode('#PBS -q {queue}')
>>>>
>>>>
>>>> I looked at the PBS doc for version 10 and 11 and I did not see any '-t'
>>>> option. When I try to run, I get :
>>>> [tanugi at ccali28 test_directory]$ ipcluster start profile=pbs n=4
>>>> [IPClusterStart] Using existing profile dir:
>>>> u'/afs/in2p3.fr/home/t/tanugi/.ipython/profile_pbs'
>>>> [IPClusterStart] Starting ipcluster with [daemon=False]
>>>> [IPClusterStart] Creating pid file:
>>>> /afs/in2p3.fr/home/t/tanugi/.ipython/profile_pbs/pid/ipcluster.pid
>>>> [IPClusterStart] Starting PBSControllerLauncher: ['qsub',
>>>> u'/afs/in2p3.fr/home/t/tanugi/.ipython/profile_pbs/pbs_controller']
>>>> [IPClusterStart] adding job array settings to batch script
>>>> [IPClusterStart] Writing instantiated batch script:
>>>> /afs/in2p3.fr/home/t/tanugi/.ipython/profile_pbs/pbs_controller
>>>> unknown -t option
>>>> ERROR:root:Error in periodic callback
>>>> Traceback (most recent call last):
>>>>       File
>>>> "/sps/glast/users/cohen/IPYDEV/local/lib/python2.6/site-packages/zmq/eventloop/ioloop.py",
>>>> line 432, in _run
>>>>         self.callback()
>>>>       File
>>>> "/sps/glast/users/cohen/IPYDEV/ipython/IPython/parallel/apps/ipclusterapp.py",
>>>> line 364, in start_controller
>>>>         self.profile_dir.location
>>>>       File
>>>> "/sps/glast/users/cohen/IPYDEV/ipython/IPython/parallel/apps/launcher.py",
>>>> line 943, in start
>>>>         return super(PBSControllerLauncher, self).start(1, profile_dir)
>>>>       File
>>>> "/sps/glast/users/cohen/IPYDEV/ipython/IPython/parallel/apps/launcher.py",
>>>> line 902, in start
>>>>         job_id = self.parse_job_id(output)
>>>>       File
>>>> "/sps/glast/users/cohen/IPYDEV/ipython/IPython/parallel/apps/launcher.py",
>>>> line 854, in parse_job_id
>>>>         raise LauncherError("Job id couldn't be determined: %s" % output)
>>>> LauncherError: Job id couldn't be determined:
>>>>
>>>> Not sure yet about the traceback, but the "unknown -t option" is clear.
>>>> Furthermore, I wonder if it is really what we want to add lines to a
>>>> template file provided by the user?
>>>>
>>>> best,
>>>> Johann
>>>> _______________________________________________
>>>> IPython-dev mailing list
>>>> IPython-dev at scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110706/c2263ccf/attachment.html>

From dsdale24 at gmail.com  Wed Jul  6 08:33:55 2011
From: dsdale24 at gmail.com (Darren Dale)
Date: Wed, 6 Jul 2011 08:33:55 -0400
Subject: [IPython-dev] Qt api selection re. ipython and matplotlib
In-Reply-To: <4E1419AD.4010003@hawaii.edu>
References: <CAHAreOoMSsD8UYCPHKT_RcESpCWAFuM0VcBWN3t+KR1MZ4ZGnQ@mail.gmail.com>
	<CAK6O52kGTchAcsxH6mt9GRxZ==yhxdX=f+8o3e+XZHujCi17=g@mail.gmail.com>
	<4E128BA4.8090308@hawaii.edu>
	<CAHNn8BWfZur_5f0Cm7NNfkg+jyAmvOXcfnD3Yj3yAOzea7XVdw@mail.gmail.com>
	<4E12AD93.4080901@hawaii.edu>
	<CAK6O52=EhM9_-h8nK-j2vHg_puF7kE=z_2JM0v58WeCsGh59HA@mail.gmail.com>
	<4E133FC3.1090108@hawaii.edu>
	<CAHNn8BV6M+6GSouOe48JtE6xhmsWBCgkZVNg_DBbZONdSS-o3w@mail.gmail.com>
	<CAK6O52m0R3ugOkV9gznHmGgMRXAF+yij3PWnisVS8N_98ti+6w@mail.gmail.com>
	<CAHNn8BU1Zh4Nu=-jgZCNMCEs4m_sZdYzB1e1C_LuNvO=Mdxh+A@mail.gmail.com>
	<4E1419AD.4010003@hawaii.edu>
Message-ID: <CAK6O52kDgXLFddH-uVDRPCj3HDpYc0Wd3hETTzWxzPoDCYaGDg@mail.gmail.com>

On Wed, Jul 6, 2011 at 4:15 AM, Eric Firing <efiring at hawaii.edu> wrote:
> On 07/05/2011 08:06 PM, MinRK wrote:
>> I didn't mean that it would ask matplotlib what PyQt API to use, only
>> whether to use PyQt or PySide. ?Eric issues a PR that suggested such
>> an option was incoming.
>>
>> I've issued another pull request based on Eric's that handles various
>> cases, and also tries to explain some of this mess in the docs as you
>> suggested.
>>
>> PyQt4 unmolested will happen most of the time, but PySide when
>> requested will still be used, and PySide will be a fallback for
>> ``gui=qt`` if PyQt isn't installed.
>>
>> The *only* way PyQt4 will be using v2 is if the ETS env variable is
>> set as QT_API=pyqt, *and* matplotlib had nothing to say about PyQt vs
>> PySide (matplotlib being<= 1.0.1 also prevents PyQt with v2). ?If we
>> gathered from matplotlib that we should use PyQt, it will not be
>> patched to v2.
>>
>> This places matplotlib / PyQt v1 code at the highest priority, but
>> also allows ETS, and code that uses modern interfaces, to work via
>> QT_API.
>
> Darren et al.,
>
> Is all this good from your mpl/qt standpoint? ?We could make mpl pay
> attention to the ETS QT_API environment variable, if present, while
> retaining the rcParam. ?For example, QT_API could simply override the
> rcParam, with the additional effect of forcing v2 in the PyQt4 case. ?In
> other words, if QT_API is defined, we would follow the original ETS
> strategy; otherwise the rcParams strategy as in my last mpl pull request.

I think this may be necessary. The error message you originally
reported came from IPython, which complained that it was trying to set
the api but could not, presumably because matplotlib had already
imported PyQt4. The api needs to be set before any PyQt4 imports.

> I think that although this is a bit more complicated, and would require one
> more iteration on the ipython side as well as on the mpl side, it might last
> longer as a way to handle just about all situations, including mpl mixed
> with ETS things.

I think you are probably right.

Darren


From takowl at gmail.com  Wed Jul  6 09:16:49 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Wed, 6 Jul 2011 14:16:49 +0100
Subject: [IPython-dev] 0.11rc1 : problem with tutorial for PBS in
	http://ipython.org/ipython-doc/dev/parallel/parallel_process.html
In-Reply-To: <4E145620.5090200@gmail.com>
References: <4E11D735.9080909@gmail.com> <4E121C1D.2040103@gmail.com>
	<CAHNn8BWcf4789EJ-zf3yJa8oYjPRjWjJMRz-Porf=1HuPAQj+g@mail.gmail.com>
	<4E12A5E7.7000202@gmail.com> <4E145620.5090200@gmail.com>
Message-ID: <CAOvn4qijTXUddvoEUykUYBm+iJhwkRQsNOucjzawN5BHk2LZaA@mail.gmail.com>

On 6 July 2011 13:33, Johann Cohen-Tanugi <johann.cohentanugi at gmail.com>wrote:

> class LSFLauncher(BatchSystemLauncher):
>     """A BatchSystemLauncher subclass for LSF."""
>
>     submit_command = List(['bsub >'], config=True,<....>
>

These args end up being passed to Popen, which will only handle shell-style
piping if called with shell=True. Looking at the code, I think you need to
override the .start() method. You can either send the file to the
subprocess' stdin yourself (see
http://docs.python.org/library/subprocess.html#replacing-shell-pipeline ),
or you can use Popen with shell=True (and pass the command as a string).

Hope that helps,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110706/ccd2bdf1/attachment.html>

From johann.cohentanugi at gmail.com  Wed Jul  6 09:32:49 2011
From: johann.cohentanugi at gmail.com (Johann Cohen-Tanugi)
Date: Wed, 06 Jul 2011 15:32:49 +0200
Subject: [IPython-dev] 0.11rc1 : problem with tutorial for PBS in
	http://ipython.org/ipython-doc/dev/parallel/parallel_process.html
In-Reply-To: <CAOvn4qijTXUddvoEUykUYBm+iJhwkRQsNOucjzawN5BHk2LZaA@mail.gmail.com>
References: <4E11D735.9080909@gmail.com> <4E121C1D.2040103@gmail.com>
	<CAHNn8BWcf4789EJ-zf3yJa8oYjPRjWjJMRz-Porf=1HuPAQj+g@mail.gmail.com>
	<4E12A5E7.7000202@gmail.com> <4E145620.5090200@gmail.com>
	<CAOvn4qijTXUddvoEUykUYBm+iJhwkRQsNOucjzawN5BHk2LZaA@mail.gmail.com>
Message-ID: <4E146401.9060304@gmail.com>



On 07/06/2011 03:16 PM, Thomas Kluyver wrote:
> On 6 July 2011 13:33, Johann Cohen-Tanugi 
> <johann.cohentanugi at gmail.com <mailto:johann.cohentanugi at gmail.com>> 
> wrote:
>
>     class LSFLauncher(BatchSystemLauncher):
>         """A BatchSystemLauncher subclass for LSF."""
>
>         submit_command = List(['bsub >'], config=True,<....>
>
first of all of course I meant "bsub <"
>
> These args end up being passed to Popen, which will only handle 
> shell-style piping if called with shell=True. Looking at the code, I 
> think you need to override the .start() method. You can either send 
> the file to the subprocess' stdin yourself (see 
> http://docs.python.org/library/subprocess.html#replacing-shell-pipeline ), 
> or you can use Popen with shell=True (and pass the command as a string).
>
I will have to digest that, but that is a start!
thanks!
Johann
> Hope that helps,
> Thomas
>
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110706/6fb57d75/attachment.html>

From johann.cohentanugi at gmail.com  Wed Jul  6 09:55:42 2011
From: johann.cohentanugi at gmail.com (Johann Cohen-Tanugi)
Date: Wed, 06 Jul 2011 15:55:42 +0200
Subject: [IPython-dev] 0.11rc1 : problem with tutorial for PBS in
	http://ipython.org/ipython-doc/dev/parallel/parallel_process.html
In-Reply-To: <4E146401.9060304@gmail.com>
References: <4E11D735.9080909@gmail.com> <4E121C1D.2040103@gmail.com>
	<CAHNn8BWcf4789EJ-zf3yJa8oYjPRjWjJMRz-Porf=1HuPAQj+g@mail.gmail.com>
	<4E12A5E7.7000202@gmail.com> <4E145620.5090200@gmail.com>
	<CAOvn4qijTXUddvoEUykUYBm+iJhwkRQsNOucjzawN5BHk2LZaA@mail.gmail.com>
	<4E146401.9060304@gmail.com>
Message-ID: <4E14695E.4020902@gmail.com>

hmmm isn't it :

     def find_args(self):
         return self.submit_command + [self.batch_file]

in BatchSystemLauncher that I need to overwrite?

Johann

On 07/06/2011 03:32 PM, Johann Cohen-Tanugi wrote:
>
>
> On 07/06/2011 03:16 PM, Thomas Kluyver wrote:
>> On 6 July 2011 13:33, Johann Cohen-Tanugi 
>> <johann.cohentanugi at gmail.com <mailto:johann.cohentanugi at gmail.com>> 
>> wrote:
>>
>>     class LSFLauncher(BatchSystemLauncher):
>>         """A BatchSystemLauncher subclass for LSF."""
>>
>>         submit_command = List(['bsub >'], config=True,<....>
>>
> first of all of course I meant "bsub <"
>>
>> These args end up being passed to Popen, which will only handle 
>> shell-style piping if called with shell=True. Looking at the code, I 
>> think you need to override the .start() method. You can either send 
>> the file to the subprocess' stdin yourself (see 
>> http://docs.python.org/library/subprocess.html#replacing-shell-pipeline 
>> ), or you can use Popen with shell=True (and pass the command as a 
>> string).
>>
> I will have to digest that, but that is a start!
> thanks!
> Johann
>> Hope that helps,
>> Thomas
>>
>> -- 
>> This message has been scanned for viruses and
>> dangerous content by *MailScanner* <http://www.mailscanner.info/>, 
>> and is
>> believed to be clean. 
>
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110706/301e9c1e/attachment.html>

From takowl at gmail.com  Wed Jul  6 10:34:38 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Wed, 6 Jul 2011 15:34:38 +0100
Subject: [IPython-dev] 0.11rc1 : problem with tutorial for PBS in
	http://ipython.org/ipython-doc/dev/parallel/parallel_process.html
In-Reply-To: <4E14695E.4020902@gmail.com>
References: <4E11D735.9080909@gmail.com> <4E121C1D.2040103@gmail.com>
	<CAHNn8BWcf4789EJ-zf3yJa8oYjPRjWjJMRz-Porf=1HuPAQj+g@mail.gmail.com>
	<4E12A5E7.7000202@gmail.com> <4E145620.5090200@gmail.com>
	<CAOvn4qijTXUddvoEUykUYBm+iJhwkRQsNOucjzawN5BHk2LZaA@mail.gmail.com>
	<4E146401.9060304@gmail.com> <4E14695E.4020902@gmail.com>
Message-ID: <CAOvn4qh0fshtsJh2rmcFeyh2rNA10YT+3ayQwMccA7uOf_6n3Q@mail.gmail.com>

On 6 July 2011 14:55, Johann Cohen-Tanugi <johann.cohentanugi at gmail.com>wrote:

> hmmm isn't it :
>
>     def find_args(self):
>         return self.submit_command + [self.batch_file]
>
> in BatchSystemLauncher that I need to overwrite?
>

find_args produces the list of args which are fed to Popen by
BatchSystemLauncher.start(). Replacing it won't fix this problem.

The line you need to look at is in the start method:

output = check_output(self.args, env=os.environ)

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

From epatters at enthought.com  Wed Jul  6 11:23:28 2011
From: epatters at enthought.com (Evan Patterson)
Date: Wed, 6 Jul 2011 10:23:28 -0500
Subject: [IPython-dev] Qt api selection re. ipython and matplotlib
In-Reply-To: <4E1419AD.4010003@hawaii.edu>
References: <CAHAreOoMSsD8UYCPHKT_RcESpCWAFuM0VcBWN3t+KR1MZ4ZGnQ@mail.gmail.com>
	<CAK6O52kGTchAcsxH6mt9GRxZ==yhxdX=f+8o3e+XZHujCi17=g@mail.gmail.com>
	<4E128BA4.8090308@hawaii.edu>
	<CAHNn8BWfZur_5f0Cm7NNfkg+jyAmvOXcfnD3Yj3yAOzea7XVdw@mail.gmail.com>
	<4E12AD93.4080901@hawaii.edu>
	<CAK6O52=EhM9_-h8nK-j2vHg_puF7kE=z_2JM0v58WeCsGh59HA@mail.gmail.com>
	<4E133FC3.1090108@hawaii.edu>
	<CAHNn8BV6M+6GSouOe48JtE6xhmsWBCgkZVNg_DBbZONdSS-o3w@mail.gmail.com>
	<CAK6O52m0R3ugOkV9gznHmGgMRXAF+yij3PWnisVS8N_98ti+6w@mail.gmail.com>
	<CAHNn8BU1Zh4Nu=-jgZCNMCEs4m_sZdYzB1e1C_LuNvO=Mdxh+A@mail.gmail.com>
	<4E1419AD.4010003@hawaii.edu>
Message-ID: <D4EEB2E1-C248-42A8-87F1-D7B1A98E438A@enthought.com>

[snip]

> Darren et al.,
> 
> Is all this good from your mpl/qt standpoint?  We could make mpl pay 
> attention to the ETS QT_API environment variable, if present, while 
> retaining the rcParam.  For example, QT_API could simply override the 
> rcParam, with the additional effect of forcing v2 in the PyQt4 case.  In 
> other words, if QT_API is defined, we would follow the original ETS 
> strategy; otherwise the rcParams strategy as in my last mpl pull 
> request.  I think that although this is a bit more complicated, and 
> would require one more iteration on the ipython side as well as on the 
> mpl side, it might last longer as a way to handle just about all 
> situations, including mpl mixed with ETS things.
> 
> Regarding PySide: I actually can't get it to work in interactive mode 
> (that is, display a plot) even from the straight python prompt; it is 
> working in interactive mode at present only in the ipython qtconsole. 
> As of April, PySide apparently did not use the input hook:
> 
> http://lists.pyside.org/pipermail/pyside/2011-April/002362.html
> 
> Google didn't turn up anything more recent.  So how is it that pylab 
> with PySide is working in qtconsole?
> 
> Eric

PySide works in the qtconsole because the ZMQ kernel actually starts the event loop, unlike the single process IPython shell. (It can do this, of course, because it does not need to prompt the user for any input.)

Evan

From benjaminrk at gmail.com  Wed Jul  6 11:34:53 2011
From: benjaminrk at gmail.com (MinRK)
Date: Wed, 6 Jul 2011 08:34:53 -0700
Subject: [IPython-dev] Qt api selection re. ipython and matplotlib
In-Reply-To: <D4EEB2E1-C248-42A8-87F1-D7B1A98E438A@enthought.com>
References: <CAHAreOoMSsD8UYCPHKT_RcESpCWAFuM0VcBWN3t+KR1MZ4ZGnQ@mail.gmail.com>
	<CAK6O52kGTchAcsxH6mt9GRxZ==yhxdX=f+8o3e+XZHujCi17=g@mail.gmail.com>
	<4E128BA4.8090308@hawaii.edu>
	<CAHNn8BWfZur_5f0Cm7NNfkg+jyAmvOXcfnD3Yj3yAOzea7XVdw@mail.gmail.com>
	<4E12AD93.4080901@hawaii.edu>
	<CAK6O52=EhM9_-h8nK-j2vHg_puF7kE=z_2JM0v58WeCsGh59HA@mail.gmail.com>
	<4E133FC3.1090108@hawaii.edu>
	<CAHNn8BV6M+6GSouOe48JtE6xhmsWBCgkZVNg_DBbZONdSS-o3w@mail.gmail.com>
	<CAK6O52m0R3ugOkV9gznHmGgMRXAF+yij3PWnisVS8N_98ti+6w@mail.gmail.com>
	<CAHNn8BU1Zh4Nu=-jgZCNMCEs4m_sZdYzB1e1C_LuNvO=Mdxh+A@mail.gmail.com>
	<4E1419AD.4010003@hawaii.edu>
	<D4EEB2E1-C248-42A8-87F1-D7B1A98E438A@enthought.com>
Message-ID: <CAHNn8BV+y-P1enkzWy_JkOa7gMn-Rhdixm7f+ueE1C5eioii=Q@mail.gmail.com>

I updated my IPython PR with my understanding of the recent discussion.

Now, QT_API will be asked *first*, and if QT_API=pyqt, IPython will
set the v2 APIs.

QT_API=pyqt : use pyqt with v2
QT_API=pyside : use pyside
QT_API unset : ask matplotlib for pyqt4 or pyside, will not set v2 APIs

The default, and most likely case remains PyQt4 without updating sip
apis, falling back on PySide.

-MinRK

On Wed, Jul 6, 2011 at 08:23, Evan Patterson <epatters at enthought.com> wrote:
> [snip]
>
>> Darren et al.,
>>
>> Is all this good from your mpl/qt standpoint? ?We could make mpl pay
>> attention to the ETS QT_API environment variable, if present, while
>> retaining the rcParam. ?For example, QT_API could simply override the
>> rcParam, with the additional effect of forcing v2 in the PyQt4 case. ?In
>> other words, if QT_API is defined, we would follow the original ETS
>> strategy; otherwise the rcParams strategy as in my last mpl pull
>> request. ?I think that although this is a bit more complicated, and
>> would require one more iteration on the ipython side as well as on the
>> mpl side, it might last longer as a way to handle just about all
>> situations, including mpl mixed with ETS things.
>>
>> Regarding PySide: I actually can't get it to work in interactive mode
>> (that is, display a plot) even from the straight python prompt; it is
>> working in interactive mode at present only in the ipython qtconsole.
>> As of April, PySide apparently did not use the input hook:
>>
>> http://lists.pyside.org/pipermail/pyside/2011-April/002362.html
>>
>> Google didn't turn up anything more recent. ?So how is it that pylab
>> with PySide is working in qtconsole?
>>
>> Eric
>
> PySide works in the qtconsole because the ZMQ kernel actually starts the event loop, unlike the single process IPython shell. (It can do this, of course, because it does not need to prompt the user for any input.)
>
> Evan
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>


From efiring at hawaii.edu  Wed Jul  6 16:23:33 2011
From: efiring at hawaii.edu (Eric Firing)
Date: Wed, 06 Jul 2011 10:23:33 -1000
Subject: [IPython-dev] Qt api selection re. ipython and matplotlib
In-Reply-To: <CAHNn8BV+y-P1enkzWy_JkOa7gMn-Rhdixm7f+ueE1C5eioii=Q@mail.gmail.com>
References: <CAHAreOoMSsD8UYCPHKT_RcESpCWAFuM0VcBWN3t+KR1MZ4ZGnQ@mail.gmail.com>
	<CAK6O52kGTchAcsxH6mt9GRxZ==yhxdX=f+8o3e+XZHujCi17=g@mail.gmail.com>
	<4E128BA4.8090308@hawaii.edu>
	<CAHNn8BWfZur_5f0Cm7NNfkg+jyAmvOXcfnD3Yj3yAOzea7XVdw@mail.gmail.com>
	<4E12AD93.4080901@hawaii.edu>
	<CAK6O52=EhM9_-h8nK-j2vHg_puF7kE=z_2JM0v58WeCsGh59HA@mail.gmail.com>
	<4E133FC3.1090108@hawaii.edu>
	<CAHNn8BV6M+6GSouOe48JtE6xhmsWBCgkZVNg_DBbZONdSS-o3w@mail.gmail.com>
	<CAK6O52m0R3ugOkV9gznHmGgMRXAF+yij3PWnisVS8N_98ti+6w@mail.gmail.com>
	<CAHNn8BU1Zh4Nu=-jgZCNMCEs4m_sZdYzB1e1C_LuNvO=Mdxh+A@mail.gmail.com>
	<4E1419AD.4010003@hawaii.edu>
	<D4EEB2E1-C248-42A8-87F1-D7B1A98E438A@enthought.com>
	<CAHNn8BV+y-P1enkzWy_JkOa7gMn-Rhdixm7f+ueE1C5eioii=Q@mail.gmail.com>
Message-ID: <4E14C445.7010602@hawaii.edu>

On 07/06/2011 05:34 AM, MinRK wrote:
> I updated my IPython PR with my understanding of the recent discussion.
>
> Now, QT_API will be asked *first*, and if QT_API=pyqt, IPython will
> set the v2 APIs.
>
> QT_API=pyqt : use pyqt with v2
> QT_API=pyside : use pyside
> QT_API unset : ask matplotlib for pyqt4 or pyside, will not set v2 APIs
>
> The default, and most likely case remains PyQt4 without updating sip
> apis, falling back on PySide.

I have updated my mpl PR in a compatible way; the only difference is 
that I have not included a fall-back to pyside.  Either PyQt4 or PySide 
is specified as an rcParam, and if whatever is specified (either 
explicitly there or via the QT_API env var) is not there, an ImportError 
will result.  Anyone who has only PySide will have to know about it and 
use the rcParam or QT_API to request it.

Eric

>
> -MinRK
>
> On Wed, Jul 6, 2011 at 08:23, Evan Patterson<epatters at enthought.com>  wrote:
>> [snip]
>>
>>> Darren et al.,
>>>
>>> Is all this good from your mpl/qt standpoint?  We could make mpl pay
>>> attention to the ETS QT_API environment variable, if present, while
>>> retaining the rcParam.  For example, QT_API could simply override the
>>> rcParam, with the additional effect of forcing v2 in the PyQt4 case.  In
>>> other words, if QT_API is defined, we would follow the original ETS
>>> strategy; otherwise the rcParams strategy as in my last mpl pull
>>> request.  I think that although this is a bit more complicated, and
>>> would require one more iteration on the ipython side as well as on the
>>> mpl side, it might last longer as a way to handle just about all
>>> situations, including mpl mixed with ETS things.
>>>
>>> Regarding PySide: I actually can't get it to work in interactive mode
>>> (that is, display a plot) even from the straight python prompt; it is
>>> working in interactive mode at present only in the ipython qtconsole.
>>> As of April, PySide apparently did not use the input hook:
>>>
>>> http://lists.pyside.org/pipermail/pyside/2011-April/002362.html
>>>
>>> Google didn't turn up anything more recent.  So how is it that pylab
>>> with PySide is working in qtconsole?
>>>
>>> Eric
>>
>> PySide works in the qtconsole because the ZMQ kernel actually starts the event loop, unlike the single process IPython shell. (It can do this, of course, because it does not need to prompt the user for any input.)
>>
>> Evan
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



From johann.cohentanugi at gmail.com  Thu Jul  7 06:43:13 2011
From: johann.cohentanugi at gmail.com (Johann Cohen-Tanugi)
Date: Thu, 07 Jul 2011 12:43:13 +0200
Subject: [IPython-dev] 0.11rc1 : problem with tutorial for PBS in
	http://ipython.org/ipython-doc/dev/parallel/parallel_process.html
In-Reply-To: <CAOvn4qh0fshtsJh2rmcFeyh2rNA10YT+3ayQwMccA7uOf_6n3Q@mail.gmail.com>
References: <4E11D735.9080909@gmail.com> <4E121C1D.2040103@gmail.com>
	<CAHNn8BWcf4789EJ-zf3yJa8oYjPRjWjJMRz-Porf=1HuPAQj+g@mail.gmail.com>
	<4E12A5E7.7000202@gmail.com> <4E145620.5090200@gmail.com>
	<CAOvn4qijTXUddvoEUykUYBm+iJhwkRQsNOucjzawN5BHk2LZaA@mail.gmail.com>
	<4E146401.9060304@gmail.com> <4E14695E.4020902@gmail.com>
	<CAOvn4qh0fshtsJh2rmcFeyh2rNA10YT+3ayQwMccA7uOf_6n3Q@mail.gmail.com>
Message-ID: <4E158DC1.9080505@gmail.com>

ok thanks a lot. I am attaching the LSF code I added to launcher.py. It 
seems to do what I expect on my LSF batch farm.
In order to pipe I follow Mathias' suggestion but the code could 
probably use expert's check. Especially I have python 2.6.5 so I 
modified the corresponding version of check_output at the top of 
launcher.py. Maybe my code does not work for python > 2.7 then?

Feel free to include it if it is deemed reasonable, or to make any 
modifications you guys see fit.
best,
Johann

On 07/06/2011 04:34 PM, Thomas Kluyver wrote:
> On 6 July 2011 14:55, Johann Cohen-Tanugi 
> <johann.cohentanugi at gmail.com <mailto:johann.cohentanugi at gmail.com>> 
> wrote:
>
>     hmmm isn't it :
>
>         def find_args(self):
>             return self.submit_command + [self.batch_file]
>
>     in BatchSystemLauncher that I need to overwrite?
>
>
> find_args produces the list of args which are fed to Popen by 
> BatchSystemLauncher.start(). Replacing it won't fix this problem.
>
> The line you need to look at is in the start method:
>
> output = check_output(self.args, env=os.environ)
>
> Thomas
>
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110707/d3d5ce39/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: launcher.py
Type: text/x-python
Size: 40744 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110707/d3d5ce39/attachment.py>

From dsdale24 at gmail.com  Thu Jul  7 10:00:46 2011
From: dsdale24 at gmail.com (Darren Dale)
Date: Thu, 7 Jul 2011 10:00:46 -0400
Subject: [IPython-dev] Argument parsing (was: Qt api selection re.
 ipython and matplotlib)
Message-ID: <CAK6O52=+cd5pcnXsDYSSeQ0WC5z7vHj0byjkqGX3xdgvtys8_Q@mail.gmail.com>

On Wed, Jul 6, 2011 at 2:19 AM, Brian Granger <ellisonbg at gmail.com> wrote:
> On Tue, Jul 5, 2011 at 11:06 PM, MinRK <benjaminrk at gmail.com> wrote:
>> On Jul 5, 2011, at 18:32, Darren Dale <dsdale24 at gmail.com> wrote:
>>> By the way, I find the new ipython's new argument parsing really
>>> non-intuitive. It took me 5 attempts to figure out how to do "ipython
>>> gui=qt", even after skimming the output of "ipython -h". What's wrong
>>> with "ipython --gui=qt"? Does ipython really need to put its own
>>> unique spin on argument parsing?
>>
>> The reason for Brian's design here is that now the command line args
>> are coupled with the config system. ?Specifying a value on the command
>> line is now identical to specifying it in a config file, so it looks
>> like a Python assignment (because it is). ?It also means that 100% of
>> IPython is configurable from the command-line.
>
> As Min mentions, the config system syntax *is* Python and we wanted to
> use a syntax that reflected that. ?When you do:
>
> Foo.bar=10
>
> At the command line, we parse that as Python code and run it through
> the traits machinery. ?Making this:
>
> --Foo.bar=10
>
> Only obscures the fact that it is parsed as Python.

That's a bit hyperbolic. I could then argue that "ipython profile
create" only makes it confusing to figure out what arguments should be
treated as options and what arguments should be treated as files.

> This approach
> also allows us to do things like the following at the command line:
>
> Foo.bar=[0,1,2]
>
> or even:
>
> Foo.bar=range(3)
>
> Which is then validated by traits as a list of ints. ?We do realize
> that there is going to be an adjustment period for users and we do
> need to continue to improve documentation to point out these important
> changes.

Could you please include some documentation on how I can invoke
ipython to run a script without a .py or .ipy extension? Lets say I
have a python script called "profile", this doesn't work:

ipython profile

Or, suppose I have a file named something pathological like foo=bar?
Python will run it without any problems. Even if I rename it
foo=bar.py, ipython appears to interpret it as an option, not a
filename.

Darren


From benjaminrk at gmail.com  Thu Jul  7 12:32:01 2011
From: benjaminrk at gmail.com (MinRK)
Date: Thu, 7 Jul 2011 09:32:01 -0700
Subject: [IPython-dev] Argument parsing (was: Qt api selection re.
 ipython and matplotlib)
In-Reply-To: <CAK6O52=+cd5pcnXsDYSSeQ0WC5z7vHj0byjkqGX3xdgvtys8_Q@mail.gmail.com>
References: <CAK6O52=+cd5pcnXsDYSSeQ0WC5z7vHj0byjkqGX3xdgvtys8_Q@mail.gmail.com>
Message-ID: <CAHNn8BXU0DXgNK_02KnNu5Rnm1_1=9=_AUVajC1oU5G0pwE-1w@mail.gmail.com>

On Thu, Jul 7, 2011 at 07:00, Darren Dale <dsdale24 at gmail.com> wrote:
> On Wed, Jul 6, 2011 at 2:19 AM, Brian Granger <ellisonbg at gmail.com> wrote:
>> On Tue, Jul 5, 2011 at 11:06 PM, MinRK <benjaminrk at gmail.com> wrote:
>>> On Jul 5, 2011, at 18:32, Darren Dale <dsdale24 at gmail.com> wrote:
>>>> By the way, I find the new ipython's new argument parsing really
>>>> non-intuitive. It took me 5 attempts to figure out how to do "ipython
>>>> gui=qt", even after skimming the output of "ipython -h". What's wrong
>>>> with "ipython --gui=qt"? Does ipython really need to put its own
>>>> unique spin on argument parsing?
>>>
>>> The reason for Brian's design here is that now the command line args
>>> are coupled with the config system. ?Specifying a value on the command
>>> line is now identical to specifying it in a config file, so it looks
>>> like a Python assignment (because it is). ?It also means that 100% of
>>> IPython is configurable from the command-line.
>>
>> As Min mentions, the config system syntax *is* Python and we wanted to
>> use a syntax that reflected that. ?When you do:
>>
>> Foo.bar=10
>>
>> At the command line, we parse that as Python code and run it through
>> the traits machinery. ?Making this:
>>
>> --Foo.bar=10
>>
>> Only obscures the fact that it is parsed as Python.
>
> That's a bit hyperbolic. I could then argue that "ipython profile
> create" only makes it confusing to figure out what arguments should be
> treated as options and what arguments should be treated as files.
>
>> This approach
>> also allows us to do things like the following at the command line:
>>
>> Foo.bar=[0,1,2]
>>
>> or even:
>>
>> Foo.bar=range(3)
>>
>> Which is then validated by traits as a list of ints. ?We do realize
>> that there is going to be an adjustment period for users and we do
>> need to continue to improve documentation to point out these important
>> changes.
>
> Could you please include some documentation on how I can invoke
> ipython to run a script without a .py or .ipy extension? Lets say I
> have a python script called "profile", this doesn't work:
>
> ipython profile
>
> Or, suppose I have a file named something pathological like foo=bar?
> Python will run it without any problems. Even if I rename it
> foo=bar.py, ipython appears to interpret it as an option, not a
> filename.

You can always give more path information, so `ipython ./profile` or
`ipython ./foo=bar` will work*.  Python has the exact same
vulnerability to pathological filenames matching their argument
patterns, like files called '-foo' or '-zebulon'. Obviously, given our
more flexible syntax, our cases cast a wider net.

*I just noticed that IPython artificially requires '.py', which I
can't find any justification for, so I removed it.  These commands do
work in master.

-MinRK

>
> Darren
>


From jtaylor.debian at googlemail.com  Thu Jul  7 12:47:39 2011
From: jtaylor.debian at googlemail.com (Julian Taylor)
Date: Thu, 07 Jul 2011 18:47:39 +0200
Subject: [IPython-dev] Argument parsing (was: Qt api selection re.
 ipython and matplotlib)
In-Reply-To: <CAK6O52=+cd5pcnXsDYSSeQ0WC5z7vHj0byjkqGX3xdgvtys8_Q@mail.gmail.com>
References: <CAK6O52=+cd5pcnXsDYSSeQ0WC5z7vHj0byjkqGX3xdgvtys8_Q@mail.gmail.com>
Message-ID: <4E15E32B.10406@googlemail.com>

On 07/07/2011 04:00 PM, Darren Dale wrote:
> On Wed, Jul 6, 2011 at 2:19 AM, Brian Granger <ellisonbg at gmail.com> wrote:
>> On Tue, Jul 5, 2011 at 11:06 PM, MinRK <benjaminrk at gmail.com> wrote:
>>> On Jul 5, 2011, at 18:32, Darren Dale <dsdale24 at gmail.com> wrote:
>>>> By the way, I find the new ipython's new argument parsing really
>>>> non-intuitive. It took me 5 attempts to figure out how to do "ipython
>>>> gui=qt", even after skimming the output of "ipython -h". What's wrong
>>>> with "ipython --gui=qt"? Does ipython really need to put its own
>>>> unique spin on argument parsing?
>>>
>>> The reason for Brian's design here is that now the command line args
>>> are coupled with the config system.  Specifying a value on the command
>>> line is now identical to specifying it in a config file, so it looks
>>> like a Python assignment (because it is).  It also means that 100% of
>>> IPython is configurable from the command-line.
>>
>> As Min mentions, the config system syntax *is* Python and we wanted to
>> use a syntax that reflected that.  When you do:
>>
>> Foo.bar=10
>>
>> At the command line, we parse that as Python code and run it through
>> the traits machinery.  Making this:
>>
>> --Foo.bar=10
>>
>> Only obscures the fact that it is parsed as Python.
> 
> That's a bit hyperbolic. I could then argue that "ipython profile
> create" only makes it confusing to figure out what arguments should be
> treated as options and what arguments should be treated as files.
> 
>> This approach
>> also allows us to do things like the following at the command line:
>>
>> Foo.bar=[0,1,2]
>>
>> or even:
>>
>> Foo.bar=range(3)
>>
>> Which is then validated by traits as a list of ints.  We do realize
>> that there is going to be an adjustment period for users and we do
>> need to continue to improve documentation to point out these important
>> changes.
> 
> Could you please include some documentation on how I can invoke
> ipython to run a script without a .py or .ipy extension? Lets say I
> have a python script called "profile", this doesn't work:
> 
> ipython profile
> 
> Or, suppose I have a file named something pathological like foo=bar?
> Python will run it without any problems. Even if I rename it
> foo=bar.py, ipython appears to interpret it as an option, not a
> filename.
> 
> Darren


0.11rc1 breaks some scripts using sys.argv:
$ cat /tmp/tmp.py
import sys
print sys.argv

$ python /tmp/tmp.py
['/tmp/tmp.py']
$ ipython0.10 /tmp/tmp.py
['/tmp/tmp.py']
$ ipython0.11 /tmp/tmp.py
['/home/jtaylor/chroots/python/bin/ipython', '/tmp/tmp.py']

also the -c and -i flag do not work any more. I assume there is some
replacement somewhere but having to dig through pages and pages of docs
just to find commonly used interpreter flags quite annoying.

Best Regards,
Julian Taylor

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110707/41da7dc1/attachment.sig>

From robert.kern at gmail.com  Thu Jul  7 12:55:20 2011
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 07 Jul 2011 11:55:20 -0500
Subject: [IPython-dev] Argument parsing (was: Qt api selection re.
	ipython and matplotlib)
In-Reply-To: <CAHNn8BXU0DXgNK_02KnNu5Rnm1_1=9=_AUVajC1oU5G0pwE-1w@mail.gmail.com>
References: <CAK6O52=+cd5pcnXsDYSSeQ0WC5z7vHj0byjkqGX3xdgvtys8_Q@mail.gmail.com>
	<CAHNn8BXU0DXgNK_02KnNu5Rnm1_1=9=_AUVajC1oU5G0pwE-1w@mail.gmail.com>
Message-ID: <iv4odo$2e9$1@dough.gmane.org>

On 7/7/11 11:32 AM, MinRK wrote:
> On Thu, Jul 7, 2011 at 07:00, Darren Dale<dsdale24 at gmail.com>  wrote:

>> Or, suppose I have a file named something pathological like foo=bar?
>> Python will run it without any problems. Even if I rename it
>> foo=bar.py, ipython appears to interpret it as an option, not a
>> filename.
>
> You can always give more path information, so `ipython ./profile` or
> `ipython ./foo=bar` will work*.  Python has the exact same
> vulnerability to pathological filenames matching their argument
> patterns, like files called '-foo' or '-zebulon'. Obviously, given our
> more flexible syntax, our cases cast a wider net.

Well, with argparse, you can use the standardized "--" marker to indicate that 
everything following is an argument, not an option. E.g.

   $ ipython -pylab -- -foo.py

-- 
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 jtaylor.debian at googlemail.com  Thu Jul  7 19:05:26 2011
From: jtaylor.debian at googlemail.com (Julian Taylor)
Date: Fri, 08 Jul 2011 01:05:26 +0200
Subject: [IPython-dev] experimental ipython 0.11rc1 debian/ubuntu package
Message-ID: <4E163BB6.2070407@googlemail.com>

Hi,
I have just uploaded the first revision of the ipython 0.11rc1 debian
package to my ppa:
https://launchpad.net/~jtaylor/+archive/ipython-dev
It is based on the 0.11rc1 snapshot from github with a few patches to
fix the testsuite (from git) and better debian integration.

To install after typing following into a terminal:
sudo apt-add-repository ppa:jtaylor/ipython-dev
sudo apt-get update
The ppa also contains newer versions of zeromq mirrored from debian so
you should have the full functionality of ipython available.

Currently it is only available for ubuntu 11.04 natty but it should also
run in oneiric 11.10 and debian testing but you may need to rebuild it [0].
I plan on doing an upload to debian experimental in the near future.

The packaging has changed quite a bit. The main difference is the
splitting into four sub package to reduce the install size and necessary
dependencies:
ipython - the shell
ipython-qtconsole - the new qtconsole
ipython-parallel - parallel processing code
ipython-doc - documentation

I would be grateful if you could test the packages and report any
problems or possible enhancements.
To report bugs either write me an email or use the launchpad or debian
bug trackers, but please indicate which version and which os you are using.

known issues:
 - ipythonX.Y qtconsole does not work
 - some missing and outdated manpages (patches welcome)
 - most reverse dependencies with embedded shells are broken [1]
   *if you rely on them work, do not install this package!*
   I'd appreciate any patches getting these to work again.
 - no desktop integration for qtconsole (including no unity launcher icon)
 - parallel testsuite fails randomly, probably some memory corruption

future plans:
ipython 0.11 will probably not make it into the next ubuntu version
11.10 but I plan on getting it into 12.04 and debian wheezy.
I'm not really sure how to transition from 0.10 yet, due to the very
large api breakage.
The current packaging does not allow parallel installation with 0.10.
Probably the package will be renamed to ipython0.11 and conflict with
all that is broken.

[0]
To build the package yourself, which might be necessary to use it in
debian or older ubuntu version, do the following:
sudo apt-get install devscripts equivs
dget -ux
https://launchpad.net/~jtaylor/+archive/ipython-dev/+files/ipython_0.11~rc1-0%2Bppa1~exp2.dsc
cd ipython-0.11~rc1/
sudo mk-build-dep -i -r
debuild -us -uc
ls -ltr ../*deb
# install the deb's e.g. with gdebi

to remove the build-deps again: sudo apt-get autoremove ipython-build-deps

[1] accerciser, exaile, griffith, mayavi2, pyqonsole, python-matplotlib,
 python-netaddr, python-nipype, python-polybori, python-pudb,
python-pylons, python-scrapy, python-sugar-0.88, python-sugar-0.90,
python-sympy, python-tg.devtools, python-werkzeug, rabbitvcs-core,
science-numericalcomputation, snimpy

Best Regards,
Julian Taylor - debian/ubuntu ipython maintainer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110708/c97fccef/attachment.sig>

From benjaminrk at gmail.com  Thu Jul  7 19:41:44 2011
From: benjaminrk at gmail.com (MinRK)
Date: Thu, 7 Jul 2011 16:41:44 -0700
Subject: [IPython-dev] Argument parsing (was: Qt api selection re.
 ipython and matplotlib)
In-Reply-To: <iv4odo$2e9$1@dough.gmane.org>
References: <CAK6O52=+cd5pcnXsDYSSeQ0WC5z7vHj0byjkqGX3xdgvtys8_Q@mail.gmail.com>
	<CAHNn8BXU0DXgNK_02KnNu5Rnm1_1=9=_AUVajC1oU5G0pwE-1w@mail.gmail.com>
	<iv4odo$2e9$1@dough.gmane.org>
Message-ID: <CAHNn8BV2gD8dx=eKVS8KaHt6nX_KTJ4SH69TK2O22fJyfCmC8g@mail.gmail.com>

We have relaxed the syntax in 0.11, so you can do the more familiar
'--gui=qt' pattern, and 'ipython -i foo.py' should work as expected.
The 'gui=qt' way will still work in 0.11, only because 0.11.rc1 got
into EPD, but I think we will remove it in 0.12.  I also added support
for '--' to halt parsing, as Robert described.

Since we aren't doing unusual things for the simple cases, I opened an
issue to replace the existing machinery for everything short of fully
specified Class.trait=value with argparse, and only using our extra
code for that single case, since it just makes more sense. I don't
believe this will happen in 0.11.

@Julian '-i' should work fine now (its alias was --i, since we used to
require two leading '-' for flags, as described in the help output).
We don't (and won't) support 'ipython -c "stuff"' until we go back to
using argparse. Its alias is 'c' (used as 'c=stuff' or, with current
master, '--c=stuff'), as described in the help output, until then.  I
also believe I fixed the inherited-argv bug for scripts that you
described.

-MinRK

On Thu, Jul 7, 2011 at 09:55, Robert Kern <robert.kern at gmail.com> wrote:
> On 7/7/11 11:32 AM, MinRK wrote:
>> On Thu, Jul 7, 2011 at 07:00, Darren Dale<dsdale24 at gmail.com> ?wrote:
>
>>> Or, suppose I have a file named something pathological like foo=bar?
>>> Python will run it without any problems. Even if I rename it
>>> foo=bar.py, ipython appears to interpret it as an option, not a
>>> filename.
>>
>> You can always give more path information, so `ipython ./profile` or
>> `ipython ./foo=bar` will work*. ?Python has the exact same
>> vulnerability to pathological filenames matching their argument
>> patterns, like files called '-foo' or '-zebulon'. Obviously, given our
>> more flexible syntax, our cases cast a wider net.
>
> Well, with argparse, you can use the standardized "--" marker to indicate that
> everything following is an argument, not an option. E.g.
>
> ? $ ipython -pylab -- -foo.py
>
> --
> 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
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>


From ischnell at enthought.com  Thu Jul  7 23:42:04 2011
From: ischnell at enthought.com (Ilan Schnell)
Date: Thu, 7 Jul 2011 22:42:04 -0500
Subject: [IPython-dev] Argument parsing (was: Qt api selection re.
 ipython and matplotlib)
In-Reply-To: <CAHNn8BV2gD8dx=eKVS8KaHt6nX_KTJ4SH69TK2O22fJyfCmC8g@mail.gmail.com>
References: <CAK6O52=+cd5pcnXsDYSSeQ0WC5z7vHj0byjkqGX3xdgvtys8_Q@mail.gmail.com>
	<CAHNn8BXU0DXgNK_02KnNu5Rnm1_1=9=_AUVajC1oU5G0pwE-1w@mail.gmail.com>
	<iv4odo$2e9$1@dough.gmane.org>
	<CAHNn8BV2gD8dx=eKVS8KaHt6nX_KTJ4SH69TK2O22fJyfCmC8g@mail.gmail.com>
Message-ID: <CAAUn5qJxoq_ZbW7yzcQ-CTYC1sQr3n7ePzkVMWnNFBVXCxoGFw@mail.gmail.com>

> only because 0.11.rc1 got into EPD

I hope this is not the only reason.  We will probably do an EPD
bug fix release in a few weeks, in which I'm planing to update
to 0.11 final.

- Ilan


On Thu, Jul 7, 2011 at 6:41 PM, MinRK <benjaminrk at gmail.com> wrote:
> We have relaxed the syntax in 0.11, so you can do the more familiar
> '--gui=qt' pattern, and 'ipython -i foo.py' should work as expected.
> The 'gui=qt' way will still work in 0.11, only because 0.11.rc1 got
> into EPD, but I think we will remove it in 0.12. ?I also added support
> for '--' to halt parsing, as Robert described.
>
> Since we aren't doing unusual things for the simple cases, I opened an
> issue to replace the existing machinery for everything short of fully
> specified Class.trait=value with argparse, and only using our extra
> code for that single case, since it just makes more sense. I don't
> believe this will happen in 0.11.
>
> @Julian '-i' should work fine now (its alias was --i, since we used to
> require two leading '-' for flags, as described in the help output).
> We don't (and won't) support 'ipython -c "stuff"' until we go back to
> using argparse. Its alias is 'c' (used as 'c=stuff' or, with current
> master, '--c=stuff'), as described in the help output, until then. ?I
> also believe I fixed the inherited-argv bug for scripts that you
> described.
>
> -MinRK
>
> On Thu, Jul 7, 2011 at 09:55, Robert Kern <robert.kern at gmail.com> wrote:
>> On 7/7/11 11:32 AM, MinRK wrote:
>>> On Thu, Jul 7, 2011 at 07:00, Darren Dale<dsdale24 at gmail.com> ?wrote:
>>
>>>> Or, suppose I have a file named something pathological like foo=bar?
>>>> Python will run it without any problems. Even if I rename it
>>>> foo=bar.py, ipython appears to interpret it as an option, not a
>>>> filename.
>>>
>>> You can always give more path information, so `ipython ./profile` or
>>> `ipython ./foo=bar` will work*. ?Python has the exact same
>>> vulnerability to pathological filenames matching their argument
>>> patterns, like files called '-foo' or '-zebulon'. Obviously, given our
>>> more flexible syntax, our cases cast a wider net.
>>
>> Well, with argparse, you can use the standardized "--" marker to indicate that
>> everything following is an argument, not an option. E.g.
>>
>> ? $ ipython -pylab -- -foo.py
>>
>> --
>> 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
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>


From benjaminrk at gmail.com  Fri Jul  8 01:32:48 2011
From: benjaminrk at gmail.com (MinRK)
Date: Thu, 7 Jul 2011 22:32:48 -0700
Subject: [IPython-dev] Argument parsing (was: Qt api selection re.
 ipython and matplotlib)
In-Reply-To: <CAAUn5qJxoq_ZbW7yzcQ-CTYC1sQr3n7ePzkVMWnNFBVXCxoGFw@mail.gmail.com>
References: <CAK6O52=+cd5pcnXsDYSSeQ0WC5z7vHj0byjkqGX3xdgvtys8_Q@mail.gmail.com>
	<CAHNn8BXU0DXgNK_02KnNu5Rnm1_1=9=_AUVajC1oU5G0pwE-1w@mail.gmail.com>
	<iv4odo$2e9$1@dough.gmane.org>
	<CAHNn8BV2gD8dx=eKVS8KaHt6nX_KTJ4SH69TK2O22fJyfCmC8g@mail.gmail.com>
	<CAAUn5qJxoq_ZbW7yzcQ-CTYC1sQr3n7ePzkVMWnNFBVXCxoGFw@mail.gmail.com>
Message-ID: <CAHNn8BUwGrxdFY18DpDn+0vrH1N2fBGt8Mn1KO2kkoTOOUQZdA@mail.gmail.com>

On Thu, Jul 7, 2011 at 20:42, Ilan Schnell <ischnell at enthought.com> wrote:
>> only because 0.11.rc1 got into EPD
>
> I hope this is not the only reason. ?We will probably do an EPD
> bug fix release in a few weeks, in which I'm planing to update
> to 0.11 final.

That helps a lot, thanks for reminding us, Ilan.  Now that I read
that, I'm pretty sure you told us this earlier, but my brain is pretty
fried right now.  This takes some pressure off, and we can make sure
we get it right, without worrying about 6 months of EPD users having
an IPython that doesn't match those before or after.

We will favor natural argparse-style arguments, even if we don't
finish migrating to argparse itself, and the vociferously opposed
'foo=value' without leading hyphens will likely be removed. master is
currently in a temporary state that supports both.

-MinRK

>
> - Ilan
>
>
> On Thu, Jul 7, 2011 at 6:41 PM, MinRK <benjaminrk at gmail.com> wrote:
>> We have relaxed the syntax in 0.11, so you can do the more familiar
>> '--gui=qt' pattern, and 'ipython -i foo.py' should work as expected.
>> The 'gui=qt' way will still work in 0.11, only because 0.11.rc1 got
>> into EPD, but I think we will remove it in 0.12. ?I also added support
>> for '--' to halt parsing, as Robert described.
>>
>> Since we aren't doing unusual things for the simple cases, I opened an
>> issue to replace the existing machinery for everything short of fully
>> specified Class.trait=value with argparse, and only using our extra
>> code for that single case, since it just makes more sense. I don't
>> believe this will happen in 0.11.
>>
>> @Julian '-i' should work fine now (its alias was --i, since we used to
>> require two leading '-' for flags, as described in the help output).
>> We don't (and won't) support 'ipython -c "stuff"' until we go back to
>> using argparse. Its alias is 'c' (used as 'c=stuff' or, with current
>> master, '--c=stuff'), as described in the help output, until then. ?I
>> also believe I fixed the inherited-argv bug for scripts that you
>> described.
>>
>> -MinRK
>>
>> On Thu, Jul 7, 2011 at 09:55, Robert Kern <robert.kern at gmail.com> wrote:
>>> On 7/7/11 11:32 AM, MinRK wrote:
>>>> On Thu, Jul 7, 2011 at 07:00, Darren Dale<dsdale24 at gmail.com> ?wrote:
>>>
>>>>> Or, suppose I have a file named something pathological like foo=bar?
>>>>> Python will run it without any problems. Even if I rename it
>>>>> foo=bar.py, ipython appears to interpret it as an option, not a
>>>>> filename.
>>>>
>>>> You can always give more path information, so `ipython ./profile` or
>>>> `ipython ./foo=bar` will work*. ?Python has the exact same
>>>> vulnerability to pathological filenames matching their argument
>>>> patterns, like files called '-foo' or '-zebulon'. Obviously, given our
>>>> more flexible syntax, our cases cast a wider net.
>>>
>>> Well, with argparse, you can use the standardized "--" marker to indicate that
>>> everything following is an argument, not an option. E.g.
>>>
>>> ? $ ipython -pylab -- -foo.py
>>>
>>> --
>>> 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
>>>
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>


From ischnell at enthought.com  Fri Jul  8 01:37:26 2011
From: ischnell at enthought.com (Ilan Schnell)
Date: Fri, 8 Jul 2011 00:37:26 -0500
Subject: [IPython-dev] ANN: EPD 7.1 released
Message-ID: <CAAUn5qKuKApKWbCLtr8ECvby-q=1hng9atwsEhnruKcPUwBy3A@mail.gmail.com>

Hello,

I am pleased to announce that EPD (Enthought Python Distribution)
version 7.1 has been released.  The most significant change is the
addition of an "EPD Free" version, which has its own very liberal
license, and can be downloaded and used free of any charge by
anyone (not only academics).  "EPD Free" includes a subset of the
packages included in the full EPD.  The highlights of this subset are:
numpy, scipy, matplotlib, traits and chaco.  To see which libraries
are included in the free vs. full version, please see:

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

In addition we have opened our PyPI build mirror for everyone.
This means that one can type "enpkg xyz" for 10,000+ packages.
However, there are still benefits to becoming an EPD subscriber.

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

Apart from the addition of "EPD Free", this release includes updates
to over 30 packages, including numpy, scipy, ipython and ETS.
We have also added PySide, Qt and MDP to this release.  Please find the
complete list of additions, updates and bug fixes 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, and many other tools.

EPD is currently available as a single-click installer for Windows XP,
Vista and 7, MacOSX (10.5 and 10.6), RedHat 3, 4 and 5, 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 ischnell at enthought.com  Fri Jul  8 01:43:17 2011
From: ischnell at enthought.com (Ilan Schnell)
Date: Fri, 8 Jul 2011 00:43:17 -0500
Subject: [IPython-dev] Argument parsing (was: Qt api selection re.
 ipython and matplotlib)
In-Reply-To: <CAHNn8BUwGrxdFY18DpDn+0vrH1N2fBGt8Mn1KO2kkoTOOUQZdA@mail.gmail.com>
References: <CAK6O52=+cd5pcnXsDYSSeQ0WC5z7vHj0byjkqGX3xdgvtys8_Q@mail.gmail.com>
	<CAHNn8BXU0DXgNK_02KnNu5Rnm1_1=9=_AUVajC1oU5G0pwE-1w@mail.gmail.com>
	<iv4odo$2e9$1@dough.gmane.org>
	<CAHNn8BV2gD8dx=eKVS8KaHt6nX_KTJ4SH69TK2O22fJyfCmC8g@mail.gmail.com>
	<CAAUn5qJxoq_ZbW7yzcQ-CTYC1sQr3n7ePzkVMWnNFBVXCxoGFw@mail.gmail.com>
	<CAHNn8BUwGrxdFY18DpDn+0vrH1N2fBGt8Mn1KO2kkoTOOUQZdA@mail.gmail.com>
Message-ID: <CAAUn5qJkcBh2+kQTExZtsx8WCTDXZoozhzocg4fq4mjVwY999A@mail.gmail.com>

That's good to hear, I don't want to be the one responsible
for keeping 'pylab=inline' around :-)

- Ilan


On Fri, Jul 8, 2011 at 12:32 AM, MinRK <benjaminrk at gmail.com> wrote:
> On Thu, Jul 7, 2011 at 20:42, Ilan Schnell <ischnell at enthought.com> wrote:
>>> only because 0.11.rc1 got into EPD
>>
>> I hope this is not the only reason. ?We will probably do an EPD
>> bug fix release in a few weeks, in which I'm planing to update
>> to 0.11 final.
>
> That helps a lot, thanks for reminding us, Ilan. ?Now that I read
> that, I'm pretty sure you told us this earlier, but my brain is pretty
> fried right now. ?This takes some pressure off, and we can make sure
> we get it right, without worrying about 6 months of EPD users having
> an IPython that doesn't match those before or after.
>
> We will favor natural argparse-style arguments, even if we don't
> finish migrating to argparse itself, and the vociferously opposed
> 'foo=value' without leading hyphens will likely be removed. master is
> currently in a temporary state that supports both.
>
> -MinRK
>
>>
>> - Ilan
>>
>>
>> On Thu, Jul 7, 2011 at 6:41 PM, MinRK <benjaminrk at gmail.com> wrote:
>>> We have relaxed the syntax in 0.11, so you can do the more familiar
>>> '--gui=qt' pattern, and 'ipython -i foo.py' should work as expected.
>>> The 'gui=qt' way will still work in 0.11, only because 0.11.rc1 got
>>> into EPD, but I think we will remove it in 0.12. ?I also added support
>>> for '--' to halt parsing, as Robert described.
>>>
>>> Since we aren't doing unusual things for the simple cases, I opened an
>>> issue to replace the existing machinery for everything short of fully
>>> specified Class.trait=value with argparse, and only using our extra
>>> code for that single case, since it just makes more sense. I don't
>>> believe this will happen in 0.11.
>>>
>>> @Julian '-i' should work fine now (its alias was --i, since we used to
>>> require two leading '-' for flags, as described in the help output).
>>> We don't (and won't) support 'ipython -c "stuff"' until we go back to
>>> using argparse. Its alias is 'c' (used as 'c=stuff' or, with current
>>> master, '--c=stuff'), as described in the help output, until then. ?I
>>> also believe I fixed the inherited-argv bug for scripts that you
>>> described.
>>>
>>> -MinRK
>>>
>>> On Thu, Jul 7, 2011 at 09:55, Robert Kern <robert.kern at gmail.com> wrote:
>>>> On 7/7/11 11:32 AM, MinRK wrote:
>>>>> On Thu, Jul 7, 2011 at 07:00, Darren Dale<dsdale24 at gmail.com> ?wrote:
>>>>
>>>>>> Or, suppose I have a file named something pathological like foo=bar?
>>>>>> Python will run it without any problems. Even if I rename it
>>>>>> foo=bar.py, ipython appears to interpret it as an option, not a
>>>>>> filename.
>>>>>
>>>>> You can always give more path information, so `ipython ./profile` or
>>>>> `ipython ./foo=bar` will work*. ?Python has the exact same
>>>>> vulnerability to pathological filenames matching their argument
>>>>> patterns, like files called '-foo' or '-zebulon'. Obviously, given our
>>>>> more flexible syntax, our cases cast a wider net.
>>>>
>>>> Well, with argparse, you can use the standardized "--" marker to indicate that
>>>> everything following is an argument, not an option. E.g.
>>>>
>>>> ? $ ipython -pylab -- -foo.py
>>>>
>>>> --
>>>> 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
>>>>
>>>> _______________________________________________
>>>> IPython-dev mailing list
>>>> IPython-dev at scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>
>>
>


From benjaminrk at gmail.com  Fri Jul  8 01:48:54 2011
From: benjaminrk at gmail.com (MinRK)
Date: Thu, 7 Jul 2011 22:48:54 -0700
Subject: [IPython-dev] Argument parsing (was: Qt api selection re.
 ipython and matplotlib)
In-Reply-To: <CAAUn5qJkcBh2+kQTExZtsx8WCTDXZoozhzocg4fq4mjVwY999A@mail.gmail.com>
References: <CAK6O52=+cd5pcnXsDYSSeQ0WC5z7vHj0byjkqGX3xdgvtys8_Q@mail.gmail.com>
	<CAHNn8BXU0DXgNK_02KnNu5Rnm1_1=9=_AUVajC1oU5G0pwE-1w@mail.gmail.com>
	<iv4odo$2e9$1@dough.gmane.org>
	<CAHNn8BV2gD8dx=eKVS8KaHt6nX_KTJ4SH69TK2O22fJyfCmC8g@mail.gmail.com>
	<CAAUn5qJxoq_ZbW7yzcQ-CTYC1sQr3n7ePzkVMWnNFBVXCxoGFw@mail.gmail.com>
	<CAHNn8BUwGrxdFY18DpDn+0vrH1N2fBGt8Mn1KO2kkoTOOUQZdA@mail.gmail.com>
	<CAAUn5qJkcBh2+kQTExZtsx8WCTDXZoozhzocg4fq4mjVwY999A@mail.gmail.com>
Message-ID: <CAHNn8BWJ2QxXujKfKUuyi7rmeTOU_qpdC6o9L1w8xQ6thO8apg@mail.gmail.com>

On Thu, Jul 7, 2011 at 22:43, Ilan Schnell <ischnell at enthought.com> wrote:
> That's good to hear, I don't want to be the one responsible
> for keeping 'pylab=inline' around :-)

It wouldn't be your fault, it would be mine for telling you rc1 was
safe, which we have clearly learned it wasn't.

Thanks,
-MinRK

>
> - Ilan
>
>
> On Fri, Jul 8, 2011 at 12:32 AM, MinRK <benjaminrk at gmail.com> wrote:
>> On Thu, Jul 7, 2011 at 20:42, Ilan Schnell <ischnell at enthought.com> wrote:
>>>> only because 0.11.rc1 got into EPD
>>>
>>> I hope this is not the only reason. ?We will probably do an EPD
>>> bug fix release in a few weeks, in which I'm planing to update
>>> to 0.11 final.
>>
>> That helps a lot, thanks for reminding us, Ilan. ?Now that I read
>> that, I'm pretty sure you told us this earlier, but my brain is pretty
>> fried right now. ?This takes some pressure off, and we can make sure
>> we get it right, without worrying about 6 months of EPD users having
>> an IPython that doesn't match those before or after.
>>
>> We will favor natural argparse-style arguments, even if we don't
>> finish migrating to argparse itself, and the vociferously opposed
>> 'foo=value' without leading hyphens will likely be removed. master is
>> currently in a temporary state that supports both.
>>
>> -MinRK
>>
>>>
>>> - Ilan
>>>
>>>
>>> On Thu, Jul 7, 2011 at 6:41 PM, MinRK <benjaminrk at gmail.com> wrote:
>>>> We have relaxed the syntax in 0.11, so you can do the more familiar
>>>> '--gui=qt' pattern, and 'ipython -i foo.py' should work as expected.
>>>> The 'gui=qt' way will still work in 0.11, only because 0.11.rc1 got
>>>> into EPD, but I think we will remove it in 0.12. ?I also added support
>>>> for '--' to halt parsing, as Robert described.
>>>>
>>>> Since we aren't doing unusual things for the simple cases, I opened an
>>>> issue to replace the existing machinery for everything short of fully
>>>> specified Class.trait=value with argparse, and only using our extra
>>>> code for that single case, since it just makes more sense. I don't
>>>> believe this will happen in 0.11.
>>>>
>>>> @Julian '-i' should work fine now (its alias was --i, since we used to
>>>> require two leading '-' for flags, as described in the help output).
>>>> We don't (and won't) support 'ipython -c "stuff"' until we go back to
>>>> using argparse. Its alias is 'c' (used as 'c=stuff' or, with current
>>>> master, '--c=stuff'), as described in the help output, until then. ?I
>>>> also believe I fixed the inherited-argv bug for scripts that you
>>>> described.
>>>>
>>>> -MinRK
>>>>
>>>> On Thu, Jul 7, 2011 at 09:55, Robert Kern <robert.kern at gmail.com> wrote:
>>>>> On 7/7/11 11:32 AM, MinRK wrote:
>>>>>> On Thu, Jul 7, 2011 at 07:00, Darren Dale<dsdale24 at gmail.com> ?wrote:
>>>>>
>>>>>>> Or, suppose I have a file named something pathological like foo=bar?
>>>>>>> Python will run it without any problems. Even if I rename it
>>>>>>> foo=bar.py, ipython appears to interpret it as an option, not a
>>>>>>> filename.
>>>>>>
>>>>>> You can always give more path information, so `ipython ./profile` or
>>>>>> `ipython ./foo=bar` will work*. ?Python has the exact same
>>>>>> vulnerability to pathological filenames matching their argument
>>>>>> patterns, like files called '-foo' or '-zebulon'. Obviously, given our
>>>>>> more flexible syntax, our cases cast a wider net.
>>>>>
>>>>> Well, with argparse, you can use the standardized "--" marker to indicate that
>>>>> everything following is an argument, not an option. E.g.
>>>>>
>>>>> ? $ ipython -pylab -- -foo.py
>>>>>
>>>>> --
>>>>> 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
>>>>>
>>>>> _______________________________________________
>>>>> IPython-dev mailing list
>>>>> IPython-dev at scipy.org
>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>>
>>>> _______________________________________________
>>>> IPython-dev mailing list
>>>> IPython-dev at scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>
>>>
>>
>


From ischnell at enthought.com  Fri Jul  8 01:53:39 2011
From: ischnell at enthought.com (Ilan Schnell)
Date: Fri, 8 Jul 2011 00:53:39 -0500
Subject: [IPython-dev] Argument parsing (was: Qt api selection re.
 ipython and matplotlib)
In-Reply-To: <CAHNn8BWJ2QxXujKfKUuyi7rmeTOU_qpdC6o9L1w8xQ6thO8apg@mail.gmail.com>
References: <CAK6O52=+cd5pcnXsDYSSeQ0WC5z7vHj0byjkqGX3xdgvtys8_Q@mail.gmail.com>
	<CAHNn8BXU0DXgNK_02KnNu5Rnm1_1=9=_AUVajC1oU5G0pwE-1w@mail.gmail.com>
	<iv4odo$2e9$1@dough.gmane.org>
	<CAHNn8BV2gD8dx=eKVS8KaHt6nX_KTJ4SH69TK2O22fJyfCmC8g@mail.gmail.com>
	<CAAUn5qJxoq_ZbW7yzcQ-CTYC1sQr3n7ePzkVMWnNFBVXCxoGFw@mail.gmail.com>
	<CAHNn8BUwGrxdFY18DpDn+0vrH1N2fBGt8Mn1KO2kkoTOOUQZdA@mail.gmail.com>
	<CAAUn5qJkcBh2+kQTExZtsx8WCTDXZoozhzocg4fq4mjVwY999A@mail.gmail.com>
	<CAHNn8BWJ2QxXujKfKUuyi7rmeTOU_qpdC6o9L1w8xQ6thO8apg@mail.gmail.com>
Message-ID: <CAAUn5q+Z85h9WHiwKo96nRf2oLmy9DbZaFR2nQ4fZ25b=Ykb0A@mail.gmail.com>

RC1 works pretty well, I think.  I've tested the qtconsole (using PySide)
on Windows, Mac, Linux, 32 and 64-bit, with and without inline
plotting, and had no troubles.

- Ilan


On Fri, Jul 8, 2011 at 12:48 AM, MinRK <benjaminrk at gmail.com> wrote:
> On Thu, Jul 7, 2011 at 22:43, Ilan Schnell <ischnell at enthought.com> wrote:
>> That's good to hear, I don't want to be the one responsible
>> for keeping 'pylab=inline' around :-)
>
> It wouldn't be your fault, it would be mine for telling you rc1 was
> safe, which we have clearly learned it wasn't.
>
> Thanks,
> -MinRK
>
>>
>> - Ilan
>>
>>
>> On Fri, Jul 8, 2011 at 12:32 AM, MinRK <benjaminrk at gmail.com> wrote:
>>> On Thu, Jul 7, 2011 at 20:42, Ilan Schnell <ischnell at enthought.com> wrote:
>>>>> only because 0.11.rc1 got into EPD
>>>>
>>>> I hope this is not the only reason. ?We will probably do an EPD
>>>> bug fix release in a few weeks, in which I'm planing to update
>>>> to 0.11 final.
>>>
>>> That helps a lot, thanks for reminding us, Ilan. ?Now that I read
>>> that, I'm pretty sure you told us this earlier, but my brain is pretty
>>> fried right now. ?This takes some pressure off, and we can make sure
>>> we get it right, without worrying about 6 months of EPD users having
>>> an IPython that doesn't match those before or after.
>>>
>>> We will favor natural argparse-style arguments, even if we don't
>>> finish migrating to argparse itself, and the vociferously opposed
>>> 'foo=value' without leading hyphens will likely be removed. master is
>>> currently in a temporary state that supports both.
>>>
>>> -MinRK
>>>
>>>>
>>>> - Ilan
>>>>
>>>>
>>>> On Thu, Jul 7, 2011 at 6:41 PM, MinRK <benjaminrk at gmail.com> wrote:
>>>>> We have relaxed the syntax in 0.11, so you can do the more familiar
>>>>> '--gui=qt' pattern, and 'ipython -i foo.py' should work as expected.
>>>>> The 'gui=qt' way will still work in 0.11, only because 0.11.rc1 got
>>>>> into EPD, but I think we will remove it in 0.12. ?I also added support
>>>>> for '--' to halt parsing, as Robert described.
>>>>>
>>>>> Since we aren't doing unusual things for the simple cases, I opened an
>>>>> issue to replace the existing machinery for everything short of fully
>>>>> specified Class.trait=value with argparse, and only using our extra
>>>>> code for that single case, since it just makes more sense. I don't
>>>>> believe this will happen in 0.11.
>>>>>
>>>>> @Julian '-i' should work fine now (its alias was --i, since we used to
>>>>> require two leading '-' for flags, as described in the help output).
>>>>> We don't (and won't) support 'ipython -c "stuff"' until we go back to
>>>>> using argparse. Its alias is 'c' (used as 'c=stuff' or, with current
>>>>> master, '--c=stuff'), as described in the help output, until then. ?I
>>>>> also believe I fixed the inherited-argv bug for scripts that you
>>>>> described.
>>>>>
>>>>> -MinRK
>>>>>
>>>>> On Thu, Jul 7, 2011 at 09:55, Robert Kern <robert.kern at gmail.com> wrote:
>>>>>> On 7/7/11 11:32 AM, MinRK wrote:
>>>>>>> On Thu, Jul 7, 2011 at 07:00, Darren Dale<dsdale24 at gmail.com> ?wrote:
>>>>>>
>>>>>>>> Or, suppose I have a file named something pathological like foo=bar?
>>>>>>>> Python will run it without any problems. Even if I rename it
>>>>>>>> foo=bar.py, ipython appears to interpret it as an option, not a
>>>>>>>> filename.
>>>>>>>
>>>>>>> You can always give more path information, so `ipython ./profile` or
>>>>>>> `ipython ./foo=bar` will work*. ?Python has the exact same
>>>>>>> vulnerability to pathological filenames matching their argument
>>>>>>> patterns, like files called '-foo' or '-zebulon'. Obviously, given our
>>>>>>> more flexible syntax, our cases cast a wider net.
>>>>>>
>>>>>> Well, with argparse, you can use the standardized "--" marker to indicate that
>>>>>> everything following is an argument, not an option. E.g.
>>>>>>
>>>>>> ? $ ipython -pylab -- -foo.py
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>>
>>>>>> _______________________________________________
>>>>>> IPython-dev mailing list
>>>>>> IPython-dev at scipy.org
>>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>>>
>>>>> _______________________________________________
>>>>> IPython-dev mailing list
>>>>> IPython-dev at scipy.org
>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>>
>>>>
>>>
>>
>


From jorgen.stenarson at bostream.nu  Fri Jul  8 10:05:50 2011
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Fri, 08 Jul 2011 16:05:50 +0200
Subject: [IPython-dev] Bug in argument parsing for %run
Message-ID: <4E170EBE.3030408@bostream.nu>

Hi,

This problem is with master 0e80619
when calling %run with parameters that have quotation marks keep the 
quotation marks in sys.argv.

Example runbug.py:
import sys
print sys.argv

In [2]: %run runbug.py "hello world"
[u'runbug.py', u'"hello world"']

I'm off for the weekend without access to internet.

/J?rgen


From benjaminrk at gmail.com  Fri Jul  8 12:02:09 2011
From: benjaminrk at gmail.com (MinRK)
Date: Fri, 8 Jul 2011 09:02:09 -0700
Subject: [IPython-dev] Bug in argument parsing for %run
In-Reply-To: <4E170EBE.3030408@bostream.nu>
References: <4E170EBE.3030408@bostream.nu>
Message-ID: <CAHNn8BWzFMgLcKzwT5aydmxg__Tssjm1weWB4jcqBEtsN9fu0w@mail.gmail.com>

On Fri, Jul 8, 2011 at 07:05, J?rgen Stenarson
<jorgen.stenarson at bostream.nu> wrote:
> Hi,
>
> This problem is with master 0e80619
> when calling %run with parameters that have quotation marks keep the
> quotation marks in sys.argv.
>
> Example runbug.py:
> import sys
> print sys.argv
>
> In [2]: %run runbug.py "hello world"
> [u'runbug.py', u'"hello world"']

This is unique to Windows, somehow. I can't make it happen on OSX or Linux.

>
> I'm off for the weekend without access to internet.
>
> /J?rgen
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>


From takowl at gmail.com  Fri Jul  8 14:31:02 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Fri, 8 Jul 2011 19:31:02 +0100
Subject: [IPython-dev] experimental ipython 0.11rc1 debian/ubuntu package
In-Reply-To: <4E163BB6.2070407@googlemail.com>
References: <4E163BB6.2070407@googlemail.com>
Message-ID: <CAOvn4qiFd9YoTTTuDcxK1d7GnyHqJavpCJDdOBT-VZ0R3qqX5g@mail.gmail.com>

On 8 July 2011 00:05, Julian Taylor <jtaylor.debian at googlemail.com> wrote:

> I have just uploaded the first revision of the ipython 0.11rc1 debian
> package to my ppa:
> https://launchpad.net/~jtaylor/+archive/ipython-dev<https://launchpad.net/%7Ejtaylor/+archive/ipython-dev>
> It is based on the 0.11rc1 snapshot from github with a few patches to
> fix the testsuite (from git) and better debian integration.
>

Thanks for doing this, Julian. I'd been avoiding installing trunk
system-wide so as not to interfere with the package manager, but it's great
to have the Qt console to hand without having to load a virtualenv for it.

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

From benjaminrk at gmail.com  Fri Jul  8 17:19:18 2011
From: benjaminrk at gmail.com (MinRK)
Date: Fri, 8 Jul 2011 14:19:18 -0700
Subject: [IPython-dev] 0.11rc1 : problem with tutorial for PBS in
	http://ipython.org/ipython-doc/dev/parallel/parallel_process.html
In-Reply-To: <4E158DC1.9080505@gmail.com>
References: <4E11D735.9080909@gmail.com> <4E121C1D.2040103@gmail.com>
	<CAHNn8BWcf4789EJ-zf3yJa8oYjPRjWjJMRz-Porf=1HuPAQj+g@mail.gmail.com>
	<4E12A5E7.7000202@gmail.com> <4E145620.5090200@gmail.com>
	<CAOvn4qijTXUddvoEUykUYBm+iJhwkRQsNOucjzawN5BHk2LZaA@mail.gmail.com>
	<4E146401.9060304@gmail.com> <4E14695E.4020902@gmail.com>
	<CAOvn4qh0fshtsJh2rmcFeyh2rNA10YT+3ayQwMccA7uOf_6n3Q@mail.gmail.com>
	<4E158DC1.9080505@gmail.com>
Message-ID: <CAHNn8BVfHHS2S=+dWM3NgFKtMfdxNrFNap_85hgJrnaJTZF-nw@mail.gmail.com>

Thanks for this!

I'll look through it when I have some time, which won't be before
Tuesday afternoon.

-MinRK

On Thu, Jul 7, 2011 at 03:43, Johann Cohen-Tanugi
<johann.cohentanugi at gmail.com> wrote:
> ok thanks a lot. I am attaching the LSF code I added to launcher.py. It
> seems to do what I expect on my LSF batch farm.
> In order to pipe I follow Mathias' suggestion but the code could probably
> use expert's check. Especially I have python 2.6.5 so I modified the
> corresponding version of check_output at the top of launcher.py. Maybe my
> code does not work for python > 2.7 then?
>
> Feel free to include it if it is deemed reasonable, or to make any
> modifications you guys see fit.
> best,
> Johann
>
> On 07/06/2011 04:34 PM, Thomas Kluyver wrote:
>
> On 6 July 2011 14:55, Johann Cohen-Tanugi <johann.cohentanugi at gmail.com>
> wrote:
>>
>> hmmm isn't it :
>>
>> ??? def find_args(self):
>> ??????? return self.submit_command + [self.batch_file]
>>
>> in BatchSystemLauncher that I need to overwrite?
>
> find_args produces the list of args which are fed to Popen by
> BatchSystemLauncher.start(). Replacing it won't fix this problem.
>
> The line you need to look at is in the start method:
>
> output = check_output(self.args, env=os.environ)
>
> Thomas
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>


From pivanov314 at gmail.com  Fri Jul  8 23:25:19 2011
From: pivanov314 at gmail.com (Paul Ivanov)
Date: Fri, 8 Jul 2011 20:25:19 -0700
Subject: [IPython-dev] please don't rename old config files by default
Message-ID: <20110709032519.GF18611@ykcyc>

While we Yanks were busy barbecuing on the 4th of July,  a
nocturnal bird of prey across the pond [hi Thomas! ;) ] made a
commit that I think should be altered back.

The SHA1 is 75bb82ba3360d4d41032ae378a8ae42b8c877a09, with the
summary "Rename old config files if they are found and not
pristine."

I think it will lead to a better user experience for users
transitioning to 0.11 if old config files are preserved and *not*
moved to get an additional .old extension the first time ipython
sees them.

My rationale is that it's a little *too* helpful to move the old
files out of the way and not see the warning ever again, because
if the user missed it the first time, it'll never come up again.

The whole point of the "nag" message is to *force* the user to
acknowledge and accept the presence of a new configuration
system, the first step of which can be as simple as adding
c.InteractiveShellApp.ignore_old_config=True to it.

How does this sound:
https://github.com/ipython/ipython/pull/565

-- 
Paul Ivanov
314 address only used for lists,  off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110708/620e55d0/attachment.sig>

From benjaminrk at gmail.com  Sat Jul  9 01:09:27 2011
From: benjaminrk at gmail.com (MinRK)
Date: Fri, 8 Jul 2011 22:09:27 -0700
Subject: [IPython-dev] please don't rename old config files by default
In-Reply-To: <20110709032519.GF18611@ykcyc>
References: <20110709032519.GF18611@ykcyc>
Message-ID: <CAHNn8BVZ=_tbRfRe4=ujVZwDng-vDaFeGAu_zEADzLJg9_J2YQ@mail.gmail.com>

On Fri, Jul 8, 2011 at 20:25, Paul Ivanov <pivanov314 at gmail.com> wrote:
> While we Yanks were busy barbecuing on the 4th of July, ?a
> nocturnal bird of prey across the pond [hi Thomas! ;) ] made a
> commit that I think should be altered back.

Don't blame Thomas, he, Fernando, and I all participated in the
decision, but I don't feel too strongly either way.

>
> The SHA1 is 75bb82ba3360d4d41032ae378a8ae42b8c877a09, with the
> summary "Rename old config files if they are found and not
> pristine."
>
> I think it will lead to a better user experience for users
> transitioning to 0.11 if old config files are preserved and *not*
> moved to get an additional .old extension the first time ipython
> sees them.
>
> My rationale is that it's a little *too* helpful to move the old
> files out of the way and not see the warning ever again, because
> if the user missed it the first time, it'll never come up again.
>
> The whole point of the "nag" message is to *force* the user to
> acknowledge and accept the presence of a new configuration
> system, the first step of which can be as simple as adding
> c.InteractiveShellApp.ignore_old_config=True to it.

This is sound. it's a question of weighing the annoyance of many users
seeing a warning they may not care about against the possible
confusion of others when they aren't getting reminded until they
address the issue.

>
> How does this sound:
> https://github.com/ipython/ipython/pull/565

Reasonable.  Can others weigh in?

a) warn about old config until moved out of the way manually and/or
ignore_old_config is set
b) warn once and move out of the way, so warnings only appear once -
set ignore_old_config if you need to keep using 0.10
c) mysterious door number 3

Either one seems fine to me.  Fernando and Thomas seemed to prefer b),
Paul prefers a).

-MinRK

>
> --
> Paul Ivanov
> 314 address only used for lists, ?off-list direct email at:
> http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk4XyhgACgkQe+cmRQ8+KPd4JgCcCJ1h73ePKL4T4FdfKBKU6hsZ
> jLYAn2vVhcF1oQ1InzXIlDvSIerpARKP
> =MqK9
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>


From pivanov314 at gmail.com  Sat Jul  9 02:58:47 2011
From: pivanov314 at gmail.com (Paul Ivanov)
Date: Fri, 8 Jul 2011 23:58:47 -0700
Subject: [IPython-dev] please don't rename old config files by default
In-Reply-To: <CAHNn8BVZ=_tbRfRe4=ujVZwDng-vDaFeGAu_zEADzLJg9_J2YQ@mail.gmail.com>
References: <20110709032519.GF18611@ykcyc>
	<CAHNn8BVZ=_tbRfRe4=ujVZwDng-vDaFeGAu_zEADzLJg9_J2YQ@mail.gmail.com>
Message-ID: <20110709065847.GI18611@ykcyc>

MinRK, on 2011-07-08 22:09,  wrote:
> This is sound. it's a question of weighing the annoyance of many users
> seeing a warning they may not care about against the possible
> confusion of others when they aren't getting reminded until they
> address the issue.

Thanks Min, good summary, and I think we should *make* the users
care - that way they'll look at the new config and also find all
of the new goodies that live in there! It's a way for the user to
get re-acquainted with his old friend IPython, that's was out
seeing more of the world, learning, getting a bit wiser and more
sophisticated (IPython only drinks red wine now, whereas IPython used
to only drink J?germeister).

> On Fri, Jul 8, 2011 at 20:25, Paul Ivanov <pivanov314 at gmail.com> wrote:
> > How does this sound:
> > https://github.com/ipython/ipython/pull/565
> 
> Reasonable.  Can others weigh in?
> 
> a) warn about old config until moved out of the way manually and/or
> ignore_old_config is set
> b) warn once and move out of the way, so warnings only appear once -
> set ignore_old_config if you need to keep using 0.10
> c) mysterious door number 3
> 
> Either one seems fine to me.  Fernando and Thomas seemed to prefer b),
> Paul prefers a).

You're kind of tempting me with c), there, but here's my use
cases for b). 

Paul is happily using 0.10.2 and wants to take 0.11 for a test
drive without committing to using it full time. He grabs the
sources, installs them in a temporary location, fires up 0.11,
and is irked by the message that tells him his config files were
just moved without anyone asking him.

He just wants to do something quick right now, and doesn't follow
the instructions right away about creating a new profile. The
sessions grows and instructions for creating a new profile and
the config option to change scroll off the screen. He exits this
session, and fires up ipython, and without a helpful message, he
now has to move the .old files back into place just to get the
helpful "Hi again, old friend, thanks for the offer, but my
tastes have changed a bit, and I don't drink J?germeister
anymore" message from IPython to appear again.

-- 
Paul Ivanov
314 address only used for lists,  off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110708/2a3c34d5/attachment.sig>

From efiring at hawaii.edu  Sat Jul  9 03:54:34 2011
From: efiring at hawaii.edu (Eric Firing)
Date: Fri, 08 Jul 2011 21:54:34 -1000
Subject: [IPython-dev] please don't rename old config files by default
In-Reply-To: <CAHNn8BVZ=_tbRfRe4=ujVZwDng-vDaFeGAu_zEADzLJg9_J2YQ@mail.gmail.com>
References: <20110709032519.GF18611@ykcyc>
	<CAHNn8BVZ=_tbRfRe4=ujVZwDng-vDaFeGAu_zEADzLJg9_J2YQ@mail.gmail.com>
Message-ID: <4E18093A.5010501@hawaii.edu>

On 07/08/2011 07:09 PM, MinRK wrote:
> On Fri, Jul 8, 2011 at 20:25, Paul Ivanov<pivanov314 at gmail.com>  wrote:
>> While we Yanks were busy barbecuing on the 4th of July,  a
>> nocturnal bird of prey across the pond [hi Thomas! ;) ] made a
>> commit that I think should be altered back.
>
> Don't blame Thomas, he, Fernando, and I all participated in the
> decision, but I don't feel too strongly either way.
>
>>
>> The SHA1 is 75bb82ba3360d4d41032ae378a8ae42b8c877a09, with the
>> summary "Rename old config files if they are found and not
>> pristine."
>>
>> I think it will lead to a better user experience for users
>> transitioning to 0.11 if old config files are preserved and *not*
>> moved to get an additional .old extension the first time ipython
>> sees them.
>>
>> My rationale is that it's a little *too* helpful to move the old
>> files out of the way and not see the warning ever again, because
>> if the user missed it the first time, it'll never come up again.
>>
>> The whole point of the "nag" message is to *force* the user to
>> acknowledge and accept the presence of a new configuration
>> system, the first step of which can be as simple as adding
>> c.InteractiveShellApp.ignore_old_config=True to it.
>
> This is sound. it's a question of weighing the annoyance of many users
> seeing a warning they may not care about against the possible
> confusion of others when they aren't getting reminded until they
> address the issue.
>
>>
>> How does this sound:
>> https://github.com/ipython/ipython/pull/565
>
> Reasonable.  Can others weigh in?
>
> a) warn about old config until moved out of the way manually and/or
> ignore_old_config is set
> b) warn once and move out of the way, so warnings only appear once -
> set ignore_old_config if you need to keep using 0.10
> c) mysterious door number 3
>
> Either one seems fine to me.  Fernando and Thomas seemed to prefer b),
> Paul prefers a).

I am mildly on Paul's side on this; it is not a big deal either way, but 
(a) seems more polite and straightforward.  Which version will annoy 
more people in practice, though, I really can't predict.

Eric

>
> -MinRK
>
>>
>> --
>> Paul Ivanov
>> 314 address only used for lists,  off-list direct email at:
>> http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.10 (GNU/Linux)
>>
>> iEYEARECAAYFAk4XyhgACgkQe+cmRQ8+KPd4JgCcCJ1h73ePKL4T4FdfKBKU6hsZ
>> jLYAn2vVhcF1oQ1InzXIlDvSIerpARKP
>> =MqK9
>> -----END PGP SIGNATURE-----
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



From takowl at gmail.com  Sat Jul  9 10:33:46 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Sat, 9 Jul 2011 15:33:46 +0100
Subject: [IPython-dev] please don't rename old config files by default
In-Reply-To: <CAHNn8BVZ=_tbRfRe4=ujVZwDng-vDaFeGAu_zEADzLJg9_J2YQ@mail.gmail.com>
References: <20110709032519.GF18611@ykcyc>
	<CAHNn8BVZ=_tbRfRe4=ujVZwDng-vDaFeGAu_zEADzLJg9_J2YQ@mail.gmail.com>
Message-ID: <CAOvn4qhDQ34LoakoXNQZ0BeW7eqUQA9aGUYOBGe0gJ4m4Vjo3Q@mail.gmail.com>

On 9 July 2011 06:09, MinRK <benjaminrk at gmail.com> wrote:

> a) warn about old config until moved out of the way manually and/or
> ignore_old_config is set
> b) warn once and move out of the way, so warnings only appear once -
> set ignore_old_config if you need to keep using 0.10
> c) mysterious door number 3
>

I'm not too concerned - my primary interest was ensuring that we didn't nag
users who had never touched their config files (probably the vast majority).

Points in favour of b:
- Most people upgrading will not want to keep running the old version
(except for those who have tools built on the old IPython.kernel). Ideally,
we shouldn't require these users to do anything to silence a big warning
message.
- We want to avoid people creating the new config files unless they need to,
so as to minimise this problem for future updates. If the nag message tells
upgrading users how to suppress it, users who skim read it might create the
config files just to shut it up.

If I might open mysterious door number 3, would it make sense to offer the
user the option to rename the files on the first run? If they don't want to,
we could drop a marker of some sort so that next time, we give the warning
message without the prompt. Or we could temporarily define a
%remove_old_config magic, and mention it in the warning message. In short:
an easy but non-automatic way to get rid of the old files for people who're
permanently upgrading.

Thanks,
Thomas

P.S. Hi Paul, hope you're well!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110709/e415892c/attachment.html>

From pivanov314 at gmail.com  Sat Jul  9 13:35:04 2011
From: pivanov314 at gmail.com (Paul Ivanov)
Date: Sat, 9 Jul 2011 10:35:04 -0700
Subject: [IPython-dev] please don't rename old config files by default
In-Reply-To: <CAOvn4qhDQ34LoakoXNQZ0BeW7eqUQA9aGUYOBGe0gJ4m4Vjo3Q@mail.gmail.com>
Message-ID: <20110709173504.GB29764@ykcyc>

Thomas Kluyver, on 2011-07-09 15:33,  wrote:
> If I might open mysterious door number 3, would it make sense to offer the
> user the option to rename the files on the first run? If they don't want to,
> we could drop a marker of some sort so that next time, we give the warning
> message without the prompt. Or we could temporarily define a
> %remove_old_config magic, and mention it in the warning message. In short:
> an easy but non-automatic way to get rid of the old files for people who're
> permanently upgrading

If a) doesn't gain momentum, I'd be ok with either move y/n
prompt of the %remove_old_config magic, as both leave the user in
the driver's seat, as opposed to doing something on the user's
behalf. I guess that what I liked about a) is that it closes the
loop between user and IPython. We engage the users, bring them in
and show them where and how to modify various new and old
behavior of the software.

very best,
-- 
Paul Ivanov
314 address only used for lists,  off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 

> P.S. Hi Paul, hope you're well!

Hi Thomas! I'm happy to have time to play with IPython again,
hope you're well as well!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110709/33349ab9/attachment.sig>

From fperez.net at gmail.com  Sun Jul 10 18:36:24 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 10 Jul 2011 15:36:24 -0700
Subject: [IPython-dev] Fwd: [SciPy-User] SciPy Central: file and link
	sharing site
In-Reply-To: <CAGD7iRY5ojyWKqbEYA0p8fFCFus+s1ePn-1RkEVQ9ALqgvV7NQ@mail.gmail.com>
References: <CAGD7iRY5ojyWKqbEYA0p8fFCFus+s1ePn-1RkEVQ9ALqgvV7NQ@mail.gmail.com>
Message-ID: <CAHAreOpnGF_D6bW40jBtxm4bKi7qVdbEnu0EkGr8CFdEpRyKcQ@mail.gmail.com>

---------- Forwarded message ----------
From: Kevin Dunn <kgdunn at gmail.com>
Date: Sun, Jul 10, 2011 at 11:14 AM
Subject: [SciPy-User] SciPy Central: file and link sharing site
To: scipy-user at scipy.org


I'm announcing an alpha release of SciPy Central, a website for
sharing code snippets, recipes and links related to scientific
computing, specifically using NumPy, SciPy, matplotlib, IPython and
similar tools.

http://scipy-central.org

The idea for the website grew out of previous discussions on this list.

The site is currently in alpha mode, which means we'd like you to
stress test it by filling in garbage information and trying to break
it. We'll keep it in this mode for a couple of days and iron out any
bugs. Please report those at
https://github.com/kgdunn/SciPyCentral/issues - for those familiar
with Django, we've left the site in DEBUG mode, so you can copy/paste
the stack trace in your bug reports.

Then we will delete all submissions and start in beta mode with DEBUG
turned off.

If you have any suggestions for improvements, please also post them on
the issues list.

Thanks,
Kevin
_______________________________________________
SciPy-User mailing list
SciPy-User at scipy.org
http://mail.scipy.org/mailman/listinfo/scipy-user


From benjaminrk at gmail.com  Mon Jul 11 17:37:53 2011
From: benjaminrk at gmail.com (MinRK)
Date: Mon, 11 Jul 2011 16:37:53 -0500
Subject: [IPython-dev] please don't rename old config files by default
In-Reply-To: <20110709173504.GB29764@ykcyc>
References: <CAOvn4qhDQ34LoakoXNQZ0BeW7eqUQA9aGUYOBGe0gJ4m4Vjo3Q@mail.gmail.com>
	<20110709173504.GB29764@ykcyc>
Message-ID: <CAHNn8BWzoedKLiY5MHJVcKQ2uiChN6hu5AeksgGHG0c70=co5Q@mail.gmail.com>

If nobody objects, I think we should use a), and merge PR #565.

Since we don't trigger a message for users who have not configured
IPython, the principle objection to the warning doesn't apply anymore.

On Sat, Jul 9, 2011 at 12:35, Paul Ivanov <pivanov314 at gmail.com> wrote:
> Thomas Kluyver, on 2011-07-09 15:33, ?wrote:
>> If I might open mysterious door number 3, would it make sense to offer the
>> user the option to rename the files on the first run? If they don't want to,
>> we could drop a marker of some sort so that next time, we give the warning
>> message without the prompt. Or we could temporarily define a
>> %remove_old_config magic, and mention it in the warning message. In short:
>> an easy but non-automatic way to get rid of the old files for people who're
>> permanently upgrading
>
> If a) doesn't gain momentum, I'd be ok with either move y/n
> prompt of the %remove_old_config magic, as both leave the user in
> the driver's seat, as opposed to doing something on the user's
> behalf. I guess that what I liked about a) is that it closes the
> loop between user and IPython. We engage the users, bring them in
> and show them where and how to modify various new and old
> behavior of the software.
>
> very best,
> --
> Paul Ivanov
> 314 address only used for lists, ?off-list direct email at:
> http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
>
>> P.S. Hi Paul, hope you're well!
>
> Hi Thomas! I'm happy to have time to play with IPython again,
> hope you're well as well!
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk4YkT8ACgkQe+cmRQ8+KPdIaACfWObw7rW7pSA34HF4U/fWTKW2
> C+wAn02pNyTa7QS7l9sc6LXS8irSgx5z
> =7i+J
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>


From takowl at gmail.com  Mon Jul 11 17:50:31 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 11 Jul 2011 22:50:31 +0100
Subject: [IPython-dev] please don't rename old config files by default
In-Reply-To: <CAHNn8BWzoedKLiY5MHJVcKQ2uiChN6hu5AeksgGHG0c70=co5Q@mail.gmail.com>
References: <CAOvn4qhDQ34LoakoXNQZ0BeW7eqUQA9aGUYOBGe0gJ4m4Vjo3Q@mail.gmail.com>
	<20110709173504.GB29764@ykcyc>
	<CAHNn8BWzoedKLiY5MHJVcKQ2uiChN6hu5AeksgGHG0c70=co5Q@mail.gmail.com>
Message-ID: <CAOvn4qjW3eQJKJn8NZ77zcyHL6bWxdj1YXwmxSnNcRco=9QTnA@mail.gmail.com>

On 11 July 2011 22:37, MinRK <benjaminrk at gmail.com> wrote:

> If nobody objects, I think we should use a), and merge PR #565.
>
> Since we don't trigger a message for users who have not configured
> IPython, the principle objection to the warning doesn't apply anymore.
>

Fine by me.

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

From jtaylor.debian at googlemail.com  Tue Jul 12 08:24:18 2011
From: jtaylor.debian at googlemail.com (Julian Taylor)
Date: Tue, 12 Jul 2011 14:24:18 +0200
Subject: [IPython-dev] experimental ipython 0.11rc1 debian/ubuntu package
In-Reply-To: <CAOvn4qiFd9YoTTTuDcxK1d7GnyHqJavpCJDdOBT-VZ0R3qqX5g@mail.gmail.com>
References: <4E163BB6.2070407@googlemail.com>
	<CAOvn4qiFd9YoTTTuDcxK1d7GnyHqJavpCJDdOBT-VZ0R3qqX5g@mail.gmail.com>
Message-ID: <4E1C3CF2.1090801@googlemail.com>

The package is now also in debian experimental.

To install it:
echo "deb http://ftp.debian.org/debian experimental main" >> /etc/apt/sources.list.d/experimental.list
apt-get update
apt-get install -t experimental ipython ipython-qtconsole ipython-parallel ipython-doc

but beware that will pull some dependencies from
experimental which might break your system.

Some packages [0] will have reduced functionality
when installing ipython 0.11 (no embedded shells etc.).
Any help in porting them is greatly appreciated.
For some ipython functions used it is not clear to me whether
they still exist in 0.11.
e.g. IPython.Shell.Term.{cin,cerr,cout} (exaile)
IPython.genutils (accerciser, pytango, pudb)

A wiki page on porting ipython 0.10 embedded shells to 0.11
might be a good idea.


[0]:
accerciser
connectomeviewer
dipy
exaile
griffith
matplotlib
mayavi2
parti-all
polybori
pudb
pylons
pytango
python-netaddr
python-pyramid
python-werkzeug
rabbitvcs
scikit-learn
snimpy
sugar-base-0.84
sugar-base-0.86
sugar-base-0.88
sugar-base-0.90
tg.devtools
yade

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110712/7e8a400e/attachment.sig>

From jorgen.stenarson at bostream.nu  Tue Jul 12 14:00:35 2011
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Tue, 12 Jul 2011 20:00:35 +0200
Subject: [IPython-dev] How to add tests in IPython/external
Message-ID: <4E1C8BC3.80107@bostream.nu>

Hi,

I'm considering adding some tests to Itpl in IPython/external to 
investigate unicode issues in that module. But after adding a tests 
submodule in the Itpl directory I can't run those tests because nose 
crashes when it can't import pexepct. Any ideas on how to solve this?

C:\python\external> python ipython-js\IPython\scripts\iptest 
IPython.external -v

Failure: ImportError (No module named resource

A critical module was not found. Probably this operating system does not
support it. Pexpect is intended for UNIX-like operating systems.) ... ERROR

======================================================================
ERROR: Failure: ImportError (No module named resource

A critical module was not found. Probably this operating system does not
support it. Pexpect is intended for UNIX-like operating systems.)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "c:\python26\lib\site-packages\nose\loader.py", line 390, in 
loadTestsFro
mName
     addr.filename, addr.module)
   File "c:\python26\lib\site-packages\nose\importer.py", line 39, in 
importFromP
ath
     return self.importFromDir(dir_path, fqname)
   File "c:\python26\lib\site-packages\nose\importer.py", line 86, in 
importFromD
ir
     mod = load_module(part_fqname, fh, filename, desc)
   File 
"c:\python\external\ipython-js\IPython\external\pexpect\__init__.py", lin
e 5, in <module>
     from _pexpect import *
   File 
"c:\python\external\ipython-js\IPython\external\pexpect\_pexpect.py", lin
e 84, in <module>
     support it. Pexpect is intended for UNIX-like operating systems.""")
ImportError: No module named resource

A critical module was not found. Probably this operating system does not
support it. Pexpect is intended for UNIX-like operating systems.

----------------------------------------------------------------------
Ran 1 test in 0.003s


From jorgen.stenarson at bostream.nu  Tue Jul 12 15:34:40 2011
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Tue, 12 Jul 2011 21:34:40 +0200
Subject: [IPython-dev] Is anyone going to euroscipy?
Message-ID: <4E1CA1D0.8040101@bostream.nu>

Hi,

I know Fernando is going to euroscipy in august. I'm also going but is 
anyone else coming? When are you planning to be there?

My tentative plan is to come a few days early to get some sightseeing 
done as well.

/J?rgen


From chris.d.burns at gmail.com  Wed Jul 13 16:30:52 2011
From: chris.d.burns at gmail.com (Christopher Burns)
Date: Wed, 13 Jul 2011 13:30:52 -0700
Subject: [IPython-dev] broken link on website
Message-ID: <CAOC8SjG=a+PS_wzQyJd-BAg9HykfEv08cSzOFm6Dy8h_ykQqBg@mail.gmail.com>

I'm not sure if the moin site is still maintained, but the
"documentation" link in the Installations Instructions is broken:

http://ipython.scipy.org/doc/rel-0.10.2/html/install/index.html

I presume that should point here:

http://ipython.org/ipython-doc/rel-0.10.2/html/

Chris


From takowl at gmail.com  Wed Jul 13 16:39:26 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Wed, 13 Jul 2011 21:39:26 +0100
Subject: [IPython-dev] broken link on website
In-Reply-To: <CAOC8SjG=a+PS_wzQyJd-BAg9HykfEv08cSzOFm6Dy8h_ykQqBg@mail.gmail.com>
References: <CAOC8SjG=a+PS_wzQyJd-BAg9HykfEv08cSzOFm6Dy8h_ykQqBg@mail.gmail.com>
Message-ID: <CAOvn4qj44AmC4-tPOrnT_v=w5wH0+vN4CKMWZy3YuRZbRqOnkw@mail.gmail.com>

On 13 July 2011 21:30, Christopher Burns <chris.d.burns at gmail.com> wrote:

> I'm not sure if the moin site is still maintained, but the
> "documentation" link in the Installations Instructions is broken:
>

Thanks, Chris. It should actually point here:
http://ipython.org/ipython-doc/rel-0.10.2/html/install/index.html, and I've
updated it so it does.

The moin site is on the way out, to be replaced by http://ipython.org/ (the
new main site), and http://wiki.ipython.org/ (the new wiki - still a work in
progress). But the imminent release of IPython 0.11 is also taking up
developer time.

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

From piotr.zolnierczuk at gmail.com  Wed Jul 13 16:58:34 2011
From: piotr.zolnierczuk at gmail.com (Piotr Zolnierczuk)
Date: Wed, 13 Jul 2011 16:58:34 -0400
Subject: [IPython-dev] wxPython console
Message-ID: <CAB-kD6=AtSDvqjPWEHHbUtOSpDfwbM-0rqM9JPMPd3+O5k1F6Q@mail.gmail.com>

I just saw Fernando's talk @scipy2011 I was wondering if there are any plans
to support a wxPython console?

Piotr

-- 

Piotr Adam Zolnierczuk
e-mail: piotr at zolnierczuk.net
www:   http://www.zolnierczuk.net
_____________________________________
written on recycled electrons
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110713/8868b611/attachment.html>

From piotr.zolnierczuk at gmail.com  Wed Jul 13 17:00:37 2011
From: piotr.zolnierczuk at gmail.com (Piotr Zolnierczuk)
Date: Wed, 13 Jul 2011 17:00:37 -0400
Subject: [IPython-dev] embedding ipython kernel
Message-ID: <CAB-kD6kw1o=zpCDiWFUCd2CgJe1JfXQ7k3LrWsrkTLgM1jyoHw@mail.gmail.com>

Another followup from Fernando's talk @scipy2011: how hard would it be to
embed ipython kernel in some other app?

My use case is hardware (experiment) control with embedded kernel that I
would like to access from various clients.

Piotr

-- 

Piotr Adam Zolnierczuk
e-mail: piotr at zolnierczuk.net
www:   http://www.zolnierczuk.net
_____________________________________
written on recycled electrons
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110713/5982cc85/attachment.html>

From ischnell at enthought.com  Wed Jul 13 17:03:28 2011
From: ischnell at enthought.com (Ilan Schnell)
Date: Wed, 13 Jul 2011 16:03:28 -0500
Subject: [IPython-dev] wxPython console
In-Reply-To: <CAB-kD6=AtSDvqjPWEHHbUtOSpDfwbM-0rqM9JPMPd3+O5k1F6Q@mail.gmail.com>
References: <CAB-kD6=AtSDvqjPWEHHbUtOSpDfwbM-0rqM9JPMPd3+O5k1F6Q@mail.gmail.com>
Message-ID: <CAAUn5qKNKM2BYvvYBZAHzhrytUhAfbZmKWuwzvD0GzZ=_ni_8Q@mail.gmail.com>

As far as I know, no.  Although, given the new infrastructure,
one could write a wxPython console (or in fact any type of
console) which connects to the IPython kernel.

- Ilan


On Wed, Jul 13, 2011 at 3:58 PM, Piotr Zolnierczuk
<piotr.zolnierczuk at gmail.com> wrote:
> I just saw Fernando's talk @scipy2011 I was wondering if there are any plans
> to support a wxPython console?
> Piotr
> --
>
> Piotr Adam Zolnierczuk
> e-mail: piotr at zolnierczuk.net
> www:?? http://www.zolnierczuk.net
> _____________________________________
> written on recycled electrons
>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>


From benjaminrk at gmail.com  Wed Jul 13 17:10:58 2011
From: benjaminrk at gmail.com (MinRK)
Date: Wed, 13 Jul 2011 16:10:58 -0500
Subject: [IPython-dev] embedding ipython kernel
In-Reply-To: <CAB-kD6kw1o=zpCDiWFUCd2CgJe1JfXQ7k3LrWsrkTLgM1jyoHw@mail.gmail.com>
References: <CAB-kD6kw1o=zpCDiWFUCd2CgJe1JfXQ7k3LrWsrkTLgM1jyoHw@mail.gmail.com>
Message-ID: <CAHNn8BVyj07pxbEdXBuoRmCp076kWeX-PsJwfpAREbz8EHzePw@mail.gmail.com>

On Wed, Jul 13, 2011 at 16:00, Piotr Zolnierczuk
<piotr.zolnierczuk at gmail.com> wrote:
> Another followup from Fernando's talk @scipy2011: how hard would it be to
> embed ipython kernel in some other app?
> My use case is hardware (experiment) control with embedded kernel that I
> would like to access from various clients.

This shouldn't be difficult.  The code to instantiate an ipython
kernel is in IPython.zmq.ipkernel

We don't have an embed method for it at the moment, but it should not
be difficult to write such a thing with the existing organization.

> Piotr
>
> --
>
> Piotr Adam Zolnierczuk
> e-mail: piotr at zolnierczuk.net
> www:?? http://www.zolnierczuk.net
> _____________________________________
> written on recycled electrons
>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>


From takowl at gmail.com  Wed Jul 13 17:11:17 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Wed, 13 Jul 2011 22:11:17 +0100
Subject: [IPython-dev] embedding ipython kernel
In-Reply-To: <CAB-kD6kw1o=zpCDiWFUCd2CgJe1JfXQ7k3LrWsrkTLgM1jyoHw@mail.gmail.com>
References: <CAB-kD6kw1o=zpCDiWFUCd2CgJe1JfXQ7k3LrWsrkTLgM1jyoHw@mail.gmail.com>
Message-ID: <CAOvn4qgMEVavq=Lf2JbNufUt0RxLw+rQ6MBU7kkO3FK0vNjAbw@mail.gmail.com>

On 13 July 2011 22:00, Piotr Zolnierczuk <piotr.zolnierczuk at gmail.com>wrote:

> Another followup from Fernando's talk @scipy2011: how hard would it be to
> embed ipython kernel in some other app?
>
> My use case is hardware (experiment) control with embedded kernel that I
> would like to access from various clients.
>

I don't know quite what Fernando said, but the kernel talks ZeroMQ (
http://www.zeromq.org/), so a frontend can be written for it in any language
that has ZeroMQ bindings. The kernel itself needs to run on a platform with
a Python 2.6 or 2.7 interpreter. If you're using it to control a device with
an embedded computer, you'd probably need to have the kernel on another
machine communicating with that. The kernel can be left running, and you can
connect and disconnect clients at liberty.

Hope that helps,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110713/5ae6f65d/attachment.html>

From piotr.zolnierczuk at gmail.com  Wed Jul 13 18:15:37 2011
From: piotr.zolnierczuk at gmail.com (Piotr Zolnierczuk)
Date: Wed, 13 Jul 2011 18:15:37 -0400
Subject: [IPython-dev] embedding ipython kernel
In-Reply-To: <CAOvn4qgMEVavq=Lf2JbNufUt0RxLw+rQ6MBU7kkO3FK0vNjAbw@mail.gmail.com>
References: <CAB-kD6kw1o=zpCDiWFUCd2CgJe1JfXQ7k3LrWsrkTLgM1jyoHw@mail.gmail.com>
	<CAOvn4qgMEVavq=Lf2JbNufUt0RxLw+rQ6MBU7kkO3FK0vNjAbw@mail.gmail.com>
Message-ID: <CAB-kD6m6Ni0cxn5v+pWgfCuDRvwej8gTHnmP7qHXgHnJi1y23g@mail.gmail.com>

Thomas - thank for reply.

I have other modules that handle hardware communications I would not (at
least initially) rewrite everything using ZeroMQ - although it sounds very
appealing.

So my thinking at the moment is to embed ipython kernel in "my app" so that
I can write and execute experiment control scripts from a ipython console
kind of like this:

hardware <-- custom comm. --> [ my_interface_module, ipython_kernel]  <--
ZMQ --> ipython_console


But I am open to any suggestions.

Piotr

On Wed, Jul 13, 2011 at 5:11 PM, Thomas Kluyver <takowl at gmail.com> wrote:

> On 13 July 2011 22:00, Piotr Zolnierczuk <piotr.zolnierczuk at gmail.com>wrote:
>
>> Another followup from Fernando's talk @scipy2011: how hard would it be to
>> embed ipython kernel in some other app?
>>
>> My use case is hardware (experiment) control with embedded kernel that I
>> would like to access from various clients.
>>
>
> I don't know quite what Fernando said, but the kernel talks ZeroMQ (
> http://www.zeromq.org/), so a frontend can be written for it in any
> language that has ZeroMQ bindings. The kernel itself needs to run on a
> platform with a Python 2.6 or 2.7 interpreter. If you're using it to control
> a device with an embedded computer, you'd probably need to have the kernel
> on another machine communicating with that. The kernel can be left running,
> and you can connect and disconnect clients at liberty.
>
> Hope that helps,
> Thomas
>



-- 

Piotr Adam Zolnierczuk
e-mail: piotr at zolnierczuk.net
www:   http://www.zolnierczuk.net
_____________________________________
written on recycled electrons
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110713/987441fd/attachment.html>

From takowl at gmail.com  Wed Jul 13 18:20:17 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Wed, 13 Jul 2011 23:20:17 +0100
Subject: [IPython-dev] embedding ipython kernel
In-Reply-To: <CAB-kD6m6Ni0cxn5v+pWgfCuDRvwej8gTHnmP7qHXgHnJi1y23g@mail.gmail.com>
References: <CAB-kD6kw1o=zpCDiWFUCd2CgJe1JfXQ7k3LrWsrkTLgM1jyoHw@mail.gmail.com>
	<CAOvn4qgMEVavq=Lf2JbNufUt0RxLw+rQ6MBU7kkO3FK0vNjAbw@mail.gmail.com>
	<CAB-kD6m6Ni0cxn5v+pWgfCuDRvwej8gTHnmP7qHXgHnJi1y23g@mail.gmail.com>
Message-ID: <CAOvn4qiwEDmPaiYpsqJRtyNbbkzb=FkzueHD6V7+S42_uV=goQ@mail.gmail.com>

On 13 July 2011 23:15, Piotr Zolnierczuk <piotr.zolnierczuk at gmail.com>wrote:

>
> hardware <-- custom comm. --> [ my_interface_module, ipython_kernel]  <--
> ZMQ --> ipython_console
>

That design makes sense.

You can also make a profile for IPython to automatically load your modules,
or embed the interactive shell within your application, if the extra
communication layer isn't needed. The key advantage to using the kernel is
that it can keep running without any client open, and you can connect to the
session from different machines.

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

From piotr.zolnierczuk at gmail.com  Wed Jul 13 18:24:27 2011
From: piotr.zolnierczuk at gmail.com (Piotr Zolnierczuk)
Date: Wed, 13 Jul 2011 18:24:27 -0400
Subject: [IPython-dev] embedding ipython kernel
In-Reply-To: <CAOvn4qiwEDmPaiYpsqJRtyNbbkzb=FkzueHD6V7+S42_uV=goQ@mail.gmail.com>
References: <CAB-kD6kw1o=zpCDiWFUCd2CgJe1JfXQ7k3LrWsrkTLgM1jyoHw@mail.gmail.com>
	<CAOvn4qgMEVavq=Lf2JbNufUt0RxLw+rQ6MBU7kkO3FK0vNjAbw@mail.gmail.com>
	<CAB-kD6m6Ni0cxn5v+pWgfCuDRvwej8gTHnmP7qHXgHnJi1y23g@mail.gmail.com>
	<CAOvn4qiwEDmPaiYpsqJRtyNbbkzb=FkzueHD6V7+S42_uV=goQ@mail.gmail.com>
Message-ID: <CAB-kD6k+Y=_351BkMJPO1s_W--ys-AkJ=EwkyjZqUFUNwY2_Mw@mail.gmail.com>

Precisely!

I will have a look at IPython.zmq.ipkernel.

Piotr

On Wed, Jul 13, 2011 at 6:20 PM, Thomas Kluyver <takowl at gmail.com> wrote:

> On 13 July 2011 23:15, Piotr Zolnierczuk <piotr.zolnierczuk at gmail.com>wrote:
>
>>
>> hardware <-- custom comm. --> [ my_interface_module, ipython_kernel]  <--
>> ZMQ --> ipython_console
>>
>
> That design makes sense.
>
> You can also make a profile for IPython to automatically load your modules,
> or embed the interactive shell within your application, if the extra
> communication layer isn't needed. The key advantage to using the kernel is
> that it can keep running without any client open, and you can connect to the
> session from different machines.
>
> Best wishes,
> Thomas
>



-- 

Piotr Adam Zolnierczuk
e-mail: piotr at zolnierczuk.net
www:   http://www.zolnierczuk.net
_____________________________________
written on recycled electrons
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110713/11401d6a/attachment.html>

From benjaminrk at gmail.com  Wed Jul 13 19:56:44 2011
From: benjaminrk at gmail.com (MinRK)
Date: Wed, 13 Jul 2011 18:56:44 -0500
Subject: [IPython-dev] IPython 0.11 RC2
Message-ID: <CAHNn8BVNs7dwGkXYuHdU3Y1=+X4a3BPWinCdcVTCfTB_AQdZbQ@mail.gmail.com>

Hello all,

Thanks for all your help with testing RC1!  We have just finished
cutting RC2, which has several bugfixes thanks to your reporting.

The only significant changes from RC1 are in command-line arguments,
in response to user feedback.

Please continue testing, and let us know what issues you find.  If
there are no more significant changes needed, we will cut the official 0.11
release in a week or so.

You can download the files at:

http://archive.ipython.org/testing

Up to date documentation is at:

http://ipython.org/ipython-doc/dev/index.html

including more details on everything that is new here:

http://ipython.org/ipython-doc/dev/whatsnew/version0.11.html

Thanks,
-The IPython team


From fperez.net at gmail.com  Wed Jul 13 23:46:08 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 13 Jul 2011 22:46:08 -0500
Subject: [IPython-dev] Is anyone going to euroscipy?
In-Reply-To: <4E1CA1D0.8040101@bostream.nu>
References: <4E1CA1D0.8040101@bostream.nu>
Message-ID: <CAHAreOo3CLvykeB=TThY46EW611pJPetf4jMuFOXHd_+9-uSsg@mail.gmail.com>

Hi Jorgen,

On Tue, Jul 12, 2011 at 2:34 PM, J?rgen Stenarson
<jorgen.stenarson at bostream.nu> wrote:
> Hi,
>
> I know Fernando is going to euroscipy in august. I'm also going but is
> anyone else coming? When are you planning to be there?

Glad I'll finally meet you!

> My tentative plan is to come a few days early to get some sightseeing
> done as well.

I'm only arriving one day early, unfortunately, on the 23rd.  I wish I
had more time, but this time around it won't be.  But we can
definitely meet up that day (I arrive in the morning), and I'm happy
to hang out with anyone else who may be coming, for geek talk or
otherwise.

Cheers,

f


From gael.varoquaux at normalesup.org  Wed Jul 13 23:49:24 2011
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Thu, 14 Jul 2011 05:49:24 +0200
Subject: [IPython-dev] Is anyone going to euroscipy?
In-Reply-To: <CAHAreOo3CLvykeB=TThY46EW611pJPetf4jMuFOXHd_+9-uSsg@mail.gmail.com>
References: <4E1CA1D0.8040101@bostream.nu>
	<CAHAreOo3CLvykeB=TThY46EW611pJPetf4jMuFOXHd_+9-uSsg@mail.gmail.com>
Message-ID: <20110714034924.GA12829@phare.normalesup.org>

On Wed, Jul 13, 2011 at 10:46:08PM -0500, Fernando Perez wrote:
> I'm only arriving one day early, unfortunately, on the 23rd.  I wish I
> had more time, but this time around it won't be.  But we can
> definitely meet up that day (I arrive in the morning), and I'm happy
> to hang out with anyone else who may be coming, for geek talk or
> otherwise.

They will be rooms with wireless open at ENS for sprinting, if people are
interested.

G


From fperez.net at gmail.com  Wed Jul 13 23:52:50 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 13 Jul 2011 22:52:50 -0500
Subject: [IPython-dev] Is anyone going to euroscipy?
In-Reply-To: <20110714034924.GA12829@phare.normalesup.org>
References: <4E1CA1D0.8040101@bostream.nu>
	<CAHAreOo3CLvykeB=TThY46EW611pJPetf4jMuFOXHd_+9-uSsg@mail.gmail.com>
	<20110714034924.GA12829@phare.normalesup.org>
Message-ID: <CAHAreOqFyzCKNst36E0XLF-j_7Ba=6dNii+TUJZwF+WxXbm5AA@mail.gmail.com>

On Wed, Jul 13, 2011 at 10:49 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
>
> They will be rooms with wireless open at ENS for sprinting, if people are
> interested.

Great, thanks!  I have to say that I'd be a little partial to
decompressing and enjoying the city for a day  :) (I haven't really
taken a proper break in months).  But if others want to get together
more for work than walking around Paris, I'm game too.

Cheers,

f

ps - done with your talk for tomorrow? :)


From gael.varoquaux at normalesup.org  Wed Jul 13 23:55:07 2011
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Thu, 14 Jul 2011 05:55:07 +0200
Subject: [IPython-dev] Is anyone going to euroscipy?
In-Reply-To: <CAHAreOqFyzCKNst36E0XLF-j_7Ba=6dNii+TUJZwF+WxXbm5AA@mail.gmail.com>
References: <4E1CA1D0.8040101@bostream.nu>
	<CAHAreOo3CLvykeB=TThY46EW611pJPetf4jMuFOXHd_+9-uSsg@mail.gmail.com>
	<20110714034924.GA12829@phare.normalesup.org>
	<CAHAreOqFyzCKNst36E0XLF-j_7Ba=6dNii+TUJZwF+WxXbm5AA@mail.gmail.com>
Message-ID: <20110714035507.GB12829@phare.normalesup.org>

On Wed, Jul 13, 2011 at 10:52:50PM -0500, Fernando Perez wrote:
> Great, thanks!  I have to say that I'd be a little partial to
> decompressing and enjoying the city for a day  :) (I haven't really
> taken a proper break in months).  But if others want to get together
> more for work than walking around Paris, I'm game too.

> ps - done with your talk for tomorrow? :)

Nope. I feel just like you describe in the above paragraph, but right
now, and about Austin :).

Gael


From benjaminrk at gmail.com  Thu Jul 14 01:13:16 2011
From: benjaminrk at gmail.com (MinRK)
Date: Thu, 14 Jul 2011 00:13:16 -0500
Subject: [IPython-dev] [IPython-User] IPython 0.11 RC2
In-Reply-To: <EA808E8C-9630-4B44-BB63-D092918B4B36@gmail.com>
References: <CAHNn8BVNs7dwGkXYuHdU3Y1=+X4a3BPWinCdcVTCfTB_AQdZbQ@mail.gmail.com>
	<4E1E3E28.1040300@uci.edu>
	<EA808E8C-9630-4B44-BB63-D092918B4B36@gmail.com>
Message-ID: <CAHNn8BVY65YX6WTiHJXm+vu3ECvAO47vduf6OBbk6gznWKL4bg@mail.gmail.com>

On Wed, Jul 13, 2011 at 19:57, Min RK <benjaminrk at gmail.com> wrote:
>
> On Jul 13, 2011, at 19:54, Christoph Gohlke <cgohlke at uci.edu> wrote:
>
>>
>>
>> On 7/13/2011 4:56 PM, MinRK wrote:
>>> Hello all,
>>>
>>> Thanks for all your help with testing RC1! ?We have just finished
>>> cutting RC2, which has several bugfixes thanks to your reporting.
>>>
>>> The only significant changes from RC1 are in command-line arguments,
>>> in response to user feedback.
>>>
>>> Please continue testing, and let us know what issues you find. ?If
>>> there are no more significant changes needed, we will cut the official 0.11
>>> release in a week or so.
>>>
>>> You can download the files at:
>>>
>>> http://archive.ipython.org/testing
>>>
>>> Up to date documentation is at:
>>>
>>> http://ipython.org/ipython-doc/dev/index.html
>>>
>>> including more details on everything that is new here:
>>>
>>> http://ipython.org/ipython-doc/dev/whatsnew/version0.11.html
>>>
>>> Thanks,
>>> -The IPython team
>>
>>
>> Hello,
>>
>> the "deathrow" package is missing in ipython-0.11.rc2.zip but is
>> specified in setupbase.py. Hence installation from source fails on Windows.
>
> Oh, for crying out loud. ?Thanks, I'll fix that.

Since I brilliantly managed to make rc2 not installable from source, I
just pushed rc3 with the tiny necessary fix.

(Thanks, Christoph)

>
>>
>> Christoph
>> _______________________________________________
>> IPython-User mailing list
>> IPython-User at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-user
>


From fperez.net at gmail.com  Thu Jul 14 04:09:06 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 14 Jul 2011 03:09:06 -0500
Subject: [IPython-dev] Scipy'11 talk slides
Message-ID: <CAHAreOq+xhHZ8gmTYKzPcftZA5x0mmTnuCp94DrC=vqCUJXv3Q@mail.gmail.com>

Hi all,

the Scipy talk was very well received, as evidenced by some of the comments on:

https://convore.com/scipy-2011/talk-ipython-a-new-architecture-for-interactive-and-parallel-computing/

and the noise on twitter.  Lots of people have put a ton of work into
making this possible, and it was great to see how well received this
effort is in the scipy community.

I know they'll post the slides and video later, and when we're done
migrating the site we'll put them up there nicely, but for now:

http://fperez.org/talks/1107_ipython_scipy.pdf

Please note that in the place of both the Qt and web screenshots, I
did live demos of each, which I think is what people liked most.  Lots
for 20 minutes, but overall I think it went well.

Cheers,

f

ps - thanks to Min for manning the fort in the meantime!!


From takowl at gmail.com  Thu Jul 14 06:35:07 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Thu, 14 Jul 2011 11:35:07 +0100
Subject: [IPython-dev] Is anyone going to euroscipy?
In-Reply-To: <4E1CA1D0.8040101@bostream.nu>
References: <4E1CA1D0.8040101@bostream.nu>
Message-ID: <CAOvn4qiGfFg0muwB+bw6tQ58cK6oCAfpA-zSocF7gqMxjPZkFA@mail.gmail.com>

On 12 July 2011 20:34, J?rgen Stenarson <jorgen.stenarson at bostream.nu>wrote:

>
> I know Fernando is going to euroscipy in august. I'm also going but is
> anyone else coming? When are you planning to be there?


I haven't made up my mind yet, although I'm aware the early bird
registration deadline is coming up fast. It would be good to see some more
of you, and I've never actually been to Paris, although it's an easy enough
journey by train.

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

From fperez.net at gmail.com  Thu Jul 14 08:39:37 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 14 Jul 2011 07:39:37 -0500
Subject: [IPython-dev] Is anyone going to euroscipy?
In-Reply-To: <CAOvn4qiGfFg0muwB+bw6tQ58cK6oCAfpA-zSocF7gqMxjPZkFA@mail.gmail.com>
References: <4E1CA1D0.8040101@bostream.nu>
	<CAOvn4qiGfFg0muwB+bw6tQ58cK6oCAfpA-zSocF7gqMxjPZkFA@mail.gmail.com>
Message-ID: <CAHAreOqfupK61yoWNBoYarwLwB_s9xkUjpa5f_u7b1sg7Qz3DA@mail.gmail.com>

On Thu, Jul 14, 2011 at 5:35 AM, Thomas Kluyver <takowl at gmail.com> wrote:
> I haven't made up my mind yet, although I'm aware the early bird
> registration deadline is coming up fast. It would be good to see some more
> of you, and I've never actually been to Paris, although it's an easy enough
> journey by train.

If it helps tip your decision, big +1 to you coming :)

Best,

f


From takowl at gmail.com  Thu Jul 14 08:51:58 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Thu, 14 Jul 2011 13:51:58 +0100
Subject: [IPython-dev] Colours in IPython 0.11 rc1 PPA package
Message-ID: <CAOvn4qgSjCF-RWcxjxEPrgRDC70+LBia6x0CoFcyrWQfPbgUoA@mail.gmail.com>

Hi Julian,

I notice that IPython in the terminal, as installed from your PPA, uses the
LightBG colours by default on Linux, which makes some bits hard to see in
the standard dark-background terminal. Looking at the code, it looks like
get_default_colors() has been tweaked to return 'LightBG' on Linux. I'd
prefer to have it back to the standard code when you package the next
version, if that's alright.

In fact, I quite like some aspects of the theme, like the blue input
prompts, and I wouldn't mind helping to design a new colour scheme for dark
backgrounds. But until then, I think the 'Linux' colour scheme should stay
as the default.

Thanks again for the packaging,

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

From jtaylor.debian at googlemail.com  Thu Jul 14 09:56:59 2011
From: jtaylor.debian at googlemail.com (Julian Taylor)
Date: Thu, 14 Jul 2011 15:56:59 +0200
Subject: [IPython-dev] Colours in IPython 0.11 rc1 PPA package
In-Reply-To: <CAOvn4qgSjCF-RWcxjxEPrgRDC70+LBia6x0CoFcyrWQfPbgUoA@mail.gmail.com>
References: <CAOvn4qgSjCF-RWcxjxEPrgRDC70+LBia6x0CoFcyrWQfPbgUoA@mail.gmail.com>
Message-ID: <4E1EF5AB.3020109@googlemail.com>

On 07/14/2011 02:51 PM, Thomas Kluyver wrote:
> Hi Julian,
> 
> I notice that IPython in the terminal, as installed from your PPA, uses
> the LightBG colours by default on Linux, which makes some bits hard to
> see in the standard dark-background terminal. Looking at the code, it
> looks like get_default_colors() has been tweaked to return 'LightBG' on
> Linux. I'd prefer to have it back to the standard code when you package
> the next version, if that's alright.
> 
> In fact, I quite like some aspects of the theme, like the blue input
> prompts, and I wouldn't mind helping to design a new colour scheme for
> dark backgrounds. But until then, I think the 'Linux' colour scheme
> should stay as the default.
> 
> Thanks again for the packaging,
> 
> Thomas

yes I modified the default color. The main reason is that in terminals
with light backgrounds certain elements, like source code in tracebacks,
are almost unreadable (bright yellow,grey on white) whereas with LightBG
you can still read everything quite well even a dark background terminal.
So I chose the in my opinion the lesser of two evils. Also the debian
default gnome-terminal has a light background (and its what I use too ;) ).

Its hard to please everyone with the default. Ideally there should be
some detection of the terminal background color at runtime.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110714/8de9732c/attachment.sig>

From takowl at gmail.com  Thu Jul 14 10:53:26 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Thu, 14 Jul 2011 15:53:26 +0100
Subject: [IPython-dev] Colours in IPython 0.11 rc1 PPA package
In-Reply-To: <4E1EF5AB.3020109@googlemail.com>
References: <CAOvn4qgSjCF-RWcxjxEPrgRDC70+LBia6x0CoFcyrWQfPbgUoA@mail.gmail.com>
	<4E1EF5AB.3020109@googlemail.com>
Message-ID: <CAOvn4qgh+YLaqqOgd=uxmV6ui4WHs4_bWGPGAkgr7xRFpCyfpg@mail.gmail.com>

On 14 July 2011 14:56, Julian Taylor <jtaylor.debian at googlemail.com> wrote:

> yes I modified the default color. The main reason is that in terminals
> with light backgrounds certain elements, like source code in tracebacks,
> are almost unreadable (bright yellow,grey on white) whereas with LightBG
> you can still read everything quite well even a dark background terminal.
> So I chose the in my opinion the lesser of two evils. Also the debian
> default gnome-terminal has a light background (and its what I use too ;) ).
>
> Its hard to please everyone with the default. Ideally there should be
> some detection of the terminal background color at runtime.
>

OK, I didn't know Debian used a light background by default. So it's going
to need to be changed between the Debian package and the Ubuntu package. It
can easily be changed in the config file if the user has their terminal set
up differently, but I think it is important that we match the default on
each platform.

At least in my terminal, unfortunately I can't read everything properly with
the LightBG colours. In particular, tracebacks and the code shown by obj??
are both too dark to see easily.

I'll have a look at whether it's possible to detect colors. The best thing I
can find at a glance is the dircolors command. If you've got a debian
machine, can you send me the output of "dircolors --print-database", and
I'll compare it to the same on my own system.

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

From fperez.net at gmail.com  Thu Jul 14 12:26:24 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 14 Jul 2011 11:26:24 -0500
Subject: [IPython-dev] Colours in IPython 0.11 rc1 PPA package
In-Reply-To: <4E1EF5AB.3020109@googlemail.com>
References: <CAOvn4qgSjCF-RWcxjxEPrgRDC70+LBia6x0CoFcyrWQfPbgUoA@mail.gmail.com>
	<4E1EF5AB.3020109@googlemail.com>
Message-ID: <CAHAreOoLaH_KeVqCVanzM+VXhnJZu6kJaa1FtFgnanwS9rkjUg@mail.gmail.com>

On Thu, Jul 14, 2011 at 8:56 AM, Julian Taylor
<jtaylor.debian at googlemail.com> wrote:
>
> Its hard to please everyone with the default. Ideally there should be
> some detection of the terminal background color at runtime.

If you can let us know how to do that, we'd be glad to.  Applescript
hacks have been posted to do it on osx and for the default
terminal.app, I have no idea how to do that generically on arbitrary
terminal apps (there's easily a dozen on *nix, from old xterms to
things like terminator).

Cheers,

f


From benjaminrk at gmail.com  Thu Jul 14 12:42:19 2011
From: benjaminrk at gmail.com (MinRK)
Date: Thu, 14 Jul 2011 11:42:19 -0500
Subject: [IPython-dev] Colours in IPython 0.11 rc1 PPA package
In-Reply-To: <CAHAreOoLaH_KeVqCVanzM+VXhnJZu6kJaa1FtFgnanwS9rkjUg@mail.gmail.com>
References: <CAOvn4qgSjCF-RWcxjxEPrgRDC70+LBia6x0CoFcyrWQfPbgUoA@mail.gmail.com>
	<4E1EF5AB.3020109@googlemail.com>
	<CAHAreOoLaH_KeVqCVanzM+VXhnJZu6kJaa1FtFgnanwS9rkjUg@mail.gmail.com>
Message-ID: <CAHNn8BWtn60UeOmoCbendQiZF1SZoeznUxUe6TzF5T=+4c5d1Q@mail.gmail.com>

Since this is such a basic problem and there doesn't appear to be a
good solution, does it make sense to just mention '%colors' in the
banner?

Also, Ubuntu did have light backgrounds on unconfigured terminals as
well, at least for a while.  I'm not sure what it is now, since I
haven't done a clean install in some time.  Probably purple.

-MinRK

On Thu, Jul 14, 2011 at 11:26, Fernando Perez <fperez.net at gmail.com> wrote:
> On Thu, Jul 14, 2011 at 8:56 AM, Julian Taylor
> <jtaylor.debian at googlemail.com> wrote:
>>
>> Its hard to please everyone with the default. Ideally there should be
>> some detection of the terminal background color at runtime.
>
> If you can let us know how to do that, we'd be glad to. ?Applescript
> hacks have been posted to do it on osx and for the default
> terminal.app, I have no idea how to do that generically on arbitrary
> terminal apps (there's easily a dozen on *nix, from old xterms to
> things like terminator).
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>


From takowl at gmail.com  Thu Jul 14 12:59:30 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Thu, 14 Jul 2011 17:59:30 +0100
Subject: [IPython-dev] Colours in IPython 0.11 rc1 PPA package
In-Reply-To: <CAHNn8BWtn60UeOmoCbendQiZF1SZoeznUxUe6TzF5T=+4c5d1Q@mail.gmail.com>
References: <CAOvn4qgSjCF-RWcxjxEPrgRDC70+LBia6x0CoFcyrWQfPbgUoA@mail.gmail.com>
	<4E1EF5AB.3020109@googlemail.com>
	<CAHAreOoLaH_KeVqCVanzM+VXhnJZu6kJaa1FtFgnanwS9rkjUg@mail.gmail.com>
	<CAHNn8BWtn60UeOmoCbendQiZF1SZoeznUxUe6TzF5T=+4c5d1Q@mail.gmail.com>
Message-ID: <CAOvn4qgf4YpB_xRUX5QZktPSJBHViMB5svU4RN_BPLSgdy5zLg@mail.gmail.com>

On 14 July 2011 17:42, MinRK <benjaminrk at gmail.com> wrote:

> Also, Ubuntu did have light backgrounds on unconfigured terminals as
> well, at least for a while.  I'm not sure what it is now, since I
> haven't done a clean install in some time.  Probably purple.
>

It is actually a dark purple ;-)

I don't remember Ubuntu's standard terminal having a light background by
default. You get a light background if you start xterm, but the standard
GNOME terminal is dark (as is Konsole on Kubuntu).

I wonder if it's possible to design a colour set that is legible on either
background? A significant amount of LightBG works on a dark background, so
it should be possible, if a bit more bland.

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

From gael.varoquaux at normalesup.org  Thu Jul 14 15:49:57 2011
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Thu, 14 Jul 2011 21:49:57 +0200
Subject: [IPython-dev] Is anyone going to euroscipy?
In-Reply-To: <CAHAreOqfupK61yoWNBoYarwLwB_s9xkUjpa5f_u7b1sg7Qz3DA@mail.gmail.com>
References: <4E1CA1D0.8040101@bostream.nu>
	<CAOvn4qiGfFg0muwB+bw6tQ58cK6oCAfpA-zSocF7gqMxjPZkFA@mail.gmail.com>
	<CAHAreOqfupK61yoWNBoYarwLwB_s9xkUjpa5f_u7b1sg7Qz3DA@mail.gmail.com>
Message-ID: <20110714194957.GE15788@phare.normalesup.org>

On Thu, Jul 14, 2011 at 07:39:37AM -0500, Fernando Perez wrote:
> If it helps tip your decision, big +1 to you coming :)

I'd love to meet you there!

G


From takowl at gmail.com  Thu Jul 14 15:57:06 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Thu, 14 Jul 2011 20:57:06 +0100
Subject: [IPython-dev] Is anyone going to euroscipy?
In-Reply-To: <20110714194957.GE15788@phare.normalesup.org>
References: <4E1CA1D0.8040101@bostream.nu>
	<CAOvn4qiGfFg0muwB+bw6tQ58cK6oCAfpA-zSocF7gqMxjPZkFA@mail.gmail.com>
	<CAHAreOqfupK61yoWNBoYarwLwB_s9xkUjpa5f_u7b1sg7Qz3DA@mail.gmail.com>
	<20110714194957.GE15788@phare.normalesup.org>
Message-ID: <CAOvn4qgx+gpNYAFbNGtwi=rcQGN8fD4KtScsqo=h+HTF229RrA@mail.gmail.com>

On 14 July 2011 20:49, Gael Varoquaux <gael.varoquaux at normalesup.org> wrote:

> > If it helps tip your decision, big +1 to you coming :)
>
> I'd love to meet you there!


Thanks, both of you, I'll see if I can arrange to be there :-)

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

From wardefar at iro.umontreal.ca  Thu Jul 14 22:36:07 2011
From: wardefar at iro.umontreal.ca (David Warde-Farley)
Date: Thu, 14 Jul 2011 21:36:07 -0500
Subject: [IPython-dev] 2.6 dependencies in 0.11?
Message-ID: <549EB7CB-D1A4-4B96-889F-444FB19D08D7@iro.umontreal.ca>

Friends,

I am in the unfortunate situation of being currently unable to coax a move to 2.6 or 2.7 on behalf of my lab. That said, I am craving like an addict the qtconsole at work.

My question is mainly, is there anything more than the 'with' statement that makes 2.6 a hard dependency? If not, I may just go through and generate a patch for the necessary __future__ imports, to be applied for my nefarious purposes...

Cheers,

David

From ellisonbg at gmail.com  Thu Jul 14 23:15:15 2011
From: ellisonbg at gmail.com (Brian Granger)
Date: Thu, 14 Jul 2011 20:15:15 -0700
Subject: [IPython-dev] 2.6 dependencies in 0.11?
In-Reply-To: <549EB7CB-D1A4-4B96-889F-444FB19D08D7@iro.umontreal.ca>
References: <549EB7CB-D1A4-4B96-889F-444FB19D08D7@iro.umontreal.ca>
Message-ID: <CAH4pYpRSqSd7VNynwJUy8BhY2Q1ZofL50r9CuBWDeisVKWnuFg@mail.gmail.com>

Yes, IPython requires Python 2.6 and above.  Keeping 2.5 support would
have made the move to Python 3 almost impossible.  At this point, the
code base has many 2.6 and above specific things, I am afraid it is
not as simple as adding __future__ imports.

Cheers,

Brian

On Thu, Jul 14, 2011 at 7:36 PM, David Warde-Farley
<wardefar at iro.umontreal.ca> wrote:
> Friends,
>
> I am in the unfortunate situation of being currently unable to coax a move to 2.6 or 2.7 on behalf of my lab. That said, I am craving like an addict the qtconsole at work.
>
> My question is mainly, is there anything more than the 'with' statement that makes 2.6 a hard dependency? If not, I may just go through and generate a patch for the necessary __future__ imports, to be applied for my nefarious purposes...
>
> Cheers,
>
> David
> _______________________________________________
> 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 wardefar at iro.umontreal.ca  Thu Jul 14 23:38:42 2011
From: wardefar at iro.umontreal.ca (David Warde-Farley)
Date: Thu, 14 Jul 2011 22:38:42 -0500
Subject: [IPython-dev] 2.6 dependencies in 0.11?
In-Reply-To: <CAH4pYpRSqSd7VNynwJUy8BhY2Q1ZofL50r9CuBWDeisVKWnuFg@mail.gmail.com>
References: <549EB7CB-D1A4-4B96-889F-444FB19D08D7@iro.umontreal.ca>
	<CAH4pYpRSqSd7VNynwJUy8BhY2Q1ZofL50r9CuBWDeisVKWnuFg@mail.gmail.com>
Message-ID: <87C4E5B1-DAAE-42B0-A54E-72556E0FB9A3@iro.umontreal.ca>

On 2011-07-14, at 10:15 PM, Brian Granger wrote:

> Yes, IPython requires Python 2.6 and above.  Keeping 2.5 support would
> have made the move to Python 3 almost impossible.  At this point, the
> code base has many 2.6 and above specific things, I am afraid it is
> not as simple as adding __future__ imports.

Okeydoke, thanks for saving me the wasted time. I may just build a copy of 2.6 in my home directory. Sigh...

David

From fperez.net at gmail.com  Fri Jul 15 02:16:36 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 15 Jul 2011 01:16:36 -0500
Subject: [IPython-dev] Colours in IPython 0.11 rc1 PPA package
In-Reply-To: <CAOvn4qgf4YpB_xRUX5QZktPSJBHViMB5svU4RN_BPLSgdy5zLg@mail.gmail.com>
References: <CAOvn4qgSjCF-RWcxjxEPrgRDC70+LBia6x0CoFcyrWQfPbgUoA@mail.gmail.com>
	<4E1EF5AB.3020109@googlemail.com>
	<CAHAreOoLaH_KeVqCVanzM+VXhnJZu6kJaa1FtFgnanwS9rkjUg@mail.gmail.com>
	<CAHNn8BWtn60UeOmoCbendQiZF1SZoeznUxUe6TzF5T=+4c5d1Q@mail.gmail.com>
	<CAOvn4qgf4YpB_xRUX5QZktPSJBHViMB5svU4RN_BPLSgdy5zLg@mail.gmail.com>
Message-ID: <CAHAreOopzecgTPt7h40nuzubjw8nDs2AX8PUVjKjFAsRg78rpg@mail.gmail.com>

On Thu, Jul 14, 2011 at 11:59 AM, Thomas Kluyver <takowl at gmail.com> wrote:
>
> I wonder if it's possible to design a colour set that is legible on either
> background? A significant amount of LightBG works on a dark background, so
> it should be possible, if a bit more bland.

It should be possible, just mixing a little of both, and using NoColor
in a few more cases.  Less fancy but more robust...

Post-0.11 what we need is to move this machinery over from ANSI
escapes to a proper styling mechanism, so that clients aren't forced
to interpret ANSI (like Evan had to do for the Qt console).

Cheers,

f


From takowl at gmail.com  Fri Jul 15 06:26:42 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Fri, 15 Jul 2011 11:26:42 +0100
Subject: [IPython-dev] 2.6 dependencies in 0.11?
In-Reply-To: <87C4E5B1-DAAE-42B0-A54E-72556E0FB9A3@iro.umontreal.ca>
References: <549EB7CB-D1A4-4B96-889F-444FB19D08D7@iro.umontreal.ca>
	<CAH4pYpRSqSd7VNynwJUy8BhY2Q1ZofL50r9CuBWDeisVKWnuFg@mail.gmail.com>
	<87C4E5B1-DAAE-42B0-A54E-72556E0FB9A3@iro.umontreal.ca>
Message-ID: <CAOvn4qjB_081rXG=Q5m=rNCQJ7Ga7P=aF0UNcmCfBbET_tkHpA@mail.gmail.com>

On 15 July 2011 04:38, David Warde-Farley <wardefar at iro.umontreal.ca> wrote:

> Okeydoke, thanks for saving me the wasted time. I may just build a copy of
> 2.6 in my home directory. Sigh...


When the other Python users see the Qt console, you might get that upgrade
after all. ;-)

I think it should be possible to have different versions of Python installed
system-wide. Leave 2.5 as the default to avoid arguments, and have 2.7 or
2.6 available when explicitly called.

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

From takowl at gmail.com  Fri Jul 15 07:13:50 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Fri, 15 Jul 2011 12:13:50 +0100
Subject: [IPython-dev] 'Unwrapping' decorated functions in IPython
Message-ID: <CAOvn4qjjGzu4xkFKk8SuQ0RsoW4HS7NfAfxz=dfpnuSEPVveBA@mail.gmail.com>

Hi Michele,

Ben's been working on getting IPython's "func??" introspection to
automatically unwrap functions decorated with @decorator. (
https://github.com/ipython/ipython/pull/578 )

If a function is wrapped in several layers, f.__wrapped__ refers to the
object one level below. This is in contrast to Python 3 functools.wraps,
which seems to point __wrapped__ to the original function from any wrapping
layer. Of course, we could unwrap repeatedly in a while loop, but I'm
reluctant to do this in case strange objects from other packages drop it
into an infinite loop.

Would you consider making __wrapped__ (or another similar attribute) point
to the original function when several layers of wrapping are present? Or do
you know of a better way to approach the problem?

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

From takowl at gmail.com  Fri Jul 15 08:02:44 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Fri, 15 Jul 2011 13:02:44 +0100
Subject: [IPython-dev] 'Unwrapping' decorated functions in IPython
In-Reply-To: <CAOrwJ=aggV-Lg6C+eO6VmcFMupg1iK5zV9-8RSBsAMmeWfKfnQ@mail.gmail.com>
References: <CAOvn4qjjGzu4xkFKk8SuQ0RsoW4HS7NfAfxz=dfpnuSEPVveBA@mail.gmail.com>
	<CAOrwJ=aggV-Lg6C+eO6VmcFMupg1iK5zV9-8RSBsAMmeWfKfnQ@mail.gmail.com>
Message-ID: <CAOvn4qhXAXbe=axnk2cN+PqQ9x56pX-wL7qmw2JGtARD4=8Sbw@mail.gmail.com>

On 15 July 2011 12:29, Michele Simionato <michele.simionato at gmail.com>wrote:

> Following the lead of  functools.wraps seems to be a sensible way to go,
> even if the "onion-like" behavior seems more natural to me. Since I am an
> user of IPython, it is my interest to have this functionality
> working. Consider this added to the list of feature requests I have for the
> decorator module. If it will enter in the next release of the module I will
> keep you informed.


Great, thanks Michele.

Ben, let's revert to the original design to just unwrap one layer, then.

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

From takowl at gmail.com  Fri Jul 15 09:35:44 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Fri, 15 Jul 2011 14:35:44 +0100
Subject: [IPython-dev] 'Unwrapping' decorated functions in IPython
In-Reply-To: <CAOrwJ=ZMv-HZSWesm1=Gcx4iDo36G+kZ4Fv2LYka2tmFKT9EBg@mail.gmail.com>
References: <CAOvn4qjjGzu4xkFKk8SuQ0RsoW4HS7NfAfxz=dfpnuSEPVveBA@mail.gmail.com>
	<CAOrwJ=aggV-Lg6C+eO6VmcFMupg1iK5zV9-8RSBsAMmeWfKfnQ@mail.gmail.com>
	<CAOvn4qhXAXbe=axnk2cN+PqQ9x56pX-wL7qmw2JGtARD4=8Sbw@mail.gmail.com>
	<CAOrwJ=ZMv-HZSWesm1=Gcx4iDo36G+kZ4Fv2LYka2tmFKT9EBg@mail.gmail.com>
Message-ID: <CAOvn4qgXfcCbSMFX049DJmWt=QXt5cU0=rO6HdEK=egYXPGLPw@mail.gmail.com>

On 15 July 2011 14:11, Michele Simionato <michele.simionato at gmail.com>wrote:

> Are you sure Python 3.2 behavior is a design decision and not just an
> artifact (perhaps unwanted) of the current implementation?
>

No, not at all, it's just what I found happens when I try it. Looking at the
code for functools, I'm not even sure quite how it happens.

I agree that in many ways it makes more sense to have __wrapped__ look a
single layer down. In most code, you can just use a while loop to unwrap to
the bottom layer. But obviously people can call obj?? on any random Python
object, so we need to be a bit careful about what we assume.

Would it make sense to have an attribute called something like
_base_wrapped? Then in IPython, we could do:

obj = getattr(obj, "_base_wrapped", getattr(obj, "__wrapped__", obj))

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

From bedwards at cs.unm.edu  Fri Jul 15 09:46:17 2011
From: bedwards at cs.unm.edu (Ben Edwards)
Date: Fri, 15 Jul 2011 08:46:17 -0500
Subject: [IPython-dev] 'Unwrapping' decorated functions in IPython
In-Reply-To: <CAOvn4qhXAXbe=axnk2cN+PqQ9x56pX-wL7qmw2JGtARD4=8Sbw@mail.gmail.com>
References: <CAOvn4qjjGzu4xkFKk8SuQ0RsoW4HS7NfAfxz=dfpnuSEPVveBA@mail.gmail.com>
	<CAOrwJ=aggV-Lg6C+eO6VmcFMupg1iK5zV9-8RSBsAMmeWfKfnQ@mail.gmail.com>
	<CAOvn4qhXAXbe=axnk2cN+PqQ9x56pX-wL7qmw2JGtARD4=8Sbw@mail.gmail.com>
Message-ID: <CAP4Ca8WxC2s4V25Y1cFugGaxYihWA1JFi1d2+hoJCNEdpQGYew@mail.gmail.com>

Thanks this sounds like a plan, I reverted the to the original in the pull
request.

Ben

On Fri, Jul 15, 2011 at 7:02 AM, Thomas Kluyver <takowl at gmail.com> wrote:

> On 15 July 2011 12:29, Michele Simionato <michele.simionato at gmail.com>wrote:
>
>> Following the lead of  functools.wraps seems to be a sensible way to go,
>> even if the "onion-like" behavior seems more natural to me. Since I am an
>> user of IPython, it is my interest to have this functionality
>> working. Consider this added to the list of feature requests I have for the
>> decorator module. If it will enter in the next release of the module I will
>> keep you informed.
>
>
> Great, thanks Michele.
>
> Ben, let's revert to the original design to just unwrap one layer, then.
>
> Best wishes,
> Thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110715/385a846a/attachment.html>

From bedwards at cs.unm.edu  Fri Jul 15 10:03:12 2011
From: bedwards at cs.unm.edu (Ben Edwards)
Date: Fri, 15 Jul 2011 09:03:12 -0500
Subject: [IPython-dev] 'Unwrapping' decorated functions in IPython
In-Reply-To: <CAP4Ca8WxC2s4V25Y1cFugGaxYihWA1JFi1d2+hoJCNEdpQGYew@mail.gmail.com>
References: <CAOvn4qjjGzu4xkFKk8SuQ0RsoW4HS7NfAfxz=dfpnuSEPVveBA@mail.gmail.com>
	<CAOrwJ=aggV-Lg6C+eO6VmcFMupg1iK5zV9-8RSBsAMmeWfKfnQ@mail.gmail.com>
	<CAOvn4qhXAXbe=axnk2cN+PqQ9x56pX-wL7qmw2JGtARD4=8Sbw@mail.gmail.com>
	<CAP4Ca8WxC2s4V25Y1cFugGaxYihWA1JFi1d2+hoJCNEdpQGYew@mail.gmail.com>
Message-ID: <CAP4Ca8VojbY8O23i74r8pSf26swWOuah_L1cCmw8Na9P1QtvVA@mail.gmail.com>

Whoops missed the thread before I sent my email. Looks like we need to think
more.

On Fri, Jul 15, 2011 at 8:46 AM, Ben Edwards <bedwards at cs.unm.edu> wrote:

> Thanks this sounds like a plan, I reverted the to the original in the pull
> request.
>
> Ben
>
>
> On Fri, Jul 15, 2011 at 7:02 AM, Thomas Kluyver <takowl at gmail.com> wrote:
>
>> On 15 July 2011 12:29, Michele Simionato <michele.simionato at gmail.com>wrote:
>>
>>> Following the lead of  functools.wraps seems to be a sensible way to go,
>>> even if the "onion-like" behavior seems more natural to me. Since I am an
>>> user of IPython, it is my interest to have this functionality
>>> working. Consider this added to the list of feature requests I have for the
>>> decorator module. If it will enter in the next release of the module I will
>>> keep you informed.
>>
>>
>> Great, thanks Michele.
>>
>> Ben, let's revert to the original design to just unwrap one layer, then.
>>
>> Best wishes,
>> Thomas
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110715/b84b927c/attachment.html>

From takowl at gmail.com  Fri Jul 15 10:22:33 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Fri, 15 Jul 2011 15:22:33 +0100
Subject: [IPython-dev] 'Unwrapping' decorated functions in IPython
In-Reply-To: <CAOrwJ=a=Pja2FLp+WrjMOfisvPZp=O9nLtbShmZTenbgVHJr9w@mail.gmail.com>
References: <CAOvn4qjjGzu4xkFKk8SuQ0RsoW4HS7NfAfxz=dfpnuSEPVveBA@mail.gmail.com>
	<CAOrwJ=aggV-Lg6C+eO6VmcFMupg1iK5zV9-8RSBsAMmeWfKfnQ@mail.gmail.com>
	<CAOvn4qhXAXbe=axnk2cN+PqQ9x56pX-wL7qmw2JGtARD4=8Sbw@mail.gmail.com>
	<CAOrwJ=ZMv-HZSWesm1=Gcx4iDo36G+kZ4Fv2LYka2tmFKT9EBg@mail.gmail.com>
	<CAOvn4qgXfcCbSMFX049DJmWt=QXt5cU0=rO6HdEK=egYXPGLPw@mail.gmail.com>
	<CAOrwJ=a=Pja2FLp+WrjMOfisvPZp=O9nLtbShmZTenbgVHJr9w@mail.gmail.com>
Message-ID: <CAOvn4qhNMeBtFEHVH49_Kg_UnWYQdevGdDrAwYgOjSLh57gfyA@mail.gmail.com>

On 15 July 2011 14:57, Michele Simionato <michele.simionato at gmail.com>wrote:

> in practice I think this cannot happen accidentally, but only if ones
> builds a contrived example
> like the following:
>

My concern is that if some bizarre object's __getattr__ method falls back on
returning an object of the same type as itself, and there isn't an actual
__wrapped__ attribute, we end up going round in circles. Of course, it's
easy enough to Ctrl-C out of it, but it's not ideal.

Maybe an unwrapping limit as you suggest is the best way forwards. If the
limit is something like 100, it should get to the bottom of any set of
decorators, but still seem instant if something recurses.

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

From takowl at gmail.com  Fri Jul 15 10:38:03 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Fri, 15 Jul 2011 15:38:03 +0100
Subject: [IPython-dev] 'Unwrapping' decorated functions in IPython
In-Reply-To: <CAOrwJ=YPLZkTJKUTKgDXbrUfVd4oJwQxAtZQNx1uJ1Oh_djd5w@mail.gmail.com>
References: <CAOvn4qjjGzu4xkFKk8SuQ0RsoW4HS7NfAfxz=dfpnuSEPVveBA@mail.gmail.com>
	<CAOrwJ=aggV-Lg6C+eO6VmcFMupg1iK5zV9-8RSBsAMmeWfKfnQ@mail.gmail.com>
	<CAOvn4qhXAXbe=axnk2cN+PqQ9x56pX-wL7qmw2JGtARD4=8Sbw@mail.gmail.com>
	<CAOrwJ=ZMv-HZSWesm1=Gcx4iDo36G+kZ4Fv2LYka2tmFKT9EBg@mail.gmail.com>
	<CAOvn4qgXfcCbSMFX049DJmWt=QXt5cU0=rO6HdEK=egYXPGLPw@mail.gmail.com>
	<CAOrwJ=a=Pja2FLp+WrjMOfisvPZp=O9nLtbShmZTenbgVHJr9w@mail.gmail.com>
	<CAOvn4qhNMeBtFEHVH49_Kg_UnWYQdevGdDrAwYgOjSLh57gfyA@mail.gmail.com>
	<CAOrwJ=YPLZkTJKUTKgDXbrUfVd4oJwQxAtZQNx1uJ1Oh_djd5w@mail.gmail.com>
Message-ID: <CAOvn4qhxEAurDOvjfm8xqWNeb1MQJMy149AReHHGJsiQek920g@mail.gmail.com>

On 15 July 2011 15:27, Michele Simionato <michele.simionato at gmail.com>wrote:

> Yes, but the decorator module by design only works on true functions, not
> on objects where you can define your custom __getattr__. Your objection
> stands for callable objects but I believe IPython is able to distinguish
> callables from true functions, right?


We could check against types.FunctionType. But I'm fairly sure the functools
wrapping can be used on arbitrary callables, and it's a handy link that
other tools might make. So I'd prefer not to do that. I think the unwrapping
limit is the best idea we've had - it should only take an extra couple of
lines of code, and I don't think there's any situation where it will fall
over.

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

From fperez.net at gmail.com  Fri Jul 15 19:32:35 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 15 Jul 2011 16:32:35 -0700
Subject: [IPython-dev] Scipy'11 talk slides
In-Reply-To: <CAHAreOq+xhHZ8gmTYKzPcftZA5x0mmTnuCp94DrC=vqCUJXv3Q@mail.gmail.com>
References: <CAHAreOq+xhHZ8gmTYKzPcftZA5x0mmTnuCp94DrC=vqCUJXv3Q@mail.gmail.com>
Message-ID: <CAHAreOoB_jiUajYVm80uk-R4T_7YNa4DWdv73j7p3QEMe5qmqw@mail.gmail.com>

On Thu, Jul 14, 2011 at 1:09 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> the Scipy talk was very well received, as evidenced by some of the comments

And many thanks to Chris Fonnesbeck for this awesome review of the new toys:

http://stronginference.com/weblog/2011/7/15/innovations-in-ipython.html

This is excellent, and we'll link to it from the "what's new"
document, as it's really a great tour of the core new toys.

Regards,

f


From jason-sage at creativetrax.com  Sat Jul 16 01:08:51 2011
From: jason-sage at creativetrax.com (Jason Grout)
Date: Fri, 15 Jul 2011 22:08:51 -0700
Subject: [IPython-dev] git and google code
Message-ID: <4E211CE3.105@creativetrax.com>

Apparently now you can create and use git repositories with Google Code! 
  For example, here is our single-cell python server as a git repository 
on google code:

http://code.google.com/p/python-singlecell/source/list

Anyways, I thought you guys might like to know.  When you create a 
project, you can choose to use git as a vcs.

Thanks,

Jason

--
Jason Grout


From takowl at gmail.com  Sat Jul 16 15:52:23 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Sat, 16 Jul 2011 20:52:23 +0100
Subject: [IPython-dev] git and google code
In-Reply-To: <4E211CE3.105@creativetrax.com>
References: <4E211CE3.105@creativetrax.com>
Message-ID: <CAOvn4qhaJ-zfvP2tYaBLtNQOdNbi8k9MoxM+Mv--fA7SYbye+g@mail.gmail.com>

On 16 July 2011 06:08, Jason Grout <jason-sage at creativetrax.com> wrote:

> Apparently now you can create and use git repositories with Google Code!
>  For example, here is our single-cell python server as a git repository
> on google code:
>
> http://code.google.com/p/python-singlecell/source/list
>
> Anyways, I thought you guys might like to know.  When you create a
> project, you can choose to use git as a vcs.
>

Good to know, but for me at least, Github is pretty much the top selling
point of git.

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

From fperez.net at gmail.com  Sun Jul 17 00:22:13 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 16 Jul 2011 21:22:13 -0700
Subject: [IPython-dev] Another good blog post - we must be doing something
	right...
Message-ID: <CAHAreOp4YuSTw3pdH-EHaYMChBAAA+gwi06-q8S3XSa0bCWcgg@mail.gmail.com>

In addition to Chris Fonnesbeck's thorough review, here's another one,
shorter but equally positive:

http://blog.rtwilson.com/the-new-ipython-is-awesome

I just heard from Min (who's still at SciPy'11 as it winds down) that
the sprints have been very productive, catching several bugs,
including a particularly nasty one that  could lock up an entire
system, discovered by Stefan.

But I think we're in pretty good shape for a full release of 0.11
soon.  I have a long day trapped in planes on Monday and I'll work on
finishing up the man pages business via rst2man and the release notes,
and we can then decide when to cut the final release later in the
week.

Cheers,

f


From ischnell at enthought.com  Sun Jul 17 00:59:58 2011
From: ischnell at enthought.com (Ilan Schnell)
Date: Sat, 16 Jul 2011 23:59:58 -0500
Subject: [IPython-dev] Another good blog post - we must be doing
	something right...
In-Reply-To: <CAHAreOp4YuSTw3pdH-EHaYMChBAAA+gwi06-q8S3XSa0bCWcgg@mail.gmail.com>
References: <CAHAreOp4YuSTw3pdH-EHaYMChBAAA+gwi06-q8S3XSa0bCWcgg@mail.gmail.com>
Message-ID: <CAAUn5qLvE3cj9j7K5jC6g2J_uHtzcmZFf0k5KXBJWJt4G-J4+g@mail.gmail.com>

Thanks for the link.  Here is another one saw on reddit today:
http://stronginference.com/weblog/2011/7/15/innovations-in-ipython.html

As promised, I will write a blog post about the import registry hooks,
so that you guys can more easily test with/without the optional
dependencies.  I will write everything down tomorrow and do the
blog on Monday.

- Ilan


On Sat, Jul 16, 2011 at 11:22 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> In addition to Chris Fonnesbeck's thorough review, here's another one,
> shorter but equally positive:
>
> http://blog.rtwilson.com/the-new-ipython-is-awesome
>
> I just heard from Min (who's still at SciPy'11 as it winds down) that
> the sprints have been very productive, catching several bugs,
> including a particularly nasty one that ?could lock up an entire
> system, discovered by Stefan.
>
> But I think we're in pretty good shape for a full release of 0.11
> soon. ?I have a long day trapped in planes on Monday and I'll work on
> finishing up the man pages business via rst2man and the release notes,
> and we can then decide when to cut the final release later in the
> week.
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>


From fperez.net at gmail.com  Sun Jul 17 02:30:31 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 16 Jul 2011 23:30:31 -0700
Subject: [IPython-dev] Another good blog post - we must be doing
	something right...
In-Reply-To: <CAAUn5qLvE3cj9j7K5jC6g2J_uHtzcmZFf0k5KXBJWJt4G-J4+g@mail.gmail.com>
References: <CAHAreOp4YuSTw3pdH-EHaYMChBAAA+gwi06-q8S3XSa0bCWcgg@mail.gmail.com>
	<CAAUn5qLvE3cj9j7K5jC6g2J_uHtzcmZFf0k5KXBJWJt4G-J4+g@mail.gmail.com>
Message-ID: <CAHAreOopENZszvoUBEnddN9-mkdBH8q+_KzNp+56XDW5+jBYzA@mail.gmail.com>

On Sat, Jul 16, 2011 at 9:59 PM, Ilan Schnell <ischnell at enthought.com> wrote:
> Thanks for the link. ?Here is another one saw on reddit today:
> http://stronginference.com/weblog/2011/7/15/innovations-in-ipython.html

Yes, that was Chris Fonnesbeck's awesome post with lots of details.

> As promised, I will write a blog post about the import registry hooks,
> so that you guys can more easily test with/without the optional
> dependencies. ?I will write everything down tomorrow and do the
> blog on Monday.

Thanks!

f


From fperez.net at gmail.com  Sun Jul 17 14:21:10 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 17 Jul 2011 11:21:10 -0700
Subject: [IPython-dev] Fwd: [ipython] ipython-qtconsole uses 100% CPU (#588)
In-Reply-To: <ipython/ipython/issues/588@github.com>
References: <ipython/ipython/issues/588@github.com>
Message-ID: <CAHAreOrq+jS3zdu+Kd4xKCeRYZe6=tx5RtcjAdHeLcQ84k_EAQ@mail.gmail.com>

Hi all,

this looks fairly serious, and we're trying to wrap up the 0.11
release so that we're not eternally promising 'one more week' forever.
 But hogging a cpu at 100% utilization is a real problem. Can anyone
else confirm this?  And does anyone have ideas as to what could be the
cause?

Thanks,

f


---------- Forwarded message ----------
From: rgaudette
<reply+i-1238118-7704c01a6c981882533d9b8effb70f2d4b39aadd at reply.github.com>
Date: Sun, Jul 17, 2011 at 10:34 AM
Subject: [ipython] ipython-qtconsole uses 100% CPU (#588)
To: fperez.net at gmail.com


Hi,
When I run ipython-qtconsole.exe, I observe 100% CPU usage (really 50%
on my dual core machine) when nothing is running in the console. ?My
machine consists of the following configuration:
Windows 7 64 bit
Python 2.7.2 64 bit binary install (from python.org)
PyQT and QT from Christoph Gohlke 's binary distribution
PyQt-Py2.7-x64-gpl-4.8.4-1.exe

I first observed this behavior on Christoph Gohlke 's
ipython-0.11.dev.win-amd64-py2.7.exe. ?I then uninstalled that package
and pull the latest IPython from github. ?The latest version still
exhibits the 100% CPU usage behavior on my machine.

Some other observations that might be helpful:

* If I close the QT console window but leave the kernel running
(selecting "No, just this console button"), the CPU usage stays at
100%.

* The windows console based ipython.exe does not have this behavior on
my machine.

* Task manager shows that it is pythonw.exe using the CPU

--
Reply to this email directly or view it on GitHub:
https://github.com/ipython/ipython/issues/588


From epatters at enthought.com  Sun Jul 17 14:28:19 2011
From: epatters at enthought.com (Evan Patterson)
Date: Sun, 17 Jul 2011 13:28:19 -0500
Subject: [IPython-dev] Fwd: [ipython] ipython-qtconsole uses 100% CPU
	(#588)
In-Reply-To: <CAHAreOrq+jS3zdu+Kd4xKCeRYZe6=tx5RtcjAdHeLcQ84k_EAQ@mail.gmail.com>
References: <ipython/ipython/issues/588@github.com>
	<CAHAreOrq+jS3zdu+Kd4xKCeRYZe6=tx5RtcjAdHeLcQ84k_EAQ@mail.gmail.com>
Message-ID: <CAFAPEOXb81T_g0VhAA6zTaZb28EJ1wUtQDgxTv4MXaT3uz-qdg@mail.gmail.com>

It would be helpful to know whether the CPU utilization is pylab-specific. I
suspect the trouble may be there.

Evan

On Sun, Jul 17, 2011 at 1:21 PM, Fernando Perez <fperez.net at gmail.com>wrote:

> Hi all,
>
> this looks fairly serious, and we're trying to wrap up the 0.11
> release so that we're not eternally promising 'one more week' forever.
>  But hogging a cpu at 100% utilization is a real problem. Can anyone
> else confirm this?  And does anyone have ideas as to what could be the
> cause?
>
> Thanks,
>
> f
>
>
> ---------- Forwarded message ----------
> From: rgaudette
> <reply+i-1238118-7704c01a6c981882533d9b8effb70f2d4b39aadd at reply.github.com
> >
> Date: Sun, Jul 17, 2011 at 10:34 AM
> Subject: [ipython] ipython-qtconsole uses 100% CPU (#588)
> To: fperez.net at gmail.com
>
>
> Hi,
> When I run ipython-qtconsole.exe, I observe 100% CPU usage (really 50%
> on my dual core machine) when nothing is running in the console.  My
> machine consists of the following configuration:
> Windows 7 64 bit
> Python 2.7.2 64 bit binary install (from python.org)
> PyQT and QT from Christoph Gohlke 's binary distribution
> PyQt-Py2.7-x64-gpl-4.8.4-1.exe
>
> I first observed this behavior on Christoph Gohlke 's
> ipython-0.11.dev.win-amd64-py2.7.exe.  I then uninstalled that package
> and pull the latest IPython from github.  The latest version still
> exhibits the 100% CPU usage behavior on my machine.
>
> Some other observations that might be helpful:
>
> * If I close the QT console window but leave the kernel running
> (selecting "No, just this console button"), the CPU usage stays at
> 100%.
>
> * The windows console based ipython.exe does not have this behavior on
> my machine.
>
> * Task manager shows that it is pythonw.exe using the CPU
>
> --
> Reply to this email directly or view it on GitHub:
> https://github.com/ipython/ipython/issues/588
> _______________________________________________
> 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/20110717/00929e67/attachment.html>

From epatters at enthought.com  Sun Jul 17 15:01:35 2011
From: epatters at enthought.com (Evan Patterson)
Date: Sun, 17 Jul 2011 14:01:35 -0500
Subject: [IPython-dev] Fwd: [ipython] ipython-qtconsole uses 100% CPU
	(#588)
In-Reply-To: <CAMEX5syY6GzdOvfOQddaCS5eRe-k4vjykQLT9=JmwUjwvHnvbQ@mail.gmail.com>
References: <ipython/ipython/issues/588@github.com>
	<CAHAreOrq+jS3zdu+Kd4xKCeRYZe6=tx5RtcjAdHeLcQ84k_EAQ@mail.gmail.com>
	<CAFAPEOXb81T_g0VhAA6zTaZb28EJ1wUtQDgxTv4MXaT3uz-qdg@mail.gmail.com>
	<CAMEX5syY6GzdOvfOQddaCS5eRe-k4vjykQLT9=JmwUjwvHnvbQ@mail.gmail.com>
Message-ID: <CAFAPEOWC7b9a0hHOOJKztJiPqYy2+k2DtPvky9z5NBOuwRnBjg@mail.gmail.com>

On Sun, Jul 17, 2011 at 1:32 PM, Charlie Sharpsteen <chuck at sharpsteen.net>wrote:

> On Sun, Jul 17, 2011 at 11:28 AM, Evan Patterson <epatters at enthought.com>wrote:
>
>> It would be helpful to know whether the CPU utilization is pylab-specific.
>> I suspect the trouble may be there.
>>
>> Evan
>>
>
> I get 100% utilization on one of my cores if I just start
> `ipython-qtconsole` using EPD 7.1 64 bit distribution on Windows 7. So
> unless Enthought altered `C:\Python27\Scripts\ipython-qtconsole` to trigger
> pylab by default, I don't think pylab is involved.
>
> -Charlie
>

OK, thanks. When I have access to Windows VM tomorrow, I will try to debug
the problem.

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

From jorgen.stenarson at bostream.nu  Sun Jul 17 18:01:33 2011
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Mon, 18 Jul 2011 00:01:33 +0200
Subject: [IPython-dev] Fwd: [ipython] ipython-qtconsole uses 100% CPU
 (#588)
In-Reply-To: <CAFAPEOWC7b9a0hHOOJKztJiPqYy2+k2DtPvky9z5NBOuwRnBjg@mail.gmail.com>
References: <ipython/ipython/issues/588@github.com>
	<CAHAreOrq+jS3zdu+Kd4xKCeRYZe6=tx5RtcjAdHeLcQ84k_EAQ@mail.gmail.com>
	<CAFAPEOXb81T_g0VhAA6zTaZb28EJ1wUtQDgxTv4MXaT3uz-qdg@mail.gmail.com>
	<CAMEX5syY6GzdOvfOQddaCS5eRe-k4vjykQLT9=JmwUjwvHnvbQ@mail.gmail.com>
	<CAFAPEOWC7b9a0hHOOJKztJiPqYy2+k2DtPvky9z5NBOuwRnBjg@mail.gmail.com>
Message-ID: <4E235BBD.5030705@bostream.nu>

Evan Patterson skrev 2011-07-17 21:01:
> On Sun, Jul 17, 2011 at 1:32 PM, Charlie Sharpsteen
> <chuck at sharpsteen.net <mailto:chuck at sharpsteen.net>> wrote:
>
>     On Sun, Jul 17, 2011 at 11:28 AM, Evan Patterson
>     <epatters at enthought.com <mailto:epatters at enthought.com>> wrote:
>
>         It would be helpful to know whether the CPU utilization is
>         pylab-specific. I suspect the trouble may be there.
>
>         Evan
>
>
>     I get 100% utilization on one of my cores if I just start
>     `ipython-qtconsole` using EPD 7.1 64 bit distribution on Windows 7.
>     So unless Enthought altered `C:\Python27\Scripts\ipython-qtconsole`
>     to trigger pylab by default, I don't think pylab is involved.
>
>     -Charlie
>
>
> OK, thanks. When I have access to Windows VM tomorrow, I will try to
> debug the problem.
>
> Evan
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev

I do not observe the problem when launching directly via python interpreter:
python ipython.py qtconsole
or
python ipython.py qtconsole --pylab

I do not see any activity when I leave ipython idle.
window 7 64-bit
python 2.6.6 (32-bit)
PyQt v4.8.3

Perhaps it is from the exe-files that launch qtconsole.

/J?rgen



From satra at mit.edu  Sun Jul 17 19:35:37 2011
From: satra at mit.edu (Satrajit Ghosh)
Date: Sun, 17 Jul 2011 19:35:37 -0400
Subject: [IPython-dev] Fwd: [ipython] ipython-qtconsole uses 100% CPU
	(#588)
In-Reply-To: <CAHAreOrq+jS3zdu+Kd4xKCeRYZe6=tx5RtcjAdHeLcQ84k_EAQ@mail.gmail.com>
References: <ipython/ipython/issues/588@github.com>
	<CAHAreOrq+jS3zdu+Kd4xKCeRYZe6=tx5RtcjAdHeLcQ84k_EAQ@mail.gmail.com>
Message-ID: <CA+A4wO=UAzmYtx7oDdz0WOEu0NxTS3h+XxUJSV1b3a6q_rMBbw@mail.gmail.com>

no 100% usage observed  on EPD 7.1 x64 on OSX 10.6.8 for ipython 0.11rc3
with or without pylab.

cheers,

satra

On Sun, Jul 17, 2011 at 2:21 PM, Fernando Perez <fperez.net at gmail.com>wrote:

> Hi all,
>
> this looks fairly serious, and we're trying to wrap up the 0.11
> release so that we're not eternally promising 'one more week' forever.
>  But hogging a cpu at 100% utilization is a real problem. Can anyone
> else confirm this?  And does anyone have ideas as to what could be the
> cause?
>
> Thanks,
>
> f
>
>
> ---------- Forwarded message ----------
> From: rgaudette
> <reply+i-1238118-7704c01a6c981882533d9b8effb70f2d4b39aadd at reply.github.com
> >
> Date: Sun, Jul 17, 2011 at 10:34 AM
> Subject: [ipython] ipython-qtconsole uses 100% CPU (#588)
> To: fperez.net at gmail.com
>
>
> Hi,
> When I run ipython-qtconsole.exe, I observe 100% CPU usage (really 50%
> on my dual core machine) when nothing is running in the console.  My
> machine consists of the following configuration:
> Windows 7 64 bit
> Python 2.7.2 64 bit binary install (from python.org)
> PyQT and QT from Christoph Gohlke 's binary distribution
> PyQt-Py2.7-x64-gpl-4.8.4-1.exe
>
> I first observed this behavior on Christoph Gohlke 's
> ipython-0.11.dev.win-amd64-py2.7.exe.  I then uninstalled that package
> and pull the latest IPython from github.  The latest version still
> exhibits the 100% CPU usage behavior on my machine.
>
> Some other observations that might be helpful:
>
> * If I close the QT console window but leave the kernel running
> (selecting "No, just this console button"), the CPU usage stays at
> 100%.
>
> * The windows console based ipython.exe does not have this behavior on
> my machine.
>
> * Task manager shows that it is pythonw.exe using the CPU
>
> --
> Reply to this email directly or view it on GitHub:
> https://github.com/ipython/ipython/issues/588
> _______________________________________________
> 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/20110717/b1cd6b5e/attachment.html>

From ischnell at enthought.com  Sun Jul 17 21:37:20 2011
From: ischnell at enthought.com (Ilan Schnell)
Date: Sun, 17 Jul 2011 20:37:20 -0500
Subject: [IPython-dev] Fwd: [ipython] ipython-qtconsole uses 100% CPU
	(#588)
In-Reply-To: <CA+A4wO=UAzmYtx7oDdz0WOEu0NxTS3h+XxUJSV1b3a6q_rMBbw@mail.gmail.com>
References: <ipython/ipython/issues/588@github.com>
	<CAHAreOrq+jS3zdu+Kd4xKCeRYZe6=tx5RtcjAdHeLcQ84k_EAQ@mail.gmail.com>
	<CA+A4wO=UAzmYtx7oDdz0WOEu0NxTS3h+XxUJSV1b3a6q_rMBbw@mail.gmail.com>
Message-ID: <CAAUn5qKN09iT_s3FOu=HNWj+EBC-LwRYWTGhBCn=75RRCrAPQg@mail.gmail.com>

no 100% usage on EPD 7.1 on OSX (both 32-bit and 64-bit) using the
current master (53d497b1).  I'll test it on Windows tomorrow.

- Ilan


On Sun, Jul 17, 2011 at 6:35 PM, Satrajit Ghosh <satra at mit.edu> wrote:
> no 100% usage observed? on EPD 7.1 x64 on OSX 10.6.8 for ipython 0.11rc3
> with or without pylab.
>
> cheers,
>
> satra
>
> On Sun, Jul 17, 2011 at 2:21 PM, Fernando Perez <fperez.net at gmail.com>
> wrote:
>>
>> Hi all,
>>
>> this looks fairly serious, and we're trying to wrap up the 0.11
>> release so that we're not eternally promising 'one more week' forever.
>> ?But hogging a cpu at 100% utilization is a real problem. Can anyone
>> else confirm this? ?And does anyone have ideas as to what could be the
>> cause?
>>
>> Thanks,
>>
>> f
>>
>>
>> ---------- Forwarded message ----------
>> From: rgaudette
>>
>> <reply+i-1238118-7704c01a6c981882533d9b8effb70f2d4b39aadd at reply.github.com>
>> Date: Sun, Jul 17, 2011 at 10:34 AM
>> Subject: [ipython] ipython-qtconsole uses 100% CPU (#588)
>> To: fperez.net at gmail.com
>>
>>
>> Hi,
>> When I run ipython-qtconsole.exe, I observe 100% CPU usage (really 50%
>> on my dual core machine) when nothing is running in the console. ?My
>> machine consists of the following configuration:
>> Windows 7 64 bit
>> Python 2.7.2 64 bit binary install (from python.org)
>> PyQT and QT from Christoph Gohlke 's binary distribution
>> PyQt-Py2.7-x64-gpl-4.8.4-1.exe
>>
>> I first observed this behavior on Christoph Gohlke 's
>> ipython-0.11.dev.win-amd64-py2.7.exe. ?I then uninstalled that package
>> and pull the latest IPython from github. ?The latest version still
>> exhibits the 100% CPU usage behavior on my machine.
>>
>> Some other observations that might be helpful:
>>
>> * If I close the QT console window but leave the kernel running
>> (selecting "No, just this console button"), the CPU usage stays at
>> 100%.
>>
>> * The windows console based ipython.exe does not have this behavior on
>> my machine.
>>
>> * Task manager shows that it is pythonw.exe using the CPU
>>
>> --
>> Reply to this email directly or view it on GitHub:
>> https://github.com/ipython/ipython/issues/588
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>


From benjaminrk at gmail.com  Sun Jul 17 21:41:40 2011
From: benjaminrk at gmail.com (Min RK)
Date: Sun, 17 Jul 2011 18:41:40 -0700
Subject: [IPython-dev] Fwd: [ipython] ipython-qtconsole uses 100% CPU
	(#588)
In-Reply-To: <CAAUn5qKN09iT_s3FOu=HNWj+EBC-LwRYWTGhBCn=75RRCrAPQg@mail.gmail.com>
References: <ipython/ipython/issues/588@github.com>
	<CAHAreOrq+jS3zdu+Kd4xKCeRYZe6=tx5RtcjAdHeLcQ84k_EAQ@mail.gmail.com>
	<CA+A4wO=UAzmYtx7oDdz0WOEu0NxTS3h+XxUJSV1b3a6q_rMBbw@mail.gmail.com>
	<CAAUn5qKN09iT_s3FOu=HNWj+EBC-LwRYWTGhBCn=75RRCrAPQg@mail.gmail.com>
Message-ID: <CDA4F1E5-A466-473D-B7FE-D940AFEAEC5C@gmail.com>

See https://github.com/ipython/ipython/pull/589 for a possible resolution.  It is a problem specific to 64b Windows.

-MinRK

On Jul 17, 2011, at 18:37, Ilan Schnell <ischnell at enthought.com> wrote:

> no 100% usage on EPD 7.1 on OSX (both 32-bit and 64-bit) using the
> current master (53d497b1).  I'll test it on Windows tomorrow.
> 
> - Ilan
> 
> 
> On Sun, Jul 17, 2011 at 6:35 PM, Satrajit Ghosh <satra at mit.edu> wrote:
>> no 100% usage observed  on EPD 7.1 x64 on OSX 10.6.8 for ipython 0.11rc3
>> with or without pylab.
>> 
>> cheers,
>> 
>> satra
>> 
>> On Sun, Jul 17, 2011 at 2:21 PM, Fernando Perez <fperez.net at gmail.com>
>> wrote:
>>> 
>>> Hi all,
>>> 
>>> this looks fairly serious, and we're trying to wrap up the 0.11
>>> release so that we're not eternally promising 'one more week' forever.
>>>  But hogging a cpu at 100% utilization is a real problem. Can anyone
>>> else confirm this?  And does anyone have ideas as to what could be the
>>> cause?
>>> 
>>> Thanks,
>>> 
>>> f
>>> 
>>> 
>>> ---------- Forwarded message ----------
>>> From: rgaudette
>>> 
>>> <reply+i-1238118-7704c01a6c981882533d9b8effb70f2d4b39aadd at reply.github.com>
>>> Date: Sun, Jul 17, 2011 at 10:34 AM
>>> Subject: [ipython] ipython-qtconsole uses 100% CPU (#588)
>>> To: fperez.net at gmail.com
>>> 
>>> 
>>> Hi,
>>> When I run ipython-qtconsole.exe, I observe 100% CPU usage (really 50%
>>> on my dual core machine) when nothing is running in the console.  My
>>> machine consists of the following configuration:
>>> Windows 7 64 bit
>>> Python 2.7.2 64 bit binary install (from python.org)
>>> PyQT and QT from Christoph Gohlke 's binary distribution
>>> PyQt-Py2.7-x64-gpl-4.8.4-1.exe
>>> 
>>> I first observed this behavior on Christoph Gohlke 's
>>> ipython-0.11.dev.win-amd64-py2.7.exe.  I then uninstalled that package
>>> and pull the latest IPython from github.  The latest version still
>>> exhibits the 100% CPU usage behavior on my machine.
>>> 
>>> Some other observations that might be helpful:
>>> 
>>> * If I close the QT console window but leave the kernel running
>>> (selecting "No, just this console button"), the CPU usage stays at
>>> 100%.
>>> 
>>> * The windows console based ipython.exe does not have this behavior on
>>> my machine.
>>> 
>>> * Task manager shows that it is pythonw.exe using the CPU
>>> 
>>> --
>>> Reply to this email directly or view it on GitHub:
>>> https://github.com/ipython/ipython/issues/588
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>> 
>> 
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>> 
>> 
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev


From fperez.net at gmail.com  Mon Jul 18 01:30:15 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 17 Jul 2011 22:30:15 -0700
Subject: [IPython-dev] Just pushed, will only touch docs tomorrow.
Message-ID: <CAHAreOqJbCMG9-fWuh4_VyAKp=sf5qqdW_LJocRAeePsYdgozw@mail.gmail.com>

Howdy,

If anyone has some bandwidth to cut the rc tomorrow so that we keep
our promise of a Friday or Saturday release, I just pushed what I'd
been doing on the plane, which included a couple of tiny code fixes
(trivial stuff).

As of tomorrow, I will *only* touch docs, so that there's zero danger
of a brown-paper-bag bug at the last minute.

I have two long flights, I'll try to put them to good use working on
the release notes, and hopefully getting the man pages in shape with
rst2man.

Cheers,

f


From sourceforge.ipython at user.fastmail.fm  Mon Jul 18 12:12:04 2011
From: sourceforge.ipython at user.fastmail.fm (Hugo Gagnon)
Date: Mon, 18 Jul 2011 12:12:04 -0400
Subject: [IPython-dev] IPython 0.11.rc1 as a built-in shell for a GUI
Message-ID: <1311005524.22141.2153081513@webmail.messagingengine.com>

Hello,

In the past I've been using 0.10 as a built-in shell for my small GUI.
When I first implemented it I remember taking most of the code from your
cookbook. However my GUI now fails miserably at the very first line with
0.11.rc1. I don't have the time to go through your doc (and quite
frankly I'm not an expert programmer) and I would appreciate if someone
could help me port my code so that it works with 0.11. Here it is:

import StringIO
import os
import re
import subprocess
import sys

import IPython


class Shell(object):

    def __init__(self, input_func, user_ns, user_global_ns):
        if '__builtins__' in user_ns: # this fixes a bug in IPython
            del user_ns['__builtins__']
        self.IP = IPython.Shell.make_IPython(argv=[],
                                             user_ns=user_ns,
                                             user_global_ns=user_global_ns,
                                             embedded=True,
                                             shell_class=IPython.Shell.InteractiveShell)
        self.IP.set_hook('shell_hook', self.shell_hook)

        self.out = StringIO.StringIO()
        IPython.iplib.raw_input_original = input_func
        IPython.genutils.Term.cout = self.out
        IPython.genutils.Term.cerr = self.out
        os.environ['TERM'] = 'dumb'

        self.ip = IPython.ipapi.get()
        self.ip.magic('colors NoColor')

        self.iter_more = 0
        self.prompt = str(self.IP.outputcache.prompt1)
        self.complete_sep = re.compile('[\s\{\}\[\]\(\)\=]')

    def execute(self):
        orig_stdout = sys.stdout
        sys.stdout = IPython.Shell.Term.cout
        line = self.IP.raw_input(continue_prompt=self.iter_more)
        self.iter_more = self.IP.push(line)
        if self.iter_more:
            self.prompt = str(self.IP.outputcache.prompt2)
        else:
            self.prompt = str(self.IP.outputcache.prompt1)
        out = self.out.getvalue().strip()
        self.out.truncate(0)
        sys.stdout = orig_stdout
        return out

    def complete(self, line):
        split_line = self.complete_sep.split(line)
        possibilities = self.IP.complete(split_line[-1])
        if possibilities:
            common_prefix = os.path.commonprefix(possibilities)
            completed = line[:-len(split_line[-1])] + common_prefix
        else:
            completed = line
        return completed, possibilities

    def shell_hook(self, IP, cmd):
        p = subprocess.Popen(cmd, shell=True,
                             stdout=subprocess.PIPE,
                             stderr=subprocess.STDOUT)
        out = p.stdout
        print out.read()
        out.close()

Your time is very much appreciated,
--
  Hugo Gagnon


From dsdale24 at gmail.com  Mon Jul 18 13:26:06 2011
From: dsdale24 at gmail.com (Darren Dale)
Date: Mon, 18 Jul 2011 13:26:06 -0400
Subject: [IPython-dev] Qt api selection re. ipython and matplotlib
In-Reply-To: <4E14C445.7010602@hawaii.edu>
References: <CAHAreOoMSsD8UYCPHKT_RcESpCWAFuM0VcBWN3t+KR1MZ4ZGnQ@mail.gmail.com>
	<CAK6O52kGTchAcsxH6mt9GRxZ==yhxdX=f+8o3e+XZHujCi17=g@mail.gmail.com>
	<4E128BA4.8090308@hawaii.edu>
	<CAHNn8BWfZur_5f0Cm7NNfkg+jyAmvOXcfnD3Yj3yAOzea7XVdw@mail.gmail.com>
	<4E12AD93.4080901@hawaii.edu>
	<CAK6O52=EhM9_-h8nK-j2vHg_puF7kE=z_2JM0v58WeCsGh59HA@mail.gmail.com>
	<4E133FC3.1090108@hawaii.edu>
	<CAHNn8BV6M+6GSouOe48JtE6xhmsWBCgkZVNg_DBbZONdSS-o3w@mail.gmail.com>
	<CAK6O52m0R3ugOkV9gznHmGgMRXAF+yij3PWnisVS8N_98ti+6w@mail.gmail.com>
	<CAHNn8BU1Zh4Nu=-jgZCNMCEs4m_sZdYzB1e1C_LuNvO=Mdxh+A@mail.gmail.com>
	<4E1419AD.4010003@hawaii.edu>
	<D4EEB2E1-C248-42A8-87F1-D7B1A98E438A@enthought.com>
	<CAHNn8BV+y-P1enkzWy_JkOa7gMn-Rhdixm7f+ueE1C5eioii=Q@mail.gmail.com>
	<4E14C445.7010602@hawaii.edu>
Message-ID: <CAK6O52nkee6Ucr3ZmQhj68WZkoTRnkjE4UFA-GLs_xtPV38SOg@mail.gmail.com>

On Wed, Jul 6, 2011 at 4:23 PM, Eric Firing <efiring at hawaii.edu> wrote:
> On 07/06/2011 05:34 AM, MinRK wrote:
>> I updated my IPython PR with my understanding of the recent discussion.
>>
>> Now, QT_API will be asked *first*, and if QT_API=pyqt, IPython will
>> set the v2 APIs.
>>
>> QT_API=pyqt : use pyqt with v2
>> QT_API=pyside : use pyside
>> QT_API unset : ask matplotlib for pyqt4 or pyside, will not set v2 APIs
>>
>> The default, and most likely case remains PyQt4 without updating sip
>> apis, falling back on PySide.
>
> I have updated my mpl PR in a compatible way; the only difference is
> that I have not included a fall-back to pyside. ?Either PyQt4 or PySide
> is specified as an rcParam, and if whatever is specified (either
> explicitly there or via the QT_API env var) is not there, an ImportError
> will result. ?Anyone who has only PySide will have to know about it and
> use the rcParam or QT_API to request it.

Unfortunately, I think we may have to reopen this discussion. As the
master branch currently stands, the embedding_in_qt4.py example is
broken when I have the QT_API environment variable defined. The reason
is simple: the example imports from PyQt4 first, which defaults to the
v1 api, then the example imports the qt4 backend, which fails in its
attempt to set the api to v2. One workaround is to perform the mpl qt4
backend import before the PyQt4 imports, but such a requirement could
be disruptive to lots of existing code. A better alternative might be
to wrap the setapi calls in a try/except:

    import sip
    if QT_API == QT_API_PYQTv2:
        try:
            sip.setapi('QString', 2)
            sip.setapi('QVariant', 2)
        except ValueError:
            pass


Darren


From benjaminrk at gmail.com  Mon Jul 18 14:16:51 2011
From: benjaminrk at gmail.com (MinRK)
Date: Mon, 18 Jul 2011 11:16:51 -0700
Subject: [IPython-dev] Qt api selection re. ipython and matplotlib
In-Reply-To: <CAK6O52nkee6Ucr3ZmQhj68WZkoTRnkjE4UFA-GLs_xtPV38SOg@mail.gmail.com>
References: <CAHAreOoMSsD8UYCPHKT_RcESpCWAFuM0VcBWN3t+KR1MZ4ZGnQ@mail.gmail.com>
	<CAK6O52kGTchAcsxH6mt9GRxZ==yhxdX=f+8o3e+XZHujCi17=g@mail.gmail.com>
	<4E128BA4.8090308@hawaii.edu>
	<CAHNn8BWfZur_5f0Cm7NNfkg+jyAmvOXcfnD3Yj3yAOzea7XVdw@mail.gmail.com>
	<4E12AD93.4080901@hawaii.edu>
	<CAK6O52=EhM9_-h8nK-j2vHg_puF7kE=z_2JM0v58WeCsGh59HA@mail.gmail.com>
	<4E133FC3.1090108@hawaii.edu>
	<CAHNn8BV6M+6GSouOe48JtE6xhmsWBCgkZVNg_DBbZONdSS-o3w@mail.gmail.com>
	<CAK6O52m0R3ugOkV9gznHmGgMRXAF+yij3PWnisVS8N_98ti+6w@mail.gmail.com>
	<CAHNn8BU1Zh4Nu=-jgZCNMCEs4m_sZdYzB1e1C_LuNvO=Mdxh+A@mail.gmail.com>
	<4E1419AD.4010003@hawaii.edu>
	<D4EEB2E1-C248-42A8-87F1-D7B1A98E438A@enthought.com>
	<CAHNn8BV+y-P1enkzWy_JkOa7gMn-Rhdixm7f+ueE1C5eioii=Q@mail.gmail.com>
	<4E14C445.7010602@hawaii.edu>
	<CAK6O52nkee6Ucr3ZmQhj68WZkoTRnkjE4UFA-GLs_xtPV38SOg@mail.gmail.com>
Message-ID: <CAHNn8BVDSB7Rp_q1As8tnkoXOxsyMTZw4GY6Kps9i=cydEsuwQ@mail.gmail.com>

On Mon, Jul 18, 2011 at 10:26, Darren Dale <dsdale24 at gmail.com> wrote:
> On Wed, Jul 6, 2011 at 4:23 PM, Eric Firing <efiring at hawaii.edu> wrote:
>> On 07/06/2011 05:34 AM, MinRK wrote:
>>> I updated my IPython PR with my understanding of the recent discussion.
>>>
>>> Now, QT_API will be asked *first*, and if QT_API=pyqt, IPython will
>>> set the v2 APIs.
>>>
>>> QT_API=pyqt : use pyqt with v2
>>> QT_API=pyside : use pyside
>>> QT_API unset : ask matplotlib for pyqt4 or pyside, will not set v2 APIs
>>>
>>> The default, and most likely case remains PyQt4 without updating sip
>>> apis, falling back on PySide.
>>
>> I have updated my mpl PR in a compatible way; the only difference is
>> that I have not included a fall-back to pyside. ?Either PyQt4 or PySide
>> is specified as an rcParam, and if whatever is specified (either
>> explicitly there or via the QT_API env var) is not there, an ImportError
>> will result. ?Anyone who has only PySide will have to know about it and
>> use the rcParam or QT_API to request it.
>
> Unfortunately, I think we may have to reopen this discussion. As the
> master branch currently stands, the embedding_in_qt4.py example is
> broken when I have the QT_API environment variable defined. The reason
> is simple: the example imports from PyQt4 first, which defaults to the
> v1 api, then the example imports the qt4 backend, which fails in its
> attempt to set the api to v2. One workaround is to perform the mpl qt4
> backend import before the PyQt4 imports, but such a requirement could
> be disruptive to lots of existing code. A better alternative might be
> to wrap the setapi calls in a try/except:
>
> ? ?import sip
> ? ?if QT_API == QT_API_PYQTv2:
> ? ? ? ?try:
> ? ? ? ? ? ?sip.setapi('QString', 2)
> ? ? ? ? ? ?sip.setapi('QVariant', 2)
> ? ? ? ?except ValueError:
> ? ? ? ? ? ?pass

QT_API=pyqt *does* imply PyQt4+v2api, since it is an ETS variable, and
that's how they use it.  Also note that this variable is only likely
to be set in cases where users have both PySide and PyQt4, and the
default is behavior is *not* what the user wants.  That said, a
warning rather than raising is perhaps preferable, to handle users who
have ETS applications, for which they use QT_API, but also other Qt
programs that want to behave differently.

-MinRK

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


From dsdale24 at gmail.com  Mon Jul 18 14:27:31 2011
From: dsdale24 at gmail.com (Darren Dale)
Date: Mon, 18 Jul 2011 14:27:31 -0400
Subject: [IPython-dev] Qt api selection re. ipython and matplotlib
In-Reply-To: <CAHNn8BVDSB7Rp_q1As8tnkoXOxsyMTZw4GY6Kps9i=cydEsuwQ@mail.gmail.com>
References: <CAHAreOoMSsD8UYCPHKT_RcESpCWAFuM0VcBWN3t+KR1MZ4ZGnQ@mail.gmail.com>
	<CAK6O52kGTchAcsxH6mt9GRxZ==yhxdX=f+8o3e+XZHujCi17=g@mail.gmail.com>
	<4E128BA4.8090308@hawaii.edu>
	<CAHNn8BWfZur_5f0Cm7NNfkg+jyAmvOXcfnD3Yj3yAOzea7XVdw@mail.gmail.com>
	<4E12AD93.4080901@hawaii.edu>
	<CAK6O52=EhM9_-h8nK-j2vHg_puF7kE=z_2JM0v58WeCsGh59HA@mail.gmail.com>
	<4E133FC3.1090108@hawaii.edu>
	<CAHNn8BV6M+6GSouOe48JtE6xhmsWBCgkZVNg_DBbZONdSS-o3w@mail.gmail.com>
	<CAK6O52m0R3ugOkV9gznHmGgMRXAF+yij3PWnisVS8N_98ti+6w@mail.gmail.com>
	<CAHNn8BU1Zh4Nu=-jgZCNMCEs4m_sZdYzB1e1C_LuNvO=Mdxh+A@mail.gmail.com>
	<4E1419AD.4010003@hawaii.edu>
	<D4EEB2E1-C248-42A8-87F1-D7B1A98E438A@enthought.com>
	<CAHNn8BV+y-P1enkzWy_JkOa7gMn-Rhdixm7f+ueE1C5eioii=Q@mail.gmail.com>
	<4E14C445.7010602@hawaii.edu>
	<CAK6O52nkee6Ucr3ZmQhj68WZkoTRnkjE4UFA-GLs_xtPV38SOg@mail.gmail.com>
	<CAHNn8BVDSB7Rp_q1As8tnkoXOxsyMTZw4GY6Kps9i=cydEsuwQ@mail.gmail.com>
Message-ID: <CAK6O52nKfYaXiLDYojWXjpPAs5KpkPo9Z=kzSyc7FpqUrQKW8A@mail.gmail.com>

On Mon, Jul 18, 2011 at 2:16 PM, MinRK <benjaminrk at gmail.com> wrote:
> On Mon, Jul 18, 2011 at 10:26, Darren Dale <dsdale24 at gmail.com> wrote:
>> On Wed, Jul 6, 2011 at 4:23 PM, Eric Firing <efiring at hawaii.edu> wrote:
>>> On 07/06/2011 05:34 AM, MinRK wrote:
>>>> I updated my IPython PR with my understanding of the recent discussion.
>>>>
>>>> Now, QT_API will be asked *first*, and if QT_API=pyqt, IPython will
>>>> set the v2 APIs.
>>>>
>>>> QT_API=pyqt : use pyqt with v2
>>>> QT_API=pyside : use pyside
>>>> QT_API unset : ask matplotlib for pyqt4 or pyside, will not set v2 APIs
>>>>
>>>> The default, and most likely case remains PyQt4 without updating sip
>>>> apis, falling back on PySide.
>>>
>>> I have updated my mpl PR in a compatible way; the only difference is
>>> that I have not included a fall-back to pyside. ?Either PyQt4 or PySide
>>> is specified as an rcParam, and if whatever is specified (either
>>> explicitly there or via the QT_API env var) is not there, an ImportError
>>> will result. ?Anyone who has only PySide will have to know about it and
>>> use the rcParam or QT_API to request it.
>>
>> Unfortunately, I think we may have to reopen this discussion. As the
>> master branch currently stands, the embedding_in_qt4.py example is
>> broken when I have the QT_API environment variable defined. The reason
>> is simple: the example imports from PyQt4 first, which defaults to the
>> v1 api, then the example imports the qt4 backend, which fails in its
>> attempt to set the api to v2. One workaround is to perform the mpl qt4
>> backend import before the PyQt4 imports, but such a requirement could
>> be disruptive to lots of existing code. A better alternative might be
>> to wrap the setapi calls in a try/except:
>>
>> ? ?import sip
>> ? ?if QT_API == QT_API_PYQTv2:
>> ? ? ? ?try:
>> ? ? ? ? ? ?sip.setapi('QString', 2)
>> ? ? ? ? ? ?sip.setapi('QVariant', 2)
>> ? ? ? ?except ValueError:
>> ? ? ? ? ? ?pass
>
> QT_API=pyqt *does* imply PyQt4+v2api, since it is an ETS variable, and
> that's how they use it.

I haven't argued otherwise.

> Also note that this variable is only likely
> to be set in cases where users have both PySide and PyQt4, and the
> default is behavior is *not* what the user wants. ?That said, a
> warning rather than raising is perhaps preferable, to handle users who
> have ETS applications, for which they use QT_API, but also other Qt
> programs that want to behave differently.

This was my point.


From benjaminrk at gmail.com  Mon Jul 18 14:37:53 2011
From: benjaminrk at gmail.com (MinRK)
Date: Mon, 18 Jul 2011 11:37:53 -0700
Subject: [IPython-dev] Qt api selection re. ipython and matplotlib
In-Reply-To: <CAK6O52nKfYaXiLDYojWXjpPAs5KpkPo9Z=kzSyc7FpqUrQKW8A@mail.gmail.com>
References: <CAHAreOoMSsD8UYCPHKT_RcESpCWAFuM0VcBWN3t+KR1MZ4ZGnQ@mail.gmail.com>
	<CAK6O52kGTchAcsxH6mt9GRxZ==yhxdX=f+8o3e+XZHujCi17=g@mail.gmail.com>
	<4E128BA4.8090308@hawaii.edu>
	<CAHNn8BWfZur_5f0Cm7NNfkg+jyAmvOXcfnD3Yj3yAOzea7XVdw@mail.gmail.com>
	<4E12AD93.4080901@hawaii.edu>
	<CAK6O52=EhM9_-h8nK-j2vHg_puF7kE=z_2JM0v58WeCsGh59HA@mail.gmail.com>
	<4E133FC3.1090108@hawaii.edu>
	<CAHNn8BV6M+6GSouOe48JtE6xhmsWBCgkZVNg_DBbZONdSS-o3w@mail.gmail.com>
	<CAK6O52m0R3ugOkV9gznHmGgMRXAF+yij3PWnisVS8N_98ti+6w@mail.gmail.com>
	<CAHNn8BU1Zh4Nu=-jgZCNMCEs4m_sZdYzB1e1C_LuNvO=Mdxh+A@mail.gmail.com>
	<4E1419AD.4010003@hawaii.edu>
	<D4EEB2E1-C248-42A8-87F1-D7B1A98E438A@enthought.com>
	<CAHNn8BV+y-P1enkzWy_JkOa7gMn-Rhdixm7f+ueE1C5eioii=Q@mail.gmail.com>
	<4E14C445.7010602@hawaii.edu>
	<CAK6O52nkee6Ucr3ZmQhj68WZkoTRnkjE4UFA-GLs_xtPV38SOg@mail.gmail.com>
	<CAHNn8BVDSB7Rp_q1As8tnkoXOxsyMTZw4GY6Kps9i=cydEsuwQ@mail.gmail.com>
	<CAK6O52nKfYaXiLDYojWXjpPAs5KpkPo9Z=kzSyc7FpqUrQKW8A@mail.gmail.com>
Message-ID: <CAHNn8BUmcd5qMaGr=SNnODqx016bKC7d1UOGY4b6zePwxGXSBA@mail.gmail.com>

On Mon, Jul 18, 2011 at 11:27, Darren Dale <dsdale24 at gmail.com> wrote:
> On Mon, Jul 18, 2011 at 2:16 PM, MinRK <benjaminrk at gmail.com> wrote:
>> On Mon, Jul 18, 2011 at 10:26, Darren Dale <dsdale24 at gmail.com> wrote:
>>> On Wed, Jul 6, 2011 at 4:23 PM, Eric Firing <efiring at hawaii.edu> wrote:
>>>> On 07/06/2011 05:34 AM, MinRK wrote:
>>>>> I updated my IPython PR with my understanding of the recent discussion.
>>>>>
>>>>> Now, QT_API will be asked *first*, and if QT_API=pyqt, IPython will
>>>>> set the v2 APIs.
>>>>>
>>>>> QT_API=pyqt : use pyqt with v2
>>>>> QT_API=pyside : use pyside
>>>>> QT_API unset : ask matplotlib for pyqt4 or pyside, will not set v2 APIs
>>>>>
>>>>> The default, and most likely case remains PyQt4 without updating sip
>>>>> apis, falling back on PySide.
>>>>
>>>> I have updated my mpl PR in a compatible way; the only difference is
>>>> that I have not included a fall-back to pyside. ?Either PyQt4 or PySide
>>>> is specified as an rcParam, and if whatever is specified (either
>>>> explicitly there or via the QT_API env var) is not there, an ImportError
>>>> will result. ?Anyone who has only PySide will have to know about it and
>>>> use the rcParam or QT_API to request it.
>>>
>>> Unfortunately, I think we may have to reopen this discussion. As the
>>> master branch currently stands, the embedding_in_qt4.py example is
>>> broken when I have the QT_API environment variable defined. The reason
>>> is simple: the example imports from PyQt4 first, which defaults to the
>>> v1 api, then the example imports the qt4 backend, which fails in its
>>> attempt to set the api to v2. One workaround is to perform the mpl qt4
>>> backend import before the PyQt4 imports, but such a requirement could
>>> be disruptive to lots of existing code. A better alternative might be
>>> to wrap the setapi calls in a try/except:
>>>
>>> ? ?import sip
>>> ? ?if QT_API == QT_API_PYQTv2:
>>> ? ? ? ?try:
>>> ? ? ? ? ? ?sip.setapi('QString', 2)
>>> ? ? ? ? ? ?sip.setapi('QVariant', 2)
>>> ? ? ? ?except ValueError:
>>> ? ? ? ? ? ?pass
>>
>> QT_API=pyqt *does* imply PyQt4+v2api, since it is an ETS variable, and
>> that's how they use it.
>
> I haven't argued otherwise.
>
>> Also note that this variable is only likely
>> to be set in cases where users have both PySide and PyQt4, and the
>> default is behavior is *not* what the user wants. ?That said, a
>> warning rather than raising is perhaps preferable, to handle users who
>> have ETS applications, for which they use QT_API, but also other Qt
>> programs that want to behave differently.
>
> This was my point.

Sorry, I guess it wasn't clear that I was agreeing with you, I only
wanted to note that this is going to be a pretty rare case.  I think
your solution, simply replacing 'pass' with a warning is the way to
go.


From benjaminrk at gmail.com  Mon Jul 18 15:16:01 2011
From: benjaminrk at gmail.com (MinRK)
Date: Mon, 18 Jul 2011 12:16:01 -0700
Subject: [IPython-dev] Just pushed, will only touch docs tomorrow.
In-Reply-To: <CAHAreOqJbCMG9-fWuh4_VyAKp=sf5qqdW_LJocRAeePsYdgozw@mail.gmail.com>
References: <CAHAreOqJbCMG9-fWuh4_VyAKp=sf5qqdW_LJocRAeePsYdgozw@mail.gmail.com>
Message-ID: <CAHNn8BVd_DJEKP_buOx4GfQRD8ZDkNBhM6BtDvL2Eb8xdpRC7Q@mail.gmail.com>

Thanks!

I will merge the few little things that have been proposed today
(expanduser in %run args, warning on windows ParentPoller failure,
desktop example fixes, another qt warning), then cut the final RC by
the end of the day.

-MinRK

On Sun, Jul 17, 2011 at 22:30, Fernando Perez <fperez.net at gmail.com> wrote:
> Howdy,
>
> If anyone has some bandwidth to cut the rc tomorrow so that we keep
> our promise of a Friday or Saturday release, I just pushed what I'd
> been doing on the plane, which included a couple of tiny code fixes
> (trivial stuff).
>
> As of tomorrow, I will *only* touch docs, so that there's zero danger
> of a brown-paper-bag bug at the last minute.
>
> I have two long flights, I'll try to put them to good use working on
> the release notes, and hopefully getting the man pages in shape with
> rst2man.
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>


From dsdale24 at gmail.com  Mon Jul 18 15:28:48 2011
From: dsdale24 at gmail.com (Darren Dale)
Date: Mon, 18 Jul 2011 15:28:48 -0400
Subject: [IPython-dev] Qt api selection re. ipython and matplotlib
In-Reply-To: <CAHNn8BUmcd5qMaGr=SNnODqx016bKC7d1UOGY4b6zePwxGXSBA@mail.gmail.com>
References: <CAHAreOoMSsD8UYCPHKT_RcESpCWAFuM0VcBWN3t+KR1MZ4ZGnQ@mail.gmail.com>
	<CAK6O52kGTchAcsxH6mt9GRxZ==yhxdX=f+8o3e+XZHujCi17=g@mail.gmail.com>
	<4E128BA4.8090308@hawaii.edu>
	<CAHNn8BWfZur_5f0Cm7NNfkg+jyAmvOXcfnD3Yj3yAOzea7XVdw@mail.gmail.com>
	<4E12AD93.4080901@hawaii.edu>
	<CAK6O52=EhM9_-h8nK-j2vHg_puF7kE=z_2JM0v58WeCsGh59HA@mail.gmail.com>
	<4E133FC3.1090108@hawaii.edu>
	<CAHNn8BV6M+6GSouOe48JtE6xhmsWBCgkZVNg_DBbZONdSS-o3w@mail.gmail.com>
	<CAK6O52m0R3ugOkV9gznHmGgMRXAF+yij3PWnisVS8N_98ti+6w@mail.gmail.com>
	<CAHNn8BU1Zh4Nu=-jgZCNMCEs4m_sZdYzB1e1C_LuNvO=Mdxh+A@mail.gmail.com>
	<4E1419AD.4010003@hawaii.edu>
	<D4EEB2E1-C248-42A8-87F1-D7B1A98E438A@enthought.com>
	<CAHNn8BV+y-P1enkzWy_JkOa7gMn-Rhdixm7f+ueE1C5eioii=Q@mail.gmail.com>
	<4E14C445.7010602@hawaii.edu>
	<CAK6O52nkee6Ucr3ZmQhj68WZkoTRnkjE4UFA-GLs_xtPV38SOg@mail.gmail.com>
	<CAHNn8BVDSB7Rp_q1As8tnkoXOxsyMTZw4GY6Kps9i=cydEsuwQ@mail.gmail.com>
	<CAK6O52nKfYaXiLDYojWXjpPAs5KpkPo9Z=kzSyc7FpqUrQKW8A@mail.gmail.com>
	<CAHNn8BUmcd5qMaGr=SNnODqx016bKC7d1UOGY4b6zePwxGXSBA@mail.gmail.com>
Message-ID: <CAK6O52=+LWpP1LWR9U9Khd0WqbDzX-FTnd1ibuO6dnPLx6rvCQ@mail.gmail.com>

On Mon, Jul 18, 2011 at 2:37 PM, MinRK <benjaminrk at gmail.com> wrote:
> Sorry, I guess it wasn't clear that I was agreeing with you

That was on me. Sorry.

> I only
> wanted to note that this is going to be a pretty rare case. ?I think
> your solution, simply replacing 'pass' with a warning is the way to
> go.

Done.


From benjaminrk at gmail.com  Mon Jul 18 15:35:45 2011
From: benjaminrk at gmail.com (MinRK)
Date: Mon, 18 Jul 2011 12:35:45 -0700
Subject: [IPython-dev] Qt api selection re. ipython and matplotlib
In-Reply-To: <CAK6O52=+LWpP1LWR9U9Khd0WqbDzX-FTnd1ibuO6dnPLx6rvCQ@mail.gmail.com>
References: <CAHAreOoMSsD8UYCPHKT_RcESpCWAFuM0VcBWN3t+KR1MZ4ZGnQ@mail.gmail.com>
	<CAK6O52kGTchAcsxH6mt9GRxZ==yhxdX=f+8o3e+XZHujCi17=g@mail.gmail.com>
	<4E128BA4.8090308@hawaii.edu>
	<CAHNn8BWfZur_5f0Cm7NNfkg+jyAmvOXcfnD3Yj3yAOzea7XVdw@mail.gmail.com>
	<4E12AD93.4080901@hawaii.edu>
	<CAK6O52=EhM9_-h8nK-j2vHg_puF7kE=z_2JM0v58WeCsGh59HA@mail.gmail.com>
	<4E133FC3.1090108@hawaii.edu>
	<CAHNn8BV6M+6GSouOe48JtE6xhmsWBCgkZVNg_DBbZONdSS-o3w@mail.gmail.com>
	<CAK6O52m0R3ugOkV9gznHmGgMRXAF+yij3PWnisVS8N_98ti+6w@mail.gmail.com>
	<CAHNn8BU1Zh4Nu=-jgZCNMCEs4m_sZdYzB1e1C_LuNvO=Mdxh+A@mail.gmail.com>
	<4E1419AD.4010003@hawaii.edu>
	<D4EEB2E1-C248-42A8-87F1-D7B1A98E438A@enthought.com>
	<CAHNn8BV+y-P1enkzWy_JkOa7gMn-Rhdixm7f+ueE1C5eioii=Q@mail.gmail.com>
	<4E14C445.7010602@hawaii.edu>
	<CAK6O52nkee6Ucr3ZmQhj68WZkoTRnkjE4UFA-GLs_xtPV38SOg@mail.gmail.com>
	<CAHNn8BVDSB7Rp_q1As8tnkoXOxsyMTZw4GY6Kps9i=cydEsuwQ@mail.gmail.com>
	<CAK6O52nKfYaXiLDYojWXjpPAs5KpkPo9Z=kzSyc7FpqUrQKW8A@mail.gmail.com>
	<CAHNn8BUmcd5qMaGr=SNnODqx016bKC7d1UOGY4b6zePwxGXSBA@mail.gmail.com>
	<CAK6O52=+LWpP1LWR9U9Khd0WqbDzX-FTnd1ibuO6dnPLx6rvCQ@mail.gmail.com>
Message-ID: <CAHNn8BVwNe-Wo50tFYCs6HY-_OOLmcRJmA+iyAmTK-GYGXNmww@mail.gmail.com>

On Mon, Jul 18, 2011 at 12:28, Darren Dale <dsdale24 at gmail.com> wrote:
> On Mon, Jul 18, 2011 at 2:37 PM, MinRK <benjaminrk at gmail.com> wrote:
>> Sorry, I guess it wasn't clear that I was agreeing with you
>
> That was on me. Sorry.
>
>> I only
>> wanted to note that this is going to be a pretty rare case. ?I think
>> your solution, simply replacing 'pass' with a warning is the way to
>> go.
>
> Done.

Awesome, thanks!  Also matched in IPython.

Thanks for all your help on this one.


From ischnell at enthought.com  Mon Jul 18 18:25:34 2011
From: ischnell at enthought.com (Ilan Schnell)
Date: Mon, 18 Jul 2011 17:25:34 -0500
Subject: [IPython-dev] Blog about import registry hooks in EPD
Message-ID: <CAAUn5qJKpjJD9PFE=mgrQ3D3vVkH14Yi0ZBc1Hs5hERW4XEXOg@mail.gmail.com>

I just finished the blog: http://blog.enthought.com/
As discussed, this could be useful for ipython testing.

- Ilan


From benjaminrk at gmail.com  Mon Jul 18 19:52:02 2011
From: benjaminrk at gmail.com (MinRK)
Date: Mon, 18 Jul 2011 16:52:02 -0700
Subject: [IPython-dev] announcing 0.11.rc4 (the last one)
Message-ID: <CAHNn8BWcdHL2n-8d8oxU59mSgLzKn=BbEAkrNDjZ2Z97zKGjxA@mail.gmail.com>

Hello again,

We just cut 0.11.rc4, which we intend to be the final release
candidate.  We were being a little bit loose with the previous few,
making some changes to interfaces, etc as they came up.  This time, we
mean it.  No code changes other than documentation and fixing critical
bugs revealed this week will make it into 0.11 final, to be released
this Friday or Saturday.

rc4 files at http://archive.ipython.org/testing

dev docs at http://ipython.org/ipython-doc/dev also updated to rc4.

Thanks again to everyone who has helped on this, especially those at
SciPy 2011, who helped me find and fix several bugs, as well as make
some improvements.

-MinRK


From ischnell at enthought.com  Mon Jul 18 21:15:21 2011
From: ischnell at enthought.com (Ilan Schnell)
Date: Mon, 18 Jul 2011 20:15:21 -0500
Subject: [IPython-dev] announcing 0.11.rc4 (the last one)
In-Reply-To: <CAHNn8BWcdHL2n-8d8oxU59mSgLzKn=BbEAkrNDjZ2Z97zKGjxA@mail.gmail.com>
References: <CAHNn8BWcdHL2n-8d8oxU59mSgLzKn=BbEAkrNDjZ2Z97zKGjxA@mail.gmail.com>
Message-ID: <CAAUn5qLY8fqXzpntG8yVmhTiD9dfBu1QPtRGBc=-WPRMaK-s2g@mail.gmail.com>

Thanks for the rc4 release Min!
I'll start testing it for EPD tomorrow.

- Ilan


On Mon, Jul 18, 2011 at 6:52 PM, MinRK <benjaminrk at gmail.com> wrote:
> Hello again,
>
> We just cut 0.11.rc4, which we intend to be the final release
> candidate. ?We were being a little bit loose with the previous few,
> making some changes to interfaces, etc as they came up. ?This time, we
> mean it. ?No code changes other than documentation and fixing critical
> bugs revealed this week will make it into 0.11 final, to be released
> this Friday or Saturday.
>
> rc4 files at http://archive.ipython.org/testing
>
> dev docs at http://ipython.org/ipython-doc/dev also updated to rc4.
>
> Thanks again to everyone who has helped on this, especially those at
> SciPy 2011, who helped me find and fix several bugs, as well as make
> some improvements.
>
> -MinRK
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>


From fperez.net at gmail.com  Tue Jul 19 02:41:57 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 19 Jul 2011 01:41:57 -0500
Subject: [IPython-dev] Just pushed, will only touch docs tomorrow.
In-Reply-To: <CAHNn8BVd_DJEKP_buOx4GfQRD8ZDkNBhM6BtDvL2Eb8xdpRC7Q@mail.gmail.com>
References: <CAHAreOqJbCMG9-fWuh4_VyAKp=sf5qqdW_LJocRAeePsYdgozw@mail.gmail.com>
	<CAHNn8BVd_DJEKP_buOx4GfQRD8ZDkNBhM6BtDvL2Eb8xdpRC7Q@mail.gmail.com>
Message-ID: <CAHAreOorPtm5kJNT5V-iREGobfToisWetj_0HYcsYj8d7N=64A@mail.gmail.com>

Hey,

On Mon, Jul 18, 2011 at 2:16 PM, MinRK <benjaminrk at gmail.com> wrote:
>
> I will merge the few little things that have been proposed today
> (expanduser in %run args, warning on windows ParentPoller failure,
> desktop example fixes, another qt warning), then cut the final RC by
> the end of the day.

Unfortunately I think my next merge is going to require some review.
While I've tried super hard not to touch any code, it's proving to be
impossible: in documenting the new gui event loop support and checking
that the examples we're providing to explain things actually run, I've
found a few actual bugs that need fixing.

I couldn't quite finish on the plane today, but I'll try to work on it
in the next two days, there's not a ton left to do.  But we really
need to supply a working set of examples and a consistent api for the
event loop stuff, so we don't confuse people, since this is one of the
major new pieces of code we have.

I'll ping again tomorrow, crashing now after a very long day.

Cheers,

f


From matthew.brett at gmail.com  Tue Jul 19 14:38:00 2011
From: matthew.brett at gmail.com (Matthew Brett)
Date: Tue, 19 Jul 2011 19:38:00 +0100
Subject: [IPython-dev] gitwash: standard commit prefix listing?
Message-ID: <CAH6Pt5rpQimFckt+LcaF-KjbX+dvskSBdg-KWATs_cGJ--Oy6g@mail.gmail.com>

Hi,

Yarik Halchenko just suggested that it might be good to list, in
gitwash, standard commit prefixes, as in, each commit message should
start with one of:

ENH: (enhancement)
BUG: (bugfix)
TST: (test)
DOC:

etc.   These are from the numpy standard prefixes.  As in commit message like:

"""
BUG: Iterator reduction buffering bug when the inner loop is bigger
than the buffer size (ticket #1837)

The symptoms of this bug were showing up only for a greater number of operands
because einsum runs specialized loops for fewer operands and dimensions.
""""

We in nibabel have been using different prefixes, but it's not big
trouble to change in the service of a standard.  Michael - what do you
think?  How about y'all at IPython?

See you,

Matthew


From ellisonbg at gmail.com  Wed Jul 20 00:23:42 2011
From: ellisonbg at gmail.com (Brian Granger)
Date: Tue, 19 Jul 2011 21:23:42 -0700
Subject: [IPython-dev] IPython 0.11.rc1 as a built-in shell for a GUI
In-Reply-To: <1311005524.22141.2153081513@webmail.messagingengine.com>
References: <1311005524.22141.2153081513@webmail.messagingengine.com>
Message-ID: <CAH4pYpRcVdupJsewJjKQ25X8qzy7oOkSTT54odoFhP5+v9015w@mail.gmail.com>

Hugo,

Unfortunately, the APIs you are using have been completely refactored
and IPython has a very different design in these areas.  I suggest
looking at the app code here as a starting point:

https://github.com/ipython/ipython/blob/master/IPython/frontend/terminal/ipapp.py

But you are going to have to spend some time becoming familiar with
the IPython internals...

Cheers,

Brian

On Mon, Jul 18, 2011 at 9:12 AM, Hugo Gagnon
<sourceforge.ipython at user.fastmail.fm> wrote:
> Hello,
>
> In the past I've been using 0.10 as a built-in shell for my small GUI.
> When I first implemented it I remember taking most of the code from your
> cookbook. However my GUI now fails miserably at the very first line with
> 0.11.rc1. I don't have the time to go through your doc (and quite
> frankly I'm not an expert programmer) and I would appreciate if someone
> could help me port my code so that it works with 0.11. Here it is:
>
> import StringIO
> import os
> import re
> import subprocess
> import sys
>
> import IPython
>
>
> class Shell(object):
>
> ? ?def __init__(self, input_func, user_ns, user_global_ns):
> ? ? ? ?if '__builtins__' in user_ns: # this fixes a bug in IPython
> ? ? ? ? ? ?del user_ns['__builtins__']
> ? ? ? ?self.IP = IPython.Shell.make_IPython(argv=[],
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? user_ns=user_ns,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? user_global_ns=user_global_ns,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? embedded=True,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? shell_class=IPython.Shell.InteractiveShell)
> ? ? ? ?self.IP.set_hook('shell_hook', self.shell_hook)
>
> ? ? ? ?self.out = StringIO.StringIO()
> ? ? ? ?IPython.iplib.raw_input_original = input_func
> ? ? ? ?IPython.genutils.Term.cout = self.out
> ? ? ? ?IPython.genutils.Term.cerr = self.out
> ? ? ? ?os.environ['TERM'] = 'dumb'
>
> ? ? ? ?self.ip = IPython.ipapi.get()
> ? ? ? ?self.ip.magic('colors NoColor')
>
> ? ? ? ?self.iter_more = 0
> ? ? ? ?self.prompt = str(self.IP.outputcache.prompt1)
> ? ? ? ?self.complete_sep = re.compile('[\s\{\}\[\]\(\)\=]')
>
> ? ?def execute(self):
> ? ? ? ?orig_stdout = sys.stdout
> ? ? ? ?sys.stdout = IPython.Shell.Term.cout
> ? ? ? ?line = self.IP.raw_input(continue_prompt=self.iter_more)
> ? ? ? ?self.iter_more = self.IP.push(line)
> ? ? ? ?if self.iter_more:
> ? ? ? ? ? ?self.prompt = str(self.IP.outputcache.prompt2)
> ? ? ? ?else:
> ? ? ? ? ? ?self.prompt = str(self.IP.outputcache.prompt1)
> ? ? ? ?out = self.out.getvalue().strip()
> ? ? ? ?self.out.truncate(0)
> ? ? ? ?sys.stdout = orig_stdout
> ? ? ? ?return out
>
> ? ?def complete(self, line):
> ? ? ? ?split_line = self.complete_sep.split(line)
> ? ? ? ?possibilities = self.IP.complete(split_line[-1])
> ? ? ? ?if possibilities:
> ? ? ? ? ? ?common_prefix = os.path.commonprefix(possibilities)
> ? ? ? ? ? ?completed = line[:-len(split_line[-1])] + common_prefix
> ? ? ? ?else:
> ? ? ? ? ? ?completed = line
> ? ? ? ?return completed, possibilities
>
> ? ?def shell_hook(self, IP, cmd):
> ? ? ? ?p = subprocess.Popen(cmd, shell=True,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? stdout=subprocess.PIPE,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? stderr=subprocess.STDOUT)
> ? ? ? ?out = p.stdout
> ? ? ? ?print out.read()
> ? ? ? ?out.close()
>
> Your time is very much appreciated,
> --
> ?Hugo Gagnon
> _______________________________________________
> 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 sourceforge.ipython at user.fastmail.fm  Wed Jul 20 10:32:12 2011
From: sourceforge.ipython at user.fastmail.fm (Hugo Gagnon)
Date: Wed, 20 Jul 2011 10:32:12 -0400
Subject: [IPython-dev] IPython 0.11.rc1 as a built-in shell for a GUI
In-Reply-To: <CAH4pYpRcVdupJsewJjKQ25X8qzy7oOkSTT54odoFhP5+v9015w@mail.gmail.com>
References: <1311005524.22141.2153081513@webmail.messagingengine.com>
	<CAH4pYpRcVdupJsewJjKQ25X8qzy7oOkSTT54odoFhP5+v9015w@mail.gmail.com>
Message-ID: <1311172332.28435.2153904849@webmail.messagingengine.com>

Hi Brian,

No worries, I contacted MinRK personally and he amiably guided me
through the port. Everything (almost) work fine now. As it turned out
all I had to do is to use TerminalInteractiveShell and mimic what was in
the interact method.

Thank you all for your support,
--
  Hugo Gagnon


On Tue, 19 Jul 2011 21:23 -0700, "Brian Granger" <ellisonbg at gmail.com>
wrote:
> Hugo,
> 
> Unfortunately, the APIs you are using have been completely refactored
> and IPython has a very different design in these areas.  I suggest
> looking at the app code here as a starting point:
> 
> https://github.com/ipython/ipython/blob/master/IPython/frontend/terminal/ipapp.py
> 
> But you are going to have to spend some time becoming familiar with
> the IPython internals...
> 
> Cheers,
> 
> Brian
> 
> On Mon, Jul 18, 2011 at 9:12 AM, Hugo Gagnon
> <sourceforge.ipython at user.fastmail.fm> wrote:
> > Hello,
> >
> > In the past I've been using 0.10 as a built-in shell for my small GUI.
> > When I first implemented it I remember taking most of the code from your
> > cookbook. However my GUI now fails miserably at the very first line with
> > 0.11.rc1. I don't have the time to go through your doc (and quite
> > frankly I'm not an expert programmer) and I would appreciate if someone
> > could help me port my code so that it works with 0.11. Here it is:
> >
> > import StringIO
> > import os
> > import re
> > import subprocess
> > import sys
> >
> > import IPython
> >
> >
> > class Shell(object):
> >
> > ? ?def __init__(self, input_func, user_ns, user_global_ns):
> > ? ? ? ?if '__builtins__' in user_ns: # this fixes a bug in IPython
> > ? ? ? ? ? ?del user_ns['__builtins__']
> > ? ? ? ?self.IP = IPython.Shell.make_IPython(argv=[],
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? user_ns=user_ns,
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? user_global_ns=user_global_ns,
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? embedded=True,
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? shell_class=IPython.Shell.InteractiveShell)
> > ? ? ? ?self.IP.set_hook('shell_hook', self.shell_hook)
> >
> > ? ? ? ?self.out = StringIO.StringIO()
> > ? ? ? ?IPython.iplib.raw_input_original = input_func
> > ? ? ? ?IPython.genutils.Term.cout = self.out
> > ? ? ? ?IPython.genutils.Term.cerr = self.out
> > ? ? ? ?os.environ['TERM'] = 'dumb'
> >
> > ? ? ? ?self.ip = IPython.ipapi.get()
> > ? ? ? ?self.ip.magic('colors NoColor')
> >
> > ? ? ? ?self.iter_more = 0
> > ? ? ? ?self.prompt = str(self.IP.outputcache.prompt1)
> > ? ? ? ?self.complete_sep = re.compile('[\s\{\}\[\]\(\)\=]')
> >
> > ? ?def execute(self):
> > ? ? ? ?orig_stdout = sys.stdout
> > ? ? ? ?sys.stdout = IPython.Shell.Term.cout
> > ? ? ? ?line = self.IP.raw_input(continue_prompt=self.iter_more)
> > ? ? ? ?self.iter_more = self.IP.push(line)
> > ? ? ? ?if self.iter_more:
> > ? ? ? ? ? ?self.prompt = str(self.IP.outputcache.prompt2)
> > ? ? ? ?else:
> > ? ? ? ? ? ?self.prompt = str(self.IP.outputcache.prompt1)
> > ? ? ? ?out = self.out.getvalue().strip()
> > ? ? ? ?self.out.truncate(0)
> > ? ? ? ?sys.stdout = orig_stdout
> > ? ? ? ?return out
> >
> > ? ?def complete(self, line):
> > ? ? ? ?split_line = self.complete_sep.split(line)
> > ? ? ? ?possibilities = self.IP.complete(split_line[-1])
> > ? ? ? ?if possibilities:
> > ? ? ? ? ? ?common_prefix = os.path.commonprefix(possibilities)
> > ? ? ? ? ? ?completed = line[:-len(split_line[-1])] + common_prefix
> > ? ? ? ?else:
> > ? ? ? ? ? ?completed = line
> > ? ? ? ?return completed, possibilities
> >
> > ? ?def shell_hook(self, IP, cmd):
> > ? ? ? ?p = subprocess.Popen(cmd, shell=True,
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? stdout=subprocess.PIPE,
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? stderr=subprocess.STDOUT)
> > ? ? ? ?out = p.stdout
> > ? ? ? ?print out.read()
> > ? ? ? ?out.close()
> >
> > Your time is very much appreciated,
> > --
> > ?Hugo Gagnon
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> >
> 
> 
> 
> -- 
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu and ellisonbg at gmail.com
> 


From jtaylor.debian at googlemail.com  Wed Jul 20 11:32:13 2011
From: jtaylor.debian at googlemail.com (Julian Taylor)
Date: Wed, 20 Jul 2011 17:32:13 +0200
Subject: [IPython-dev] IPython 0.11.rc1 as a built-in shell for a GUI
In-Reply-To: <1311172332.28435.2153904849@webmail.messagingengine.com>
References: <1311005524.22141.2153081513@webmail.messagingengine.com>	<CAH4pYpRcVdupJsewJjKQ25X8qzy7oOkSTT54odoFhP5+v9015w@mail.gmail.com>
	<1311172332.28435.2153904849@webmail.messagingengine.com>
Message-ID: <4E26F4FD.5080502@googlemail.com>

On 07/20/2011 04:32 PM, Hugo Gagnon wrote:
> Hi Brian,
> 
> No worries, I contacted MinRK personally and he amiably guided me
> through the port. Everything (almost) work fine now. As it turned out
> all I had to do is to use TerminalInteractiveShell and mimic what was in
> the interact method.
> 
> Thank you all for your support,
> --
>   Hugo Gagnon
> 
> 

Hi,
can you place what you have learned on a wiki page?
There is still lots of software that needs porting and that would make
it easier to identify common issues.
I plan on doing some porting of software in debian this weekend.

Thanks,
Julian Taylor

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110720/f02fe5c3/attachment.sig>

From takowl at gmail.com  Wed Jul 20 12:30:07 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Wed, 20 Jul 2011 17:30:07 +0100
Subject: [IPython-dev] IPython 0.11.rc1 as a built-in shell for a GUI
In-Reply-To: <4E26F4FD.5080502@googlemail.com>
References: <1311005524.22141.2153081513@webmail.messagingengine.com>
	<CAH4pYpRcVdupJsewJjKQ25X8qzy7oOkSTT54odoFhP5+v9015w@mail.gmail.com>
	<1311172332.28435.2153904849@webmail.messagingengine.com>
	<4E26F4FD.5080502@googlemail.com>
Message-ID: <CAOvn4qiZQEXyeoe9OzLpq6rexssPZad2muOmm3t4=GiYZpy74g@mail.gmail.com>

On 20 July 2011 16:32, Julian Taylor <jtaylor.debian at googlemail.com> wrote:

> can you place what you have learned on a wiki page?


In fact, if you'd like to inaugurate the new IPython wiki, that would be
great. We'll be moving the content across from the moin wiki after the
release.

http://wiki.ipython.org/index.php?title=Main_Page

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

From benjaminrk at gmail.com  Wed Jul 20 12:40:41 2011
From: benjaminrk at gmail.com (MinRK)
Date: Wed, 20 Jul 2011 09:40:41 -0700
Subject: [IPython-dev] updating an IPython application to work with 0.11
Message-ID: <CAHNn8BVUpLXX5JC1NEmVfOkgas9J20Xqkd56q87uFd7Wc8uzWg@mail.gmail.com>

Forwarding off-list discussion of updating an IPython application to
work with 0.11, since it could be useful to others.


---------- Forwarded message ----------
From: Hugo Gagnon <hugo.gagnon at fastmail.fm>
Date: Tue, Jul 19, 2011 at 12:24
Subject: Re: Embedding IPython 0.11 in a GUI
To: MinRK <benjaminrk at gmail.com>


That worked like a charm! There's one thing left (really) which I just
noticed: right after instantiating TerminalInteractiveShell I turned
off colouring:

IP.magic('colors NoColor')

which works fine for prompts etc. except sometimes for the header of
an object info. For example say I do "a=1" then querying "a?" may
print:

[0;31mType: ? ? ? ? ? ? [0mint
[0;31mBase class: ?[0m<type 'int'>
...

I say sometimes because at first the nocolor command works but after a
while (I would say right after the first command) it turns on again
(again, just for the info headers though). I'm not sure as to what
triggers that change. Then if I manually reset nocolor inside my GUI
it seems to remain in effect indefinitely. Bleh, I don't know if I'm
making sense at all!
--
?Hugo Gagnon



On 2011-07-19, at 2:17 PM, MinRK wrote:

> On Tue, Jul 19, 2011 at 11:10, Hugo Gagnon <hugo.gagnon at fastmail.fm> wrote:
>> Yep, this works. By the way is it possible that io.stdout and io.stderr are sometimes flushed? For example I noticed that when I use IP.complete (or maybe it is something else) they may get redirected to the terminal. I used to use
>
> No, they never get redirected to the terminal. ?They are hooked up to
> sys.stdout/err when an InteractiveShell is instantiated, and any
> changes you make after that will last. ?They are module-level now,
> since the Term object didn't actually do anything except contain the
> two objects, but the module itself does that just as well.
>
> It's possible there are some methods that (possibly incorrectly) hook
> themselves up directly to sys.stdout, in which case io.stdout would be
> ignored.
>
> An easier way to ensure everything goes to the right place is to
> redirect sys.stdout itself before instantiating the InteractiveShell.
> Then anything you still want to print to the terminal should use
> sys.__stdout__, or io.raw_print.
>
>>
>> self.cout = StringIO.StringIO()
>> IPython.genutils.Term.cout = self.out
>> IPython.genutils.Term.cerr = self.out
>>
>> which set them for good, but the variable Term is now gone...
>> --
>> ?Hugo Gagnon
>>
>>
>>
>> On 2011-07-19, at 12:32 PM, MinRK wrote:
>>
>>> On Tue, Jul 19, 2011 at 09:17, Hugo Gagnon <hugo.gagnon at fastmail.fm> wrote:
>>>> You're right all the tools are in that interact method, and it works!
>>>>
>>>> Although FYI I had to use TerminalInteractiveShell since it has the raw_input method.
>>>>
>>>> One last thing: I redirect stdout and stderr to my own file object likewise:
>>>>
>>>> self.out = StringIO.StringIO()
>>>> IPython.utils.io.stdout = IPython.utils.io.IOStream(self.out)
>>>> IPython.utils.io.stderr = IPython.utils.io.IOStream(self.out)
>>>>
>>>> which again works fine, except for e.g. "ls", where then the output appears in the terminal running my GUI.
>>>
>>> The TerminalInteractiveShell uses os.system to launch subprocesses,
>>> which hook up directly to stdin/stdout (not sys.stdin/stdout which can
>>> change). ?This is necessary to allow thing like launching subprocesses
>>> that expect input.
>>> To hook up stdout to your io.stdout, you should just need to do:
>>>
>>> IP.system = IP.system_piped
>>>
>>>>
>>>> I remember writing my own "shell_hook" in 0.10 but that hook seems to have disappeared in 0.11. Any idea?
>>>>
>>>> I am already extremely grateful for your help, and I would understand if you couldn't reply to this email,
>>>>
>>>> Cheers,
>>>> --
>>>> ?Hugo Gagnon
>>>>
>>>>
>>>>
>>>> On 2011-07-19, at 3:09 AM, MinRK wrote:
>>>>
>>>>> I've been swamped with cutting the release, but I will have a look.
>>>>>
>>>>> -MinRK
>>>>>
>>>>> On Jul 18, 2011, at 17:04, "Hugo Gagnon"
>>>>> <sourcefoge.ipython at user.fastmail.fm> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I am sorry to personally disturb you about this issue but I haven't been
>>>>>> able to fix it myself and I really need an expert on the subject... or
>>>>>> perhaps you would like to redirect me to someone else?
>>>>>>
>>>>>> As of 0.10 I could embed an IPython shell in my GUI and everything ran
>>>>>> smoothly. What I need is actually fairly simple but unfortunately I am
>>>>>> quite at a loss in the API :(
>>>>>>
>>>>>> 1) IP = IPython.Shell.make_IPython(argv=[], user_ns=user_ns,
>>>>>> user_global_ns=user_global_ns, embedded=True,
>>>>>> shell_class=IPython.Shell.InteractiveShell)
>>>>>
>>>>> This will be:
>>>>> from IPython import InteractiveShell
>>>>>
>>>>> shell = InteractiveShell(user_ns=user_ns, user_global_ns=user_global_ns)
>>>>>
>>>>>>
>>>>>> 2) Then whenever I had a command to process I invoked:
>>>>>>
>>>>>> line = IP.raw_input(continue_prompt=iter_more)
>>>>>>
>>>>>> where raw_input was my own function returning whatever was at the prompt
>>>>>> and iter_more initially set to 0.
>>>>>>
>>>>>
>>>>> If this is your own function, then I don't know what would change. The
>>>>> raw_input method on the current InteractiveShell takes a string (the
>>>>> prompt), not a bool, though.
>>>>>
>>>>>> 3) This was followed by:
>>>>>>
>>>>>> iter_more = IP.push(line)
>>>>>> if iter_more:
>>>>>> ? prompt = str(IP.outputcache.prompt2)
>>>>>> else:
>>>>>> ? prompt = str(IP.outputcache.prompt1)
>>>>>> to_out = out.getvalue().strip()
>>>>>
>>>>> See the last block in TerminalInteractiveShell.interact, here:
>>>>> https://github.com/ipython/ipython/blob/master/IPython/frontend/terminal/interactiveshell.py#L258
>>>>>
>>>>> So it would be something like:
>>>>>
>>>>> prompt = IP.hooks.generate_prompt(more)
>>>>>
>>>>> IP.input_splitter.push(line)
>>>>> more = IP.input_splitter.push_accepts_more()
>>>>> if not more:
>>>>> ? ?source_raw = IP.input_splitter.source_raw_reset()[1]
>>>>> ? ?IP.run_cell(source_raw)
>>>>>
>>>>>
>>>>> I hope that helps. ?I haven't actually worked much at all on the
>>>>> InteractiveShell, so this is mostly new to me.
>>>>>
>>>>> -MinRK
>>>>>
>>>>>>
>>>>>> where prompt is the (possibly) new prompt, out is a file-like object and
>>>>>> to_out is what I would output in my GUI.
>>>>>>
>>>>>> I would greatly appreciate if you could give me some pointers to
>>>>>> replicate the 3 steps above. I am using the EPD distro which is
>>>>>> currently on 0.11.rc1. I tried a few things myself but somehow I cannot
>>>>>> seem to find the output caching system anymore, for example.
>>>>>>
>>>>>> Kind regards,
>>>>>> --
>>>>>> Hugo Gagnon
>>>>
>>>>
>>
>>


From fperez.net at gmail.com  Fri Jul 22 15:28:57 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 22 Jul 2011 14:28:57 -0500
Subject: [IPython-dev] 0.11 release, last call
Message-ID: <CAHAreOqBBiFraL=KE7OvRfAr2rpewoUR2viTxQ2afSD-WbXwoA@mail.gmail.com>

Hi all,

we're basically ready for releasing 0.11.  Thomas found two very
isolated but nasty bugs that had safe fixes and we reviewed them (PRs
600 and 618) and I have been cleaning up the GUI docs, which required
some small code fixes, but Brian and Thomas have had a look (more eyes
welcome, PR 620).  Once I finish 620, I'll cut the actual release,
either tonight if I find some time or tomorrow.

Cheers,

f


From takowl at gmail.com  Fri Jul 22 17:52:30 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Fri, 22 Jul 2011 22:52:30 +0100
Subject: [IPython-dev] Wiki troubles
Message-ID: <CAOvn4qhD5XBeNshEOOWrOVX+WZ+tz_KUTLhtLFirwCBq7XuyMg@mail.gmail.com>

Hi all,

I'm having some trouble getting the rst extension working on the wiki. See
e.g. http://wiki.ipython.org/index.php?title=Python_3

The plain rst is disappearing, so it's evidently recognises the extension
that should process it (unrecognised tags are shown as plain text). But
nothing else appears, and despite some fiddling, I can't get any error
messages or debug logs to say what's going wrong. I tried first with the
rsttohtml extension, and now with the sphinx-wiki extension, but neither of
them seem to work. The syntax highlighting extension does work, so I believe
I've installed them correctly.

Any ideas?

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

From matthew.brett at gmail.com  Fri Jul 22 18:08:08 2011
From: matthew.brett at gmail.com (Matthew Brett)
Date: Fri, 22 Jul 2011 23:08:08 +0100
Subject: [IPython-dev] Wiki troubles
In-Reply-To: <CAOvn4qhD5XBeNshEOOWrOVX+WZ+tz_KUTLhtLFirwCBq7XuyMg@mail.gmail.com>
References: <CAOvn4qhD5XBeNshEOOWrOVX+WZ+tz_KUTLhtLFirwCBq7XuyMg@mail.gmail.com>
Message-ID: <CAH6Pt5rgg-BK_KJvG=nJdHJR85+xTp8k6eAG=9LS-UzDshJSEA@mail.gmail.com>

Hi,

On Fri, Jul 22, 2011 at 10:52 PM, Thomas Kluyver <takowl at gmail.com> wrote:
> Hi all,
>
> I'm having some trouble getting the rst extension working on the wiki. See
> e.g. http://wiki.ipython.org/index.php?title=Python_3
>
> The plain rst is disappearing, so it's evidently recognises the extension
> that should process it (unrecognised tags are shown as plain text). But
> nothing else appears, and despite some fiddling, I can't get any error
> messages or debug logs to say what's going wrong. I tried first with the
> rsttohtml extension, and now with the sphinx-wiki extension, but neither of
> them seem to work. The syntax highlighting extension does work, so I believe
> I've installed them correctly.
>
> Any ideas?

I wasn't sure exactly what you were doing.  Are you uploading the pages via git?

I think the Gollum setup uses .rest as the extension.  Could that be
the problem?

Best,

Matthew


From matthew.brett at gmail.com  Fri Jul 22 18:56:32 2011
From: matthew.brett at gmail.com (Matthew Brett)
Date: Fri, 22 Jul 2011 23:56:32 +0100
Subject: [IPython-dev] Wiki troubles
In-Reply-To: <CAH6Pt5o4YyySf4WB6FGkWEs0qNPAidiHCt3hyz2qPYCJbRj=0w@mail.gmail.com>
References: <CAOvn4qhD5XBeNshEOOWrOVX+WZ+tz_KUTLhtLFirwCBq7XuyMg@mail.gmail.com>
	<CAH6Pt5rgg-BK_KJvG=nJdHJR85+xTp8k6eAG=9LS-UzDshJSEA@mail.gmail.com>
	<CAH6Pt5o4YyySf4WB6FGkWEs0qNPAidiHCt3hyz2qPYCJbRj=0w@mail.gmail.com>
Message-ID: <CAH6Pt5ocuu=YSWbNd+ctGdKdEEF2ycEKTKjVmi_P4GMxEnFsqQ@mail.gmail.com>

Hi,

On Fri, Jul 22, 2011 at 11:08 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
> Hi,
>
> On Fri, Jul 22, 2011 at 10:52 PM, Thomas Kluyver <takowl at gmail.com> wrote:
>> Hi all,
>>
>> I'm having some trouble getting the rst extension working on the wiki. See
>> e.g. http://wiki.ipython.org/index.php?title=Python_3
>>
>> The plain rst is disappearing, so it's evidently recognises the extension
>> that should process it (unrecognised tags are shown as plain text). But
>> nothing else appears, and despite some fiddling, I can't get any error
>> messages or debug logs to say what's going wrong. I tried first with the
>> rsttohtml extension, and now with the sphinx-wiki extension, but neither of
>> them seem to work. The syntax highlighting extension does work, so I believe
>> I've installed them correctly.
>>
>> Any ideas?
>
> I wasn't sure exactly what you were doing. ?Are you uploading the pages via git?
>
> I think the Gollum setup uses .rest as the extension. ?Could that be
> the problem?

Ah no, you are not using the github wiki machinery, sorry.

This reminds me not to email after going out to the pub. ?Again.

See you,

Matthew


From benjaminrk at gmail.com  Fri Jul 22 20:44:02 2011
From: benjaminrk at gmail.com (MinRK)
Date: Fri, 22 Jul 2011 17:44:02 -0700
Subject: [IPython-dev] 0.11 release, last call
In-Reply-To: <CAHAreOqBBiFraL=KE7OvRfAr2rpewoUR2viTxQ2afSD-WbXwoA@mail.gmail.com>
References: <CAHAreOqBBiFraL=KE7OvRfAr2rpewoUR2viTxQ2afSD-WbXwoA@mail.gmail.com>
Message-ID: <CAHNn8BXAChfiBbhE5MZC74D05E0SqWRuX2R5qVgTbqh1YYxp1Q@mail.gmail.com>

We should also merge #598, 596, and 590, which are all small, easy
fixes that can probably be auto-merged.

-MinRK

On Fri, Jul 22, 2011 at 12:28, Fernando Perez <fperez.net at gmail.com> wrote:
> Hi all,
>
> we're basically ready for releasing 0.11. ?Thomas found two very
> isolated but nasty bugs that had safe fixes and we reviewed them (PRs
> 600 and 618) and I have been cleaning up the GUI docs, which required
> some small code fixes, but Brian and Thomas have had a look (more eyes
> welcome, PR 620). ?Once I finish 620, I'll cut the actual release,
> either tonight if I find some time or tomorrow.
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>


From takowl at gmail.com  Fri Jul 22 20:49:24 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Sat, 23 Jul 2011 01:49:24 +0100
Subject: [IPython-dev] 0.11 release, last call
In-Reply-To: <CAHNn8BXAChfiBbhE5MZC74D05E0SqWRuX2R5qVgTbqh1YYxp1Q@mail.gmail.com>
References: <CAHAreOqBBiFraL=KE7OvRfAr2rpewoUR2viTxQ2afSD-WbXwoA@mail.gmail.com>
	<CAHNn8BXAChfiBbhE5MZC74D05E0SqWRuX2R5qVgTbqh1YYxp1Q@mail.gmail.com>
Message-ID: <CAOvn4qhywWx-k4rzSfjr6CUeFB1bn9XUWoCkiyR3osWo8GAqWw@mail.gmail.com>

On 23 July 2011 01:44, MinRK <benjaminrk at gmail.com> wrote:

> We should also merge #598, 596, and 590, which are all small, easy
> fixes that can probably be auto-merged.
>

Looking at them, I agree that these are pretty harmless and worth tidying up
if we can.

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

From fperez.net at gmail.com  Fri Jul 22 21:22:51 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 22 Jul 2011 20:22:51 -0500
Subject: [IPython-dev] 0.11 release, last call
In-Reply-To: <CAOvn4qhywWx-k4rzSfjr6CUeFB1bn9XUWoCkiyR3osWo8GAqWw@mail.gmail.com>
References: <CAHAreOqBBiFraL=KE7OvRfAr2rpewoUR2viTxQ2afSD-WbXwoA@mail.gmail.com>
	<CAHNn8BXAChfiBbhE5MZC74D05E0SqWRuX2R5qVgTbqh1YYxp1Q@mail.gmail.com>
	<CAOvn4qhywWx-k4rzSfjr6CUeFB1bn9XUWoCkiyR3osWo8GAqWw@mail.gmail.com>
Message-ID: <CAHAreOpGbUh1+E4BSYbe7kG7SGxvC=ZL+irqe9Ws1o7fUx_ZXg@mail.gmail.com>

On Fri, Jul 22, 2011 at 7:49 PM, Thomas Kluyver <takowl at gmail.com> wrote:
> Looking at them, I agree that these are pretty harmless and worth tidying up
> if we can.

Done.

I don't have much more time to work tonight, but I'll try to wrap it
up tomorrow.

Cheers,

f

ps - Thomas and I sorted out the problem we were having with the wiki,
so now you can edit at will, by bracketing the content with

<rst>
</rst>

and it seems to be working fine.


From fperez.net at gmail.com  Sat Jul 23 14:03:30 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 23 Jul 2011 13:03:30 -0500
Subject: [IPython-dev] 0.11 release, last call
In-Reply-To: <CAHAreOpGbUh1+E4BSYbe7kG7SGxvC=ZL+irqe9Ws1o7fUx_ZXg@mail.gmail.com>
References: <CAHAreOqBBiFraL=KE7OvRfAr2rpewoUR2viTxQ2afSD-WbXwoA@mail.gmail.com>
	<CAHNn8BXAChfiBbhE5MZC74D05E0SqWRuX2R5qVgTbqh1YYxp1Q@mail.gmail.com>
	<CAOvn4qhywWx-k4rzSfjr6CUeFB1bn9XUWoCkiyR3osWo8GAqWw@mail.gmail.com>
	<CAHAreOpGbUh1+E4BSYbe7kG7SGxvC=ZL+irqe9Ws1o7fUx_ZXg@mail.gmail.com>
Message-ID: <CAHAreOppVh3GZQ+w8F9yZMUHqw8fp4dgJyxup+Wh60ji1i_HLA@mail.gmail.com>

I've just pushed some updates of the what's new file:

https://github.com/fperez/ipython/blob/whatsnew011/docs/source/whatsnew/version0.11.txt

It would be great if you guys can let me know if you spot any major
missing section (there's text to be written, but I want to make sure I
didn't forget any key piece).

Thanks

f


From takowl at gmail.com  Sun Jul 24 19:36:51 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 25 Jul 2011 00:36:51 +0100
Subject: [IPython-dev] Is anyone going to euroscipy?
In-Reply-To: <20110714194957.GE15788@phare.normalesup.org>
References: <4E1CA1D0.8040101@bostream.nu>
	<CAOvn4qiGfFg0muwB+bw6tQ58cK6oCAfpA-zSocF7gqMxjPZkFA@mail.gmail.com>
	<CAHAreOqfupK61yoWNBoYarwLwB_s9xkUjpa5f_u7b1sg7Qz3DA@mail.gmail.com>
	<20110714194957.GE15788@phare.normalesup.org>
Message-ID: <CAOvn4qg9JgC1pXOfJv1BNQOTFnhXoaT7vGejQKYN_Wpnq_8XOg@mail.gmail.com>

On 14 July 2011 20:49, Gael Varoquaux <gael.varoquaux at normalesup.org> wrote:

> On Thu, Jul 14, 2011 at 07:39:37AM -0500, Fernando Perez wrote:
> > If it helps tip your decision, big +1 to you coming :)
>
> I'd love to meet you there!


So I am now registered to go to Euroscipy next month, and I'm looking
forward to meeting those of you who'll be there. Is there any interest in
having a little IPython sprint? There's rooms available on the 23rd & 24th
for sprints, if people are there by then. 0.11 should be out the door soon,
so we could put in some work towards 0.12.

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

From gael.varoquaux at normalesup.org  Mon Jul 25 03:08:07 2011
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Mon, 25 Jul 2011 09:08:07 +0200
Subject: [IPython-dev] Is anyone going to euroscipy?
In-Reply-To: <CAOvn4qg9JgC1pXOfJv1BNQOTFnhXoaT7vGejQKYN_Wpnq_8XOg@mail.gmail.com>
References: <4E1CA1D0.8040101@bostream.nu>
	<CAOvn4qiGfFg0muwB+bw6tQ58cK6oCAfpA-zSocF7gqMxjPZkFA@mail.gmail.com>
	<CAHAreOqfupK61yoWNBoYarwLwB_s9xkUjpa5f_u7b1sg7Qz3DA@mail.gmail.com>
	<20110714194957.GE15788@phare.normalesup.org>
	<CAOvn4qg9JgC1pXOfJv1BNQOTFnhXoaT7vGejQKYN_Wpnq_8XOg@mail.gmail.com>
Message-ID: <20110725070807.GB29808@phare.normalesup.org>

On Mon, Jul 25, 2011 at 12:36:51AM +0100, Thomas Kluyver wrote:
>    So I am now registered to go to Euroscipy next month, and I'm looking
>    forward to meeting those of you who'll be there. Is there any interest in
>    having a little IPython sprint? There's rooms available on the 23rd & 24th
>    for sprints, if people are there by then. 0.11 should be out the door
>    soon, so we could put in some work towards 0.12.

Just send me an email when you want to organize the sprints.

Gael


From fperez.net at gmail.com  Mon Jul 25 16:05:24 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 25 Jul 2011 15:05:24 -0500
Subject: [IPython-dev] Is anyone going to euroscipy?
In-Reply-To: <20110725070807.GB29808@phare.normalesup.org>
References: <4E1CA1D0.8040101@bostream.nu>
	<CAOvn4qiGfFg0muwB+bw6tQ58cK6oCAfpA-zSocF7gqMxjPZkFA@mail.gmail.com>
	<CAHAreOqfupK61yoWNBoYarwLwB_s9xkUjpa5f_u7b1sg7Qz3DA@mail.gmail.com>
	<20110714194957.GE15788@phare.normalesup.org>
	<CAOvn4qg9JgC1pXOfJv1BNQOTFnhXoaT7vGejQKYN_Wpnq_8XOg@mail.gmail.com>
	<20110725070807.GB29808@phare.normalesup.org>
Message-ID: <CAHAreOri4ZOm=cWQnxiVYL42BGkjifvUr63-sTU1kLyVUbfQBg@mail.gmail.com>

On Mon, Jul 25, 2011 at 2:08 AM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Mon, Jul 25, 2011 at 12:36:51AM +0100, Thomas Kluyver wrote:
>> ? ?So I am now registered to go to Euroscipy next month, and I'm looking
>> ? ?forward to meeting those of you who'll be there. Is there any interest in
>> ? ?having a little IPython sprint? There's rooms available on the 23rd & 24th
>> ? ?for sprints, if people are there by then. 0.11 should be out the door
>> ? ?soon, so we could put in some work towards 0.12.
>
> Just send me an email when you want to organize the sprints.

I arrive on the 24th at 9am to Paris, it would be great if Thomas and
others get a head start.  I'll try to make my way as soon as I can to
the meeting room, though needless to say, in that jetlagged state I
may not be terribly useful :)  But making 0.12 progress will be great
(and sorry for the delay in finishing up the 0.11 release, I'm in
Colombia dealing with some family matters and my time availability has
been much more limited than I'd hoped.  With a bit of luck I'll be
done tonight).

Cheers,

f


From kevin.buchs at gmail.com  Tue Jul 26 15:07:09 2011
From: kevin.buchs at gmail.com (Kevin Buchs)
Date: Tue, 26 Jul 2011 14:07:09 -0500
Subject: [IPython-dev] documentation correction - 0.11.rc4
Message-ID: <CAKT9s6DVL9t+_MVr4HQ3HOEucX_N26dxfqE+sBiWm984J3K-JQ@mail.gmail.com>

I noticed in the %magic interactive help, after "%recall" there seems to be
some content missing and the "%rep" is not starting on a line by itself.
Then there seems to be a repeat of %rep after %rehashx and %reload_ext are
included.

I was also wondering if it has ever been considered to add a blank line
between the sections here ("%recall" and "%rep", e.g.). It would surely help
readability and allow quicker location of the desired info.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110726/e70ee34e/attachment.html>

From takowl at gmail.com  Wed Jul 27 08:55:20 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Wed, 27 Jul 2011 13:55:20 +0100
Subject: [IPython-dev] Fwd: [IPython-User] Cannot background system commands
 in IPython 0.11rc1, Win 7
In-Reply-To: <CAOvn4qiLbHR5aw=ct9CP7b+Mv=OzWXrxTBZNPzxyjSWYmoTnwg@mail.gmail.com>
References: <loom.20110726T132858-185@post.gmane.org>
	<CAOvn4qitSQziM-mMb6ygBRgPusyxsVudfCvV6D0vcmoRaYc2qw@mail.gmail.com>
	<loom.20110726T160700-632@post.gmane.org>
	<CAOvn4qgGhEHmO=QiiG9q0RDX8PyxSPPKnSZ5nsfpxT92uS0RJw@mail.gmail.com>
	<loom.20110726T233329-864@post.gmane.org>
	<loom.20110726T235849-113@post.gmane.org>
	<CAOvn4qi58epkDzMmtRAATZS-PMP6otrseBBmi9z0M3mmXBqEdQ@mail.gmail.com>
	<CADgCd130evHxnhgR8GU4D+j9hUyxO_ErvZ6MT54PZT+JpPW+Jg@mail.gmail.com>
	<CAOvn4qgezFu_ETWp=9jqeC2SFEfAUHzebdQXk88EtdZjjDxJzQ@mail.gmail.com>
	<CADgCd10txfHfsGn3GK9-CbnLfxBSyE49mUgOqhPSXA-s2yuPVA@mail.gmail.com>
	<CAOvn4qiLbHR5aw=ct9CP7b+Mv=OzWXrxTBZNPzxyjSWYmoTnwg@mail.gmail.com>
Message-ID: <CAOvn4qhYQStXJS7hd55t8v6=FdojB1QBzoAHcS85eqy2hcixuw@mail.gmail.com>

Oops, we dropped off list. I'm sending to the dev list rather than the user
list, because this is getting rather technical.

Summary of what's been said:
- Config docs need to be updated, because they still refer to
IPython.config.default.ipython_config, which is gone (the equivalent is
automatically generated)
- Using the Qt console on Windows, you don't see the warning message about
old IPython config files. This might be due to issue 617.
- Some character encoding issues when using pythonw.exe for the Qt console.
When sys.stdin.encoding is None, we might want to fall back to "mbcs" on
Windows before going for ascii.

Thomas

---------- Forwarded message ----------
From: Thomas Kluyver <takowl at gmail.com>
Date: 27 July 2011 13:50
Subject: Re: [IPython-User] Cannot background system commands in IPython
0.11rc1, Win 7
To: Jon Olav Vik <jonovik at gmail.com>


On 27 July 2011 13:31, Jon Olav Vik <jonovik at gmail.com> wrote:

> > Character encoding issues again... So do these only appear when you're
> using
> > pythonw, or do you see them when you start it with python (and leave it
> with
> > system_piped) as well?
>
> Only with pythonw:
> pythonw -m ipython qtconsole


OK, I think the reason for this is that pythonw presumably creates an
environment where sys.stdin is a dummy object, and sys.stdin.encoding is
None. So we fall back to ascii, and the thousands separator, which I guess
is a non-breaking space and therefore not part of ascii, gets decoded as the
replacement symbol (?).*

*I think that we can fall back to "mbcs" as an encoding before ascii on
Windows. From what I can tell, mbcs should correspond to the active code
page on the system, so it should decode the output correctly. The docs are a
bit brief, however.

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

From ellisonbg at gmail.com  Wed Jul 27 17:59:24 2011
From: ellisonbg at gmail.com (Brian Granger)
Date: Wed, 27 Jul 2011 14:59:24 -0700
Subject: [IPython-dev] QT backend failure on EPD 7.1 w ipython master
Message-ID: <CAH4pYpSdZcdb1-r1ocY7RGeDjs1bWtaHK7He1kbDK7RLOb7+Nw@mail.gmail.com>

Hi,

I am testing ipython/master with EPD 7.1 and the qt matplotlib backend
fails with

ImportError: Warning: formlayout requires PyQt4 >v4.3

This is true even with QT_API=pyside.  This fails in both the terminal
based IPython and the qtconsole:

ipython --pylab=qt
ipython qtconsole --pylab=qt

I thought all of this was working?  What is the status of this?

Cheers,

Brian

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


From ischnell at enthought.com  Wed Jul 27 18:31:58 2011
From: ischnell at enthought.com (Ilan Schnell)
Date: Wed, 27 Jul 2011 17:31:58 -0500
Subject: [IPython-dev] QT backend failure on EPD 7.1 w ipython master
In-Reply-To: <CAH4pYpSdZcdb1-r1ocY7RGeDjs1bWtaHK7He1kbDK7RLOb7+Nw@mail.gmail.com>
References: <CAH4pYpSdZcdb1-r1ocY7RGeDjs1bWtaHK7He1kbDK7RLOb7+Nw@mail.gmail.com>
Message-ID: <CAAUn5qKtBCwtxGKyt0oQDuQUTzmsf_eGDCUY0vvwJ3Zvy9r-Ug@mail.gmail.com>

matplotlib does not support PySide yet, however the
qtconsole works with either:
  *  --pylab=inline; in which case matplotlib generates an svn which is
    then rendered by ipython's qtconsole
  * --pylab; in which case (in EPD) matplotlib's wx backend is used in
    an external window

- Ilan

On Wed, Jul 27, 2011 at 4:59 PM, Brian Granger <ellisonbg at gmail.com> wrote:
> Hi,
>
> I am testing ipython/master with EPD 7.1 and the qt matplotlib backend
> fails with
>
> ImportError: Warning: formlayout requires PyQt4 >v4.3
>
> This is true even with QT_API=pyside. ?This fails in both the terminal
> based IPython and the qtconsole:
>
> ipython --pylab=qt
> ipython qtconsole --pylab=qt
>
> I thought all of this was working? ?What is the status of this?
>
> Cheers,
>
> Brian
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu and ellisonbg at gmail.com
>


From dsdale24 at gmail.com  Wed Jul 27 19:58:45 2011
From: dsdale24 at gmail.com (Darren Dale)
Date: Wed, 27 Jul 2011 19:58:45 -0400
Subject: [IPython-dev] QT backend failure on EPD 7.1 w ipython master
In-Reply-To: <CAH4pYpSdZcdb1-r1ocY7RGeDjs1bWtaHK7He1kbDK7RLOb7+Nw@mail.gmail.com>
References: <CAH4pYpSdZcdb1-r1ocY7RGeDjs1bWtaHK7He1kbDK7RLOb7+Nw@mail.gmail.com>
Message-ID: <CAK6O52nbsmXO-nY2W9XtHRse57zUsmGoHboU7KP4CnD3SJis7Q@mail.gmail.com>

On Wed, Jul 27, 2011 at 5:59 PM, Brian Granger <ellisonbg at gmail.com> wrote:
> Hi,
>
> I am testing ipython/master with EPD 7.1 and the qt matplotlib backend
> fails with
>
> ImportError: Warning: formlayout requires PyQt4 >v4.3

What version of PyQt4 do you have installed? What version of
matplotlib? We had worked things out at one point such that this
import error would simply result in the plot options editor being
unavailable. But in the recent work to coordinate all of the import
and api settings logic, the problem may have been reintroduced.


From benjaminrk at gmail.com  Wed Jul 27 20:07:00 2011
From: benjaminrk at gmail.com (MinRK)
Date: Wed, 27 Jul 2011 17:07:00 -0700
Subject: [IPython-dev] QT backend failure on EPD 7.1 w ipython master
In-Reply-To: <CAK6O52nbsmXO-nY2W9XtHRse57zUsmGoHboU7KP4CnD3SJis7Q@mail.gmail.com>
References: <CAH4pYpSdZcdb1-r1ocY7RGeDjs1bWtaHK7He1kbDK7RLOb7+Nw@mail.gmail.com>
	<CAK6O52nbsmXO-nY2W9XtHRse57zUsmGoHboU7KP4CnD3SJis7Q@mail.gmail.com>
Message-ID: <CAHNn8BVox4oA_p3g=vkcQjT+fzzadRGhAAxAo3qrEwPjMuqOAQ@mail.gmail.com>

On Wed, Jul 27, 2011 at 16:58, Darren Dale <dsdale24 at gmail.com> wrote:
> On Wed, Jul 27, 2011 at 5:59 PM, Brian Granger <ellisonbg at gmail.com> wrote:
>> Hi,
>>
>> I am testing ipython/master with EPD 7.1 and the qt matplotlib backend
>> fails with
>>
>> ImportError: Warning: formlayout requires PyQt4 >v4.3
>
> What version of PyQt4 do you have installed? What version of
> matplotlib? We had worked things out at one point such that this
> import error would simply result in the plot options editor being
> unavailable. But in the recent work to coordinate all of the import
> and api settings logic, the problem may have been reintroduced.

Brian,

If you are using the matplotlib in EPD, it's 1.0.1, and doesn't
support PySide, so
PyQt is used unconditionally in that case.  The QT_API support is only
in matplotlib
master right now.

-MinRK


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


From Fernando.Perez at berkeley.edu  Thu Jul 28 01:01:28 2011
From: Fernando.Perez at berkeley.edu (Fernando Perez)
Date: Thu, 28 Jul 2011 00:01:28 -0500
Subject: [IPython-dev] Screenshot of Visual Studio integration?
In-Reply-To: <6C7ABA8B4E309440B857D74348836F2E28ECFC47@TK5EX14MBXC294.redmond.corp.microsoft.com>
References: <CAFFEDumS6=46z8WRfZSWr0zXNS2LMn=8HOuZiuSexhX8+x-smw@mail.gmail.com>
	<6C7ABA8B4E309440B857D74348836F2E28ECFC47@TK5EX14MBXC294.redmond.corp.microsoft.com>
Message-ID: <CAFFEDunRu2LrB5hxOQiJ5eXyWq2-4TvdYunJY4LXNJqAH2bpug@mail.gmail.com>

Hi Dino,

thanks for the Visual Studio screenshot, just in time for the 0.11
release notes!

I'm forwarding your email to the -dev list because I'm out of the
country and with very spotty availability at the moment.  I'm back in
the States next week and in a more normal schedule, but I'm sure  in
the meantime others on thie list may be able to lend a helping hand.

Cheers,

f

On Wed, Jul 27, 2011 at 16:46, Dino Viehland <dinov at microsoft.com> wrote:
> It was good to see you at SciPy as well. ?Sorry for the delay, hopefully this isn't too late,
> and thanks for doing this! ? It's been a rough couple of weeks finishing up our release
> and I had a few problems getting this running, but I have a simple screen shot going.
> Let me know if you'd like it to be smaller or have suggestions on something else I
> should show.
>
> Here's what I ran into:
>
> Ipcluster documentation is out of date in that it mentions "ipcluster create" which
> no longer seems to be valid:
>
> An IPython cluster consists of 1 controller and 1 or more engines. This command
> automates the startup of these processes using a wide range of startup methods
> (SSH, local processes, PBS, mpiexec, Windows HPC Server 2008). To start a
> cluster with 4 engines on your local host simply do 'ipcluster start n=4'. For
> more complex usage you will typically do 'ipcluster create profile=mycluster',
> then edit configuration files, followed by 'ipcluster start profile=mycluster
> n=4'.
>
> That's just a small wart, but I'm having troubles getting up and running on the
> WinHPC cluster. ?In particular I think you've just tightened up your security model
> but I'm not sure exactly what steps I should do to setup the SSH server. ?Have you
> tried this or do you know anyone who has tried this on Windows? ?Should I just
> setup OpenSSH on the cluster and the client and setup keys?
>
>> -----Original Message-----
>> From: fdo.perez at gmail.com [mailto:fdo.perez at gmail.com] On Behalf Of
>> Fernando Perez
>> Sent: Sunday, July 17, 2011 1:12 AM
>> To: Dino Viehland
>> Subject: Screenshot of Visual Studio integration?
>>
>> Hey Dino,
>>
>> It was great to see you at Scipy'11!
>>
>> We haven't written the release notes for 0.11 yet, and I was wondering if you
>> guys would like us to put a screenie in there. ?If so, just send me a png you'd
>> like us to add and I'll be happy to put it in.
>>
>> Cheers,
>>
>> f
>
>


From benjaminrk at gmail.com  Thu Jul 28 02:14:51 2011
From: benjaminrk at gmail.com (MinRK)
Date: Wed, 27 Jul 2011 23:14:51 -0700
Subject: [IPython-dev] Screenshot of Visual Studio integration?
In-Reply-To: <CAFFEDunRu2LrB5hxOQiJ5eXyWq2-4TvdYunJY4LXNJqAH2bpug@mail.gmail.com>
References: <CAFFEDumS6=46z8WRfZSWr0zXNS2LMn=8HOuZiuSexhX8+x-smw@mail.gmail.com>
	<6C7ABA8B4E309440B857D74348836F2E28ECFC47@TK5EX14MBXC294.redmond.corp.microsoft.com>
	<CAFFEDunRu2LrB5hxOQiJ5eXyWq2-4TvdYunJY4LXNJqAH2bpug@mail.gmail.com>
Message-ID: <CAHNn8BWz7m1kf3fT2xvSYKj1qLoP+Ks+zsax7zAAHQqAqb_a1A@mail.gmail.com>

On Wed, Jul 27, 2011 at 22:01, Fernando Perez
<Fernando.Perez at berkeley.edu> wrote:
> Hi Dino,
>
> thanks for the Visual Studio screenshot, just in time for the 0.11
> release notes!
>
> I'm forwarding your email to the -dev list because I'm out of the
> country and with very spotty availability at the moment. ?I'm back in
> the States next week and in a more normal schedule, but I'm sure ?in
> the meantime others on thie list may be able to lend a helping hand.
>
> Cheers,
>
> f
>
> On Wed, Jul 27, 2011 at 16:46, Dino Viehland <dinov at microsoft.com> wrote:
>> It was good to see you at SciPy as well. ?Sorry for the delay, hopefully this isn't too late,
>> and thanks for doing this! ? It's been a rough couple of weeks finishing up our release
>> and I had a few problems getting this running, but I have a simple screen shot going.
>> Let me know if you'd like it to be smaller or have suggestions on something else I
>> should show.
>>
>> Here's what I ran into:
>>
>> Ipcluster documentation is out of date in that it mentions "ipcluster create" which
>> no longer seems to be valid:
>>
>> An IPython cluster consists of 1 controller and 1 or more engines. This command
>> automates the startup of these processes using a wide range of startup methods
>> (SSH, local processes, PBS, mpiexec, Windows HPC Server 2008). To start a
>> cluster with 4 engines on your local host simply do 'ipcluster start n=4'. For
>> more complex usage you will typically do 'ipcluster create profile=mycluster',
>> then edit configuration files, followed by 'ipcluster start profile=mycluster
>> n=4'.

I think this was fixed some weeks ago, but looking over it again, I
did find another typo.

>>
>> That's just a small wart, but I'm having troubles getting up and running on the
>> WinHPC cluster. ?In particular I think you've just tightened up your security model
>> but I'm not sure exactly what steps I should do to setup the SSH server. ?Have you
>> tried this or do you know anyone who has tried this on Windows? ?Should I just
>> setup OpenSSH on the cluster and the client and setup keys?

I have run localhost clusters on Windows, and I understand that Brian
has succeeded in running it with WinHPC.  Windows use is certainly the
least tested, especially with tunnels.

We haven't exactly tightened our security, but since zeromq provides
exactly none, we have to restrict our connections to 'trusted
networks'.  This means that if you want to traverse an untrusted
boundary, you must use ssh tunnels, VPNs, or some such tool.  We do
support paramiko, so you shouldn't need to use openssh on Windows, but
I honestly don't know what the best choice is.  You will need an SSH
server running in a location that has access to the port the
Controller listens on, but as I understand it, Paramiko has the
ability to run a simple tunnel server.  This, I have never tried.

If your machines *are* on a trusted, secure network, you can simply
listen on external interfaces and have no need for ssh.  Simply
specify:

c.HubFactory.ip='*'

(or c.HubFactory.ip='0.0.0.0' if '*' doesn't work for some reason)

to make your Controller listen on all interfaces.

-MinRK

>>
>>> -----Original Message-----
>>> From: fdo.perez at gmail.com [mailto:fdo.perez at gmail.com] On Behalf Of
>>> Fernando Perez
>>> Sent: Sunday, July 17, 2011 1:12 AM
>>> To: Dino Viehland
>>> Subject: Screenshot of Visual Studio integration?
>>>
>>> Hey Dino,
>>>
>>> It was great to see you at Scipy'11!
>>>
>>> We haven't written the release notes for 0.11 yet, and I was wondering if you
>>> guys would like us to put a screenie in there. ?If so, just send me a png you'd
>>> like us to add and I'll be happy to put it in.
>>>
>>> Cheers,
>>>
>>> f
>>
>>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>


From matthew.brett at gmail.com  Thu Jul 28 15:36:35 2011
From: matthew.brett at gmail.com (Matthew Brett)
Date: Thu, 28 Jul 2011 12:36:35 -0700
Subject: [IPython-dev] ipython_directive broken?
Message-ID: <CAH6Pt5pEuJ_dRXysY1_0oiEL=b7vBLG+PD6q823yDm-eZZN3-w@mail.gmail.com>

Hi guys,

Sorry, I spent a little while trying to fix this, but started getting
out of my depth.

[mb312 at angela ~/dev_trees/ipython (master)]$ cd docs/sphinxext/
[mb312 at angela ~/dev_trees/ipython/docs/sphinxext (master)]$ ipython
Python 2.7.1+ (r271:86832, Apr 11 2011, 18:13:53)
Type "copyright", "credits" or "license" for more information.

IPython 0.11.dev -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object', use 'object??' for extra details.

In [1]: import ipython_directive
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)
/home/mb312/dev_trees/ipython/docs/sphinxext/<ipython-input-1-ae3bcd0bc034>
in <module>()
----> 1 import ipython_directive

/home/mb312/dev_trees/ipython/docs/sphinxext/ipython_directive.py in <module>()
     79 # Our own

     80 from IPython import Config, InteractiveShell
---> 81 from IPython.utils.io import Term
     82
     83 #-----------------------------------------------------------------------------


ImportError: cannot import name Term

In [2]:

I tried replacing ``Term`` with ``IOTerm``, but that didn't get me
far, and I realized that didn't make sense for the code using Term
later in the module.

Any pointers?

Thanks a lot,

Matthew


From benjaminrk at gmail.com  Thu Jul 28 15:48:18 2011
From: benjaminrk at gmail.com (MinRK)
Date: Thu, 28 Jul 2011 12:48:18 -0700
Subject: [IPython-dev] ipython_directive broken?
In-Reply-To: <CAH6Pt5pEuJ_dRXysY1_0oiEL=b7vBLG+PD6q823yDm-eZZN3-w@mail.gmail.com>
References: <CAH6Pt5pEuJ_dRXysY1_0oiEL=b7vBLG+PD6q823yDm-eZZN3-w@mail.gmail.com>
Message-ID: <CAHNn8BU3U+ddM=DuxGv+eXNwwuXcBq7Gck5SRXjuu5r+fVOucg@mail.gmail.com>

This was discussed a bit on ipython-user last week
(http://mail.scipy.org/pipermail/ipython-user/2011-July/007918.html)

I have a version of the directive working, at least to some degree, in a branch:

https://github.com/minrk/ipython/blob/ipython_directive/docs/sphinxext/ipython_directive.py


The main part about io.Term is that the IOStream objects are now
module-level, as there was no reason to create a singleton object that
just contained the three streams.

Essentially:

`io.Term.cout/cerr` became `io.stdout/stderr`

And there were a few other changes regarding running code and getting output.

-MinRK


On Thu, Jul 28, 2011 at 12:36, Matthew Brett <matthew.brett at gmail.com> wrote:
> Hi guys,
>
> Sorry, I spent a little while trying to fix this, but started getting
> out of my depth.
>
> [mb312 at angela ~/dev_trees/ipython (master)]$ cd docs/sphinxext/
> [mb312 at angela ~/dev_trees/ipython/docs/sphinxext (master)]$ ipython
> Python 2.7.1+ (r271:86832, Apr 11 2011, 18:13:53)
> Type "copyright", "credits" or "license" for more information.
>
> IPython 0.11.dev -- An enhanced Interactive Python.
> ? ? ? ? ? -> Introduction and overview of IPython's features.
> %quickref -> Quick reference.
> help ? ? ?-> Python's own help system.
> object? ? -> Details about 'object', use 'object??' for extra details.
>
> In [1]: import ipython_directive
> ---------------------------------------------------------------------------
> ImportError ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Traceback (most recent call last)
> /home/mb312/dev_trees/ipython/docs/sphinxext/<ipython-input-1-ae3bcd0bc034>
> in <module>()
> ----> 1 import ipython_directive
>
> /home/mb312/dev_trees/ipython/docs/sphinxext/ipython_directive.py in <module>()
> ? ? 79 # Our own
>
> ? ? 80 from IPython import Config, InteractiveShell
> ---> 81 from IPython.utils.io import Term
> ? ? 82
> ? ? 83 #-----------------------------------------------------------------------------
>
>
> ImportError: cannot import name Term
>
> In [2]:
>
> I tried replacing ``Term`` with ``IOTerm``, but that didn't get me
> far, and I realized that didn't make sense for the code using Term
> later in the module.
>
> Any pointers?
>
> Thanks a lot,
>
> Matthew
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>


From kevin.buchs at gmail.com  Thu Jul 28 15:52:15 2011
From: kevin.buchs at gmail.com (Kevin Buchs)
Date: Thu, 28 Jul 2011 14:52:15 -0500
Subject: [IPython-dev] 0.11.rc4 - shell behavior with spaces in paths
Message-ID: <CAKT9s6B39-0Fs5GpwyxTUSY7URxs9_0Wjr=U1FrTtvwd8insWQ@mail.gmail.com>

Using this rc, I observed the following on Windows XP, 32-bit:

In [9]: cd buchs
C:\Documents and Settings\buchs

In [10]: cd My\ Documents
[Error 3] The system cannot find the path specified: u'My\\ Documents'
C:\Documents and Settings\buchs

In [11]: cd "My Documents"
C:\Documents and Settings\buchs\My Documents

In [12]:

For Input 10, I pressed tab after typing in "My" and it matched "My
Documents", but when I pressed enter, it gave an error.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110728/62c37c00/attachment.html>

From benjaminrk at gmail.com  Thu Jul 28 18:26:02 2011
From: benjaminrk at gmail.com (MinRK)
Date: Thu, 28 Jul 2011 15:26:02 -0700
Subject: [IPython-dev] 0.11.rc4 - shell behavior with spaces in paths
In-Reply-To: <CAKT9s6B39-0Fs5GpwyxTUSY7URxs9_0Wjr=U1FrTtvwd8insWQ@mail.gmail.com>
References: <CAKT9s6B39-0Fs5GpwyxTUSY7URxs9_0Wjr=U1FrTtvwd8insWQ@mail.gmail.com>
Message-ID: <CAHNn8BW7xH+Yx5HqaTckc1DZ0e37jKHy=M13vUMacHzruNXF6w@mail.gmail.com>

This is a known issue, and, as far as I can tell, has been true in
IPython for at least some years, and possibly always.  I reproduced it
with 0.10.2 just now, and something like it is referenced in the 0.9
docs.

See
https://github.com/ipython/ipython/issues/378
and
http://ipython.org/ipython-doc/dev/interactive/reference.html#caution-for-windows-users

IPython has exactly zero Windows users on the dev team, so this kind
of unpleasantness tends to survive longer than it should.  If someone
who actually uses Windows can step up and improve the situation, we
would be exceedingly grateful.

-MinRK

On Thu, Jul 28, 2011 at 12:52, Kevin Buchs <kevin.buchs at gmail.com> wrote:
> Using this rc, I observed the following on Windows XP, 32-bit:
> In [9]: cd buchs
> C:\Documents and Settings\buchs
> In [10]: cd My\ Documents
> [Error 3] The system cannot find the path specified: u'My\\ Documents'
> C:\Documents and Settings\buchs
> In [11]: cd "My Documents"
> C:\Documents and Settings\buchs\My Documents
> In [12]:
> For Input 10, I pressed tab after typing in "My" and it matched "My
> Documents", but when I pressed enter, it gave an error.
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>


From matthew.brett at gmail.com  Thu Jul 28 20:28:22 2011
From: matthew.brett at gmail.com (Matthew Brett)
Date: Thu, 28 Jul 2011 17:28:22 -0700
Subject: [IPython-dev] ipython_directive broken?
In-Reply-To: <CAHNn8BU3U+ddM=DuxGv+eXNwwuXcBq7Gck5SRXjuu5r+fVOucg@mail.gmail.com>
References: <CAH6Pt5pEuJ_dRXysY1_0oiEL=b7vBLG+PD6q823yDm-eZZN3-w@mail.gmail.com>
	<CAHNn8BU3U+ddM=DuxGv+eXNwwuXcBq7Gck5SRXjuu5r+fVOucg@mail.gmail.com>
Message-ID: <CAH6Pt5rF43Ea=dY4_B0YBCJeWgFmofZz-NQFKukL7hooL-Zpzw@mail.gmail.com>

Hi,

On Thu, Jul 28, 2011 at 12:48 PM, MinRK <benjaminrk at gmail.com> wrote:
> This was discussed a bit on ipython-user last week
> (http://mail.scipy.org/pipermail/ipython-user/2011-July/007918.html)
>
> I have a version of the directive working, at least to some degree, in a branch:
>
> https://github.com/minrk/ipython/blob/ipython_directive/docs/sphinxext/ipython_directive.py
>
>
> The main part about io.Term is that the IOStream objects are now
> module-level, as there was no reason to create a singleton object that
> just contained the three streams.
>
> Essentially:
>
> `io.Term.cout/cerr` became `io.stdout/stderr`
>
> And there were a few other changes regarding running code and getting output.

Sorry, I'm not the user list I believe.

Thanks for the file, that works for me, and thanks for the explanation.

Cheers,

Matthew


From tomspur at fedoraproject.org  Fri Jul 29 03:53:55 2011
From: tomspur at fedoraproject.org (Thomas Spura)
Date: Fri, 29 Jul 2011 09:53:55 +0200
Subject: [IPython-dev] 0.11 release, last call
In-Reply-To: <CAHAreOqBBiFraL=KE7OvRfAr2rpewoUR2viTxQ2afSD-WbXwoA@mail.gmail.com>
References: <CAHAreOqBBiFraL=KE7OvRfAr2rpewoUR2viTxQ2afSD-WbXwoA@mail.gmail.com>
Message-ID: <20110729095355.08d56c9a@fedoraproject.com>


There is another really little bug:

When running ipython on the console and exiting, there is a newline
missing, when usung CTRL+d as "exit command" and "saying yes to really
exit".

Greetings,
  Thomas


From takowl at gmail.com  Fri Jul 29 06:03:10 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Fri, 29 Jul 2011 11:03:10 +0100
Subject: [IPython-dev] 0.11 release, last call
In-Reply-To: <20110729095355.08d56c9a@fedoraproject.com>
References: <CAHAreOqBBiFraL=KE7OvRfAr2rpewoUR2viTxQ2afSD-WbXwoA@mail.gmail.com>
	<20110729095355.08d56c9a@fedoraproject.com>
Message-ID: <CAOvn4qgWS=hS40Mbha4H+W=CA2z3n3=DsD8dOguoxB43bpVMcg@mail.gmail.com>

On 29 July 2011 08:53, Thomas Spura <tomspur at fedoraproject.org> wrote:

> When running ipython on the console and exiting, there is a newline
> missing, when usung CTRL+d as "exit command" and "saying yes to really
> exit".
>

Not seeing that here, either with rc3 or master. What version are you using?
Is the problem between the last IPython prompt and the "Do you really want
to exit", or between the confirmation and the next shell prompt?

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

From tomspur at fedoraproject.org  Fri Jul 29 06:21:08 2011
From: tomspur at fedoraproject.org (Thomas Spura)
Date: Fri, 29 Jul 2011 12:21:08 +0200
Subject: [IPython-dev] 0.11 release, last call
In-Reply-To: <CAOvn4qgWS=hS40Mbha4H+W=CA2z3n3=DsD8dOguoxB43bpVMcg@mail.gmail.com>
References: <CAHAreOqBBiFraL=KE7OvRfAr2rpewoUR2viTxQ2afSD-WbXwoA@mail.gmail.com>
	<20110729095355.08d56c9a@fedoraproject.com>
	<CAOvn4qgWS=hS40Mbha4H+W=CA2z3n3=DsD8dOguoxB43bpVMcg@mail.gmail.com>
Message-ID: <20110729122108.4d56a46f@fedoraproject.com>

On Fri, 29 Jul 2011 11:03:10 +0100
Thomas Kluyver wrote:

> On 29 July 2011 08:53, Thomas Spura <tomspur at fedoraproject.org> wrote:
> 
> > When running ipython on the console and exiting, there is a newline
> > missing, when usung CTRL+d as "exit command" and "saying yes to
> > really exit".
> >
> 
> Not seeing that here, either with rc3 or master. What version are you
> using? Is the problem between the last IPython prompt and the "Do you
> really want to exit", or between the confirmation and the next shell
> prompt?

I have rc2 installed and running out of git commit d49dfb2290a it's
also there.

It's between the confirmation and the next shell prompt.

git bisect tells me it's:
70ac4d312b23da91b6eb2eeff8607ab7e3c14a85 is the first bad commit
commit 70ac4d312b23da91b6eb2eeff8607ab7e3c14a85
Author: Fernando Perez
Date:   Tue Aug 24 20:00:39 2010 -0700

    Improve io.rprint* interface, unify usage in ipkernel.
    
    Starting to use print_function where possible.

:040000 040000 88fd0659e38d2f26d054084e717a238ae0b1e6d4
97ffa08e96f21077b67950e30b01fe7f90fc5f97 M	IPython

Thanks,
  Thomas? :)


From pivanov314 at gmail.com  Fri Jul 29 13:50:53 2011
From: pivanov314 at gmail.com (Paul Ivanov)
Date: Fri, 29 Jul 2011 10:50:53 -0700
Subject: [IPython-dev] vim-ipython integration's back
Message-ID: <20110729175052.GE4623@ykcyc>

Hey IPython devs,

I've updated ipy.vim, so you can send lines or whole files for IPython
to execute, and also get back object introspection and word
completions in Vim, like what you get with: object?<enter> and
object.<tab> in IPython.

The big change for ipy.vim is that it no longer requires
the brittle ipy_vimserver.py instantiation, and since it uses
just vim and python, it is platform independent (i.e. should work
even on windows, unlike the previous *nix only solution).

I made a pull request to IPython and just wanted to share here,
for those following the list but not getting pull-request
notification:
https://github.com/ipython/ipython/pull/631

Here's a 3 minute demo of this goodness in action:
http://pirsquared.org/blog/2011/07/28/vim-ipython/

If anyone wants to help improve this guy, I started a standalone
plugin repo here:
http://github.com/ivanov/vim-ipython

big thanks to Min for guiding me through the new IPython
internals at the SciPy2011 sprints (though the bulk of the work
since then has been in wrestling with vim).

best,
-- 
Paul Ivanov
314 address only used for lists,  off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110729/4829fc5b/attachment.sig>

From fperez.net at gmail.com  Fri Jul 29 14:25:10 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 29 Jul 2011 13:25:10 -0500
Subject: [IPython-dev] 0.11 release, last call
In-Reply-To: <20110729122108.4d56a46f@fedoraproject.com>
References: <CAHAreOqBBiFraL=KE7OvRfAr2rpewoUR2viTxQ2afSD-WbXwoA@mail.gmail.com>
	<20110729095355.08d56c9a@fedoraproject.com>
	<CAOvn4qgWS=hS40Mbha4H+W=CA2z3n3=DsD8dOguoxB43bpVMcg@mail.gmail.com>
	<20110729122108.4d56a46f@fedoraproject.com>
Message-ID: <CAHAreOqtmgQ1t-ACagmXSia=cVmFC=Ywr9HNDzt=410xn87R4A@mail.gmail.com>

On Fri, Jul 29, 2011 at 5:21 AM, Thomas Spura <tomspur at fedoraproject.org> wrote:
> I have rc2 installed and running out of git commit d49dfb2290a it's
> also there.
>
> It's between the confirmation and the next shell prompt.

Unfortunately I can't reproduce it either here, ubuntu 10.10...

I'm trying to finish up the release today, so if you want you can file
a ticket for it, and we may be able to track it down later on with a
VM if it only happens in Fedora, for example (I also have a Fedora box
at work, that I'll be able to access next week when I return to the
States).

Cheers,

f


From fperez.net at gmail.com  Fri Jul 29 14:32:57 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 29 Jul 2011 13:32:57 -0500
Subject: [IPython-dev] vim-ipython integration's back
In-Reply-To: <20110729175052.GE4623@ykcyc>
References: <20110729175052.GE4623@ykcyc>
Message-ID: <CAHAreOoBydDOcmM+KYtP_f=OGu9SCjYZTsPJU0gLwCfQN=BMFQ@mail.gmail.com>

On Fri, Jul 29, 2011 at 12:50 PM, Paul Ivanov <pivanov314 at gmail.com> wrote:
> I've updated ipy.vim, so you can send lines or whole files for IPython
> to execute, and also get back object introspection and word
> completions in Vim, like what you get with: object?<enter> and
> object.<tab> in IPython.

Wow!  I just watched the video, this is seriously not cool at all...
Now I may finally have run out of excuses to learn vim and switch from
emacs :)

Awesome work, many thanks!

> The big change for ipy.vim is that it no longer requires
> the brittle ipy_vimserver.py instantiation, and since it uses
> just vim and python, it is platform independent (i.e. should work
> even on windows, unlike the previous *nix only solution).

As I noted in the pull request, this is a little too close to the core
to merge it now, but we'll do it right after release.  I will mention
it in the release notes, however, for more adventurous users who can
use 0.11 and add the small changes themselves, as it's basically made
possible by the 0.11 architecture.

Great work, Paul!

Cheers,

f


From tomspur at fedoraproject.org  Fri Jul 29 15:32:20 2011
From: tomspur at fedoraproject.org (Thomas Spura)
Date: Fri, 29 Jul 2011 21:32:20 +0200
Subject: [IPython-dev] 0.11 release, last call
In-Reply-To: <CAHAreOqtmgQ1t-ACagmXSia=cVmFC=Ywr9HNDzt=410xn87R4A@mail.gmail.com>
References: <CAHAreOqBBiFraL=KE7OvRfAr2rpewoUR2viTxQ2afSD-WbXwoA@mail.gmail.com>
	<20110729095355.08d56c9a@fedoraproject.com>
	<CAOvn4qgWS=hS40Mbha4H+W=CA2z3n3=DsD8dOguoxB43bpVMcg@mail.gmail.com>
	<20110729122108.4d56a46f@fedoraproject.com>
	<CAHAreOqtmgQ1t-ACagmXSia=cVmFC=Ywr9HNDzt=410xn87R4A@mail.gmail.com>
Message-ID: <20110729213220.5888c2ae@fedoraproject.com>

On Fri, 29 Jul 2011 13:25:10 -0500
Fernando Perez wrote:

> On Fri, Jul 29, 2011 at 5:21 AM, Thomas Spura
> <tomspur at fedoraproject.org> wrote:
> > I have rc2 installed and running out of git commit d49dfb2290a it's
> > also there.
> >
> > It's between the confirmation and the next shell prompt.
> 
> Unfortunately I can't reproduce it either here, ubuntu 10.10...
> 
> I'm trying to finish up the release today, so if you want you can file
> a ticket for it, and we may be able to track it down later on with a
> VM if it only happens in Fedora, for example (I also have a Fedora box
> at work, that I'll be able to access next week when I return to the
> States).
> 
> Cheers,
> 
> f

I got it...

It seems fedoras python doesn't support:
"""
print "here"
"""
(I used that for tracking this down)

So I was forced to use:
"""
print("here")
"""
instead.

a simple:
"""
print
"""
without the brackets results in a noop -> No newline.

But with proper python there is another issue:
"""
$ python -c "print"

$ python -c "print()"
()
$ python -c "print('')"

"""

The fix with useing print() is here (works in ipython, in python, we
should need print('') - whyever...):

https://github.com/tomspur/ipython/tree/my_fix_exit

I just did a pull reguest #637.

Thanks,
  Thomas


From ellisonbg at gmail.com  Fri Jul 29 16:10:17 2011
From: ellisonbg at gmail.com (Brian Granger)
Date: Fri, 29 Jul 2011 13:10:17 -0700
Subject: [IPython-dev] vim-ipython integration's back
In-Reply-To: <20110729175052.GE4623@ykcyc>
References: <20110729175052.GE4623@ykcyc>
Message-ID: <CAH4pYpTxA5kKLhp_Y+4YDM-nFtAR1vjfOVTgmQXvGomkL1S0Ew@mail.gmail.com>

I am not a Vim user, but this is great!

Cheers,

Brian

On Fri, Jul 29, 2011 at 10:50 AM, Paul Ivanov <pivanov314 at gmail.com> wrote:
> Hey IPython devs,
>
> I've updated ipy.vim, so you can send lines or whole files for IPython
> to execute, and also get back object introspection and word
> completions in Vim, like what you get with: object?<enter> and
> object.<tab> in IPython.
>
> The big change for ipy.vim is that it no longer requires
> the brittle ipy_vimserver.py instantiation, and since it uses
> just vim and python, it is platform independent (i.e. should work
> even on windows, unlike the previous *nix only solution).
>
> I made a pull request to IPython and just wanted to share here,
> for those following the list but not getting pull-request
> notification:
> https://github.com/ipython/ipython/pull/631
>
> Here's a 3 minute demo of this goodness in action:
> http://pirsquared.org/blog/2011/07/28/vim-ipython/
>
> If anyone wants to help improve this guy, I started a standalone
> plugin repo here:
> http://github.com/ivanov/vim-ipython
>
> big thanks to Min for guiding me through the new IPython
> internals at the SciPy2011 sprints (though the bulk of the work
> since then has been in wrestling with vim).
>
> best,
> --
> Paul Ivanov
> 314 address only used for lists, ?off-list direct email at:
> http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk4y8vYACgkQe+cmRQ8+KPeNRACgl5u6ZCmlHRUcnX0o7sknV7zm
> tpwAnjxwIuzmQkX9WDiGD0hLMLpFfSvq
> =ulC1
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> 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 pivanov314 at gmail.com  Fri Jul 29 16:41:48 2011
From: pivanov314 at gmail.com (Paul Ivanov)
Date: Fri, 29 Jul 2011 13:41:48 -0700
Subject: [IPython-dev] vim-ipython integration's back
In-Reply-To: <CAHAreOoBydDOcmM+KYtP_f=OGu9SCjYZTsPJU0gLwCfQN=BMFQ@mail.gmail.com>
References: <20110729175052.GE4623@ykcyc>
	<CAHAreOoBydDOcmM+KYtP_f=OGu9SCjYZTsPJU0gLwCfQN=BMFQ@mail.gmail.com>
Message-ID: <20110729204148.GF4623@ykcyc>

Fernando Perez, on 2011-07-29 13:32,  wrote:
> Wow!  I just watched the video, this is seriously not cool at all...
> Now I may finally have run out of excuses to learn vim and switch from
> emacs :)

There's no default pinky-binding for brewing coffee, so you may still
reconsider ;)

> As I noted in the pull request, this is a little too close to the core
> to merge it now, but we'll do it right after release.  I will mention
> it in the release notes, however, for more adventurous users who can
> use 0.11 and add the small changes themselves, as it's basically made
> possible by the 0.11 architecture.

Ok, the issue was a missing "flush" method to stdout and stderr
in vim's implementation of sys. This is fixed in vim sources now
(someone from Sage actually sent the patch back in March), but
I've patched it up in ipy.vim itself, so now there are no changes
to the trunk source code needed.

might this make 0.11, now?
-- 
Paul Ivanov
314 address only used for lists,  off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110729/04128b53/attachment.sig>

From fperez.net at gmail.com  Fri Jul 29 19:56:43 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 29 Jul 2011 18:56:43 -0500
Subject: [IPython-dev] vim-ipython integration's back
In-Reply-To: <20110729204148.GF4623@ykcyc>
References: <20110729175052.GE4623@ykcyc>
	<CAHAreOoBydDOcmM+KYtP_f=OGu9SCjYZTsPJU0gLwCfQN=BMFQ@mail.gmail.com>
	<20110729204148.GF4623@ykcyc>
Message-ID: <CAHAreOogtOjrOGap3ZHCMGZosKnN9sRj1ou0wB=oFjRFnsYh6Q@mail.gmail.com>

On Fri, Jul 29, 2011 at 3:41 PM, Paul Ivanov <pivanov314 at gmail.com> wrote:
> might this make 0.11, now?

for the record, since now this is just an example and doesn't touch
the IPython code itself at all, we're merging it.

Cheers,

f


From fperez.net at gmail.com  Fri Jul 29 21:07:48 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 29 Jul 2011 20:07:48 -0500
Subject: [IPython-dev] documentation correction - 0.11.rc4
In-Reply-To: <CAKT9s6DVL9t+_MVr4HQ3HOEucX_N26dxfqE+sBiWm984J3K-JQ@mail.gmail.com>
References: <CAKT9s6DVL9t+_MVr4HQ3HOEucX_N26dxfqE+sBiWm984J3K-JQ@mail.gmail.com>
Message-ID: <CAHAreOrCmQL5X7Lj5LhSJzBAFoMdg3raNWF=+DB9AeTjjXS1PA@mail.gmail.com>

Hi Kevin,

On Tue, Jul 26, 2011 at 2:07 PM, Kevin Buchs <kevin.buchs at gmail.com> wrote:
> I noticed in the %magic interactive help, after "%recall" there seems to be
> some content missing and the "%rep" is not starting on a line by itself.
> Then there seems to be a repeat of %rep after %rehashx and %reload_ext are
> included.
> I was also wondering if it has ever been considered to add a blank line
> between the sections here ("%recall" and "%rep", e.g.). It would surely help
> readability and allow quicker location of the desired info.

this is really a  bug of how we show information about magics: %recall
is just an alias for %rep.  I don't have the time to fix it before
release, so it's tracked here for future work:

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

Thanks for the report!

f


From takowl at gmail.com  Sat Jul 30 11:25:00 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Sat, 30 Jul 2011 16:25:00 +0100
Subject: [IPython-dev] 0.11 release notes
Message-ID: <CAOvn4qjrRxC1o0PdDcCavWKP+NhzSjfmMUf-qACR=SnqwK=o2g@mail.gmail.com>

A couple of points from looking at the release notes after Fernando's merged
his changes in:

The 'Refactoring' section is out of date in that it describes passing
command line options without the leading --, which has been reintroduced.
I'm not sure how best to reword it, but it definitely needs updating.

We're including the full list of issues closed at the bottom, which is going
to make an already long document longer. I suggest we link to them on a
separate page for those who're interested.

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

From gokhansever at gmail.com  Sat Jul 30 12:02:28 2011
From: gokhansever at gmail.com (=?UTF-8?Q?G=C3=B6khan_Sever?=)
Date: Sat, 30 Jul 2011 10:02:28 -0600
Subject: [IPython-dev] vim-ipython integration's back
In-Reply-To: <20110729175052.GE4623@ykcyc>
References: <20110729175052.GE4623@ykcyc>
Message-ID: <CAE5kuyhUD8mXPfXTOPfMNVn_iJ3W2iocj8Njk3+a-0aTwNf6+A@mail.gmail.com>

Great job again Paul. I should overcome my tendency to open two
seperate unconnected Ipython and GVim windows, and force myself to
upgrade to the new IPython with this change.

What is your next feat? Mind controlled Ipython and Vim interaction?

On 7/29/11, Paul Ivanov <pivanov314 at gmail.com> wrote:
> Hey IPython devs,
>
> I've updated ipy.vim, so you can send lines or whole files for IPython
> to execute, and also get back object introspection and word
> completions in Vim, like what you get with: object?<enter> and
> object.<tab> in IPython.
>
> The big change for ipy.vim is that it no longer requires
> the brittle ipy_vimserver.py instantiation, and since it uses
> just vim and python, it is platform independent (i.e. should work
> even on windows, unlike the previous *nix only solution).
>
> I made a pull request to IPython and just wanted to share here,
> for those following the list but not getting pull-request
> notification:
> https://github.com/ipython/ipython/pull/631
>
> Here's a 3 minute demo of this goodness in action:
> http://pirsquared.org/blog/2011/07/28/vim-ipython/
>
> If anyone wants to help improve this guy, I started a standalone
> plugin repo here:
> http://github.com/ivanov/vim-ipython
>
> big thanks to Min for guiding me through the new IPython
> internals at the SciPy2011 sprints (though the bulk of the work
> since then has been in wrestling with vim).
>
> best,
> --
> Paul Ivanov
> 314 address only used for lists,  off-list direct email at:
> http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
>


-- 
G?khan


From fperez.net at gmail.com  Sat Jul 30 12:19:12 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 30 Jul 2011 11:19:12 -0500
Subject: [IPython-dev] 0.11 release notes
In-Reply-To: <CAOvn4qjrRxC1o0PdDcCavWKP+NhzSjfmMUf-qACR=SnqwK=o2g@mail.gmail.com>
References: <CAOvn4qjrRxC1o0PdDcCavWKP+NhzSjfmMUf-qACR=SnqwK=o2g@mail.gmail.com>
Message-ID: <CAHAreOpb-nkgvtsyP1A5G_eEAg=pUzqeK+77yqghbn8tHRjugg@mail.gmail.com>

On Sat, Jul 30, 2011 at 10:25 AM, Thomas Kluyver <takowl at gmail.com> wrote:
>
> The 'Refactoring' section is out of date in that it describes passing
> command line options without the leading --, which has been reintroduced.
> I'm not sure how best to reword it, but it definitely needs updating.

Thanks, I'll take care of it now...

> We're including the full list of issues closed at the bottom, which is going
> to make an already long document longer. I suggest we link to them on a
> separate page for those who're interested.

Sounds good.  I figured putting it last would suffice, but it really
is very long, so I'll just link it for anyone interested.

Thanks for the review!  I've been testing the installation in empty
environments and it's looking good, so later this evening I should be
able to cut the actual release (I only have a few minutes available
right now).

Cheers,

f


From takowl at gmail.com  Sat Jul 30 19:03:36 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Sun, 31 Jul 2011 00:03:36 +0100
Subject: [IPython-dev] IPython websites
Message-ID: <CAOvn4qjBLurPvv_qnN1u6-sB3W2c+vQcR3dr+zGkq_PZ=3ChBw@mail.gmail.com>

If you're doing the release while I'm asleep, I've prepared some updates for
the website in a branch. It may need some more changes, but it's got the new
version numbers, links and brief announcements:

https://github.com/ipython/ipython-website/pull/1

Also, I think we could now make the ipython.scipy.org/ root address a
redirect to ipython.org. Let me know if you see anything on the moin wiki
that needs to be moved across to the new wiki or the new site.

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

From fperez.net at gmail.com  Sat Jul 30 21:03:03 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 30 Jul 2011 20:03:03 -0500
Subject: [IPython-dev] IPython websites
In-Reply-To: <CAOvn4qjBLurPvv_qnN1u6-sB3W2c+vQcR3dr+zGkq_PZ=3ChBw@mail.gmail.com>
References: <CAOvn4qjBLurPvv_qnN1u6-sB3W2c+vQcR3dr+zGkq_PZ=3ChBw@mail.gmail.com>
Message-ID: <CAHAreOpKeh4VzM==cZ3gAzXbjXD59ysorZKnSWW6bdBiDLwWKA@mail.gmail.com>

Hey,

On Sat, Jul 30, 2011 at 6:03 PM, Thomas Kluyver <takowl at gmail.com> wrote:
> If you're doing the release while I'm asleep, I've prepared some updates for
> the website in a branch. It may need some more changes, but it's got the new
> version numbers, links and brief announcements:
>
> https://github.com/ipython/ipython-website/pull/1

Great, many thanks!  I'll take care of it now.

> Also, I think we could now make the ipython.scipy.org/ root address a
> redirect to ipython.org. Let me know if you see anything on the moin wiki
> that needs to be moved across to the new wiki or the new site.

I'll ping the Enthought admin again about it, since I don't have
control over the DNS over there.

I guess in the meantime, your notices at the front page are great.  To
emphasize the point, I'll just remove all other content from the front
page, so nobody has a temptation to linger there.

Cheers,

f


From asmeurer at gmail.com  Sat Jul 30 22:48:43 2011
From: asmeurer at gmail.com (Aaron Meurer)
Date: Sat, 30 Jul 2011 20:48:43 -0600
Subject: [IPython-dev] IPython websites
In-Reply-To: <CAOvn4qjBLurPvv_qnN1u6-sB3W2c+vQcR3dr+zGkq_PZ=3ChBw@mail.gmail.com>
References: <CAOvn4qjBLurPvv_qnN1u6-sB3W2c+vQcR3dr+zGkq_PZ=3ChBw@mail.gmail.com>
Message-ID: <CAKgW=6Jxvxz9GD+UvK9YJqLVAYUoV_XPaboYMC60pb3xBQkJ1g@mail.gmail.com>

On Sat, Jul 30, 2011 at 5:03 PM, Thomas Kluyver <takowl at gmail.com> wrote:
> If you're doing the release while I'm asleep, I've prepared some updates for
> the website in a branch. It may need some more changes, but it's got the new
> version numbers, links and brief announcements:
>
> https://github.com/ipython/ipython-website/pull/1
>
> Also, I think we could now make the ipython.scipy.org/ root address a
> redirect to ipython.org. Let me know if you see anything on the moin wiki
> that needs to be moved across to the new wiki or the new site.

You should definitely do that.  I didn't even know about ipython.org
(though I did wonder why ipython.scipy.org was so out of date).
Google returns ipython.scipy.org as the first result when I search for
"ipython".

Aaron Meurer


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


From fperez.net at gmail.com  Sat Jul 30 22:52:50 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 30 Jul 2011 21:52:50 -0500
Subject: [IPython-dev] IPython websites
In-Reply-To: <CAKgW=6Jxvxz9GD+UvK9YJqLVAYUoV_XPaboYMC60pb3xBQkJ1g@mail.gmail.com>
References: <CAOvn4qjBLurPvv_qnN1u6-sB3W2c+vQcR3dr+zGkq_PZ=3ChBw@mail.gmail.com>
	<CAKgW=6Jxvxz9GD+UvK9YJqLVAYUoV_XPaboYMC60pb3xBQkJ1g@mail.gmail.com>
Message-ID: <CAHAreOqPqr0WfkhT4A51i2zgX2YY-77fLr84wSUJ_HkV77GVTg@mail.gmail.com>

On Sat, Jul 30, 2011 at 9:48 PM, Aaron Meurer <asmeurer at gmail.com> wrote:
> You should definitely do that. ?I didn't even know about ipython.org
> (though I did wonder why ipython.scipy.org was so out of date).
> Google returns ipython.scipy.org as the first result when I search for
> "ipython".

I just did :)

Cheers,

f


From fperez.net at gmail.com  Sun Jul 31 01:14:19 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 31 Jul 2011 00:14:19 -0500
Subject: [IPython-dev] 0.11 final files ready!
Message-ID: <CAHAreOrwHTuOKyLFnYYYpH9cJciPM=LFZ+f7a3NSqf-MyGYaUw@mail.gmail.com>

Hi all,

I'm too tired to write up the final announcement and I want to have a
few brain cells on when I run the PyPI uploads, so instead I'm going
to crash now and will push the formal release tomorrow.  But unless
someone in the next few hours catches a major problem, the final
release files will be these:

http://archive.ipython.org/testing/0.11/

I've already pushed these changes to master, and if no major problems
are found before tomorrow, will just tag this as 0.11 final and make
the formal announcement.

Boy, if there ever was an argument for release early, release often,
it's that writing up and finalizing a two-year development cycle is an
insane amount of work in and of itself...

Cheers,

f


From tomspur at fedoraproject.org  Sun Jul 31 10:15:16 2011
From: tomspur at fedoraproject.org (Thomas Spura)
Date: Sun, 31 Jul 2011 16:15:16 +0200
Subject: [IPython-dev] 0.11 final files ready!
In-Reply-To: <CAHAreOrwHTuOKyLFnYYYpH9cJciPM=LFZ+f7a3NSqf-MyGYaUw@mail.gmail.com>
References: <CAHAreOrwHTuOKyLFnYYYpH9cJciPM=LFZ+f7a3NSqf-MyGYaUw@mail.gmail.com>
Message-ID: <20110731161516.55b0f5cf@fedoraproject.com>

On Sun, 31 Jul 2011 00:14:19 -0500
Fernando Perez wrote:

> I've already pushed these changes to master, and if no major problems
> are found before tomorrow, will just tag this as 0.11 final and make
> the formal announcement.

I just tested it here, and there are only nitpicking rpmlint
warnings/errors. Will do a pull request, when I have it ready (but
nothing that would block the release ;))

(Just the usual 2 failing tests here, what we tend to ignore for a
while.)

Thanks all for the hard work!
	Tom


From fperez.net at gmail.com  Sun Jul 31 10:26:06 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 31 Jul 2011 09:26:06 -0500
Subject: [IPython-dev] 0.11 final files ready!
In-Reply-To: <20110731161516.55b0f5cf@fedoraproject.com>
References: <CAHAreOrwHTuOKyLFnYYYpH9cJciPM=LFZ+f7a3NSqf-MyGYaUw@mail.gmail.com>
	<20110731161516.55b0f5cf@fedoraproject.com>
Message-ID: <CAHAreOrHfHjACiUp6cy=OgDoUfagkdm8YPgugEap9-e0w+D+Xg@mail.gmail.com>

On Sun, Jul 31, 2011 at 9:15 AM, Thomas Spura <tomspur at fedoraproject.org> wrote:
> I just tested it here, and there are only nitpicking rpmlint
> warnings/errors. Will do a pull request, when I have it ready (but
> nothing that would block the release ;))

Glad to hear that! Thanks a lot for checking, I'll proceed then.

> (Just the usual 2 failing tests here, what we tend to ignore for a
> while.)
>
> Thanks all for the hard work!

Happy to have this one out, I must say :)  Thanks for the kind words.

Cheers,

f


From fperez.net at gmail.com  Sun Jul 31 13:19:51 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 31 Jul 2011 12:19:51 -0500
Subject: [IPython-dev] [ANN] IPython 0.11 is officially out
Message-ID: <CAHAreOpeS1yWz_dg7+HYwyCLvL12DZ3JwoWb_6nHOq4eMNGd+w@mail.gmail.com>

Hi all,

on behalf of the IPython development team, I'm thrilled to announce,
after more than two years of development work, the official release of
IPython 0.11.

This release brings a long list of improvements and new features
(along with hopefully few new bugs).  We have completely refactored
IPython, making it a much more friendly project to participate in by
having better separated and organized internals.  We hope you will not
only use the new tools and libraries, but also join us with new ideas
and development.

After this very long development effort, we hope to make a few
stabilization releases at a quicker pace, where we iron out the kinks
in the new APIs and complete some remaining internal cleanup work.  We
will then make a (long awaited) IPython 1.0 release with these stable
APIs.

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

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

- Standalone Qt console
- High-level parallel computing with ZeroMQ
- New model for GUI/plotting support in the terminal
- A two-process architecture
- Fully refactored internal project structure
- Vim integration
- Integration into Microsoft Visual Studio
- Improved unicode support
- Python 3 support
- New profile model
- SQLite storage for history
- New configuration system
- Pasting of code with prompts

And many more...

We closed over 500 tickets, merged over 200 pull requests, and more
than 60 people contributed over 2200 commits for the final release.
Please see our release notes for the full details on everything about
this release: https://github.com/ipython/ipython/zipball/rel-0.11

As usual, if you find any 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 fperez.net at gmail.com  Sun Jul 31 13:24:19 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 31 Jul 2011 12:24:19 -0500
Subject: [IPython-dev] Scipy 2011 IPython talk video is now up
Message-ID: <CAHAreOr+5JV7wxVkEqdFJa+MsSEXuV01Kw-_ByHg74KzNbgq1A@mail.gmail.com>

The Scipy 2011 talk about the new version is now up on video:
http://www.archive.org/details/Wednesday-203-6-IpythonANewArchitectureForInteractiveAndParallel

For reference, the slides that go along with it are here:
http://fperez.org/talks/1107_ipython_scipy.pdf

And this complements nicely Chris' post I mentioned before:
http://stronginference.com/weblog/2011/7/15/innovations-in-ipython.html

I probably should have added these links to the release announcement,
but I don't want to spam those lists now...

Cheers,

f


From satra at mit.edu  Sun Jul 31 13:34:12 2011
From: satra at mit.edu (Satrajit Ghosh)
Date: Sun, 31 Jul 2011 13:34:12 -0400
Subject: [IPython-dev] congratulations
Message-ID: <CA+A4wOk39zxJZgb1nmigABLeRorXvatQUiS2Ca_DYxxBFcvT0w@mail.gmail.com>

awesome job guys. great to see it out!.

cheers,

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

From johann.cohentanugi at gmail.com  Sun Jul 31 13:49:37 2011
From: johann.cohentanugi at gmail.com (Johann Cohen-Tanugi)
Date: Sun, 31 Jul 2011 19:49:37 +0200
Subject: [IPython-dev] congratulations
In-Reply-To: <CA+A4wOk39zxJZgb1nmigABLeRorXvatQUiS2Ca_DYxxBFcvT0w@mail.gmail.com>
References: <CA+A4wOk39zxJZgb1nmigABLeRorXvatQUiS2Ca_DYxxBFcvT0w@mail.gmail.com>
Message-ID: <4E3595B1.1030609@gmail.com>

+1, huge kudos to the core team. It is impressive to see what the 
ipython software evolved into.
cheers,
Johann

On 07/31/2011 07:34 PM, Satrajit Ghosh wrote:
> awesome job guys. great to see it out!.
>
> cheers,
>
> satra
>
>
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>
>
> _______________________________________________
> 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/20110731/5d421f8b/attachment.html>

From takowl at gmail.com  Sun Jul 31 14:35:53 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Sun, 31 Jul 2011 19:35:53 +0100
Subject: [IPython-dev] congratulations
In-Reply-To: <4E3595B1.1030609@gmail.com>
References: <CA+A4wOk39zxJZgb1nmigABLeRorXvatQUiS2Ca_DYxxBFcvT0w@mail.gmail.com>
	<4E3595B1.1030609@gmail.com>
Message-ID: <CAOvn4qhxUjuUuLrssz-SAdKwEnDoAnxO+CYY1-ziz+RETAB-iw@mail.gmail.com>

Well done to everyone who's spent time on it!

The Vim integration Paul wrote at the last minute seems to be getting a good
reception - thanks, Paul. I wonder if this will prompt some emacs user into
updating their integration. ;-)

Thomas

On 31 July 2011 18:49, Johann Cohen-Tanugi <johann.cohentanugi at gmail.com>wrote:

> **
> +1, huge kudos to the core team. It is impressive to see what the ipython
> software evolved into.
> cheers,
> Johann
>
>
> On 07/31/2011 07:34 PM, Satrajit Ghosh wrote:
>
> awesome job guys. great to see it out!.
>
> cheers,
>
> satra
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>
>
> _______________________________________________
> IPython-dev mailing listIPython-dev at scipy.orghttp://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/20110731/c3f44830/attachment.html>

From erik.tollerud at gmail.com  Sun Jul 31 15:18:18 2011
From: erik.tollerud at gmail.com (Erik Tollerud)
Date: Sun, 31 Jul 2011 12:18:18 -0700
Subject: [IPython-dev] congratulations
In-Reply-To: <4E3595B1.1030609@gmail.com>
References: <CA+A4wOk39zxJZgb1nmigABLeRorXvatQUiS2Ca_DYxxBFcvT0w@mail.gmail.com>
	<4E3595B1.1030609@gmail.com>
Message-ID: <CAARXUwXU7VCE2j3SS9BQJf9zOgUNGoasPWrdCncXgfOVWWA=yw@mail.gmail.com>

+10, more like... congrats to the whole team!

This is a huge step forward and I'm thrilled to be able to tell my
colleagues that they should go and get the new release!

On Sun, Jul 31, 2011 at 10:49 AM, Johann Cohen-Tanugi
<johann.cohentanugi at gmail.com> wrote:
> +1, huge kudos to the core team. It is impressive to see what the ipython
> software evolved into.
> cheers,
> Johann
>
> On 07/31/2011 07:34 PM, Satrajit Ghosh wrote:
>
> awesome job guys. great to see it out!.
>
> cheers,
>
> satra
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> 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
>
>



-- 
Erik Tollerud


From asmeurer at gmail.com  Sun Jul 31 20:21:53 2011
From: asmeurer at gmail.com (Aaron Meurer)
Date: Sun, 31 Jul 2011 18:21:53 -0600
Subject: [IPython-dev] 0.11 final files ready!
In-Reply-To: <CAHAreOrHfHjACiUp6cy=OgDoUfagkdm8YPgugEap9-e0w+D+Xg@mail.gmail.com>
References: <CAHAreOrwHTuOKyLFnYYYpH9cJciPM=LFZ+f7a3NSqf-MyGYaUw@mail.gmail.com>
	<20110731161516.55b0f5cf@fedoraproject.com>
	<CAHAreOrHfHjACiUp6cy=OgDoUfagkdm8YPgugEap9-e0w+D+Xg@mail.gmail.com>
Message-ID: <CAKgW=6+e6OngED8DEVqoMoLmfVydT6QTWjSSt837o2b0pmK_Zw@mail.gmail.com>

I realize it is too late to fix this for the 0.11 release, but does or
does not IPython officially support Python 3?  The website seems to
imply that it does, but the README implies that it doesn't.

Aaron Meurer

On Sun, Jul 31, 2011 at 8:26 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Sun, Jul 31, 2011 at 9:15 AM, Thomas Spura <tomspur at fedoraproject.org> wrote:
>> I just tested it here, and there are only nitpicking rpmlint
>> warnings/errors. Will do a pull request, when I have it ready (but
>> nothing that would block the release ;))
>
> Glad to hear that! Thanks a lot for checking, I'll proceed then.
>
>> (Just the usual 2 failing tests here, what we tend to ignore for a
>> while.)
>>
>> Thanks all for the hard work!
>
> Happy to have this one out, I must say :) ?Thanks for the kind words.
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>


From fperez.net at gmail.com  Sun Jul 31 20:24:31 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 31 Jul 2011 19:24:31 -0500
Subject: [IPython-dev] 0.11 final files ready!
In-Reply-To: <CAKgW=6+e6OngED8DEVqoMoLmfVydT6QTWjSSt837o2b0pmK_Zw@mail.gmail.com>
References: <CAHAreOrwHTuOKyLFnYYYpH9cJciPM=LFZ+f7a3NSqf-MyGYaUw@mail.gmail.com>
	<20110731161516.55b0f5cf@fedoraproject.com>
	<CAHAreOrHfHjACiUp6cy=OgDoUfagkdm8YPgugEap9-e0w+D+Xg@mail.gmail.com>
	<CAKgW=6+e6OngED8DEVqoMoLmfVydT6QTWjSSt837o2b0pmK_Zw@mail.gmail.com>
Message-ID: <CAHAreOq0=J2y3vxXGb+eg0sJ65OFzyROxgj1iNai8h0=iqXx5Q@mail.gmail.com>

On Sun, Jul 31, 2011 at 7:21 PM, Aaron Meurer <asmeurer at gmail.com> wrote:
> I realize it is too late to fix this for the 0.11 release, but does or
> does not IPython officially support Python 3? ?The website seems to
> imply that it does, but the README implies that it doesn't.
>

Sorry for the confusion, we're precisely talking about that on IRC right now :)

There *is* py3 support, but currently off a separate repo.  Instructions here:

http://wiki.ipython.org/index.php?title=Python_3

I'm going to update the main page on the site to make this more clearly visible.

Cheers,

f


From klonuo at gmail.com  Sun Jul 31 23:13:24 2011
From: klonuo at gmail.com (Klonuo)
Date: Mon, 1 Aug 2011 05:13:24 +0200
Subject: [IPython-dev] congratulations
In-Reply-To: <CA+A4wOk39zxJZgb1nmigABLeRorXvatQUiS2Ca_DYxxBFcvT0w@mail.gmail.com>
References: <CA+A4wOk39zxJZgb1nmigABLeRorXvatQUiS2Ca_DYxxBFcvT0w@mail.gmail.com>
Message-ID: <20110801051324.78752a31@OS>

Congratulations IPython team for making long-waited official 0.11
release :)

I wish many people be introduced to IPython possibilities. Even general
Python public, not just scientific interested people, as this project
embraces exciting and diverse possibilities of how one may interface
Python code.

Thanks


Cheers