[matplotlib-devel] scatter segfaults - mpl 0.91.2
Whilst trying to plot a scatter plot with no facecolor I was able to reliably reproduce a segfault in mpl 0.91.2 - see below: Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] IPython 0.8.3.svn.r3001 -- An enhanced Interactive Python. In [1]: import matplotlib In [2]: matplotlib.__version__ Out[2]: '0.91.2' In [3]: from pylab import scatter, rand In [4]: scatter(rand(100),rand(100),c='') <--SegFault--> That's probably not the right way to do it but it does work in 0.98.0. I'm unable to test on 0.91.3 at the moment. NB: The work-around (correct way?) to get the same result in 0.91.2 is: scatter(rand(100),rand(100),c='w',alpha=0) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Matplotlib patch on EPD trac?
Ryan May wrote: John Hunter wrote: Ryan May has been doing all the heavy lifting with respect to PSD and specgram, so I am going to turf this to him :-) It may be that the bug filer's problems are resolved in the recent changes in 98.5.2, but Ryan should confirm On Fri, Jan 9, 2009 at 2:45 PM, Dave Peterson wrote: Hi John, Sorry for sending this directly, but I'm still waiting for my matplotlib devel mailing subscription to go through We've just had an EPD user submit a patch for matplotlib to 'fix' a problem they were seeing with the PSD function. Is this a known issue or something that you'd be interested in including in future versions of matplotlib? Or is it something that you disagree is 'right'? https://svn.enthought.com/epd/ticket/581 I'd like to know to do the right thing with the matplotlib we include in EPD. :-) Specgram specifically handles the case of moving frequencies to -Fs/2 to Fs/2, instead of 0 to Fs. It was this way before I did any of my changes and I just left it as it was. Psd returns frequencies 0 to Fs for Matlab compatibility (I think anyways, John?). Personally, I'd also prefer to have -Fs/2 to Fs/2 returned as well, so I don't have to do it in my own code. However, I'm also loath to add yet another flag to toggle Matlab compatibility. As far as the patch goes, it looks fine. It won't work as is with the refactoring I've already done in SVN, but it wouldn't be hard to implement the changes, if we decide to go that way. Maybe it's time to refactor here to get routine(s) that operate how we want (IMO more sanely than Matlab), and we provide wrappers that give Matlab-like behavior. Maybe we can also get these sane routines upstream into Scipy. At that point, however, I'm not sure what to do about the plotting functions, since there's a variety of behavior. Thoughts? Ryan Hi Guys, I'm not sure what's going on with my subscription request e-mail. So I'll reply-all and see what happens... I can't speak too strongly about what should be there but I certainly like Ryan's idea of getting more sane behavior and simultaneously providing a wrapper / second API entry point to get the Matlab compatible behavior. As far as EPD goes, since this didn't result in a "yes, we'll apply it" response, we'll hold off on applying this patch to the matplotlib build we ship inside EPD until you guys figure out which way you're headed. It clearly seems wrong to have different, non-bug, behavior between your releases and EPD. -- Dave -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Enhancement to matplotlib's PyQt4 backend
Darren Dale wrote:
On Tue, Apr 28, 2009 at 12:19 PM, Pierre Raybaut <mailto:cont...@pythonxy.com>> wrote:
2009/4/28 John Hunter mailto:jdh2...@gmail.com>>:
>
>
> On Tue, Apr 28, 2009 at 8:18 AM, Pierre Raybaut
mailto:cont...@pythonxy.com>>
> wrote:
>>
>> Hi all,
>>
>> I would like to contribute to matplotlib with this enhancement
for the
>> PyQt4 backend: the idea is to add a toolbar button to configure
figure
>> options (axes, curves, ...).
>>
>> It's based on a tiny module called formlayout to generate PyQt4
form
>> dialog automatically.
>>
>> Some screenshots:
>> http://code.google.com/p/formlayout/
>>
>> So, if you're interested (all the following is GPL2):
>>
>> *matplotlib patch*
>>
>> In FigureManagerQT.__init__, added:
>> self.canvas.axes = self.canvas.figure.add_subplot(111)
>>
>> In NavigationToolbar2QT._init_toolbar, added:
>> a = self.addAction(self._icon("customize.png"), 'Customize',
>> self.edit_parameters)
>> a.setToolTip('Edit curves line and axes parameters')
>>
>> Added the following method in NavigationToolbar2QT:
>> def edit_parameters(self):
>>from figureoptions import figure_edit
>>figure_edit(self.canvas, self)
>>
>> *additionnal modules and data*
>>
>> formlayout.py (http://code.google.com/p/formlayout/)
>> figureoptions.py (http://code.google.com/p/PyQtShell/)
>> customize.png (http://code.google.com/p/PyQtShell/)
>
> Hi Pierre -- this looks very nice (the last link is broken
though , I get a
> 404 error). We would be happy to include this in matplotlib or as a
Here is the last link:
http://code.google.com/p/pyqtshell/
> toolkit. To contribute it to to mpl, the license needs to be
matplotlib
> compatible
>
(http://matplotlib.sourceforge.net/devel/coding_guide.html#licenses)
but we
> have more licensing flexibility in a toolkit, though we prefer
to keep
> everything BSD compatible where possible. And of course you
would need to
> agree to maintain it :-) but I think many users would appreciate
a GUI plot
> configuration dialog.
I was not aware of this license restriction in matplotlib... I fully
understand the motivation, of course, but still: I wrote all this on
my free time which means no PyQt4 commercial license, so it can't be
anything but GPL. Sorry...
I think you have overlooked a subtlety of PyQt4's license. The author
of PyQt4 wrote on the enthought-dev mailing list:
"PyQt is GPL but has exceptions that allow it to be used with BSD code -
hence it's Ok for TraitsBackendQt to be BSD.
However, the exception imposes additional conditions which, to all intents
and purposes, infects the code with the GPL. To be fair to people that
should be made clear in any text.
It's still a good idea for TraitsBackendQt to use a BSD license because it
allows commercial (ie. non-GPL) users to use it without problems."
Darren
I think it might be worth contacting the PyQt folks (Phil Thompson)
about this. I think there might be some differences here because Phil
was the author of TraitsBackendQt and thus his efforts didn't quite fall
under the "develop under a free license, your results needs to be GPL"
clause Qt/PyQt have in their licensing.
-- Dave
--
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Solaris and GCC 4.3.x: error TTStreamWriter has no putc
When attempting to build matplotlib 0.98.5.2 on Solaris 10 using GCC
4.3.3, I get an error:
ttconv/pprdrv_tt2.cpp: In member function ‘void
GlyphToType3::stack(TTStreamWriter&, int)’:
ttconv/pprdrv_tt2.cpp:107: error: ‘class TTStreamWriter’ has no member
named ‘putc’
So I tried invoking GCC with the -E flag to get the output of the
preprocessor and I see that line 107 of pprdrv_tt2.cpp gets rewritten to:
stream.putc(('{'), (&__iob[1]));
so it seems that something in GCC 4.3.3 on Solaris is defining a putchar
macro that is doing this, but not correspondingly being applied to the
pprdrv.h.
Searching the list archives, I see that back in July & August, 2008
there was a brief thread between Peter Norton and Mike Droettboom about
this and a proposal was made to rename TTStreamWriter::putchar to
TTStreamWriter:put_char. I just looked at the trunk and it looks like
this has never been done. Was there some other work-around that didn't
make it into the thread that obviated the need for the mentioned change?
I can confirm that the renaming of putchar to put_char does solve the
problem. I've attached a patch file, though it is against 0.98.5.2.
-- Dave
--- ttconv/pprdrv.h Wed Apr 29 15:04:00 2009
+++ ttconv/pprdrv.h Wed Apr 29 15:08:46 2009
@@ -40,7 +40,7 @@
virtual void write(const char*) = 0;
virtual void printf(const char* format, ...);
- virtual void putchar(int val);
+ virtual void put_char(int val);
virtual void puts(const char* a);
virtual void putline(const char* a);
};
--- ttconv/pprdrv_tt.cppWed Apr 29 15:06:16 2009
+++ ttconv/pprdrv_tt.cppWed Apr 29 15:08:46 2009
@@ -482,20 +482,20 @@
if(!in_string)
{
- stream.putchar('<');
+ stream.put_char('<');
string_len=0;
line_len++;
in_string=TRUE;
}
-stream.putchar( hexdigits[ n / 16 ] );
-stream.putchar( hexdigits[ n % 16 ] );
+stream.put_char( hexdigits[ n / 16 ] );
+stream.put_char( hexdigits[ n % 16 ] );
string_len++;
line_len+=2;
if(line_len > 70)
{
- stream.putchar('\n');
+ stream.put_char('\n');
line_len=0;
}
@@ -548,7 +548,7 @@
#endif
sfnts_pputBYTE(stream, 0); /* extra byte for pre-2013
compatibility */
- stream.putchar('>');
+ stream.put_char('>');
line_len++;
}
in_string=FALSE;
@@ -955,7 +955,7 @@
/* a BuildGlyph and BuildChar proceedures. */
if( font->target_type == PS_TYPE_3 )
{
- stream.putchar('\n');
+ stream.put_char('\n');
stream.putline("/BuildGlyph");
stream.putline(" {exch begin"); /* start font dictionary */
@@ -964,7 +964,7 @@
stream.putline(" true 3 1 roll get exec");
stream.putline(" end}_d");
- stream.putchar('\n');
+ stream.put_char('\n');
/* This proceedure is for compatiblity with */
/* level 1 interpreters. */
@@ -973,7 +973,7 @@
stream.putline(" 1 index /BuildGlyph get exec");
stream.putline("}_d");
- stream.putchar('\n');
+ stream.put_char('\n');
}
/* If we are generating a type 42 font, we need to check to see */
@@ -985,7 +985,7 @@
/* setup instructions and part of BuildGlyph came from. */
else if( font->target_type == PS_TYPE_42 )
{
- stream.putchar('\n');
+ stream.put_char('\n');
/* If we have no "resourcestatus" command, or FontType 42 */
/* is unknown, leave "true" on the stack. */
@@ -1066,7 +1066,7 @@
/* if the printer has no built-in TrueType */
/* rasterizer. */
stream.putline("}if");
- stream.putchar('\n');
+ stream.put_char('\n');
} /* end of if Type 42 not understood. */
stream.putline("FontName currentdict end definefont pop");
--- ttconv/pprdrv_tt2.cpp Wed Apr 29 15:10:48 2009
+++ ttconv/pprdrv_tt2.cpp Wed Apr 29 15:08:46 2009
@@ -104,7 +104,7 @@
{ /* have a log of points. */
if(stack_depth == 0)
{
- stream.putchar('{');
+ stream.put_char('{');
stack_depth=1;
}
--- ttconv/ttutil.cpp Wed Apr 29 15:04:25 2009
+++ ttconv/ttutil.cpp Wed Apr 29 15:08:46 2009
@@ -52,7 +52,7 @@
va_end(arg_list);
}
-void TTStreamWriter::putchar(int val)
+void TTStreamWriter::put_char(int val)
{
char c[2];
c[0] = (char)val;
--
Register Now & Save for Velocity, the Web Performance & Operations
Conference
Re: [matplotlib-devel] scipy conference
John Hunter wrote: > Also, we have raised a few hundred dollars in donations, so we could > either fly a worthy person out who might not otherwise be able to > attend, or pay for sprint registration for someone not getting > institutional support. Or at least provide coffee, doughnuts, pizza > and beer as fuel for participants. Fernando has also informed me > there may be some travel and conference money from other sources for > student developers so please email me us list if you are interested. > One small correction: sprints are free to attend. The only registration costs are for the tutorials and conference itself. -- Dave -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Building matplotlib on os x
Gael Varoquaux wrote: On Thu, Aug 13, 2009 at 09:30:22AM -0600, Jeff Whitaker wrote: Ariel Rokem wrote import matplotlib matplotlib.__version__ '0.98.5.2' Ariel: This tells me you really didn't install it, or you installed it in a different version of python than you are trying to import it with. So - still no version update. I ran: 'easy_install matplotlib', which somehow seems to change the path setting to find the most recent version of things (maybe someone here can tell me how this happens?) now: I am not sure that Ariel didn't install things right. He might be a victim of setuptools' monkey patching of sys.path. That depends. When doing a "python setup.py install" where setup.py's setup() function is imported from setuptools instead of distutils, then the setuptools install command deactivates any other eggs in the python environment, installs a "distutils" style install of the project in question, creates an .egg-info file in the install directory which acts just like a .egg, and finally updates the easy-install.pth in that install directory to reflect that the new install is active. If the setup.py uses the setup() function from distutils, then none of that happens and Gael is right. Any previous install of matplotlib via setuptools will go to the front of the sys.path and the new install won't be seen. -- Dave -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ 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
Replying to this, even though I replied to a later message to enthought-dev, since this one is also cc'd to matplotlib-devel Darren Dale wrote: > On Sunday 22 July 2007 02:10:50 pm John Hunter wrote: > >> 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. >> > > I just ran that command myself (9:45 EST, July 23), and it installed: > > enthought.debug-2.0b2.dev_r12984-py2.5.egg/ > enthought.developer-2.0b2.dev_r12984-py2.5.egg/ > enthought.envisage-2.0b2.dev_r12984-py2.5.egg/ > enthought.etsconfig-2.0b1.dev_r12883-py2.5.egg/ > enthought.help-2.0b2.dev_r12984-py2.5.egg/ > enthought.io-2.0b1.dev_r12810-py2.5.egg/ > enthought.logger-2.0b2.dev_r12984-py2.5.egg/ > enthought.naming-2.0b2.dev_r12810-py2.5.egg/ > enthought.plugins.text_editor-2.0b2.dev_r12984-py2.5.egg/ > enthought.pyface-2.0b2.dev_r12984-py2.5.egg/ > enthought.resource-2.0b1.dev_r12810-py2.5.egg/ > enthought.sweet_pickle-2.0b2.dev_r12810-py2.5.egg/ > enthought.traits-2.0b2.dev_r12984-py2.5-linux-x86_64.egg/ > enthought.traits.ui.wx-2.0b2.dev_r12984-py2.5.egg/ > enthought.type_manager-2.0b1.dev_r12810-py2.5.egg/ > enthought.units-2.0b2.dev_r12984-py2.5.egg/ > enthought.util-2.0b2.dev_r12981-py2.5.egg/ > :-( I validated that this is indeed the current state of things as a result of my adding in extras to the dependencies that previously existed. Looks like we'll have to delay our release to spend more time minimizing these dependencies. -- 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] Experimental, traited config module available in svn
Mike, I apologize for not reading through your script completely to test, but does this re-write the __init__.py files so that they don't declare namespace packages using pkg_resources? If you aren't doing this, then you still won't get to the time savings Fernando and I did because a significant part of the overhead was in setuptools/pkg_resources declaring namespace packages and importing from them. In fact, in Fernando's small test script using Traits, there were over 5,000 calls(!!!) to pkg_resources even when we'd de-eggified, but not de-package-namespace-ified. -- Dave Michael McLay wrote: > The attached script creates an enthought packages out of enthought > eggs. It uses symbolic links so it won't work on Windows and the eggs > need to be kept on the filesystem. I'll rework it to copy the trees > instead of just setting up symbolic links. > > On 8/18/07, Fernando Perez <[EMAIL PROTECTED]> wrote: > >> On 8/16/07, Eric Firing <[EMAIL PROTECTED]> wrote: >> >>> So, 10% slower with backend_agg, 18% slower with backend_svg. It's not >>> devastating, but it's not so great, either. >>> >>> >>>> Those results look fine to me. I dont know what has changed since we last >>>> discussed this, but when Eric brought up the speed issue I remember the >>>> traited config was significantly slower at that time. Maybe this is very >>>> good >>>> news! >>>> >>> Maybe there is some sensitivity to machine architecture; my tests were >>> on a Lenovo T60 laptop, Core2 at 2 GHz. >>> >>> For Fernando's simple_plot, using /usr/bin/time, I get: >>> 0.53user 0.11system 0:00.66elapsed without traits >>> 0.66user 0.21system 0:00.89elapsed with traits >>> >>> (The figures are quite repeatable; numbers above are representative. CPU >>> is 98% in both cases.) >>> >>> So the total time for this very simple plot (which makes it something of >>> a worst case) is more than 30% longer with traits than without, implying >>> that the startup time increase is even larger as a percentage. One >>> might argue that the difference of 0.23 seconds doesn't matter, but I >>> think it is still worth considering. Maybe it can be beaten down to a >>> small fraction of that. >>> >> Here's some interesting info. I'm sitting here with Dave Peterson, >> from Enthought, and we've done a bunch of profiling that pointed to >> setuptools, not Traits, being the culprit for the time increase. >> We've now just done an install of Traits *without* any setuptools >> (right now that requires manual surgery, but later it can be done >> automatically if needed). Here are the resulting times: >> >> # Using traits >> >> maqroll[mpl-traits-debug]> time ./simple_plot.py >> *** Using Traits!!! >> 1.844u 0.212s 0:02.13 96.2% 0+0k 0+0io 0pf+0w >> maqroll[mpl-traits-debug]> time ./simple_plot.py >> *** Using Traits!!! >> 1.840u 0.216s 0:02.58 79.4% 0+0k 0+0io 0pf+0w >> maqroll[mpl-traits-debug]> time ./simple_plot.py >> *** Using Traits!!! >> 1.836u 0.196s 0:02.12 95.2% 0+0k 0+0io 0pf+0w >> >> # NOT Using traits >> >> maqroll[mpl-traits-debug]> time ./simple_plot.py >> 2.200u 0.280s 0:02.67 92.8% 0+0k 0+0io 0pf+0w >> maqroll[mpl-traits-debug]> time ./simple_plot.py >> 2.248u 0.220s 0:02.74 89.7% 0+0k 0+0io 0pf+0w >> maqroll[mpl-traits-debug]> time ./simple_plot.py >> 2.216u 0.244s 0:02.72 90.0% 0+0k 0+0io 0pf+0w >> >> >> As you'll notice, the traits times are *lower*. This is what my gut >> told me, since I know how tight the traits code is. The point is that >> traits can actually give you a performance *benefit*, not a cost. The >> problem is with setuptools, which goes ballistic on the filesystem at >> init time. The profiles I sent earlier have already all the >> information on that, if you use kcachegrind to see it (that's how Dave >> and I pinned it down). >> >> This hopefully settles the argument on the performance side. We'll >> leave the final decision up to you guys, obviously. For IPython, this >> settles the matter and we're going with traits, with setuptools banned >> til further notice from ipython. >> >> Cheers, >> >> f >> - 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] Python novice stumped by ImportError
Darren Dale wrote: > I think we would rather make traits an external dependency, if it could be > easily installed as a separate package by a novice python user. Would it be > possible for http://code.enthought.com/projects/traits/ to list specific > instructions and links to the downloads? Or to list traits on the Python > Package Index? > We have now scheduled resources to finish the ETS refactoring that will allow us to release Traits 3, which means publishing it into PyPI. The effort won't start until next week at the earliest though. Even though I'm a bit gun-shy about doing this, I'd forecast we have Traits 3.0 officially released and on PyPI by the end of June, perhaps a week into July. -- Dave - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Enthought-dev] Python novice stumped by ImportError
Gael Varoquaux wrote: On Mon, Jun 09, 2008 at 12:04:58PM -0400, Darren Dale wrote: Gael, maybe the following situation caused the trouble: 1) user downloads mpl source 2) builds matplotlib - traits now exists in the temproary build directory 3) installs enthought traits 4) installs matplotlib - traits would not have been built in this case, its already installed on the system, but it still exists in the build directory and gets installed anyway. Actually, after looking at the code and thinking a bit more, I think the problem might simply be with different version of traits installed in different directories in the sys.path, with Python's import mechanism picking up the MPL-installed one, rather then the user-installed one. Tricky problems that I see more and more happenning. But I don't have an example box to test this hypothesis, so we are still clueless. In my experience, the current method really only falls down for those trying to publish binary distributions who don't realize the potential consequences of this build-time detection, or that there is even a decision being made there about the content of what is being built. Say, perhaps those building EPD. :-) Luckily, once you know what is going on during the build, it's a pretty easy problem to solve. That said, given the upcoming release of Traits 3 this situation may get a little crazier. T2 and T3 are not fully api compatible, though they are very close. So I suspect version numbers are going to play a larger role in the future. Is there anything we can do in the T3 release to make resolution of this upcoming issue easier to deal with for the matplotlib team? One point probably worth mentioning is that, IIRC, we currently rely on T3 being installed with egg meta-data in order to determine an accurate version number. -- Dave - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Enthought-dev] Python novice stumped by ImportError
Eric Firing wrote: > Dave Peterson wrote: > >> That said, given the upcoming release of Traits 3 this situation may >> get a little crazier. T2 and T3 are not fully api compatible, though >> they are very close. So I suspect version numbers are going to play >> a larger role in the future. Is there anything we can do in the T3 >> release to make resolution of this upcoming issue easier to deal with >> for the matplotlib team? One point probably worth mentioning is >> that, IIRC, we currently rely on T3 being installed with egg >> meta-data in order to determine an accurate version number. > > Whether, or to what extent, mpl starts depending on traits is still > open; but if we do depend on it, I think we should simply require T3 > as an external dependency. If that requires some slight modifications > of Darren's code, which was written for T2, I expect the changes will > be easy. > > Three questions: > > 1) To what extent would the range of T3 eggs cover the various > platforms on which people run mpl? Not quite sure on this one as I don't know what platforms are most used by mpl. What I can say is that we've worked very hard to minimize the dependencies Traits has on other things in order to make it as easy as possible for people to install. We'll definitely be uploading a source tarball, which should meet most people's needs, and a Windows binary (since not all users there have a c compiler.) We may or may not put up OS X, and a couple linux distribution, binaries. > 2) For uncovered cases, should T3 be easy to build and install? T3 proper needs a c compiler, gcc seems to work fine. TraitsGUI and the backend projects seem to be pure-python though clearly you'll need libs for the chosen backend. > 3) My recollection is that setuptools was determined to be causing a > hit to the startup time, and mpl is already sluggish in starting up. > Is there any more insight or progress on this front? Is there a way > to use traits in mpl without increasing the startup time? I'm not sure it was setuptools' egg features that were the problem so much as I thought it was the use of namespace packaging we have embedded all over in ETS. I don't see any significant efforts underway at this time that are trying to speed this up, but perhaps I'm just uninformed about any such efforts. I don't see anything on the horizon that would let us remove this from the ETS projects either. The end result is I don't see any way mpl could work around this and still treat Traits as an external dependency. -- Dave - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Enthought-dev] Python novice stumped by ImportError
Darren Dale wrote: On Monday 09 June 2008 04:04:47 pm Dave Peterson wrote: Eric Firing wrote: Dave Peterson wrote: That said, given the upcoming release of Traits 3 this situation may get a little crazier. T2 and T3 are not fully api compatible, though they are very close. So I suspect version numbers are going to play a larger role in the future. Is there anything we can do in the T3 release to make resolution of this upcoming issue easier to deal with for the matplotlib team? One point probably worth mentioning is that, IIRC, we currently rely on T3 being installed with egg meta-data in order to determine an accurate version number. Whether, or to what extent, mpl starts depending on traits is still open; but if we do depend on it, I think we should simply require T3 as an external dependency. If that requires some slight modifications of Darren's code, which was written for T2, I expect the changes will be easy. I think T2->T3 would not be a difficult transition for us. It may not even require any modifications, I seem to remember the traited config stuff just worked with traits3 last time I tried it, I just dont remember when I tried it last. Yes, the API breaks are not large at all. They're actually fairly small, the bulk of the effort on T3 was behind the scenes and added functionality. But there are some there so it may not be clear sailing for everyone. Three questions: 1) To what extent would the range of T3 eggs cover the various platforms on which people run mpl? Not quite sure on this one as I don't know what platforms are most used by mpl. What I can say is that we've worked very hard to minimize the dependencies Traits has on other things in order to make it as easy as possible for people to install. We'll definitely be uploading a source tarball, which should meet most people's needs, and a Windows binary (since not all users there have a c compiler.) We may or may not put up OS X, and a couple linux distribution, binaries. 2) For uncovered cases, should T3 be easy to build and install? T3 proper needs a c compiler, gcc seems to work fine. TraitsGUI and the backend projects seem to be pure-python though clearly you'll need libs for the chosen backend. 3) My recollection is that setuptools was determined to be causing a hit to the startup time, and mpl is already sluggish in starting up. Is there any more insight or progress on this front? Is there a way to use traits in mpl without increasing the startup time? I'm not sure it was setuptools' egg features that were the problem so much as I thought it was the use of namespace packaging we have embedded all over in ETS. I don't see any significant efforts underway at this time that are trying to speed this up, but perhaps I'm just uninformed about any such efforts. I don't see anything on the horizon that would let us remove this from the ETS projects either. The end result is I don't see any way mpl could work around this and still treat Traits as an external dependency. Fernando saw a big performance hit due to namespace packaging, but I never saw it. I think we concluded that the presence of large NFS mounts were causing the performance hit in namespace packages that Fernando reported at Scipy last year (Dave, was it you who worked with him?). Yes, he and I sat together in a sprint room at Scipy and refactored Traits code (and everything else using setuptools and namespace packages) until we removed it all, taking timing runs each step of the way. I'd actually be surprised if Fernando was using NSF mounts during this effort, but I don't remember asking. I do remember him pointing out how bad it *would* be for anyone using network drives to suffer through some of the API call counts we saw when using namespace packages. I did some profiling a while back also, after we added traits to the mpl codebase and stripped out the namespace packaging. We still saw something like a 30% performance hit, which I tracked back to regular expressions being compiled in traits and in configobj. See: http://thread.gmane.org/gmane.comp.python.enthought.devel/10908/focus=10989 I didn't intend to start up the root cause discussion again. :-) I only wanted to point out that I hadn't heard of anyone working on improving whatever performance problems exist / existed. -- Dave Darren - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
