matplotlib-devel Mailing List for matplotlib

On 7/22/07, Dave Peterson <dpe...@en...> wrote:
> Just uploaded a new source tarball that I believe should have this fixed
> so that you don't need to install enthought.resource. Basically, I
Bingo, I am now getting a working install with
sudo easy_install -f
http://code.enthought.com/enstaller/eggs/source/unstable
"enthought.traits < 3.0a"
which brings in only etsconfig, util and traits. Thanks for tracking this down.

Dave Peterson wrote:
> It does look like one of the dependencies in enthought.traits is wrong 
> then. In particular, it was thought that enthought.resource was only 
> required if you actually *used* Traits UI features. I just looked at 
> the code and the only import, in traits, of a package from 
> enthought.resource is in the tree_node.py file which is imported as part 
> of the enthought.traits.ui.api namespace -- which means it happens 
> *alot*. I'll look at avoiding that import, or handling it in a 
> try...except, or update the dependencies and check the changes in as 
> soon as I can get to it. (I'm in the middle of something else currently.)
> 
Just uploaded a new source tarball that I believe should have this fixed 
so that you don't need to install enthought.resource. Basically, I 
moved the import from enthought.resource such that it is only executed 
if you're actually using Traits UI tree node features. I also wrapped 
it with a try...except so that if you don't have enthought.resource 
installed, you just don't find some of the tree node images instead of 
getting a hard failure.
It is svn revision 12960.
-- Dave

John Hunter wrote:
> On 7/22/07, Dave Peterson <dpe...@en...> wrote:
> 
>> Hmm, why did you choose to install enthought.debug? The current source
>> for enthought.traits requires only enthought.etsconfig (which has no
>> other dependencies) and enthought.util (which, without extras, requires
>> only enthought.traits.)
>> 
>
> I added enthought debug to our list of enthought packages a few days
> back when I was having install troubles. I think this was back when
> the traits 3 stuff was creeping into our traits 2 installs, and I was
> getting error messages about not having debug installed. That may
> have all gone away now with your recent work, and it is probably a
> residual hack in our install instructions.
>
> The following, however, gives me a broken install:
>
> sudo rm -rf /usr/local/lib/python2.5/site-packages/enthought*
> sudo easy_install -f
> http://code.enthought.com/enstaller/eggs/source/unstable
> "enthought.traits < 3.0a"
>
> eg, with the file
>
> class C(HasTraits):
> x = Array('d', (3,3))
>
> c = C()
> c.x = [[1,0,0], [0,1,0], [0,0,1]]
>
> I get the traceback:
>
> ImportError: No module named resource.api
>
> But if I add the resource explcitly,
>
> sudo rm -rf /usr/local/lib/python2.5/site-packages/enthought*
> sudo easy_install -f
> http://code.enthought.com/enstaller/eggs/source/unstable
> "enthought.resource <3.0a" "enthought.traits < 3.0a"
>
> I get a working traits install, so maybe a simple dependency is
> missing somewhere. 
> 
It does look like one of the dependencies in enthought.traits is wrong 
then. In particular, it was thought that enthought.resource was only 
required if you actually *used* Traits UI features. I just looked at 
the code and the only import, in traits, of a package from 
enthought.resource is in the tree_node.py file which is imported as part 
of the enthought.traits.ui.api namespace -- which means it happens 
*alot*. I'll look at avoiding that import, or handling it in a 
try...except, or update the dependencies and check the changes in as 
soon as I can get to it. (I'm in the middle of something else currently.)
(Thanks to Darren Dale for providing the full traceback btw.)
-- Dave

On Sunday 22 July 2007 12:46:50 pm John Hunter wrote:
> The following, however, gives me a broken install:
>
> sudo rm -rf /usr/local/lib/python2.5/site-packages/enthought*
> sudo easy_install -f
> http://code.enthought.com/enstaller/eggs/source/unstable
> "enthought.traits < 3.0a"
>
> eg, with the file
>
> class C(HasTraits):
> x =3D Array('d', (3,3))
>
> c =3D C()
> c.x =3D [[1,0,0], [0,1,0], [0,0,1]]
>
> I get the traceback:
>
> ImportError: No module named resource.api
Just an additional data point, with traits 3 from the trunk. Running this:
import enthought.traits.api as T
class C(HasTraits):
=A0 =A0 x =3D Array('d', (3,3))
=A0 =A0 c =3D C()
=A0 =A0 c.x =3D [[1,0,0], [0,1,0], [0,0,1]]
yeilds:
Traceback (most recent call last):
[...] =20
=46ile "/usr/lib/python2.5/site-packages/enthought.traits-3.0.0b1-py2.5-lin=
ux-i686.egg/enthought/traits/has_traits.py",=20
line 289, in _check_trait
 trait =3D trait()
 =20
=46ile "/usr/lib/python2.5/site-packages/enthought.traits-3.0.0b1-py2.5-lin=
ux-i686.egg/enthought/traits/ui/ui_traits.py",=20
line 125, in __init__
 super( Image, self ).__init__( convert_image( value ), **metadata )
 =20
=46ile "/usr/lib/python2.5/site-packages/enthought.traits-3.0.0b1-py2.5-lin=
ux-i686.egg/enthought/traits/ui/ui_traits.py",=20
line 86, in convert_image
 from enthought.pyface.image_resource import ImageResource
ImportError: No module named pyface.image_resource

On Sunday 22 July 2007 1:04:10 pm Darren Dale wrote:
> I think the problem lies in traits.ui, which is looking for
> enthought.resource, which requires pyface.
Scratch that. I thought I remembered that pyface was getting pulled in by 
enthought.resource, but I think that was wrong. Somewhere along the way, I 
was getting errors about pyface, but it must have been while I was trying to 
traits 3 working. Sorry for the noise.
Darren

On Sunday 22 July 2007 12:12:40 pm Dave Peterson wrote:
> Gael Varoquaux wrote:
> > On Sun, Jul 22, 2007 at 11:43:31AM -0400, Darren Dale wrote:
> >> The issue of configuration has come up several times on the mailing
> >> lists over the last few years, and Fernando's tconfig feels like the
> >> right solution. On the other hand, I can't be too enthusiastic about
> >> pushing for inclusion in matplotlib in the near future, because I
> >> havent been able to install traits as a separate package. At the
> >> moment, the following command
> >>
> >>
> >>
> >> easy_install -f
> >> http://code.enthought.com/enstaller/eggs/source/unstable
> >> "enthought.traits < 3.0a"
> >>
> >>
> >>
> >> does not install all the required modules. Running this command:
>
> What didn't get installed that should have been? Definitely this
> command line *should* have worked to get you a working install of
> traits, even if it did install too many things.
That installed etsconfig, util, and traits. I can import traits, but when I 
run John Hunters mpl1.py script, I get messages like:
Traceback (most recent call last):
 File "mpl1.py", line 32, in <module>
 class Affine(traits.HasTraits):
 File "mpl1.py", line 65, in Affine
 data = traits.Array('d', (3,3))
 
File "/usr/lib/python2.5/site-packages/enthought.traits-2.0b2.dev_r12847-py2.5-linux-i686.egg/enthought/traits/traits.py", 
line 329, in __call__
 return self.maker_function( *args, **metadata )
 
File "/usr/lib/python2.5/site-packages/enthought.traits-2.0b2.dev_r12847-py2.5-linux-i686.egg/enthought/traits/traits.py", 
line 805, in Array
 return _Array( typecode, shape, value, coerce = False, **metadata )
 
File "/usr/lib/python2.5/site-packages/enthought.traits-2.0b2.dev_r12847-py2.5-linux-i686.egg/enthought/traits/traits.py", 
line 877, in _Array
 from enthought.traits.ui.api import ArrayEditor
 
File "/usr/lib/python2.5/site-packages/enthought.traits-2.0b2.dev_r12847-py2.5-linux-i686.egg/enthought/traits/ui/api.py", 
line 69, in <module>
 from tree_node \
 
File "/usr/lib/python2.5/site-packages/enthought.traits-2.0b2.dev_r12847-py2.5-linux-i686.egg/enthought/traits/ui/tree_node.py", 
line 36, in <module>
 from enthought.resource.api \
ImportError: No module named resource.api
> >> sudo easy_install -f
> >> http://code.enthought.com/enstaller/eggs/source/unstable
> >> "enthought.etsconfig < 3.0a" "enthought.util <3.0a" "enthought.debug
> >> <3.0a"
> >>
> >> will get you traits, along with debug, developer, envisage, etsconfig,
> >> help io, logger, naming, plugins.python_shell, plugins.text_editor,
> >> pyface, resource, sweet_pickle, traits.ui.wx, type_manager, and util.
> >> Remember that email we got a while back from the guy complaining about
> >> the ubuntu package manager installing too many gui toolkits? Hopefully
> >> it is in Enthought's best interest to work out the dependency issues.
> >
> > Damn it. That certainly is not normal. I am CCing the enthought-dev
> > mailing-list where somebody can take care of this.
>
> Hmm, why did you choose to install enthought.debug? 
It was suggested here: 
https://mail.enthought.com/pipermail/enthought-dev/2007-July/007236.html
> The current source 
> for enthought.traits requires only enthought.etsconfig (which has no
> other dependencies) and enthought.util (which, without extras, requires
> only enthought.traits.)
I think the problem lies in traits.ui, which is looking for 
enthought.resource, which requires pyface.
> The list of dependencies you're seeing is because enthought.debug egg
> does require enthought.pyface, which then heads up a big, big chain of
> other dependencies. That's just the state of the code soon after
> switching over from a monolithic distribution plan. We do hope to
> further minimize the dependencies of enthought.pyface, and all of the
> enthought components in the future!
I'm looking forward to working more with traits, so this is great news. I 
think the same traits.ui issue may be preventing us from using traits3, since 
enthought.resource does not exist in the trunk.
Darren

On 7/22/07, Dave Peterson <dpe...@en...> wrote:
> Hmm, why did you choose to install enthought.debug? The current source
> for enthought.traits requires only enthought.etsconfig (which has no
> other dependencies) and enthought.util (which, without extras, requires
> only enthought.traits.)
I added enthought debug to our list of enthought packages a few days
back when I was having install troubles. I think this was back when
the traits 3 stuff was creeping into our traits 2 installs, and I was
getting error messages about not having debug installed. That may
have all gone away now with your recent work, and it is probably a
residual hack in our install instructions.
The following, however, gives me a broken install:
 sudo rm -rf /usr/local/lib/python2.5/site-packages/enthought*
 sudo easy_install -f
http://code.enthought.com/enstaller/eggs/source/unstable
"enthought.traits < 3.0a"
eg, with the file
 class C(HasTraits):
 x = Array('d', (3,3))
 c = C()
 c.x = [[1,0,0], [0,1,0], [0,0,1]]
I get the traceback:
ImportError: No module named resource.api
But if I add the resource explcitly,
 sudo rm -rf /usr/local/lib/python2.5/site-packages/enthought*
 sudo easy_install -f
http://code.enthought.com/enstaller/eggs/source/unstable
"enthought.resource <3.0a" "enthought.traits < 3.0a"
I get a working traits install, so maybe a simple dependency is
missing somewhere. And I don't get all the extra stuff that comes
along with debug (my fault Darren):
c-67-176-251-149:~> ls /usr/local/lib/python2.5/site-packages/ent*
 enthought.etsconfig-2.0b1.dev_r12810-py2.5.egg:
 enthought.resource-2.0b1.dev_r12810-py2.5.egg:
 enthought.traits-2.0b2.dev_r12847-py2.5-macosx-10.3-ppc.egg:
 enthought.util-2.0b2.dev_r12810-py2.5.egg:
JDH

On 7/22/07, Darren Dale <dd...@co...> wrote:
> the other hand, I can't be too enthusiastic about pushing for inclusion in
> matplotlib in the near future, because I havent been able to install traits
> as a separate package. At the moment, the following command
Well, we always have matplotlib.enthought.traits already installed,
and stable, but obviously we won't be able to take advantage of the
recent bugfixes and enhancements with that, and as importantly,
enthought support. On the other hand, it already ships with mpl, and
if it does everything you need, then you should be OK with it, at
least while enthought gets the install sorted out. I know this a high
priority with them. We always retain the option of pulling a new
traits version into our src tree, but hopefully it won't come to that
because it is in everyone's interest to get the working cross platform
versioned dependency manager using PYPI that they are targeting.
Please bring up your install issues on enthought dev, they are quite
responsive, weekdays and weekends, morning, noon and night, in my
experience. Since they now are a truly international operation (US,
England, India, others?), and seem to be inhabited by guys who really
like to code, someone is usually up and working at all times, it
appears :-)
https://mail.enthought.com/mailman/listinfo/enthought-dev
JDH

On Sun, Jul 22, 2007 at 11:43:31AM -0400, Darren Dale wrote:
> The issue of configuration has come up several times on the mailing
> lists over the last few years, and Fernando's tconfig feels like the
> right solution. On the other hand, I can't be too enthusiastic about
> pushing for inclusion in matplotlib in the near future, because I
> havent been able to install traits as a separate package. At the
> moment, the following command 
> easy_install -f 
> http://code.enthought.com/enstaller/eggs/source/unstable "enthought.traits < 
> 3.0a"
> does not install all the required modules. Running this command:
> sudo easy_install -f 
> http://code.enthought.com/enstaller/eggs/source/unstable "enthought.etsconfig 
> < 3.0a" "enthought.util <3.0a" "enthought.debug <3.0a"
> will get you traits, along with debug, developer, envisage, etsconfig, help 
> io, logger, naming, plugins.python_shell, plugins.text_editor, pyface, 
> resource, sweet_pickle, traits.ui.wx, type_manager, and util. Remember that 
> email we got a while back from the guy complaining about the ubuntu package 
> manager installing too many gui toolkits? Hopefully it is in Enthought's best 
> interest to work out the dependency issues.
Damn it. That certainly is not normal. I am CCing the enthought-dev
mailing-list where somebody can take care of this.
Gaël

Hi John,
On Sunday 22 July 2007 9:51:05 am John Hunter wrote:
> On 7/21/07, Darren Dale <dd...@co...> wrote:
> > 2) It would be nice to be able to write a default file that has
> > everything commented out with the exception of backend.use and numerix.
> > We comment out all the parameters in the current matplotlibrc, which
> > makes it easier to identify what has been customized during
> > troubleshooting.
>
> F and I talked about the "commented out" thing on the phone last
> night. The motivation for this was: when we upgrade rc we don't want
> users who have never seen or modified an rc file to get a rc
> deprecation warning. But Fernando thought it would be impossible to
> deal intelligently with comment files in the new framework, eg
> persisted changes would not necessarily be written to the portion
> where the commented out version was, and the commented part would
> still be in. We discussed one possibility to install a full,
> uncommented default config file in the system directory (eg mpl-data)
> at install time which was guaranteed to be correct, and in the users
> .matplotlib directory just put a stub which includes that file (so
> they know where to find it and copy-and-paste from) and in the user
> file also puy any build time config we detect, eg backend and
> formerly, numerix. Changes made to the rc object when saved would
> always go to the top level rc file, eg the one in the user dir. So
> the user rc would be a pointer to the main rc with local
> modifications.
I was thinking along these lines as well, having an uncommented "master 
config" file that ships with mpl. I was thinking of using that file as a 
template to automatically generate commented out versions, but I like 
Fernando's recursive include framework much better.
> > 3) Any key appearing in the conf file is validated, so you cant mispell a
> > key name or accidentally include some garbage. But after generating the
> > MPLConfig object mplrc, you can do something like mplrc.nonsense = 1
> > without generating an error. Is there a way to prevent the creation of
> > additional attributes once mplrc has been instantiated? That was a useful
> > improvement to our current rcParams.
>
> I believe HasStrictTraits is designed for this.
>
> > 4) It would be nice to create a new mpl.conf file based on changes made
> > interactively, without having to overwrite the old file, yet still
> > preserving the order and comments seen in the default I attached. Maybe
> > copying the default into the new location, and using it as the template?
> > Even better, when I saved a new file, it would preserve the defaults
> > order, and any settings that are identical to the defaults would be
> > commented out. Ok, I'm getting carried away. sorry.
>
> I don't know if my comments above address this..
They do.
> > I'm feeling a bit cross-eyed from coding all day, and this is a little
> > too abstract at the moment for my poor head. Good luck!
>
> I know the feeling from my own experience over the last few days.
>
> I think we should make sure we know what we are getting with this new
> config approach, ie what is missing from our current system that
> people want to do but can't. For mpl1, I don't mind doing something
> different if it is simply better and cleaner. For matplotlib, I think
> we need a higher bar, though not an infinitely high one. For the
> latter, I think it needs to solve an existing problem, and do so in a
> way that we expect to solve it "for good". I think the system you and
> Fernando are discussing probably meets the second criteria, since
> you've obviously put a lot of thought into what a good config system
> needs. I am less convinced about the first. With your latest changes 
> to the current rc system, we have config time and runtime validation
> of the keys and values, albeit a homegrown and not terribly elegant
> version of what traits does more elegantly.
As long as matplotlib is not designed to take advantage of notification, etc, 
the existing rc system could provide nearly the same functionality as the 
traited config system. The validators would have to be significantly 
improved. We would still have problems arising from having to parse strings, 
convert values, and then validate. For example, the latex preamble is of 
limited usefulness.
> Recursive includes and 
> runtime persistence are nice, but noone has ever asked for that as far
> as I know. 
I imagine our more advanced users would find them extremely useful once they 
knew about them. But imagine trying to explain them in the users guide.
> For ipython, which is an environment where building 
> hybrids of other environments is a common need, recursive includes are
> clearly useful. So I'd like to make sure we have a clear rationale
> here, other than shiny and new. We geeks do like our toys.
The issue of configuration has come up several times on the mailing lists over 
the last few years, and Fernando's tconfig feels like the right solution. On 
the other hand, I can't be too enthusiastic about pushing for inclusion in 
matplotlib in the near future, because I havent been able to install traits 
as a separate package. At the moment, the following command 
easy_install -f 
http://code.enthought.com/enstaller/eggs/source/unstable "enthought.traits < 
3.0a"
does not install all the required modules. Running this command:
sudo easy_install -f 
http://code.enthought.com/enstaller/eggs/source/unstable "enthought.etsconfig 
< 3.0a" "enthought.util <3.0a" "enthought.debug <3.0a"
will get you traits, along with debug, developer, envisage, etsconfig, help 
io, logger, naming, plugins.python_shell, plugins.text_editor, pyface, 
resource, sweet_pickle, traits.ui.wx, type_manager, and util. Remember that 
email we got a while back from the guy complaining about the ubuntu package 
manager installing too many gui toolkits? Hopefully it is in Enthought's best 
interest to work out the dependency issues.
> That said, as part of a general traitification of matplotlib artists,
> I think it is natural and good to have a traitified rc file. If you
> view this work as a first step in that direction, I think that is
> sufficient justification, because having traitified artists will solve
> a clear and existing need: a generalized validation and notification
> framework. And the goal of having a common config system across core
> packages certainly has merits as well.
I agree. I think we could give the new system a trial in svn (when we think it 
is ready) by wrapping the traited rc object with an object that quacks like 
an rcParams dict. That way, the new system could be turned on or off so it 
wouldnt be disruptful to the broader community of svn users.
Darren

On 7/21/07, Darren Dale <dd...@co...> wrote:
> Im attaching a patch, it includes lots of changes to mplconfig.py, a realistic
> mplrc.conf file (feel free to rename it to mpl.conf or matplotlib.conf or
> whatever seems standard), and a backup of that .conf file. The mpltest lets
> me try your trick of modifying a well formatted file in place. Very nice!
Hey Darren,
I've been following the config discussion, but am not as deep into it
as you and Fernando so I'll just make some general comments.
> 2) It would be nice to be able to write a default file that has everything
> commented out with the exception of backend.use and numerix. We comment out
> all the parameters in the current matplotlibrc, which makes it easier to
> identify what has been customized during troubleshooting.
F and I talked about the "commented out" thing on the phone last
night. The motivation for this was: when we upgrade rc we don't want
users who have never seen or modified an rc file to get a rc
deprecation warning. But Fernando thought it would be impossible to
deal intelligently with comment files in the new framework, eg
persisted changes would not necessarily be written to the portion
where the commented out version was, and the commented part would
still be in. We discussed one possibility to install a full,
uncommented default config file in the system directory (eg mpl-data)
at install time which was guaranteed to be correct, and in the users
.matplotlib directory just put a stub which includes that file (so
they know where to find it and copy-and-paste from) and in the user
file also puy any build time config we detect, eg backend and
formerly, numerix. Changes made to the rc object when saved would
always go to the top level rc file, eg the one in the user dir. So
the user rc would be a pointer to the main rc with local
modifications.
> 3) Any key appearing in the conf file is validated, so you cant mispell a key
> name or accidentally include some garbage. But after generating the MPLConfig
> object mplrc, you can do something like mplrc.nonsense = 1 without generating
> an error. Is there a way to prevent the creation of additional attributes
> once mplrc has been instantiated? That was a useful improvement to our
> current rcParams.
I believe HasStrictTraits is designed for this.
> 4) It would be nice to create a new mpl.conf file based on changes made
> interactively, without having to overwrite the old file, yet still preserving
> the order and comments seen in the default I attached. Maybe copying the
> default into the new location, and using it as the template? Even better,
> when I saved a new file, it would preserve the defaults order, and any
> settings that are identical to the defaults would be commented out. Ok, I'm
> getting carried away. sorry.
I don't know if my comments above address this..
> I'm feeling a bit cross-eyed from coding all day, and this is a little too
> abstract at the moment for my poor head. Good luck!
I know the feeling from my own experience over the last few days.
I think we should make sure we know what we are getting with this new
config approach, ie what is missing from our current system that
people want to do but can't. For mpl1, I don't mind doing something
different if it is simply better and cleaner. For matplotlib, I think
we need a higher bar, though not an infinitely high one. For the
latter, I think it needs to solve an existing problem, and do so in a
way that we expect to solve it "for good". I think the system you and
Fernando are discussing probably meets the second criteria, since
you've obviously put a lot of thought into what a good config system
needs. I am less convinced about the first. With your latest changes
to the current rc system, we have config time and runtime validation
of the keys and values, albeit a homegrown and not terribly elegant
version of what traits does more elegantly. Recursive includes and
runtime persistence are nice, but noone has ever asked for that as far
as I know. For ipython, which is an environment where building
hybrids of other environments is a common need, recursive includes are
clearly useful. So I'd like to make sure we have a clear rationale
here, other than shiny and new. We geeks do like our toys.
That said, as part of a general traitification of matplotlib artists,
I think it is natural and good to have a traitified rc file. If you
view this work as a first step in that direction, I think that is
sufficient justification, because having traitified artists will solve
a clear and existing need: a generalized validation and notification
framework. And the goal of having a common config system across core
packages certainly has merits as well.
JDH

On 7/22/07, Eric Firing <ef...@ha...> wrote:
> You are going great guns with mpl1; I am trying to get spun up on
> traits, and to understand where you are going with mpl1. In general I
> like what I see--as expected. Regarding the following comments: I
> recognize that you are engaged in a sketching activity, and I may be
> thinking prematurely about detail.
A bit of both, some of the things you mention I've simply left out for
expediency, and some of them reflect murky thinking, so these comments
are useful. Also, you'll notice that the examples are quite verbose
right now -- I think there is plenty we can do to simplify as well as
wrap these calls up into convenience methods. I've been focused more
on trying to get things wired up properly and then later worry about
how it looks.
> You raised the question of 3D. I don't know anything about fancy 3D
> with hardware acceleration etc., but for the simplest 3D it seems like
> everything can be done at the model stage of the transformation;
> everything after that is 2D. Maybe this doesn't get us very far; I
> don't know how hidden-line removal would be handled for multiple paths.
This is essentially the approach taken by axes3d and friends in
current matplotlib, and yes, you do get into 3d clipping problems this
way. I don't really have much of an appetite for 3D personally. It's
plenty of work to get 2D right. My comment was more in the vein of:
would it be useful to stick in 3D transformations and data structures
from the ground up if they aren't too expensive so that if someone who
*does* have more of an appetite for making it work comes around, they
will have a fighting chance.
> It seems to me that in the interesting cases such as polar plots, map
> projections, and simple 3D plotting, the Func class is really a
> Projection class, so I suggest it be renamed to that, or to Proj if you
> want something short. ("Func" always seemed a bit ugly.) It will
> typically need additional attributes, and should supply additional
> information. For example, for a given set of coordinate limits (say r
> from 1 to 2 and theta from 0 to pi/2 in the polar case) it should be
> able to provide a bounding box in the rectilinear coordinates. It will
> need a method to generate a path that is "straight" in the original
> coordinates, hence curved in the rectilinear coordinates. (This method
> will probably be used both to calculate the bounding box and to generate
> the axis objects, grids, bounding "polygon", and things like the bar
> paths in a polar bar plot, for example.) I suspect it will also help to
> have a method that returns a rotation matrix for each of a set of
> points. This would be a help in generating an axis with tick marks in a
> curvilinear system, and in orienting vectors drawn on a map projection.
This is very helpful -- as you saw, what I have in their are mostly
stubs and I have not given a lot of thought to how they need to fit in
with a general transformation scheme vis-a-vis tick labeling and
gridding. The other question is: where should they live? In the
draft, they are attached to the artist, but probably the artist should
get them from the axes they live in because the axes will also need to
use them for ticking and gridding. I'm pretty close to having the
axis, axes portion of the sketch done, though I have to take a few
days off from this to attend to other things. If you have some time,
in the interim, you should sketch out a traited API of the Projection
class (much better name). When I get that axis portion working,
perhaps you should jump and see if you can plug your projection class
into it. For me it will probably be Tues or Wed at the earliest.
> This brings up another question, regarding the drawing model: what do
> you view as (1) required and (2) not required but used if available? So
> far, everything is in terms of moveto, lineto, and close_polygon. What
> about curves? Do you anticipate sticking to line-segment paths, or do
> you expect to use any curve-generation (bezier, arc, ellipse)
> facilities? Is this something to be done as a phase-2 optimization,
> after initially doing everything with line-segment paths?
No we'll support the bezier curves at the outset, this was an example
of an expediency. I just didn't add the extra codes in m first pass.
Ellipse and Arc will just be special cases of a Path with bezier
codes, but they won't be primitives.
> Returning to a point of terminology: what you are calling Affine is
> actually a very limited subset of affine transformations, correct?
> Rotation and shear are not included.
> Also, I was puzzled initially by the xlim and ylim attributes; these are
> the bounds that get mapped to the 0-1 interval by the transform,
> correct? If so, this is an additional specialization of your Affine
> relative to the general meaning of the term.
This is the example of the mix of expediency and murkiness I was
referring to above. I planned to go back and add rotation and shear
interfaces (eg along the lines of the current translate and scale
properties). The murkiness part is that I made the xlim and ylim a
property based view into the affine, which was quite handy, but will
probably cause problems down the road. We might want to have a
derived special case of the affine for separable coordinate systems so
that we can support this usage of the xlim and ylim. The aritst.adata
would then be the seperable affine, where as the aview would be a full
affine, eg to support rotated axes. Does this seem workable?
Thanks,
JDH

>> Im attaching a patch
> Is the patch against current SVN?
It was one version out of date. Here is a new one, against 2533

On Sat, Jul 21, 2007 at 10:41:27PM -1000, Eric Firing wrote:
> You raised the question of 3D. I don't know anything about fancy 3D 
> with hardware acceleration etc., but for the simplest 3D it seems like 
> everything can be done at the model stage of the transformation; 
> everything after that is 2D. Maybe this doesn't get us very far; I 
> don't know how hidden-line removal would be handled for multiple paths.
I tried to work on gnuplot a while ago, adding some 3D features. My
contribution ended up being inexistant (a physics undergrad with no
experience in C doesn't get terribly far on this kind of project), but I
did learn something: a 3D package must be fully 3D, or I think it won't
go far. My personnal opinion is that I won't spend my time on a package
that wants to do 3D and that does not keep a complete 3D representation
of its object at all time, and even feeds it to the backends.
<shameless plug> If you want cool 3D, come and help us with mayavi 2D, we
are currently working on a pylab like interface. It is in its early
stages, but if more people work on it, it will go far </shameless plug>.
If you are going down the 3D slope you should define precisely what you
want to do, and where you stop, and think the architecture in these
terms. The big question is: when does the projection happen ? What lives
in the 2D canvas (IMHO, the less, the better), what live in the 3D world,
and when is it projected.
My 2 cents,
Gaël

John,
You are going great guns with mpl1; I am trying to get spun up on 
traits, and to understand where you are going with mpl1. In general I 
like what I see--as expected. Regarding the following comments: I 
recognize that you are engaged in a sketching activity, and I may be 
thinking prematurely about detail.
You raised the question of 3D. I don't know anything about fancy 3D 
with hardware acceleration etc., but for the simplest 3D it seems like 
everything can be done at the model stage of the transformation; 
everything after that is 2D. Maybe this doesn't get us very far; I 
don't know how hidden-line removal would be handled for multiple paths.
It seems to me that in the interesting cases such as polar plots, map 
projections, and simple 3D plotting, the Func class is really a 
Projection class, so I suggest it be renamed to that, or to Proj if you 
want something short. ("Func" always seemed a bit ugly.) It will 
typically need additional attributes, and should supply additional 
information. For example, for a given set of coordinate limits (say r 
from 1 to 2 and theta from 0 to pi/2 in the polar case) it should be 
able to provide a bounding box in the rectilinear coordinates. It will 
need a method to generate a path that is "straight" in the original 
coordinates, hence curved in the rectilinear coordinates. (This method 
will probably be used both to calculate the bounding box and to generate 
the axis objects, grids, bounding "polygon", and things like the bar 
paths in a polar bar plot, for example.) I suspect it will also help to 
have a method that returns a rotation matrix for each of a set of 
points. This would be a help in generating an axis with tick marks in a 
curvilinear system, and in orienting vectors drawn on a map projection.
This brings up another question, regarding the drawing model: what do 
you view as (1) required and (2) not required but used if available? So 
far, everything is in terms of moveto, lineto, and close_polygon. What 
about curves? Do you anticipate sticking to line-segment paths, or do 
you expect to use any curve-generation (bezier, arc, ellipse) 
facilities? Is this something to be done as a phase-2 optimization, 
after initially doing everything with line-segment paths?
Returning to a point of terminology: what you are calling Affine is 
actually a very limited subset of affine transformations, correct? 
Rotation and shear are not included.
Also, I was puzzled initially by the xlim and ylim attributes; these are 
the bounds that get mapped to the 0-1 interval by the transform, 
correct? If so, this is an additional specialization of your Affine 
relative to the general meaning of the term.
Eric

On 7/21/07, Paul Kienzle <pki...@ni...> wrote:
> Hi,
>
> I really love mathtext! I wrote a simple formula parser
> and now I can label my graphs with easy to read chemical
> names (I've attached it below for the curious).
>
> The problem is that the baseline is wandering. On my machine
> the following has the 'h' too low and the 'io' too high:
Just guessing, but...
There is a problem we have with text alignment in the ft2font module.
We can either align to top, bottom or center, but we need an option to
align to the glyph baseline. Michael is currently working on mathtext
and is now our resident font guru. Michael, can you take a look at
this. This would be an important enhancement for mathtext, multiline
text, and a text entry widget.
Thanks,
JDH
>
> import pylab
> ax = pylab.subplot(111)
> pylab.text(0.5,0.5,r'$\rm{Thiol}$', va='bottom')
> pylab.show()
>
> I'm using wxAgg on OS X. I know I've installed freetype, but
> beyond that I have no idea what font it is using.
>
> Do others experience the same problem?
>
> Any idea where I can start when debugging this?
>
> - Paul
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On 7/21/07, Darren Dale <dd...@co...> wrote:
> On Saturday 21 July 2007 3:12:44 pm Fernando Perez wrote:
> > On 7/21/07, Darren Dale <dd...@co...> wrote:
> > > I'm working on converting our existing rc code to tconfig this weekend.
> > > So far so good. I just wanted to let people know to avoid duplicating
> > > effort.
> >
> > Excellent! Ping me if you have any problems.
>
> Im attaching a patch, it includes lots of changes to mplconfig.py, a realistic
> mplrc.conf file (feel free to rename it to mpl.conf or matplotlib.conf or
> whatever seems standard), and a backup of that .conf file. The mpltest lets
> me try your trick of modifying a well formatted file in place. Very nice!
Is the patch against current SVN? I'm in a hurry and can't look at it
now, so if you can double-check, that would be great. For tconfig.py,
my last commit was:
Last Changed Rev: 2532
Last Changed Date: 2007年07月21日 15:19:06 -0600 (2007年7月21日)
> A couple comments:
>
> 1) Comments in the config file must appear on a separate line from the
> parameters, or they will be overwritten
>
> 2) It would be nice to be able to write a default file that has everything
> commented out with the exception of backend.use and numerix. We comment out
> all the parameters in the current matplotlibrc, which makes it easier to
> identify what has been customized during troubleshooting.
John and I just had a long conversation on this topic, and I think we
have a reasonable solution. I have to run now, but I'll try to
implement it tomorrow and will get back to you with more feedback.
Sorry but I have guests coming now :)
> 3) Any key appearing in the conf file is validated, so you cant mispell a key
> name or accidentally include some garbage. But after generating the MPLConfig
> object mplrc, you can do something like mplrc.nonsense = 1 without generating
> an error. Is there a way to prevent the creation of additional attributes
> once mplrc has been instantiated? That was a useful improvement to our
> current rcParams.
Yes, we can inherit from HasStrictTraits instead of HasTraits. I was
in fact doing that but had some problem, can't remember what. I'm
sure it's doable though.
> 4) It would be nice to create a new mpl.conf file based on changes made
> interactively, without having to overwrite the old file, yet still preserving
> the order and comments seen in the default I attached. Maybe copying the
> default into the new location, and using it as the template? Even better,
> when I saved a new file, it would preserve the defaults order, and any
> settings that are identical to the defaults would be commented out. Ok, I'm
> getting carried away. sorry.
>
> > I'm going to try and finish hierarchical inclusion of files (aka
> > ipython profiles) now. Consider for example a paper that requires
> > black and white only styles. You could then have in that paper's
> > directory a .matplotlib.conf file with:
> >
> > # paper-specific tweaks
> > include = "$HOME/.matplotlib/matplotlib.conf"
> >
> > [lines]
> > color = 'black'
> > thickness = 2
> >
> > etc.
>
> Thats a nice idea.
>
> > Or in your .matplotlib dir, you could keep multiple configurations
> > that branch off the basic one for different needs, while keeping
> > common defaults in one central location.
> >
> > In my first implementation I'll have to give up on safe roundtripping
> > to files with recursion active, because it's a bit tricky to do both
> > (not impossible).
>
> I'm feeling a bit cross-eyed from coding all day, and this is a little too
> abstract at the moment for my poor head. Good luck!
Yup, I'm pretty tired too. It seems we're all in the same
carpal-tunnel-inducing marathon :)
Thanks again for pitching in!
Cheers,
f

Hi,
I really love mathtext! I wrote a simple formula parser
and now I can label my graphs with easy to read chemical
names (I've attached it below for the curious).
The problem is that the baseline is wandering. On my machine
the following has the 'h' too low and the 'io' too high:
import pylab
ax = pylab.subplot(111)
pylab.text(0.5,0.5,r'$\rm{Thiol}$', va='bottom')
pylab.show()
I'm using wxAgg on OS X. I know I've installed freetype, but 
beyond that I have no idea what font it is using.
Do others experience the same problem?
Any idea where I can start when debugging this?
	- Paul

On Sat, Jul 21, 2007 at 02:39:52PM -0500, John Hunter wrote:
> On 7/21/07, Paul Kienzle <pki...@ni...> wrote:
> > Hi,
> >
> > I'm attaching the canvas object code I've been playing with.
> >
> > The API is still incomplete, but in the spirit of release early,
> > release often, I'll put it out there for people to comment on.
> 
> Hey Paul this is really cool stuff. There is a minor bug -- the onAdd
> callback in bindertest.py on line 26 should be onAddend I think.
onAppend. That's a brown paper bagger :-(
> Also, I wanted to know if you've looked that the copy_region/blit
> stuff we have.
I'm aware of the blit stuff but haven't looked in detail. So far I 
don't need it because my graphs are simple. Later when I define
widgets operating on meshes I will look more closely.
> BTW, poly_editor was broken but I just fixed it so you can check it
> out of svn if you want to take a look.
Yup, it works now! Even when it was broken it was still a good source
of examples.
> Right now I don't have any answers or comments to the questions you
> raise in the code, eg on keyboard vs mouse focus handling -- you are
> much deeper in this stuff than I am -- so I'll it's probably best if
> you just keep thinking through these things as you go.
I'll be away for a weeks but will continue when I return. Working
with it when I return. 
I already know that I need to use keyboard focus handling. My real 
application can move objects around on the screen with the keyboard 
for finer control, and this will only work if the keyboard focus stays 
with the object even as it moves from the mouse.
> As for your traits question, you are absolutely right about the need
> for a common callback framework. I have been cleaning up the
> transformations in mpl1 and the callbacks and properties on the
> affines are tremendously useful (eg xlim is just a property based view
> into the affine, and one can connect to events on affine changes). I
> don't have a GUI backend layer yet in which one can begin playing
> around with interaction, but I am close, with a few more changes, to
> having a serviceable first cut at the transformations, artist
> hierarchy, and renderer layer.
I'm looking forward to seeing it.
> FYI, every artist does have a callback mechanism built in which you
> can easily extend to support additional events (right now I have been
> adding them on as as needed basis -- what traits does so nicely is
> that they are there for every traited instance).
> 
> Eg to connect to the Axes xlim:
> 
> ax.callbacks.connect('xlim_changed', func)
> 
> and func will be called with the signature func(ax). Eg see
> examples/shared_axis_across_figures.py which utilizes the callbacks to
> couple xlim across figure instances.
How much control is there over the which callbacks are called, what order
they are called in, and when effects show up on the screen? 
My first implementation sends the event to the artist, and if the artist 
returns false it goes to the axes, then the figure. This is much weaker 
than the Tk/BLT canvas model, which allows the programmer to control the 
order, and also has class-based dispatch.
Also, I'm nervous about this from a performance perspective --- I don't want
others to have a slower graphics engine just because I need callbacks
for what I'm doing.
Has anyone done profiling to see where the current bottlenecks are?
I know we will be looking into this; the user experience was so
awkward with four plotting panels in an wx.aui frame that we went
back to a straight wx.lib.plot backend.
- Paul

On Saturday 21 July 2007 3:12:44 pm Fernando Perez wrote:
> On 7/21/07, Darren Dale <dd...@co...> wrote:
> > I'm working on converting our existing rc code to tconfig this weekend.
> > So far so good. I just wanted to let people know to avoid duplicating
> > effort.
>
> Excellent! Ping me if you have any problems.
Im attaching a patch, it includes lots of changes to mplconfig.py, a realistic 
mplrc.conf file (feel free to rename it to mpl.conf or matplotlib.conf or 
whatever seems standard), and a backup of that .conf file. The mpltest lets 
me try your trick of modifying a well formatted file in place. Very nice!
A couple comments:
1) Comments in the config file must appear on a separate line from the 
parameters, or they will be overwritten
2) It would be nice to be able to write a default file that has everything 
commented out with the exception of backend.use and numerix. We comment out 
all the parameters in the current matplotlibrc, which makes it easier to 
identify what has been customized during troubleshooting.
3) Any key appearing in the conf file is validated, so you cant mispell a key 
name or accidentally include some garbage. But after generating the MPLConfig 
object mplrc, you can do something like mplrc.nonsense = 1 without generating 
an error. Is there a way to prevent the creation of additional attributes 
once mplrc has been instantiated? That was a useful improvement to our 
current rcParams.
4) It would be nice to create a new mpl.conf file based on changes made 
interactively, without having to overwrite the old file, yet still preserving 
the order and comments seen in the default I attached. Maybe copying the 
default into the new location, and using it as the template? Even better, 
when I saved a new file, it would preserve the defaults order, and any 
settings that are identical to the defaults would be commented out. Ok, I'm 
getting carried away. sorry.
> I'm going to try and finish hierarchical inclusion of files (aka
> ipython profiles) now. Consider for example a paper that requires
> black and white only styles. You could then have in that paper's
> directory a .matplotlib.conf file with:
>
> # paper-specific tweaks
> include = "$HOME/.matplotlib/matplotlib.conf"
>
> [lines]
> color = 'black'
> thickness = 2
>
> etc.
Thats a nice idea.
> Or in your .matplotlib dir, you could keep multiple configurations
> that branch off the basic one for different needs, while keeping
> common defaults in one central location.
>
> In my first implementation I'll have to give up on safe roundtripping
> to files with recursion active, because it's a bit tricky to do both
> (not impossible).
I'm feeling a bit cross-eyed from coding all day, and this is a little too 
abstract at the moment for my poor head. Good luck!
Darren