Re: [matplotlib-devel] matplotlib build options
On Monday 12 November 2007 06:39:28 pm Darren Dale wrote: > On Monday 12 November 2007 05:52:55 pm John Hunter wrote: > > On Nov 12, 2007 4:09 PM, Darren Dale <[EMAIL PROTECTED]> wrote: > > > I have been updating the logic in our setup.py and setupext.py files, > > > so all of the build options are now exposed in setup.cfg. This should > > > make it easier for anyone wishing to distribute matplotlib, like > > > package managers. See setup.cfg.template for the details. > > > > I just did a clean build and it went through -- a good start! I tried > > enabling the new config with by setting NEWCONFIG = True in > > __init__.py, and also enabled in setup.cfg I altered mplconfig to create a matplotlib.conf.template file, which gets read and modified at build time like we do with matplotlibrc.template. It's not as elegant as using the config package machinery to create the default config file at build time, but I think this will serve our needs. Devs still need to execute mplconfig.py when we make changes that would affect the default config file. I also updated the selection of the default backend at build time: SVG -> Agg -> TkAgg -> WXAgg -> GTK -> GTKAagg -> selection in setup.cfg committed in svn-4242. 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] matplotlib build options
On Nov 13, 2007 8:01 AM, Darren Dale <[EMAIL PROTECTED]> wrote:
> On Monday 12 November 2007 06:39:28 pm Darren Dale wrote:
> > On Monday 12 November 2007 05:52:55 pm John Hunter wrote:
> > > On Nov 12, 2007 4:09 PM, Darren Dale <[EMAIL PROTECTED]> wrote:
> > > > I have been updating the logic in our setup.py and setupext.py files,
> > > > so all of the build options are now exposed in setup.cfg. This should
> > > > make it easier for anyone wishing to distribute matplotlib, like
> > > > package managers. See setup.cfg.template for the details.
> > >
> > > I just did a clean build and it went through -- a good start! I tried
> > > enabling the new config with by setting NEWCONFIG = True in
> > > __init__.py, and also enabled in setup.cfg
>
> I altered mplconfig to create a matplotlib.conf.template file, which gets read
> and modified at build time like we do with matplotlibrc.template. It's not as
> elegant as using the config package machinery to create the default config
> file at build time, but I think this will serve our needs. Devs still need to
> execute mplconfig.py when we make changes that would affect the default
> config file.
>
> I also updated the selection of the default backend at build time:
>
> SVG -> Agg -> TkAgg -> WXAgg -> GTK -> GTKAagg -> selection in setup.cfg
I'm not sure we need GTK in that pipeline, since its future status is
in question and I think we'd rather have someone on tkagg or wxagg
than plain vanilla gtk.
I think in the autogen of matplotlib.conf, there are a few things you
could do to make the file much more readable.
* for the enumeration of options, print
# 'bilinear' or 'nearest' or 'bicubic' or 'spline16' or 'spline36' or 'hanni
# ng' or 'hamming' or 'hermite' or 'kaiser' or 'quadric' or 'catrom' or 'gau
# ssian' or 'bessel' or 'mitchell' or 'sinc' or 'lanczos' or 'blackman'
like
# bilinear | nearest | bicubic | spline16
* For floating point numbers, use a str converter rather than a repr
converter, eg '%s'
In [4]: '%s'%0.1
Out[4]: '0.1'
In [5]: '%r'%0.1
Out[5]: '0.10001'
* I think your wrap algorithm is breaking in the middle of words. You
might look at cbook.wrap
In [15]: s = 'A regular expression used to determine the amount of
space to remove. It looks for the first sequence of spaces
immediately following the first newline, or at the beginning of the
string.'
In [16]: print cbook.wrap('', s, 76)
A regular expression used to determine the amount of space to remove. It
looks for the first sequence of spaces immediately following the first
newline, or at the beginning of the string.
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] matplotlib build options
On Tuesday 13 November 2007 09:30:52 am John Hunter wrote:
> On Nov 13, 2007 8:01 AM, Darren Dale <[EMAIL PROTECTED]> wrote:
> > On Monday 12 November 2007 06:39:28 pm Darren Dale wrote:
> > > On Monday 12 November 2007 05:52:55 pm John Hunter wrote:
> > > > On Nov 12, 2007 4:09 PM, Darren Dale <[EMAIL PROTECTED]> wrote:
> > > > > I have been updating the logic in our setup.py and setupext.py
> > > > > files, so all of the build options are now exposed in setup.cfg.
> > > > > This should make it easier for anyone wishing to distribute
> > > > > matplotlib, like package managers. See setup.cfg.template for the
> > > > > details.
> > > >
> > > > I just did a clean build and it went through -- a good start! I
> > > > tried enabling the new config with by setting NEWCONFIG = True in
> > > > __init__.py, and also enabled in setup.cfg
> >
> > I altered mplconfig to create a matplotlib.conf.template file, which gets
> > read and modified at build time like we do with matplotlibrc.template.
> > It's not as elegant as using the config package machinery to create the
> > default config file at build time, but I think this will serve our needs.
> > Devs still need to execute mplconfig.py when we make changes that would
> > affect the default config file.
> >
> > I also updated the selection of the default backend at build time:
> >
> > SVG -> Agg -> TkAgg -> WXAgg -> GTK -> GTKAagg -> selection in setup.cfg
>
> I'm not sure we need GTK in that pipeline, since its future status is
> in question and I think we'd rather have someone on tkagg or wxagg
> than plain vanilla gtk.
Done.
> I think in the autogen of matplotlib.conf, there are a few things you
> could do to make the file much more readable.
>
> * for the enumeration of options, print
>
> # 'bilinear' or 'nearest' or 'bicubic' or 'spline16' or 'spline36' or
> 'hanni # ng' or 'hamming' or 'hermite' or 'kaiser' or 'quadric' or 'catrom'
> or 'gau # ssian' or 'bessel' or 'mitchell' or 'sinc' or 'lanczos' or
> 'blackman'
>
> like
>
> # bilinear | nearest | bicubic | spline16
That is a good suggestion. However, most of the formatting is done under the
hood, by the Traits package itself. It looks like the logic is spread out
over traits code so it won't be easy to subclass and override the default
behavior.
However, when we define our own trait handlers, like we do with BackendHandler
and BoolHandler, we define an "info" method which controls the formatting. If
we end up committing to using Traits, and we started adding more complex
validation and notification, etc., I think that would be the time to add
additional TraitHandlers to improve the formatting.
> * For floating point numbers, use a str converter rather than a repr
> converter, eg '%s'
>
> In [4]: '%s'%0.1
> Out[4]: '0.1'
>
> In [5]: '%r'%0.1
> Out[5]: '0.10001'
This is also dictated by Traits.
I'll have to think some more about formatting. Right now, its not obvious to
me that there is a simple solution, aside from defining TraitHandlers.
> * I think your wrap algorithm is breaking in the middle of words. You
> might look at cbook.wrap
>
> In [15]: s = 'A regular expression used to determine the amount of
> space to remove. It looks for the first sequence of spaces
> immediately following the first newline, or at the beginning of the
> string.'
>
> In [16]: print cbook.wrap('', s, 76)
> A regular expression used to determine the amount of space to remove.
> It looks for the first sequence of spaces immediately following the first
> newline, or at the beginning of the string.
Thank you for noticing this, and for pointing out the solution in cbook. I
updated tconfig in our repository and in ipython1.
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
[matplotlib-devel] small patch for axes.specgram
Hello,
This is fairly minor, but I'd wonder if you'd consider including it.
It adds an optional Fc parameter to the specgram method of the Axes
class, and makes the calculation of the extent a bit more efficient.
Also, a quick fix for mlab.py.
Thank you,
Glen Mabey
*** zipsrc/matplotlib-20071113_svn/lib/matplotlib/axes.py 2007-11-13 13:13:03.0 -0600
--- /usr/local/tmp/axes.py 2007-11-13 16:08:13.0 -0600
***
*** 5035,5045
return cxy, freqs
cohere.__doc__ = cbook.dedent(cohere.__doc__) % martist.kwdocd
! def specgram(self, x, NFFT=256, Fs=2, detrend=mlab.detrend_none,
window=mlab.window_hanning, noverlap=128,
cmap = None, xextent=None):
"""
! SPECGRAM(x, NFFT=256, Fs=2, detrend=mlab.detrend_none,
window = mlab.window_hanning, noverlap=128,
cmap=None, xextent=None)
--- 5035,5045
return cxy, freqs
cohere.__doc__ = cbook.dedent(cohere.__doc__) % martist.kwdocd
! def specgram(self, x, NFFT=256, Fs=2, Fc=0, detrend=mlab.detrend_none,
window=mlab.window_hanning, noverlap=128,
cmap = None, xextent=None):
"""
! SPECGRAM(x, NFFT=256, Fs=2, Fc=0, detrend=mlab.detrend_none,
window = mlab.window_hanning, noverlap=128,
cmap=None, xextent=None)
***
*** 5050,5055
--- 5050,5060
* cmap is a colormap; if None use default determined by rc
+ * Fc is the center frequency of x (defaults to 0), which offsets
+ the yextents of the image to reflect the frequency range used
+ when a signal is acquired and then filtered and downsampled to
+ baseband.
+
* xextent is the image extent in the xaxes xextent=xmin, xmax -
default 0, max(bins), 0, max(freqs) where bins is the return
value from mlab.specgram
***
*** 5081,5087
if xextent is None: xextent = 0, npy.amax(bins)
xmin, xmax = xextent
! extent = xmin, xmax, npy.amin(freqs), npy.amax(freqs)
im = self.imshow(Z, cmap, extent=extent)
self.axis('auto')
--- 5086,5093
if xextent is None: xextent = 0, npy.amax(bins)
xmin, xmax = xextent
! freqs += Fc
! extent = xmin, xmax, freqs[0], freqs[-1]
im = self.imshow(Z, cmap, extent=extent)
self.axis('auto')
*** zipsrc/matplotlib-20071113_svn/lib/matplotlib/mlab.py 2007-11-13 16:14:22.0 -0600
--- /usr/local/stow/matplotlib-20071113_svn-py2.5/lib/python2.5/site-packages/matplotlib/mlab.py 2007-11-13 16:17:41.0 -0600
***
*** 353,359
# zero pad x up to NFFT if it is shorter than NFFT
if len(x)-
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
