[matplotlib-devel] mpl1: models, projections, other comments
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
-
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl1: models, projections, other comments
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. 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 . 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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
>> Im attaching a patch
> Is the patch against current SVN?
It was one version out of date. Here is a new one, against 2533
Index: mpltest.py
===
--- mpltest.py (revision 2533)
+++ mpltest.py (working copy)
@@ -5,43 +5,14 @@
import mplconfig; reload(mplconfig)
from mplconfig import MPLConfig
-# Main code
-app = App(MPLConfig,'mpl2.conf')
-
-print app.rc
-
-# some more examples:
-print '-'*80
-print "Here is a default mpl config generated purely from the code:"
-mplrc = MPLConfig()
-print mplrc
-
-print '-'*80
-print "And here is a modified one, using a config file that only changes"
-print "a few parameters and otherwise uses the defaults:"
-mpl2conf = mkConfigObj('mpl2.conf')
-mplrc2 = MPLConfig(mpl2conf)
-print mplrc2
-
-# An example of the ConfigManager usage.
-m3conf = 'mpl3.conf'
-if os.path.isfile(m3conf):
-os.unlink(m3conf)
-mplconf = ConfigManager(MPLConfig,m3conf)
+m3conf = 'mplrc.conf'
+mplconf = ConfigManager(MPLConfig, m3conf, filePriority=True)
+mplconf.tconf.backend.use = 'Qt4Agg'
mplconf.write()
-print '-'*80
-print "The file %r was written to disk..." % m3conf
-os.system('more %s' % m3conf)
-if 0:
-print '-'*80
-print "Play with the 'mpl' object a little, esp its .rc attribute..."
-print "You can even do mpl.rc.edit_traits() if you are running in "
-print "ipython -wthread. It only works with the top-level for now."
-print
-print "The following is an auto-generated dump of the rc object."
-print "Note that this remains valid input for an rc file:"
-print
-mpl = App(MPLConfig,'mpl.conf')
-print mpl.rc
+##mplrc = mplconf.tconf
+##
+##mplrc.nonsense = 1
+##
+##print mplrc
Index: mplrc.conf
===
--- mplrc.conf (revision 0)
+++ mplrc.conf (revision 0)
@@ -0,0 +1,443 @@
+### MATPLOTLIBRC FORMAT
+
+# This is a sample matplotlib configuration file. It should be placed
+# in HOME/.matplotlib/matplotlibrc (unix/linux like systems) and
+# C:\Documents and Settings\yourname\.matplotlib (win32 systems)
+#
+# By default, the installer will overwrite the existing file in the
+# install path, so if you want to preserve your's, please move it to
+# your HOME dir and set the environment variable if necessary.
+#
+# This file is best viewed in a editor which supports ini or conf mode
+# syntax highlighting
+#
+# Blank lines, or lines starting with a comment symbol, are ignored,
+# as are trailing comments. Other lines must have the format
+#
+# key = val # optional comment
+#
+# val should be valid python syntax, just as you would use when setting
+# properties using rcParams. This should become more obvious by inspecting
+# the default values listed herein.
+#
+# Colors: for the color values below, you can either use
+# - a matplotlib color string, such as r, k, or b
+# - an rgb tuple, such as (1.0, 0.5, 0.0)
+# - a hex string, such as #ff00ff or ff00ff
+# - a scalar grayscale intensity such as 0.75
+# - a legal html color name, eg red, blue, darkslategray
+
+ CONFIGURATION BEGINS HERE
+# see http://matplotlib.sourceforge.net/interactive.html
+interactive = False
+
+# None | classic | toolbar2
+toolbar = 'toolbar2'
+
+# a pytz timezone string, eg US/Central or Europe/Paris
+timezone = 'UTC'
+
+# Where your matplotlib data lives if you installed to a non-default
+#location. This is where the matplotlib fonts, bitmaps, etc reside
+datapath = '/home/darren/.matplotlib'
+
+[backend]
+# 'GTKAgg', 'GTKCairo', 'QtAgg', 'Qt4Agg', 'TkAgg', 'Agg',
+# 'Cairo', 'PS', 'PDF', 'SVG'
+use = 'Qt4Agg'
+
+[[cairo]]
+# png, ps, pdf, svg
+format = 'png'
+
+[[tk]]
+# Maintain shell focus for TkAgg
+window_focus = False
+
+# tk sets PYTHONINSEPCT
+pythoninspect = False
+
+[[ps]]
+# auto, letter, legal, ledger, A0-A10, B0-B10
+papersize = 'letter'
+
+# use of afm fonts, results in smaller files
+useafm = False
+
+# 3 (Type3) or 42 (TrueType)
+fonttype = 3
+
+[[[distiller]]]
+# can be: None, ghostscript or xpdf
+# xpdf intended for production of publication quality
+# files, but requires ghostscript, xpdf and ps2eps
+use = None
+
+# distiller resolution, dpi
+resolution = 6000.0
+
+[[pdf]]
+# integer from 0 to 9
+# 0 disables compression (good for debugging)
+compression = 6
+
+# 3 (Type3) or 42 (TrueType)
+fonttype = 3
+
+[[svg]]
+# write raster image data directly into the svg file
+image_inline = True
+
+# suppress scaling of raster data embedded in SVG
+image_noscale = False
+
+# embed character outlines in the SVG file
+embed_chars = False
+
+[InitOnl
Re: [matplotlib-devel] mpl1: models, projections, other comments
On 7/22/07, Eric Firing <[EMAIL PROTECTED]> 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
Re: [matplotlib-devel] rcParams and validation
On 7/21/07, Darren Dale <[EMAIL PROTECTED]> 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 - 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 brow
Re: [matplotlib-devel] rcParams and validation
Hi John, On Sunday 22 July 2007 9:51:05 am John Hunter wrote: > On 7/21/07, Darren Dale <[EMAIL PROTECTED]> 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
Re: [matplotlib-devel] rcParams and validation
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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
On 7/22/07, Darren Dale <[EMAIL PROTECTED]> 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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Enthought-dev] rcParams and validation
On 7/22/07, Dave Peterson <[EMAIL PROTECTED]> 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
-
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Enthought-dev] rcParams and validation
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
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
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
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
-
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Enthought-dev] rcParams and validation
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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Enthought-dev] rcParams and validation
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 = 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
Just an additional data point, with traits 3 from the trunk. Running this:
import enthought.traits.api as T
class C(HasTraits):
x = Array('d', (3,3))
c = C()
c.x = [[1,0,0], [0,1,0], [0,0,1]]
yeilds:
Traceback (most recent call last):
[...]
File
"/usr/lib/python2.5/site-packages/enthought.traits-3.0.0b1-py2.5-linux-i686.egg/enthought/traits/has_traits.py",
line 289, in _check_trait
trait = trait()
File
"/usr/lib/python2.5/site-packages/enthought.traits-3.0.0b1-py2.5-linux-i686.egg/enthought/traits/ui/ui_traits.py",
line 125, in __init__
super( Image, self ).__init__( convert_image( value ), **metadata )
File
"/usr/lib/python2.5/site-packages/enthought.traits-3.0.0b1-py2.5-linux-i686.egg/enthought/traits/ui/ui_traits.py",
line 86, in convert_image
from enthought.pyface.image_resource import ImageResource
ImportError: No module named pyface.image_resource
-
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Enthought-dev] rcParams and validation
John Hunter wrote:
> On 7/22/07, Dave Peterson <[EMAIL PROTECTED]> 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
-
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Enthought-dev] rcParams and validation
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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Enthought-dev] rcParams and validation
On 7/22/07, Dave Peterson <[EMAIL PROTECTED]> 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. - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
