matplotlib-devel Mailing List for matplotlib (Page 16)

Hi,
 I narrowed down the problem I've posted on the matplotlib user list
and now it looks like I found a matplotlib bug in 0.98 version.
The shared axes auto-scaling is not properly working in 0.98 (works
with the 0.91). Indeed, As shown, in the small attached script, the
shared x scale does not show the full curves (axs1 blue curve should go 
up to 120 on axis).
In fact, if x axes is shared, the figure xmin and xmax are defined by 
the last plotted axes (axs2) and does not take into account the min/max 
from the first one which cut it. One would expect to see both curve 
entirely.
Could someone have look at this problem. I will try to dive in 
matplotlib code but I'm not an expert at all...
Thanks in advance,
David

Hi guys,
in Debian we finally find a nice way to let the documentation be
compiled at package build-time so we are ready for a "real" new
release of matplotlib (more that the source-only you kindly provided
me last week), so when you're ready.... :)
For sure, I won't upload a new one in the next 2/3 days or so, because
I want to let 0.98.1 transit from unstable to testing (the Debian
staging area used to release lenny), so from the weekend on I'd be
glad to upgrade matplotlib and bother the release team to include it
in the next release :)
Thank a lot for the great support you gave/giving me,
Sandro
-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Tue, Jul 1, 2008 at 1:34 PM, Nicolas Rougier
<Nic...@lo...> wrote:
>
> I'm not yet on the ipython-dev but I read the archive to check progress
> on ipython1 and I get a bit lost with the redesign. The backend/frontend
> will definitely help to embed ipython. Where can I get the latest
> version (with wx for example) so I can try to code the GTK one ?
All development for ipython now happens on launchpad, so you can just
bzr branch lp:iptyhon
as indicated here:
http://ipython.scipy.org/moin/Developer_Zone
The various GUI frontends are just being built, so there isn't a
single component to download yet. But feel free to jump on the list
with questions (and show your code!) I'm sure there will be plenty of
interest.
>
> Concerning the colors options, I'm not sure where to put it, in the argv
> argument ?
You can do that, but here's a cleaner solution that uses the actual ipython api:
tlon[pycons]> diff -u ishell.py.ori ishell.py
--- ishell.py.ori 2008年07月01日 15:25:01.000000000 -0700
+++ ishell.py 2008年07月01日 15:33:46.000000000 -0700
@@ -19,6 +19,7 @@
 from StringIO import StringIO
 try:
 import IPython
+ from IPython import ipapi
 except Exception,e:
 raise "Error importing IPython (%s)" % str(e)
@@ -52,6 +53,11 @@
 self.IP.system = lambda cmd: self.shell(self.IP.var_expand(cmd),
 header='IPython system call: ',
verbose=self.IP.rc.system_verbose)
+
+ # Get a hold of the public IPython API object and use it
+ self.ip = ipapi.get()
+ self.ip.magic('colors LightBG')
+
 sys.excepthook = excepthook
 self.iter_more = 0
 self.complete_sep = re.compile('[\s\{\}\[\]\(\)]')
##### END PATCH
Cheers,
f

I'm not yet on the ipython-dev but I read the archive to check progress
on ipython1 and I get a bit lost with the redesign. The backend/frontend
will definitely help to embed ipython. Where can I get the latest
version (with wx for example) so I can try to code the GTK one ?
Concerning the colors options, I'm not sure where to put it, in the argv
argument ?
Cheers.
Nicolas 
On Tue, 2008年07月01日 at 12:22 -0700, Fernando Perez wrote:
> On Tue, Jul 1, 2008 at 6:01 AM, Nicolas Rougier
> <Nic...@lo...> wrote:
> >
> >
> > Thanks,
> >
> > I changed the license to a BSD one, hope this is compatible with
> > matplotlib. I also changed the module name from 'gtk_console' to pycons
> > since it makes more sense.
> 
> Beautiful work, and many thanks for the license change too, since it's
> now comatible with ipython as well.
> 
> BTW, are you on the ipython-dev list? If not, I'd like to encourage
> you to join in. Right now we're in the middle of refactoring the
> ipython code and we have people working on WX, Qt and Cocoa consoles,
> with a proper architecture (backend/frontend separation). I think it
> would be great if your GTK one also made it into the same codebase, so
> that your console could 'ride' on top of the common layer that all
> others will share.
> 
> Minor note: you may want to initialize the ipython session with
> --colors LightBG since you have a light background, so we get better
> readability.
> 
> Cheers,
> 
> f

The "help()" freeze is not really a freeze since you can type input
within the terminal from where you started pycons. I managed to find
that the IPython import was responsible for this behavior for some
unknown reason. If you remove all reference to IPython in the pycons
file, then you got the expected behavior. Since IPython is under
heavy redesign, I won't investigate further until the next version.
What is the problem when closing with a graph inside ?
Nicolas
On Tue, 2008年07月01日 at 15:37 +0200, David Trem wrote:
> Sorry for the trouble, I started testing your "old" pylab wich was 
> provided without the setup script, which led me testing pycons from the 
> pycons folder itself (no setup.py install done).
> Pycons was actually working fine.
> However, I encounter problem when closing the console with a graph 
> inside and with the >>>help() command which is freezing the windows... 
> But this is basically usable.
> 
> Thanks you very much considering my license request!
> I don't think there could be license issue with matplotlib since it is 
> also using a quite permissive license. Could the matplotlib gurus 
> comment on that?
> 
> Thanks,
> 
> David
> 
> Nicolas Rougier a écrit :
> > 
> > Thanks,
> > 
> > I changed the license to a BSD one, hope this is compatible with
> > matplotlib. I also changed the module name from 'gtk_console' to pycons
> > since it makes more sense.
> > 
> > I also tried to remove the gtk_console.console (now this is
> > pycons.console) in favor of console but it does not work as expected I
> > would say. In fact, I'm surprised it's working for you. What do you get
> > from a simple "import pycons" ?
> > 
> > Nicolas
> > 
> > 
> > On Tue, 2008年07月01日 at 14:32 +0200, David Trem wrote:
> >> Hi Nicolas,
> >>
> >> Your pycons is great!
> >> I has to correct a small issue in the tar.gz from your website before 
> >> being able to test pycons:
> >> I had to change:
> >> "import gtk_console.console as cons"
> >> to "import console as cons"
> >> in pycons file around line 12.
> >>
> >> After that I can report pycons is running on my MacBook (MacOS 10.5) 
> >> with python, pygtk... from macports.
> >>
> >> Another point:
> >> do you mind releasing your code in a more permissive license that GPL. I 
> >> mean LGPL or BSD like? I'm interested in including your code in my own 
> >> LGPL app.
> >>
> >> Thanks for this great peace of work.
> >>
> >> All the best,
> >>
> >> David
> >>
> >> Nicolas Rougier a écrit :
> >>> Hi,
> >>>
> >>> I've added some basic support for readline shortcuts:
> >>>
> >>> Ctrl-A: start of line
> >>> Ctrl-E: end of line
> >>> Ctrl-K: kill from cursor to end of line
> >>> Ctrl-Y: yank kill buffer
> >>> Ctrl-L: clear console
> >>>
> >>> I've also added an option for displaying the toolbar(2).
> >>>
> >>> Usage is now:
> >>>
> >>> pycons [--ipython] [--pylab] [--toolbar]
> >>>
> >>>
> >>> If the toolbar is not specified, commands can be typed directly within
> >>> console: zoom(), pan(), home(), back(), forward(), save()
> >>>
> >>> There is now a installable package (pycons.tgz) available from:
> >>>
> >>> http://www.loria.fr/~rougier/pycons.html
> >>>
> >>>
> >>>
> >>> Nicolas
> >>>
> >>>
> >>>
> >>> On Mon, 2008年06月30日 at 21:21 -0500, John Hunter wrote:
> >>>> On Sun, Jun 29, 2008 at 9:28 AM, Nicolas Rougier
> >>>> <Nic...@lo...> wrote:
> >>>>> Thanks John, I've update the new version with your code.
> >>>>>
> >>>>> It is now available at:
> >>>>> http://www.loria.fr/~rougier/pylab.html
> >>>>>
> >>>>> You can now choose between python and ipython (option -s python
> >>>>> or -s ipython) and all user events on a figure should be handled
> >>>>> properly (mouse, scroll and key).
> >>>>>
> >>>>> Concerning the toolbar, is is quite easy to add but it is not
> >>>>> very pleasant to the eyes. I'm looking for a more asethetic solution.
> >>>> I've only had a limited chance to test this but it looks very
> >>>> exciting. I am amazed by how quickly you go the ipython shell
> >>>> incorporated. I am still a bit vexed by the lack of support for emacs
> >>>> key bindings (I guess having ipython and readline support are not
> >>>> enough, but I bet there is some gtk console code out there to support
> >>>> them). I do miss my CTRL-a and CTRL-k and friends.
> >>>>
> >>>> As for the toolbar, I think functionality over aesthetics carries the
> >>>> day because it is easy to make it pretty after you make it work (and
> >>>> you can always make it optional with a flag), but note that you do not
> >>>> need to use the standard gtk toolbar widget -- you can write your own
> >>>> that works however you want. There is only minimal overhead for the
> >>>> toolbar writer that is fairly well documented in backend_bases.py.
> >>>> One option is to draw no toolbar at all but just just set up key
> >>>> bindings (press 'z' to toggle zoom mode, 'r' to toggle draw to rect
> >>>> mode, etc, or draw your own toolbar or whatever. But having the
> >>>> functionality is a killer feature, in my opinion.
> >>>>
> >>>> Keep us posted.
> >>>>
> >>>> JDH
> >>>
> >>> -------------------------------------------------------------------------
> >>> Check out the new SourceForge.net Marketplace.
> >>> It's the best place to buy or sell services for
> >>> just about anything Open Source.
> >>> http://sourceforge.net/services/buy/index.php
> >>> _______________________________________________
> >>> Matplotlib-devel mailing list
> >>> Mat...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> > 

Thanks, corrected.
I just forgot the pylab import, it has been corrected as well.
Nicolas
On Tue, 2008年07月01日 at 08:38 -0500, John Hunter wrote:
> On Tue, Jul 1, 2008 at 5:31 AM, Nicolas Rougier
> <Nic...@lo...> wrote:
> 
> > There is now a installable package (pycons.tgz) available from:
> >
> > http://www.loria.fr/~rougier/pycons.html
> 
> Cool, this is working for me now. Very nice. Two more comments:
> 
> You must override draw_if_interactive *before* importing pylab:
> 
> import matplotlib.backends.backend_gtkagg as backend_gtkagg
> 
> def draw_if_interactive():
> """ Is called after every pylab drawing command """
> show(console)
> # do this before importing pylab
> backend_gtkagg.draw_if_interactive = draw_if_interactive
> import pylab
> import matplotlib.pylab
> from matplotlib._pylab_helpers import Gcf
> 
> 
> and when I run in --pylab mode, the pylab namespace is not imported.
> I have to manually 'from pylab import *' . Is that intentional?

I picked "axes_class" because this is what is used in
"subplot_class_factory" function.
I rather prefer "axes_class" because, IMO, subclassing of Axes is not
only for a new projection.
For example, I have a simple subclass of Axes where I have
"baseline"-aligned x-ticklabels (instead of "top" align). Also, from
available options
 from matplotlib.projection import AitoffAxes
 1) f.add_subplot(1,2,1, projection=AitoffAxes)
 2) f.add_subplot(1,2,1, projection_class=AitoffAxes)
 3) f.add_subplot(1,2,1, axes_class=AitoffAxes)
I think option 3 makes a slightly more sense.
My patch (which is attached) if for option 3 and simply adds
"axes_class" keyword. It raises an Exception if "projection" is
supplied or polar=True. But feel free to modify or give me
suggestions. If others prefer option 1 or 2, I'll make a subsequent
change for it.
Regards,
-JJ
On Tue, Jul 1, 2008 at 7:51 AM, Michael Droettboom <md...@st...> wrote:
> Sounds ok to me. One thing to clarify though -- what to do if both
> "projection" and "axes_class" are provided? Throw an exception?
>
> I have a small problem with the name "axes_class" because it is very
> non-obvious that it corresponds to "projection". Perhaps we should either
> 1) overload projection to take a class as well as strings, or 2) use
> "projection_class" instead of "axes_class". I think I prefer 1) though I'm
> wary of overloading in Python in general.
>
> Cheers,
> Mike
>
> John Hunter wrote:
>>
>> On Mon, Jun 30, 2008 at 2:31 PM, Jae-Joon Lee <lee...@gm...>
>> wrote:
>>
>>
>>>
>>> It seems rather straight forward to implement "axes_class" keyword in
>>> add_subplot() and I may make a patch for it.
>>> So, how does others think?
>>>
>>
>> Seems totally reasonable an we'd be happy to accept a patch.
>>
>> Thanks,
>> JDH
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> 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
>
>

On Tue, Jul 1, 2008 at 6:01 AM, Nicolas Rougier
<Nic...@lo...> wrote:
>
>
> Thanks,
>
> I changed the license to a BSD one, hope this is compatible with
> matplotlib. I also changed the module name from 'gtk_console' to pycons
> since it makes more sense.
Beautiful work, and many thanks for the license change too, since it's
now comatible with ipython as well.
BTW, are you on the ipython-dev list? If not, I'd like to encourage
you to join in. Right now we're in the middle of refactoring the
ipython code and we have people working on WX, Qt and Cocoa consoles,
with a proper architecture (backend/frontend separation). I think it
would be great if your GTK one also made it into the same codebase, so
that your console could 'ride' on top of the common layer that all
others will share.
Minor note: you may want to initialize the ipython session with
--colors LightBG since you have a light background, so we get better
readability.
Cheers,
f

On Tue, Jul 1, 2008 at 8:37 AM, David Trem <dav...@gm...> wrote:
> Thanks you very much considering my license request!
> I don't think there could be license issue with matplotlib since it is
> also using a quite permissive license. Could the matplotlib gurus
> comment on that?
Yes, the BSD license is compatible with mpl, the GPL one was not.
Thanks for changing it Nicolas.
JDH

On Tue, Jul 1, 2008 at 5:31 AM, Nicolas Rougier
<Nic...@lo...> wrote:
> There is now a installable package (pycons.tgz) available from:
>
> http://www.loria.fr/~rougier/pycons.html
Cool, this is working for me now. Very nice. Two more comments:
You must override draw_if_interactive *before* importing pylab:
 import matplotlib.backends.backend_gtkagg as backend_gtkagg
 def draw_if_interactive():
 """ Is called after every pylab drawing command """
 show(console)
 # do this before importing pylab
 backend_gtkagg.draw_if_interactive = draw_if_interactive
 import pylab
 import matplotlib.pylab
 from matplotlib._pylab_helpers import Gcf
and when I run in --pylab mode, the pylab namespace is not imported.
I have to manually 'from pylab import *' . Is that intentional?

Sorry for the trouble, I started testing your "old" pylab wich was 
provided without the setup script, which led me testing pycons from the 
pycons folder itself (no setup.py install done).
Pycons was actually working fine.
However, I encounter problem when closing the console with a graph 
inside and with the >>>help() command which is freezing the windows... 
But this is basically usable.
Thanks you very much considering my license request!
I don't think there could be license issue with matplotlib since it is 
also using a quite permissive license. Could the matplotlib gurus 
comment on that?
Thanks,
David
Nicolas Rougier a écrit :
> 
> Thanks,
> 
> I changed the license to a BSD one, hope this is compatible with
> matplotlib. I also changed the module name from 'gtk_console' to pycons
> since it makes more sense.
> 
> I also tried to remove the gtk_console.console (now this is
> pycons.console) in favor of console but it does not work as expected I
> would say. In fact, I'm surprised it's working for you. What do you get
> from a simple "import pycons" ?
> 
> Nicolas
> 
> 
> On Tue, 2008年07月01日 at 14:32 +0200, David Trem wrote:
>> Hi Nicolas,
>>
>> Your pycons is great!
>> I has to correct a small issue in the tar.gz from your website before 
>> being able to test pycons:
>> I had to change:
>> "import gtk_console.console as cons"
>> to "import console as cons"
>> in pycons file around line 12.
>>
>> After that I can report pycons is running on my MacBook (MacOS 10.5) 
>> with python, pygtk... from macports.
>>
>> Another point:
>> do you mind releasing your code in a more permissive license that GPL. I 
>> mean LGPL or BSD like? I'm interested in including your code in my own 
>> LGPL app.
>>
>> Thanks for this great peace of work.
>>
>> All the best,
>>
>> David
>>
>> Nicolas Rougier a écrit :
>>> Hi,
>>>
>>> I've added some basic support for readline shortcuts:
>>>
>>> Ctrl-A: start of line
>>> Ctrl-E: end of line
>>> Ctrl-K: kill from cursor to end of line
>>> Ctrl-Y: yank kill buffer
>>> Ctrl-L: clear console
>>>
>>> I've also added an option for displaying the toolbar(2).
>>>
>>> Usage is now:
>>>
>>> pycons [--ipython] [--pylab] [--toolbar]
>>>
>>>
>>> If the toolbar is not specified, commands can be typed directly within
>>> console: zoom(), pan(), home(), back(), forward(), save()
>>>
>>> There is now a installable package (pycons.tgz) available from:
>>>
>>> http://www.loria.fr/~rougier/pycons.html
>>>
>>>
>>>
>>> Nicolas
>>>
>>>
>>>
>>> On Mon, 2008年06月30日 at 21:21 -0500, John Hunter wrote:
>>>> On Sun, Jun 29, 2008 at 9:28 AM, Nicolas Rougier
>>>> <Nic...@lo...> wrote:
>>>>> Thanks John, I've update the new version with your code.
>>>>>
>>>>> It is now available at:
>>>>> http://www.loria.fr/~rougier/pylab.html
>>>>>
>>>>> You can now choose between python and ipython (option -s python
>>>>> or -s ipython) and all user events on a figure should be handled
>>>>> properly (mouse, scroll and key).
>>>>>
>>>>> Concerning the toolbar, is is quite easy to add but it is not
>>>>> very pleasant to the eyes. I'm looking for a more asethetic solution.
>>>> I've only had a limited chance to test this but it looks very
>>>> exciting. I am amazed by how quickly you go the ipython shell
>>>> incorporated. I am still a bit vexed by the lack of support for emacs
>>>> key bindings (I guess having ipython and readline support are not
>>>> enough, but I bet there is some gtk console code out there to support
>>>> them). I do miss my CTRL-a and CTRL-k and friends.
>>>>
>>>> As for the toolbar, I think functionality over aesthetics carries the
>>>> day because it is easy to make it pretty after you make it work (and
>>>> you can always make it optional with a flag), but note that you do not
>>>> need to use the standard gtk toolbar widget -- you can write your own
>>>> that works however you want. There is only minimal overhead for the
>>>> toolbar writer that is fairly well documented in backend_bases.py.
>>>> One option is to draw no toolbar at all but just just set up key
>>>> bindings (press 'z' to toggle zoom mode, 'r' to toggle draw to rect
>>>> mode, etc, or draw your own toolbar or whatever. But having the
>>>> functionality is a killer feature, in my opinion.
>>>>
>>>> Keep us posted.
>>>>
>>>> JDH
>>>
>>> -------------------------------------------------------------------------
>>> Check out the new SourceForge.net Marketplace.
>>> It's the best place to buy or sell services for
>>> just about anything Open Source.
>>> http://sourceforge.net/services/buy/index.php
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

On Tuesday 01 July 2008 08:44:32 am Sandro Tosi wrote:
> On Tue, Jul 1, 2008 at 14:42, Darren Dale <dsd...@gm...> wrote:
> > On Tuesday 01 July 2008 08:21:10 am Sandro Tosi wrote:
> >> Hi Chris,
> >>
> >> > I'm using the svn version of the docs on a debian system with
> >> > matplotlib 0.98.1 and sphinx 0.4.
> >>
> >> here the same with 0.91.2
> >
> > You need to install 0.98.svn to work with the sphinx-based docs.
>
> Sorry, mistype: I'm using 0.98.2 (the source only release created fro
> Debian).
Looks like John fixed it, latex was successful here.
Darren

Thanks,
I changed the license to a BSD one, hope this is compatible with
matplotlib. I also changed the module name from 'gtk_console' to pycons
since it makes more sense.
I also tried to remove the gtk_console.console (now this is
pycons.console) in favor of console but it does not work as expected I
would say. In fact, I'm surprised it's working for you. What do you get
from a simple "import pycons" ?
Nicolas
On Tue, 2008年07月01日 at 14:32 +0200, David Trem wrote:
> Hi Nicolas,
> 
> Your pycons is great!
> I has to correct a small issue in the tar.gz from your website before 
> being able to test pycons:
> I had to change:
> "import gtk_console.console as cons"
> to "import console as cons"
> in pycons file around line 12.
> 
> After that I can report pycons is running on my MacBook (MacOS 10.5) 
> with python, pygtk... from macports.
> 
> Another point:
> do you mind releasing your code in a more permissive license that GPL. I 
> mean LGPL or BSD like? I'm interested in including your code in my own 
> LGPL app.
> 
> Thanks for this great peace of work.
> 
> All the best,
> 
> David
> 
> Nicolas Rougier a écrit :
> > 
> > Hi,
> > 
> > I've added some basic support for readline shortcuts:
> > 
> > Ctrl-A: start of line
> > Ctrl-E: end of line
> > Ctrl-K: kill from cursor to end of line
> > Ctrl-Y: yank kill buffer
> > Ctrl-L: clear console
> > 
> > I've also added an option for displaying the toolbar(2).
> > 
> > Usage is now:
> > 
> > pycons [--ipython] [--pylab] [--toolbar]
> > 
> > 
> > If the toolbar is not specified, commands can be typed directly within
> > console: zoom(), pan(), home(), back(), forward(), save()
> > 
> > There is now a installable package (pycons.tgz) available from:
> > 
> > http://www.loria.fr/~rougier/pycons.html
> > 
> > 
> > 
> > Nicolas
> > 
> > 
> > 
> > On Mon, 2008年06月30日 at 21:21 -0500, John Hunter wrote:
> >> On Sun, Jun 29, 2008 at 9:28 AM, Nicolas Rougier
> >> <Nic...@lo...> wrote:
> >>>
> >>> Thanks John, I've update the new version with your code.
> >>>
> >>> It is now available at:
> >>> http://www.loria.fr/~rougier/pylab.html
> >>>
> >>> You can now choose between python and ipython (option -s python
> >>> or -s ipython) and all user events on a figure should be handled
> >>> properly (mouse, scroll and key).
> >>>
> >>> Concerning the toolbar, is is quite easy to add but it is not
> >>> very pleasant to the eyes. I'm looking for a more asethetic solution.
> >> I've only had a limited chance to test this but it looks very
> >> exciting. I am amazed by how quickly you go the ipython shell
> >> incorporated. I am still a bit vexed by the lack of support for emacs
> >> key bindings (I guess having ipython and readline support are not
> >> enough, but I bet there is some gtk console code out there to support
> >> them). I do miss my CTRL-a and CTRL-k and friends.
> >>
> >> As for the toolbar, I think functionality over aesthetics carries the
> >> day because it is easy to make it pretty after you make it work (and
> >> you can always make it optional with a flag), but note that you do not
> >> need to use the standard gtk toolbar widget -- you can write your own
> >> that works however you want. There is only minimal overhead for the
> >> toolbar writer that is fairly well documented in backend_bases.py.
> >> One option is to draw no toolbar at all but just just set up key
> >> bindings (press 'z' to toggle zoom mode, 'r' to toggle draw to rect
> >> mode, etc, or draw your own toolbar or whatever. But having the
> >> functionality is a killer feature, in my opinion.
> >>
> >> Keep us posted.
> >>
> >> JDH
> > 
> > 
> > -------------------------------------------------------------------------
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for
> > just about anything Open Source.
> > http://sourceforge.net/services/buy/index.php
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Tue, Jul 1, 2008 at 14:42, Darren Dale <dsd...@gm...> wrote:
> On Tuesday 01 July 2008 08:21:10 am Sandro Tosi wrote:
>> Hi Chris,
>>
>> > I'm using the svn version of the docs on a debian system with
>> > matplotlib 0.98.1 and sphinx 0.4.
>>
>> here the same with 0.91.2
>
> You need to install 0.98.svn to work with the sphinx-based docs.
Sorry, mistype: I'm using 0.98.2 (the source only release created fro Debian).
-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Tuesday 01 July 2008 08:21:10 am Sandro Tosi wrote:
> Hi Chris,
>
> > I'm using the svn version of the docs on a debian system with
> > matplotlib 0.98.1 and sphinx 0.4.
>
> here the same with 0.91.2
You need to install 0.98.svn to work with the sphinx-based docs.
Darren

Hi Nicolas,
 Your pycons is great!
I has to correct a small issue in the tar.gz from your website before 
being able to test pycons:
 I had to change:
"import gtk_console.console as cons"
to "import console as cons"
in pycons file around line 12.
After that I can report pycons is running on my MacBook (MacOS 10.5) 
with python, pygtk... from macports.
Another point:
do you mind releasing your code in a more permissive license that GPL. I 
mean LGPL or BSD like? I'm interested in including your code in my own 
LGPL app.
Thanks for this great peace of work.
All the best,
David
Nicolas Rougier a écrit :
> 
> Hi,
> 
> I've added some basic support for readline shortcuts:
> 
> Ctrl-A: start of line
> Ctrl-E: end of line
> Ctrl-K: kill from cursor to end of line
> Ctrl-Y: yank kill buffer
> Ctrl-L: clear console
> 
> I've also added an option for displaying the toolbar(2).
> 
> Usage is now:
> 
> pycons [--ipython] [--pylab] [--toolbar]
> 
> 
> If the toolbar is not specified, commands can be typed directly within
> console: zoom(), pan(), home(), back(), forward(), save()
> 
> There is now a installable package (pycons.tgz) available from:
> 
> http://www.loria.fr/~rougier/pycons.html
> 
> 
> 
> Nicolas
> 
> 
> 
> On Mon, 2008年06月30日 at 21:21 -0500, John Hunter wrote:
>> On Sun, Jun 29, 2008 at 9:28 AM, Nicolas Rougier
>> <Nic...@lo...> wrote:
>>>
>>> Thanks John, I've update the new version with your code.
>>>
>>> It is now available at:
>>> http://www.loria.fr/~rougier/pylab.html
>>>
>>> You can now choose between python and ipython (option -s python
>>> or -s ipython) and all user events on a figure should be handled
>>> properly (mouse, scroll and key).
>>>
>>> Concerning the toolbar, is is quite easy to add but it is not
>>> very pleasant to the eyes. I'm looking for a more asethetic solution.
>> I've only had a limited chance to test this but it looks very
>> exciting. I am amazed by how quickly you go the ipython shell
>> incorporated. I am still a bit vexed by the lack of support for emacs
>> key bindings (I guess having ipython and readline support are not
>> enough, but I bet there is some gtk console code out there to support
>> them). I do miss my CTRL-a and CTRL-k and friends.
>>
>> As for the toolbar, I think functionality over aesthetics carries the
>> day because it is easy to make it pretty after you make it work (and
>> you can always make it optional with a flag), but note that you do not
>> need to use the standard gtk toolbar widget -- you can write your own
>> that works however you want. There is only minimal overhead for the
>> toolbar writer that is fairly well documented in backend_bases.py.
>> One option is to draw no toolbar at all but just just set up key
>> bindings (press 'z' to toggle zoom mode, 'r' to toggle draw to rect
>> mode, etc, or draw your own toolbar or whatever. But having the
>> functionality is a killer feature, in my opinion.
>>
>> Keep us posted.
>>
>> JDH
> 
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi Chris,
> I'm using the svn version of the docs on a debian system with
> matplotlib 0.98.1 and sphinx 0.4.
here the same with 0.91.2
> Latex hangs ( but can be made to continue by pressing return) at the
> following point:
>
> Underfull \hbox (badness 10000) in paragraph at lines 17819--17822
> []\T1/txr/m/n/10.95 A dic-tio-nary with key-word ar-gu-ments ac-cepted by the
> [181] [182]
> Underfull \hbox (badness 10000) in paragraph at lines 18251--18254
> [][][]\T1/txtt/m/n/10.95 semilogx()[][] \T1/txr/m/n/10.95 sup-ports all the key
> -word ar-gu-ments of [][]\T1/txtt/m/n/10.95 plot()[][] \T1/txr/m/n/10.95 and
> [183]
> Overfull \hbox (92.42264pt too wide) in paragraph at lines 18443--18444
> [][]
>
> Underfull \hbox (badness 10000) in paragraph at lines 18458--18461
> [][][]\T1/txtt/m/n/10.95 semilogy()[][] \T1/txr/m/n/10.95 sup-ports all the key
> -word ar-gu-ments of \T1/txtt/m/n/10.95 plot() \T1/txr/m/n/10.95 and
> [184]
> Overfull \hbox (92.42264pt too wide) in paragraph at lines 18650--18651
> [][]
> [185]
> Overfull \hbox (92.41579pt too wide) in paragraph at lines 18760--18761
> [][]
> [186]
> Overfull \hbox (92.45047pt too wide) in paragraph at lines 19150--19151
> [][]
> [187]
> Overfull \hbox (92.45047pt too wide) in paragraph at lines 19351--19352
> [][]
> [188] [189]
>
> ! LaTeX Error: Too deeply nested.
>
> See the LaTeX manual or LaTeX Companion for explanation.
> Type H <return> for immediate help.
> ...
>
> l.19440 \begin{Verbatim}[commandchars=@\[\]]
>
> ?
I got this fixed with:
MATPLOTLIBDATA=../lib/matplotlib/mpl-data/
PYTHONPATH=../build/lib.linux-x86_64-2.5/ ./make.py
(discard the PYTHONPATH) in the matplotlib debian trunk.
Cheers,
Sandro
-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Sounds ok to me. One thing to clarify though -- what to do if both 
"projection" and "axes_class" are provided? Throw an exception?
I have a small problem with the name "axes_class" because it is very 
non-obvious that it corresponds to "projection". Perhaps we should 
either 1) overload projection to take a class as well as strings, or 2) 
use "projection_class" instead of "axes_class". I think I prefer 1) 
though I'm wary of overloading in Python in general.
Cheers,
Mike
John Hunter wrote:
> On Mon, Jun 30, 2008 at 2:31 PM, Jae-Joon Lee <lee...@gm...> wrote:
>
> 
>> It seems rather straight forward to implement "axes_class" keyword in
>> add_subplot() and I may make a patch for it.
>> So, how does others think?
>> 
>
> Seems totally reasonable an we'd be happy to accept a patch.
>
> Thanks,
> JDH
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> 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

Hi,
I've added some basic support for readline shortcuts:
 Ctrl-A: start of line
 Ctrl-E: end of line
 Ctrl-K: kill from cursor to end of line
 Ctrl-Y: yank kill buffer
 Ctrl-L: clear console
I've also added an option for displaying the toolbar(2).
Usage is now:
pycons [--ipython] [--pylab] [--toolbar]
If the toolbar is not specified, commands can be typed directly within
console: zoom(), pan(), home(), back(), forward(), save()
There is now a installable package (pycons.tgz) available from:
http://www.loria.fr/~rougier/pycons.html
Nicolas
On Mon, 2008年06月30日 at 21:21 -0500, John Hunter wrote:
> On Sun, Jun 29, 2008 at 9:28 AM, Nicolas Rougier
> <Nic...@lo...> wrote:
> >
> >
> > Thanks John, I've update the new version with your code.
> >
> > It is now available at:
> > http://www.loria.fr/~rougier/pylab.html
> >
> > You can now choose between python and ipython (option -s python
> > or -s ipython) and all user events on a figure should be handled
> > properly (mouse, scroll and key).
> >
> > Concerning the toolbar, is is quite easy to add but it is not
> > very pleasant to the eyes. I'm looking for a more asethetic solution.
> 
> I've only had a limited chance to test this but it looks very
> exciting. I am amazed by how quickly you go the ipython shell
> incorporated. I am still a bit vexed by the lack of support for emacs
> key bindings (I guess having ipython and readline support are not
> enough, but I bet there is some gtk console code out there to support
> them). I do miss my CTRL-a and CTRL-k and friends.
> 
> As for the toolbar, I think functionality over aesthetics carries the
> day because it is easy to make it pretty after you make it work (and
> you can always make it optional with a flag), but note that you do not
> need to use the standard gtk toolbar widget -- you can write your own
> that works however you want. There is only minimal overhead for the
> toolbar writer that is fairly well documented in backend_bases.py.
> One option is to draw no toolbar at all but just just set up key
> bindings (press 'z' to toggle zoom mode, 'r' to toggle draw to rect
> mode, etc, or draw your own toolbar or whatever. But having the
> functionality is a killer feature, in my opinion.
> 
> Keep us posted.
> 
> JDH

On Mon, Jun 30, 2008 at 8:40 PM, Chris Walker
<ch...@ch...> wrote:
> When building the docs using make.py in the doc directory, Latex hangs.
>
>
> I'm using the svn version of the docs on a debian system with
> matplotlib 0.98.1 and sphinx 0.4.
>
> Latex hangs ( but can be made to continue by pressing return) at the
> following point:
I'm pretty sure this is fixed in svn -- I made some docstring edits to
fix this bug a while back. I've tried to emphasize that the docs are
a very fast moving target, slated for release end of summer, so should
be considered bleeding-edge only. In other words, if you expect them
to build, you should be ready to use mpl svn and/or svn from any of
the packages they depend on (sphinx, pygments, ....)
JDH

On Sun, Jun 29, 2008 at 9:28 AM, Nicolas Rougier
<Nic...@lo...> wrote:
>
>
> Thanks John, I've update the new version with your code.
>
> It is now available at:
> http://www.loria.fr/~rougier/pylab.html
>
> You can now choose between python and ipython (option -s python
> or -s ipython) and all user events on a figure should be handled
> properly (mouse, scroll and key).
>
> Concerning the toolbar, is is quite easy to add but it is not
> very pleasant to the eyes. I'm looking for a more asethetic solution.
I've only had a limited chance to test this but it looks very
exciting. I am amazed by how quickly you go the ipython shell
incorporated. I am still a bit vexed by the lack of support for emacs
key bindings (I guess having ipython and readline support are not
enough, but I bet there is some gtk console code out there to support
them). I do miss my CTRL-a and CTRL-k and friends.
As for the toolbar, I think functionality over aesthetics carries the
day because it is easy to make it pretty after you make it work (and
you can always make it optional with a flag), but note that you do not
need to use the standard gtk toolbar widget -- you can write your own
that works however you want. There is only minimal overhead for the
toolbar writer that is fairly well documented in backend_bases.py.
One option is to draw no toolbar at all but just just set up key
bindings (press 'z' to toggle zoom mode, 'r' to toggle draw to rect
mode, etc, or draw your own toolbar or whatever. But having the
functionality is a killer feature, in my opinion.
Keep us posted.
JDH

On Mon, Jun 30, 2008 at 2:31 PM, Jae-Joon Lee <lee...@gm...> wrote:
> It seems rather straight forward to implement "axes_class" keyword in
> add_subplot() and I may make a patch for it.
> So, how does others think?
Seems totally reasonable an we'd be happy to accept a patch.
Thanks,
JDH

On Mon, Jun 30, 2008 at 6:34 PM, Darren Dale <dsd...@gm...> wrote:
> I *think* I found a simple fix: use the Text._x and ._y directly in draw,
> rather than get_position which refers to the text position in Text and the
> Dash position in TextWith Dash (thank you for pointing this out, John). Please
> let me know if something is still amiss, svn 5701.
That seems like an easy enough fix, and my simple tests are working
fine, but it speaks well of you that you found it, because the dash
with text innards are sufficiently confusing that it left Michael,
Manuel and I scratching our heads. All the better because my email to
Daishi bounced. Thanks, Darren.
JDH

When building the docs using make.py in the doc directory, Latex hangs. 
I'm using the svn version of the docs on a debian system with
matplotlib 0.98.1 and sphinx 0.4.
Latex hangs ( but can be made to continue by pressing return) at the
following point:
Underfull \hbox (badness 10000) in paragraph at lines 17819--17822
[]\T1/txr/m/n/10.95 A dic-tio-nary with key-word ar-gu-ments ac-cepted by the
[181] [182]
Underfull \hbox (badness 10000) in paragraph at lines 18251--18254
[][][]\T1/txtt/m/n/10.95 semilogx()[][] \T1/txr/m/n/10.95 sup-ports all the key
-word ar-gu-ments of [][]\T1/txtt/m/n/10.95 plot()[][] \T1/txr/m/n/10.95 and
[183]
Overfull \hbox (92.42264pt too wide) in paragraph at lines 18443--18444
[][] 
Underfull \hbox (badness 10000) in paragraph at lines 18458--18461
[][][]\T1/txtt/m/n/10.95 semilogy()[][] \T1/txr/m/n/10.95 sup-ports all the key
-word ar-gu-ments of \T1/txtt/m/n/10.95 plot() \T1/txr/m/n/10.95 and
[184]
Overfull \hbox (92.42264pt too wide) in paragraph at lines 18650--18651
[][] 
[185]
Overfull \hbox (92.41579pt too wide) in paragraph at lines 18760--18761
[][] 
[186]
Overfull \hbox (92.45047pt too wide) in paragraph at lines 19150--19151
[][] 
[187]
Overfull \hbox (92.45047pt too wide) in paragraph at lines 19351--19352
[][] 
[188] [189]
! LaTeX Error: Too deeply nested.
See the LaTeX manual or LaTeX Companion for explanation.
Type H <return> for immediate help.
 ... 
 
l.19440 \begin{Verbatim}[commandchars=@\[\]]
 
? 
This corresponds to the following latex code where a second
\begin{quote} is opened before closing the first. Commenting out one
of these \begin{quote} (and the corresponding \end{quote} fixes the
problem:
 Set the scaling of the y-axis: `linear' | `log' | `symlog'
 
 ACCEPTS: {[}'linear' | `log' | `symlog'{]}
 
 Different kwargs are accepted, depending on the scale:
 `linear'
 \begin{quote}
 
 `log'
 \begin{quote}
 \begin{description}
 \item[\emph{basex}/\emph{basey}:]
 The base of the logarithm
 
 \item[\emph{subsx}/\emph{subsy}:]
 Where to place the subticks between each major tick.
 Should be a sequence of integers. For example, in a log10
 scale:
 
This latex seems to be generated by the following lines in axes.py -
but I haven't worked out how to fix it.
 def set_yscale(self, value, **kwargs):
 """
 call signature::
 set_yscale(value)
 Set the scaling of the y-axis: %(scale)s
 ACCEPTS: [%(scale)s]
 Different kwargs are accepted, depending on the scale:
 %(scale_docs)s
 """
 self.yaxis.set_scale(value, **kwargs)
 self.autoscale_view()
 self._update_transScale()
 set_yscale.__doc__ = cbook.dedent(set_yscale.__doc__) % {
 'scale': ' | '.join([repr(x) for x in mscale.get_scale_names()]),
 'scale_docs': mscale.get_scale_docs().strip()}
 
Chris