[matplotlib-devel] IPython proposal: getting rid of "ipython -pylab\-wthread\etc."

[Brian Granger]

Hello all,

[sent to mpl-dev, enthought-dev and ipython-dev]

This summer, we are doing some major refactoring of IPython's core.  One of
the things I am working on is changing how IPython's works with GUI
toolkits.  These changes will have a significant impact (hopefully for the
better) on your project, so I wanted to open a discussion about this issue.

Here is the current situation:  currently, IPython uses threads to allow GUI
event loops.  This code lives in IPython.Shell and is extremely subtle, hard
to maintain and fragile.  Fernando and John Hunter have done a fantastic job
in developing this code, but in the long run we need a more robust approach.

Here is the proposal:  Python has an obscure hook called PyOS_InputHook.  By
using this hook, GUI toolkits can interleave their event loop with a command
line program *without threads*.  Even though PyOS_InputHook is not well
known, this is how Python's built-in integration with Tk works.  The good
news is that other GUI toolkits are starting to support PyOS_InputHook:

* PyGTK 2.15.1 has this.
* The mpl MacOSX backend works this way
* Recent versions of PyQT 4 have this.
* I am working with Robin Dunn to implement this in wxPython 2.8 and 2.9

Bottom line: once people are using these recent/upcoming versions of the GUI
toolkits, IPython will no longer need to maintain the code in Shell.py and
IPython won't need to have -pylab/-wthread/etc options.

So, how does affect your project?

* People will be able to use your project interactive from the regular
python prompt.
* You will need to make small changes to your GUI toolkits initialization
code.
* All of us will need to coordinate version transitions to make sure that
there is a clean transition to this new approach.
* I need help testing the new approach (especially with wxPython) to make
sure that your project actually works with the new approach.

What needs to be done at this point?

* I would like to discuss how the transition should be made in terms of
versions.
* I need help testing this new approach in the various toolkits - especially
with wx.
* I want to see if there are other issues related to this that I am missing.

Cheers,

Brian
--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [IPython-dev] IPython proposal: getting rid of "ipython -pylab\-wthread\etc."

[Gael Varoquaux]

On Thu, Jul 16, 2009 at 10:04:33AM -0700, Brian Granger wrote:
>So, how does affect your project?

>* People will be able to use your project interactive from the regular
>python prompt.
>* You will need to make small changes to your GUI toolkits initialization
>code.
>* All of us will need to coordinate version transitions to make sure that
>there is a clean transition to this new approach.
>* I need help testing the new approach (especially with wxPython) to make
>sure that your project actually works with the new approach.

Would it be possible for IPython to expose both solutions for a while
(say 6 month to a year), so that we all have time to adapt?

Ga�l

--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] IPython proposal: getting rid of "ipython -pylab\-wthread\etc."

[Michael Droettboom]

This is a great project and I'm sure we're all looking forward to having 
"just one way to do it".

However, do not overestimate how up-to-date these packages will be, 
particularly in managed environments.  For instance the RHEL4 boxes we 
run at my employer still have pygtk 2.4.  (Yes, that is 4 years old!)  
It would be unfortunate if our users couldn't update matplotlib without 
the pain of recompiling a large part of the gtk stack underneath.

So just a plea to keep the old code paths working -- perhaps surrounded 
in big flashing "REMOVE ME LATER" comments.  I understand that 
maintaining code that fewer and fewer users will be running is like a 
time bomb.  Maybe we could raise a deprecation warning if a user has an 
old version of a toolkit, so at least when the bomb finally goes off the 
user has a first guess as to why.  But I think dropping all support for 
these older versions in one step would be a mistake.

Cheers,
Mike

Brian Granger wrote:
> Hello all,
>
> [sent to mpl-dev, enthought-dev and ipython-dev]
>
> This summer, we are doing some major refactoring of IPython's core.  
> One of the things I am working on is changing how IPython's works with 
> GUI toolkits.  These changes will have a significant impact (hopefully 
> for the better) on your project, so I wanted to open a discussion 
> about this issue.
>
> Here is the current situation:  currently, IPython uses threads to 
> allow GUI event loops.  This code lives in IPython.Shell and is 
> extremely subtle, hard to maintain and fragile.  Fernando and John 
> Hunter have done a fantastic job in developing this code, but in the 
> long run we need a more robust approach.
>
> Here is the proposal:  Python has an obscure hook called 
> PyOS_InputHook.  By using this hook, GUI toolkits can interleave their 
> event loop with a command line program *without threads*.  Even though 
> PyOS_InputHook is not well known, this is how Python's built-in 
> integration with Tk works.  The good news is that other GUI toolkits 
> are starting to support PyOS_InputHook:
>
> * PyGTK 2.15.1 has this.
> * The mpl MacOSX backend works this way
> * Recent versions of PyQT 4 have this.
> * I am working with Robin Dunn to implement this in wxPython 2.8 and 2.9
>
> Bottom line: once people are using these recent/upcoming versions of 
> the GUI toolkits, IPython will no longer need to maintain the code in 
> Shell.py and IPython won't need to have -pylab/-wthread/etc options. 
>
> So, how does affect your project?
>
> * People will be able to use your project interactive from the regular 
> python prompt.
> * You will need to make small changes to your GUI toolkits 
> initialization code.
> * All of us will need to coordinate version transitions to make sure 
> that there is a clean transition to this new approach.
> * I need help testing the new approach (especially with wxPython) to 
> make sure that your project actually works with the new approach.
>
> What needs to be done at this point?
>
> * I would like to discuss how the transition should be made in terms 
> of versions.
> * I need help testing this new approach in the various toolkits - 
> especially with wx.
> * I want to see if there are other issues related to this that I am 
> missing.
>
> Cheers,
>
> Brian
> 
>
> --
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> 
>
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [IPython-dev] IPython proposal: getting rid of "ipython -pylab\-wthread\etc."

[Brian Granger]

On Thu, Jul 16, 2009 at 10:20 AM, Gael Varoquaux <
gael.varoqu...@normalesup.org> wrote:

> On Thu, Jul 16, 2009 at 10:04:33AM -0700, Brian Granger wrote:
> >So, how does affect your project?
>
> >* People will be able to use your project interactive from the regular
> >python prompt.
> >* You will need to make small changes to your GUI toolkits
> initialization
> >code.
> >* All of us will need to coordinate version transitions to make sure
> that
> >there is a clean transition to this new approach.
> >* I need help testing the new approach (especially with wxPython) to
> make
> >sure that your project actually works with the new approach.
>
> Would it be possible for IPython to expose both solutions for a while
> (say 6 month to a year), so that we all have time to adapt?
>

Yes and no.  In the short term, this is definitely possible.  Also, as Ville
mentions, the new approach will also work with *any* older version of
IPython.

However, one of the main things that needs to be refactored in IPython is
the threading model.  This is needed for a variety of reasons, but the
bottom line is this - a number of projects are using IPython as if it were
thread safe (including IPython itself) - but it is not.  When I fix these
things (which will be soon), I am not sure (I am doubtful) that the threaded
Shell.py code will continue to work.  But, this is something that I can look
into.

But, at some point, we will have to say "if you want the old threaded
shells, you will have to use an older version of IPython".  We just have to
figure out what the transition looks like.

Cheers,

Brian




> Gaël
>
--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [IPython-dev] IPython proposal: getting rid of "ipython -pylab\-wthread\etc."

[Gael Varoquaux]

On Thu, Jul 16, 2009 at 08:28:11PM +0300, Ville M. Vainio wrote:
> On Thu, Jul 16, 2009 at 8:20 PM, Gael
> Varoquaux wrote:

> > Would it be possible for IPython to expose both solutions for a while
> > (say 6 month to a year), so that we all have time to adapt?

> You can start adapting already, as indicated in previous post. Just
> adjust the embedding code, and any old version of ipython will work.

So, ... I am dumb, and I haven't been following things well enough (not
enough time). Concretely, what do I need to do to be able to launch
IPython, and pop up a wx dialog not blocking IPython with the new
technology?

Gaël

--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [IPython-dev] IPython proposal: getting rid of "ipython -pylab\-wthread\etc."

[Gael Varoquaux]

On Thu, Jul 16, 2009 at 10:38:56AM -0700, Brian Granger wrote:
>But, at some point, we will have to say "if you want the old threaded
>shells, you will have to use an older version of IPython".� We just have
>to figure out what the transition looks like.

As long as the packages sitting outside of IPython have a way of dealing
with both reasonnably easily that fine. What we don't want to happen is
having confusing errors or instructions depending on the version of
IPython people use.

As Michael points out, there will be people using the old model for a
long time.

Ga�l

--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [IPython-dev] IPython proposal: getting rid of "ipython -pylab\-wthread\etc."

[Brian Granger]

Good question Gael,


> So, ... I am dumb, and I haven't been following things well enough (not
> enough time). Concretely, what do I need to do to be able to launch
> IPython, and pop up a wx dialog not blocking IPython with the new
> technology?
>

If you have a patched version of wx (that Robin and I are working on) you
just do the following (from either ipython or python!):

>>> import wx
>>> app = wx.IApp(clearSigInt=False)  # for interactive app
then you are off to the races (you don't even need to start the mainloop)

With current versions of mpl, you can do:

>>> import wx
>>> app = wx.IApp(clearSigInt=False)
>>> from matplotlib import pyplot as plt
>>> plt.interactive(True)
the everything just works...

Obviously, the creation of the IApp object should be put into the GUI
toolkit initialization code in mpl/mayavi/etc.  I will work with Robin to
get a version of wx posted that has the patched applied so people can begin
to test this.

Cheers,

Brian
--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [IPython-dev] IPython proposal: getting rid of "ipython -pylab\-wthread\etc."

[Gael Varoquaux]

On Thu, Jul 16, 2009 at 10:45:04AM -0700, Brian Granger wrote:
>Obviously, the creation of the IApp object should be put into the GUI
>toolkit initialization code in mpl/mayavi/etc.� I will work with Robin to
>get a version of wx posted that has the patched applied so people can
>begin to test this.

OK, that's great. It enlightens me. So, it seems you guys are on the
right track. I'll just wait for the new versions of wx to come out. You
are doing great work on that.

One piece of warning: Wx has a terrible upgrade path. Upgrading it breaks
stuff. As a consequence, people don't upgrade it often, and my experience
is that we have to maintain compatibility with old version for years (at
least 3 years: in Ubuntu, latest release, installing SPE drags along
wxPython 2.6, and thus people find themselves importing this version
without realizing it).

Ga�l

--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] IPython proposal: getting rid of "ipython -pylab\-wthread\etc."

[Brian Granger]

This is a great project and I'm sure we're all looking forward to having
> "just one way to do it".
>
> However, do not overestimate how up-to-date these packages will be,
> particularly in managed environments.  For instance the RHEL4 boxes we run
> at my employer still have pygtk 2.4.  (Yes, that is 4 years old!)  It would
> be unfortunate if our users couldn't update matplotlib without the pain of
> recompiling a large part of the gtk stack underneath.
>

I am fully aware that some environments upgrade things like GUI toolkits
over very long time scales.  More important - there isn't a released version
of wx that has these capabilities in it.  It will be a long time before
everyone is running the needed versions of wx/gtk/qt.  In the meantime, we
will do everything we can to make sure that people running older versions of
GUI toolkits can continue to use IPython (and mpl).

On the mpl side of things, there will probably have to be some changes to
the GUI toolkit initialization code that detects which way things are being
run (old/new) and then does the right thing.  If we coordinate this well,
that should allow newer versions of mpl to work with both new and old
versions of IPython and the GUI toolkits.  However *at some point*, we will
have to make a clean break.


> So just a plea to keep the old code paths working -- perhaps surrounded in
> big flashing "REMOVE ME LATER" comments.  I understand that maintaining code
> that fewer and fewer users will be running is like a time bomb.


This is especially true of the threaded Shells in IPython.  Honestly, even
with thousands of people using it (as is currently the case) it is a time
bomb.



> Maybe we could raise a deprecation warning if a user has an old version of
> a toolkit, so at least when the bomb finally goes off the user has a first
> guess as to why.  But I think dropping all support for these older versions
> in one step would be a mistake.
>

Yes, there will definitely have to be some sort of transition.  One
possibility is that during the transition, the old threaded Shells would
slowly loose features that become impossible to maintain (such as interrupt
handling in the threaded shells).

With our very limited IPython manpower, we have a very fine line to walk
between moving forward and maintaining backwards compatibility.

Cheers,

Brian


> Cheers,
> Mike
>
> Brian Granger wrote:
>
>> Hello all,
>>
>> [sent to mpl-dev, enthought-dev and ipython-dev]
>>
>> This summer, we are doing some major refactoring of IPython's core.  One
>> of the things I am working on is changing how IPython's works with GUI
>> toolkits.  These changes will have a significant impact (hopefully for the
>> better) on your project, so I wanted to open a discussion about this issue.
>>
>> Here is the current situation:  currently, IPython uses threads to allow
>> GUI event loops.  This code lives in IPython.Shell and is extremely subtle,
>> hard to maintain and fragile.  Fernando and John Hunter have done a
>> fantastic job in developing this code, but in the long run we need a more
>> robust approach.
>>
>> Here is the proposal:  Python has an obscure hook called PyOS_InputHook.
>>  By using this hook, GUI toolkits can interleave their event loop with a
>> command line program *without threads*.  Even though PyOS_InputHook is not
>> well known, this is how Python's built-in integration with Tk works.  The
>> good news is that other GUI toolkits are starting to support PyOS_InputHook:
>>
>> * PyGTK 2.15.1 has this.
>> * The mpl MacOSX backend works this way
>> * Recent versions of PyQT 4 have this.
>> * I am working with Robin Dunn to implement this in wxPython 2.8 and 2.9
>>
>> Bottom line: once people are using these recent/upcoming versions of the
>> GUI toolkits, IPython will no longer need to maintain the code in Shell.py
>> and IPython won't need to have -pylab/-wthread/etc options.
>> So, how does affect your project?
>>
>> * People will be able to use your project interactive from the regular
>> python prompt.
>> * You will need to make small changes to your GUI toolkits initialization
>> code.
>> * All of us will need to coordinate version transitions to make sure that
>> there is a clean transition to this new approach.
>> * I need help testing the new approach (especially with wxPython) to make
>> sure that your project actually works with the new approach.
>>
>> What needs to be done at this point?
>>
>> * I would like to discuss how the transition should be made in terms of
>> versions.
>> * I need help testing this new approach in the various toolkits -
>> especially with wx.
>> * I want to see if there are other issues related to this that I am
>> missing.
>>
>> Cheers,
>>
>> Brian
>> 
>>
>>
>> --
>> Enter the BlackBerry Developer Challenge  This is your chance to win up to
>> $100,000 in prizes! For a limit

Re: [matplotlib-devel] [IPython-dev] IPython proposal: getting rid of "ipython -pylab\-wthread\etc."

[Brian Granger]

> OK, that's great. It enlightens me. So, it seems you guys are on the
> right track. I'll just wait for the new versions of wx to come out. You
> are doing great work on that.
>

Thanks.


> One piece of warning: Wx has a terrible upgrade path. Upgrading it breaks
> stuff. As a consequence, people don't upgrade it often, and my experience
> is that we have to maintain compatibility with old version for years (at
> least 3 years: in Ubuntu, latest release, installing SPE drags along
> wxPython 2.6, and thus people find themselves importing this version
> without realizing it).
>

This is good to know.

Cheers,

Brian


>
> Gaël
>
--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] [OT] Question about the SVN repo

[Gökhan SEVER]

Hello,

I have a little of the topic question. We have a project (
http://sourceforge.net/projects/adpaa/) setup in SF using the CVS.

There when I look at the code submit logs: for instance:

gsever  committed patchset
219of module src
to the Airborne
Data Processing and Analysis  CVS

when I click the patchset link it transfers me into the main src folder not
directly to the modified file as in matplotlib's :

heeres  committed revision
7260to
the
matplotlib  SVN repository,
changing 1 files

here revision nicely transfers me into the right place. So that I can follow
changes easily.

Is this an SVN feature or should we enable something somewhere in the
project proterties?

Thank.

-- 
Gökhan
--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] scipy conference

[Darren Dale]

On Wed, Jul 1, 2009 at 9:39 AM, John Hunter  wrote:

> After a two year hiatus where I inadvertently scheduled my travel
> plans to overlap scipy, I will finally be able to make it to the scipy
> conference this year, and plan to make up for lost time by coming
> early to lead a tutorial on advanced mpl usage, stay through the
> conference, and if any of you are interested, do a sprint.


I am finally able to attend this year! I'm really looking forward to meeting
everyone in person after all these years.



> There are
> lots of interesting things we can work on: refactoring the ticks to
> work nicely with the new spines, pushing forward on the documentation,
> optimizing stuff that is too slow or memory intensive, improving the
> animation API and backend support, gradients, 
>
> Anyone interested?  And if so, feel free to suggest topics or weigh in
> on some I listed.


There was some discussion about units a while back as well, which might be
worth revisiting.


>
> Also, if any of you will be there early for the tutorials, it would be
> great to have some help  from floaters, people who walk around the
> room and help people who get stuck during the hands-on examples or
> teachers, people who lead part of the tutorial.  In particular,
> Michael could do a segment on transforms and paths, JJ could do a
> segment on all his fancy arrows, boxes, annotations, etc, Andrew on
> his spines, Reinier on mplot3d, etc...  I will probably cover all of
> these even if you can't attend or don't want to teach, but it is best
> ot hear from the experts.  And if anyone not mentioned wants to
> contribute a segment, that would be great -- just let me know what it
> is.  The tutorial is 2 hours and focuses on advanced mpl usage so I
> want to avoid the everyday stuff and focus on transforms, paths, event
> handling, animation, the newer features (spines, fancy*, mplot3d) and
> everything else I am currently forgetting.
>

I could possibly serve as a floater during the mpl tutorial, if you still
need one.

Darren
--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [IPython-dev] IPython proposal: getting rid of "ipython -pylab\-wthread\etc."

[Brian Granger]

Yes, this is also a possibility that we need to pursue as it would greatly
help the transition.  I do have a Cython prototype that works.  But, we are
currently testing all of this on wx trunk.  I am not sure if what we are
doing will work on previous versions.  I plan on looking into this.

Cheers,

Brian

On Thu, Jul 16, 2009 at 11:11 AM, Ville M. Vainio wrote:

> On Thu, Jul 16, 2009 at 9:06 PM, Brian Granger
> wrote:
>
> > I am fully aware that some environments upgrade things like GUI toolkits
> > over very long time scales.  More important - there isn't a released
> version
> > of wx that has these capabilities in it.  It will be a long time before
>
> I thought you were able to make wx work with a cython-based
> PyOS_InputHook extension. Possibly a C-based extension could fix this
> issue for users of old wx versions?
>
> --
> Ville M. Vainio
> http://tinyurl.com/vainio
>
--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [IPython-dev] IPython proposal: getting rid of "ipython -pylab\-wthread\etc."

[Brian Granger]

I tried ctypes first, but with no luck.  Here is what I tried:

>>> import readline
>>> import ctypes
>>> ctypes.pythonapi.PyOS_InputHook
<_FuncPtr object at 0x76420>
>>> def my_callback():
...   print "In am here"
...   return 0
...
>>> cbf = ctypes.CFUNCTYPE(ctypes.c_int)(my_callback)
>>> cbf

>>> ctypes.pythonapi.PyOS_InputHook = cbf

Do you see anything wrong with this?

I should probably try it again to see if I can make it work though.

Cheers,

Brian

On Thu, Jul 16, 2009 at 11:35 AM, Robert Kern  wrote:

> On 2009-07-16 13:11, Ville M. Vainio wrote:
> > On Thu, Jul 16, 2009 at 9:06 PM, Brian Granger
>  wrote:
> >
> >> I am fully aware that some environments upgrade things like GUI toolkits
> >> over very long time scales.  More important - there isn't a released
> version
> >> of wx that has these capabilities in it.  It will be a long time before
> >
> > I thought you were able to make wx work with a cython-based
> > PyOS_InputHook extension. Possibly a C-based extension could fix this
> > issue for users of old wx versions?
>
> Or even just a bit of ctypes?
>
> --
> 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-...@scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [IPython-dev] IPython proposal: getting rid of "ipython -pylab\-wthread\etc."

[Brian Granger]

OK, I just found this thread that shows how to set PyOS_InputHook from
ctypes:

http://osdir.com/ml/python.ctypes/2006-12/msg00045.html

I tried it and it works fine.  This will simplify the transition a lot.  I
will develop some pure ctypes prototypes for the various toolkits and then
folks can begin to try this out.

Cheers,

Brian

On Thu, Jul 16, 2009 at 12:13 PM, Brian Granger wrote:

> I tried ctypes first, but with no luck.  Here is what I tried:
>
> >>> import readline
> >>> import ctypes
> >>> ctypes.pythonapi.PyOS_InputHook
> <_FuncPtr object at 0x76420>
> >>> def my_callback():
> ...   print "In am here"
> ...   return 0
> ...
> >>> cbf = ctypes.CFUNCTYPE(ctypes.c_int)(my_callback)
> >>> cbf
> 
> >>> ctypes.pythonapi.PyOS_InputHook = cbf
>
> Do you see anything wrong with this?
>
> I should probably try it again to see if I can make it work though.
>
> Cheers,
>
> Brian
>
>
> On Thu, Jul 16, 2009 at 11:35 AM, Robert Kern wrote:
>
>> On 2009-07-16 13:11, Ville M. Vainio wrote:
>> > On Thu, Jul 16, 2009 at 9:06 PM, Brian Granger
>>  wrote:
>> >
>> >> I am fully aware that some environments upgrade things like GUI
>> toolkits
>> >> over very long time scales.  More important - there isn't a released
>> version
>> >> of wx that has these capabilities in it.  It will be a long time before
>> >
>> > I thought you were able to make wx work with a cython-based
>> > PyOS_InputHook extension. Possibly a C-based extension could fix this
>> > issue for users of old wx versions?
>>
>> Or even just a bit of ctypes?
>>
>> --
>> 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-...@scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>
>
--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] IPython proposal: getting rid of "ipython -pylab\-wthread\etc."

[Brian Granger]

After playing a bit more, I have a ctypes based prototype that can set
PyOS_InputHook in an appropriate way for wx 2.9 (trunk).  I think it is
possible to have a ctypes based version that would work for all the major
GUI toolkits that we could ship with IPython until the transition is over
(i.e., everyone is using a GUI toolkits recent enough).

BUT.  I need to begin to narrow the GUI toolkits and versions that we will
support.

The total number of possibilities (for testing, etc.) is approximately:

(number of OSs~3) x (number of GUI toolkits~qt4/wx/gtk) x (number of
supported versions of each GUI)

Because the first 2 terms are pretty fixed, I want to bring sanity to the
picture by keeping the 3rd term as small as possible.  So, here is a
question.

What versions of what GUI toolkits do we realistically need to support
moving forward (today and beyond)?  By this, I mean that:

"unsupported" = older versions of GUIs toolkits that will have to use older
versions of IPython.
 "supported" = versions of GUIS that will be able to use the PyOS_InputHook
approach in newer releases of IPython.

Cheers,

Brian
--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [IPython-dev] IPython proposal: getting rid of "ipython -pylab\-wthread\etc."

[Gael Varoquaux]

On Thu, Jul 16, 2009 at 01:36:21PM -0700, Brian Granger wrote:
>What versions of what GUI toolkits do we realistically need to support
>moving forward (today and beyond)?� By this, I mean that:

>"unsupported" = older versions of GUIs toolkits that will have to use
>older versions of IPython.
>�"supported" = versions of GUIS that will be able to use the
>PyOS_InputHook approach in newer releases of IPython.

For Wx, we would obviously need to support 2.8. We can toy with the idea
of not supporting 2.6, I believe. A lot of people are starting to feel
that 2.6 is depreciated.

Ga�l

--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [IPython-dev] IPython proposal: getting rid of "ipython -pylab\-wthread\etc."

[Brian Granger]

> For Wx, we would obviously need to support 2.8. We can toy with the idea
> of not supporting 2.6, I believe. A lot of people are starting to feel
> that 2.6 is depreciated.
>

Yes, 2.8 is latest stable, so we should support it.  How many people would
complain if 2.6 were not supported?  I take it that all of ETS is 2.8 based?

Cheers,

Brian



>
> Gaël
>
--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [IPython-dev] IPython proposal: getting rid of "ipython -pylab\-wthread\etc."

[Gael Varoquaux]

On Thu, Jul 16, 2009 at 02:34:01PM -0700, Brian Granger wrote:
>Yes, 2.8 is latest stable, so we should support it.� How many people would
>complain if 2.6 were not supported?� I take it that all of ETS is 2.8
>based?

ETS works better on wx 2.8, but it also works on 2.6, with small bugs.

Ga�l

--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9

[Brian Granger]

Hi,

I am attaching a working ctypes based prototype of a module that allows wx
to be used interactively from *both* python and ipython.  It uses
PyOS_InputHook and has been tested on wx 2.8 and 2.9 (trunk) on Mac OS X
(python 2.5).

It can be used with an existing wx install and all versions of ipython, but
***don't use the -pylab or -wthread flag***.  At this point, I need help
testing the heck out of this (window and linux users esp).  I have run most
matplotlib pylab_examples and they work fine.  I also need people to try out
things like ETS/Mayavi.  The current plan is to replace the existing
threaded shells in IPython with this (much simpler) code.

Cheers,

Brian


inputhook.py
Description: Binary data
--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9

[Gael Varoquaux]

On Thu, Jul 16, 2009 at 03:26:23PM -0700, Brian Granger wrote:
>I am attaching a working ctypes based prototype of a module that allows wx
>to be used interactively from *both* python and ipython.� It uses
>PyOS_InputHook and has been tested on wx 2.8 and 2.9 (trunk) on Mac OS X
>(python 2.5).

>It can be used with an existing wx install and all versions of ipython,
>but ***don't use the -pylab or -wthread flag***.� At this point, I need
>help testing the heck out of this (window and linux users esp).� I have
>run most matplotlib pylab_examples and they work fine.� I also need people
>to try out things like ETS/Mayavi.� The current plan is to replace the
>existing threaded shells in IPython with this (much simpler) code.

I won't be able to do that reliably before two weeks, I am travelling and
have deadlines on top of that. Maybe somebody else can try this?

Cheers,

Ga�l

--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9

[Robert Kern]

On Thu, Jul 16, 2009 at 17:26, Brian Granger wrote:
> Hi,
>
> I am attaching a working ctypes based prototype of a module that allows wx
> to be used interactively from *both* python and ipython.  It uses
> PyOS_InputHook and has been tested on wx 2.8 and 2.9 (trunk) on Mac OS X
> (python 2.5).
>
> It can be used with an existing wx install and all versions of ipython, but
> ***don't use the -pylab or -wthread flag***.  At this point, I need help
> testing the heck out of this (window and linux users esp).  I have run most
> matplotlib pylab_examples and they work fine.  I also need people to try out
> things like ETS/Mayavi.  The current plan is to replace the existing
> threaded shells in IPython with this (much simpler) code.

Works for me with wx 2.8.8.1 on OS X 10.5 and Chaco. Pan and zoom
interactions are substantially chunky, though. I do not see such
chunkiness with -wthread. It would be worth exploring a Cython
alternative to see if it is just ctypes and general Python overhead to
blame.

-- 
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

--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9

[Brian Granger]

Robert,

Thanks for testing this so quickly.  Performance is one of the big issues
that I am concerned about.  I will work on a Cython based version to see if
that solves the problem.

Cheers,

Brian


> Works for me with wx 2.8.8.1 on OS X 10.5 and Chaco. Pan and zoom
> interactions are substantially chunky, though. I do not see such
> chunkiness with -wthread. It would be worth exploring a Cython
> alternative to see if it is just ctypes and general Python overhead to
> blame.
>
> --
> 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-...@scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9

[Michiel de Hoon]

The chunkiness probably comes from the fact that inputhook_wx is called 
repeatedly. This is different from how PyOS_InputHook is being used in Tkinter, 
PyGTK, and the Mac OS X backend.

Schematically, this is how the Tkinter/PyGTK/MacOSX event loops work:

1) PyOS_InputHook is called when Python is waiting for the user to type in the 
next Python command.

2) The hook function sets up the event loop such that stdin is being monitored 
while the event loop is running.

3) The hook function then starts the event loop.

4) When input is available on stdin, the hook function exits the event loop, 
and returns.

This is how the proposed Wx event loop currently works:

1) PyOS_InputHook is called when Python is waiting for the user to type in the 
next Python command.

2) The hook function processes whatever events are available at the time.

3) The hook function returns.

4) If still no input is available on stdin, Python calls the hook function 
again via PyOS_InputHook after a timeout.

I believe the timeout is 0.1 seconds by default. However, Python may not call 
PyOS_InputHook repeatedly at all; this depends on which Python version is being 
used, and the version of the readline library. In some configurations 
(particularly on Windows), PyOS_InputHook is called only once, so wx will 
freeze between Python commands.

I am not familiar with wx, but there hopefully there is some way to monitor 
stdin while the event loop is running?

--Michiel.


--- On Thu, 7/16/09, Brian Granger  wrote:

> From: Brian Granger 
> Subject: Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes based 
> prototype of PyOS_InputHook for wx 2.8 and 2.9
> To: "Robert Kern" 
> Cc: enthought-...@enthought.com, "matplotlib development list" 
> , "IPython Development list" 
> 
> Date: Thursday, July 16, 2009, 6:57 PM
> Robert,
> 
> Thanks for testing this so quickly.  Performance is one of
> the big issues that I am concerned about.  I will work on a
> Cython based version to see if that solves the problem.
> 
> Cheers,
> 
> Brian
> 
> 
> 
> 
> Works for me with wx 2.8.8.1 on OS X 10.5 and
> Chaco. Pan and zoom
> 
> interactions are substantially chunky, though. I do not see
> such
> 
> chunkiness with -wthread. It would be worth exploring a
> Cython
> 
> alternative to see if it is just ctypes and general Python
> overhead to
> 
> blame.
> 
> 
> 
> --
> 
> 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-...@scipy.org
> 
> http://mail.scipy.org/mailman/listinfo/ipython-dev
> 
> 
> 
> 
> -Inline Attachment Follows-
> 
> --
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a
> limited time, 
> vendors submitting new applications to BlackBerry App
> World(TM) will have
> the opportunity to enter the BlackBerry Developer
> Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> -Inline Attachment Follows-
> 
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 


  

--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9

[Brian Granger]

Michiel,

Thanks for the reply, this will help us to find a better approach.
According to one of the wx devs, Robin Dunn, wx currently does not have the
ability to monitor stdin in its even loop without polling.  I guess there is
a GSoC project to add this capability, but it is not there yet.  Any
thoughts on how this could be done without monitoring stdin.  I will give
the polling stdin approach a try though.

Cheers,

Brian



> The chunkiness probably comes from the fact that inputhook_wx is called
> repeatedly. This is different from how PyOS_InputHook is being used in
> Tkinter, PyGTK, and the Mac OS X backend.
>
> Schematically, this is how the Tkinter/PyGTK/MacOSX event loops work:
>
> 1) PyOS_InputHook is called when Python is waiting for the user to type in
> the next Python command.
>
> 2) The hook function sets up the event loop such that stdin is being
> monitored while the event loop is running.
>
> 3) The hook function then starts the event loop.
>
> 4) When input is available on stdin, the hook function exits the event
> loop, and returns.
>
> This is how the proposed Wx event loop currently works:
>
> 1) PyOS_InputHook is called when Python is waiting for the user to type in
> the next Python command.
>
> 2) The hook function processes whatever events are available at the time.
>
> 3) The hook function returns.
>
> 4) If still no input is available on stdin, Python calls the hook function
> again via PyOS_InputHook after a timeout.
>
> I believe the timeout is 0.1 seconds by default. However, Python may not
> call PyOS_InputHook repeatedly at all; this depends on which Python version
> is being used, and the version of the readline library. In some
> configurations (particularly on Windows), PyOS_InputHook is called only
> once, so wx will freeze between Python commands.
>
> I am not familiar with wx, but there hopefully there is some way to monitor
> stdin while the event loop is running?
>
> --Michiel.
>
>
> --- On Thu, 7/16/09, Brian Granger  wrote:
>
> > From: Brian Granger 
> > Subject: Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes
> based prototype of PyOS_InputHook for wx 2.8 and 2.9
> > To: "Robert Kern" 
> > Cc: enthought-...@enthought.com, "matplotlib development list" <
> matplotlib-devel@lists.sourceforge.net>, "IPython Development list" <
> ipython-...@scipy.org>
> > Date: Thursday, July 16, 2009, 6:57 PM
> > Robert,
> >
> > Thanks for testing this so quickly.  Performance is one of
> > the big issues that I am concerned about.  I will work on a
> > Cython based version to see if that solves the problem.
> >
> > Cheers,
> >
> > Brian
> >
> >
> >
> >
> > Works for me with wx 2.8.8.1 on OS X 10.5 and
> > Chaco. Pan and zoom
> >
> > interactions are substantially chunky, though. I do not see
> > such
> >
> > chunkiness with -wthread. It would be worth exploring a
> > Cython
> >
> > alternative to see if it is just ctypes and general Python
> > overhead to
> >
> > blame.
> >
> >
> >
> > --
> >
> > 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-...@scipy.org
> >
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> >
> >
> >
> >
> > -Inline Attachment Follows-
> >
> >
> --
> > Enter the BlackBerry Developer Challenge
> > This is your chance to win up to $100,000 in prizes! For a
> > limited time,
> > vendors submitting new applications to BlackBerry App
> > World(TM) will have
> > the opportunity to enter the BlackBerry Developer
> > Challenge. See full prize
> > details at: http://p.sf.net/sfu/Challenge
> > -Inline Attachment Follows-
> >
> > ___
> > Matplotlib-devel mailing list
> > Matplotlib-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
>
>
>
>
--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9

[Ondrej Certik]

On Thu, Jul 16, 2009 at 4:42 PM, Robert Kern wrote:
> On Thu, Jul 16, 2009 at 17:26, Brian Granger wrote:
>> Hi,
>>
>> I am attaching a working ctypes based prototype of a module that allows wx
>> to be used interactively from *both* python and ipython.  It uses
>> PyOS_InputHook and has been tested on wx 2.8 and 2.9 (trunk) on Mac OS X
>> (python 2.5).
>>
>> It can be used with an existing wx install and all versions of ipython, but
>> ***don't use the -pylab or -wthread flag***.  At this point, I need help
>> testing the heck out of this (window and linux users esp).  I have run most
>> matplotlib pylab_examples and they work fine.  I also need people to try out
>> things like ETS/Mayavi.  The current plan is to replace the existing
>> threaded shells in IPython with this (much simpler) code.
>
> Works for me with wx 2.8.8.1 on OS X 10.5 and Chaco. Pan and zoom
> interactions are substantially chunky, though. I do not see such
> chunkiness with -wthread. It would be worth exploring a Cython
> alternative to see if it is just ctypes and general Python overhead to
> blame.

Works for me on Ubuntu 9.04 with default packages (wx 2.8.9.1), I
tried this example:

In [1]: import inputhook

In [2]: inputhook.set_inputhook_wx()

In [3]: app = wx.App(redirect=False, clearSigInt=False)
---
NameError Traceback (most recent call last)

/home/ondrej/Desktop/ in ()

NameError: name 'wx' is not defined

In [4]: import wx

In [5]: app = wx.App(redirect=False, clearSigInt=False)

In [6]: from matplotlib import pyplot as plt

In [7]: plt.interactive(True)

In [8]: plt.plot(range(10))
Out[8]: []


(maybe you want to add "import wx" into that example docstring)


Pan is perfectly smooth, zoom is a bit chunky, but not much, it's
definitely usable.

Ondrej

--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9

[Ondrej Certik]

On Thu, Jul 16, 2009 at 11:11 PM, Ondrej Certik wrote:
> On Thu, Jul 16, 2009 at 4:42 PM, Robert Kern wrote:
>> On Thu, Jul 16, 2009 at 17:26, Brian Granger wrote:
>>> Hi,
>>>
>>> I am attaching a working ctypes based prototype of a module that allows wx
>>> to be used interactively from *both* python and ipython.  It uses
>>> PyOS_InputHook and has been tested on wx 2.8 and 2.9 (trunk) on Mac OS X
>>> (python 2.5).
>>>
>>> It can be used with an existing wx install and all versions of ipython, but
>>> ***don't use the -pylab or -wthread flag***.  At this point, I need help
>>> testing the heck out of this (window and linux users esp).  I have run most
>>> matplotlib pylab_examples and they work fine.  I also need people to try out
>>> things like ETS/Mayavi.  The current plan is to replace the existing
>>> threaded shells in IPython with this (much simpler) code.
>>
>> Works for me with wx 2.8.8.1 on OS X 10.5 and Chaco. Pan and zoom
>> interactions are substantially chunky, though. I do not see such
>> chunkiness with -wthread. It would be worth exploring a Cython
>> alternative to see if it is just ctypes and general Python overhead to
>> blame.
>
> Works for me on Ubuntu 9.04 with default packages (wx 2.8.9.1), I
> tried this example:
>
> In [1]: import inputhook
>
> In [2]: inputhook.set_inputhook_wx()
>
> In [3]: app = wx.App(redirect=False, clearSigInt=False)
> ---
> NameError                                 Traceback (most recent call last)
>
> /home/ondrej/Desktop/ in ()
>
> NameError: name 'wx' is not defined
>
> In [4]: import wx
>
> In [5]: app = wx.App(redirect=False, clearSigInt=False)
>
> In [6]: from matplotlib import pyplot as plt
>
> In [7]: plt.interactive(True)
>
> In [8]: plt.plot(range(10))
> Out[8]: []
>
>
> (maybe you want to add "import wx" into that example docstring)
>
>
> Pan is perfectly smooth, zoom is a bit chunky, but not much, it's
> definitely usable.

I also tested mayavi, this demo:

http://code.enthought.com/projects/mayavi/docs/development/html/mayavi/mlab.html#a-demo

and I didn't notice any speed difference --- e.g. it's as slow as
regular mayavi with ipython -wthread. :)

Ondrej

--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9

[Gael Varoquaux]

On Thu, Jul 16, 2009 at 11:27:51PM -0600, Ondrej Certik wrote:
> and I didn't notice any speed difference --- e.g. it's as slow as
> regular mayavi with ipython -wthread. :)

Nice, nice!

Test the volume_slicer example, with latest release, please. That should
be a good test.

Gaël

--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9

[Michiel de Hoon]

Without monitoring stdin, you could do the following:

while True:
run the event loop for a specified duration (say, 0.1 seconds)
check for input on stdin; if there is any: break

But you can only do this if wx has such a time-out capability. If not, you can 
do the following:

while True:
handle all accumulated events
check for input on stdin; if there is any: break
sleep for 0.1 seconds

The sleep is important, otherwise the CPU is busy 100% of the time, which will 
drain your battery.

This loop is essentially what you are doing in your current code, except that 
you're using Python/readline for the repeated calls into the hook function. 
It's better to have this loop explicitly inside your hook function, because of 
the variation in PyOS_InputHook behavior between different versions of 
Python/readline.

--Michiel

--- On Fri, 7/17/09, Brian Granger  wrote:

> From: Brian Granger 
> Subject: Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes based  
> prototype of PyOS_InputHook for wx 2.8 and 2.9
> To: "Michiel de Hoon" 
> Cc: "Robert Kern" , enthought-...@enthought.com, 
> "matplotlib development list" , 
> "IPython Development list" 
> Date: Friday, July 17, 2009, 12:59 AM
> Michiel,
> 
> Thanks for the reply, this will help us to find a better
> approach.  According to one of the wx devs, Robin Dunn, wx
> currently does not have the ability to monitor stdin in its
> even loop without polling.  I guess there is a GSoC project
> to add this capability, but it is not there yet.  Any
> thoughts on how this could be done without monitoring
> stdin.  I will give the polling stdin approach a try
> though.
> 
> 
> Cheers,
> 
> Brian
> 
> 
> 
> 
> The chunkiness probably comes from the fact that
> inputhook_wx is called repeatedly. This is different from
> how PyOS_InputHook is being used in Tkinter, PyGTK, and the
> Mac OS X backend.
> 
> 
> 
> Schematically, this is how the Tkinter/PyGTK/MacOSX event
> loops work:
> 
> 
> 
> 1) PyOS_InputHook is called when Python is waiting for the
> user to type in the next Python command.
> 
> 
> 
> 2) The hook function sets up the event loop such that stdin
> is being monitored while the event loop is running.
> 
> 
> 
> 3) The hook function then starts the event loop.
> 
> 
> 
> 4) When input is available on stdin, the hook function
> exits the event loop, and returns.
> 
> 
> 
> This is how the proposed Wx event loop currently works:
> 
> 
> 
> 1) PyOS_InputHook is called when Python is waiting for the
> user to type in the next Python command.
> 
> 
> 
> 2) The hook function processes whatever events are
> available at the time.
> 
> 
> 
> 3) The hook function returns.
> 
> 
> 
> 4) If still no input is available on stdin, Python calls
> the hook function again via PyOS_InputHook after a timeout.
> 
> 
> 
> I believe the timeout is 0.1 seconds by default. However,
> Python may not call PyOS_InputHook repeatedly at all; this
> depends on which Python version is being used, and the
> version of the readline library. In some configurations
> (particularly on Windows), PyOS_InputHook is called only
> once, so wx will freeze between Python commands.
> 
> 
> 
> 
> I am not familiar with wx, but there hopefully there is
> some way to monitor stdin while the event loop is running?
> 
> 
> 
> --Michiel.
> 
> 
> 
> 
> 
> --- On Thu, 7/16/09, Brian Granger  wrote:
> 
> 
> 
> > From: Brian Granger 
> 
> > Subject: Re: [matplotlib-devel] [IPython-dev]
> [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for
> wx 2.8 and 2.9
> 
> > To: "Robert Kern" 
> 
> > Cc: enthought-...@enthought.com,
> "matplotlib development list" ,
> "IPython Development list" 
> 
> 
> > Date: Thursday, July 16, 2009, 6:57 PM
> 
> > Robert,
> 
> >
> 
> > Thanks for testing this so quickly.  Performance is
> one of
> 
> > the big issues that I am concerned about.  I will
> work on a
> 
> > Cython based version to see if that solves the
> problem.
> 
> >
> 
> > Cheers,
> 
> >
> 
> > Brian
> 
> >
> 
> >
> 
> >
> 
> >
> 
> > Works for me with wx 2.8.8.1 on OS X 10.5 and
> 
> > Chaco. Pan and zoom
> 
> >
> 
> > interactions are substantially chunky, though. I do
> not see
> 
> > such
> 
> >
> 
> > chunkiness with -wthread. It would be worth exploring
> a
> 
> > Cython
> 
> >
> 
> > alternative to see if it is just ctypes and general
> Python
> 
> > overhead to
> 
> >
> 
> > blame.
> 
> >
> 
> >
> 
> >
> 
> > --
> 
> >
> 
> > 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-...@scipy.org
> 
> >
> 
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> 
> >
> 
> >
> 
> >
> 
> >
> 
> > -Inline Attachment Follo