matplotlib-devel Mailing List for matplotlib

I've used:
"C-x v a" from emacs with some success in the past.
Of course this is no help at all if you're not using emacs.
>From the emacs help:
C-x v a runs the command vc-update-change-log
 which is an interactive compiled Lisp function in `vc'.
(vc-update-change-log &rest ARGS)
 
Find change log file and add entries from recent version control logs.
Normally, find log entries for all registered files in the default
directory.
 
With prefix arg of C-u, only find log entries for the current buffer's
file.
 
With any numeric prefix arg, find log entries for all currently visited
files that are under version control. This puts all the entries in the
log for the default directory, which may not be appropriate.
 
>From a program, any ARGS are assumed to be filenames for which
log entries should be gathered.
John
On Mon, 2004年03月29日 at 15:56, John Hunter wrote:
> Steve Chaplin rightly pointed out on matplotlib-users that the
> CHANGELOG is not being updated. So I'm going to make a renewed effort
> to do this, and I urge others who make CVS commits to do the same.
> 
> Is there a good way to automate this, so that the -m messages with
> commits automatically get added to the CHANGELOG, or some other trick?
> 
> JDH
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Steve Chaplin rightly pointed out on matplotlib-users that the
CHANGELOG is not being updated. So I'm going to make a renewed effort
to do this, and I urge others who make CVS commits to do the same.
Is there a good way to automate this, so that the -m messages with
commits automatically get added to the CHANGELOG, or some other trick?
JDH

On Sat, 2004年03月27日 at 16:22, John Hunter wrote:
> I just updated the image module to work with Numeric or numarray (now
> that matplotlib is the recommended 2D plotting package on the numarray
> homepage!). Changes in CVS.
> 
> The code uses the Numeric compatibility layer of numarray, but I am
> unsure how to best handle the decision of which one to build with.
> Whichever arrayobject.h you include (Numeric or numarray), the code
> works with either kind of array, so that is not the issue. But there
> will be those who want to build with numarray and vice-versa, so my
> question is how to best support this.
> 
> Here is what I am currently doing in setup.py:
> 
> # build the image support module - requires agg and Numeric or
> # numarray. You can build the image module with either Numeric or
> # numarray. Whichever way you build it, the code will work with
> # both Numeric or numarray arrays, but you will get the best
> # performance if you build with the type of array you use most
> #BUILD_IMAGE = 0 # no image support
> #BUILD_IMAGE = 'Numeric' # use Numeric 
> BUILD_IMAGE = 'numarray' # use numarray 
> 
> and then setting a precompiler macro in setupext.py which determines
> which header is used.
> 
> Another possibility is to look for a matplotlibrc file at build time
> and build according to the numerix setting. I think this is a nice
> solution but adds an extra later of complexity.
> 
> The additional (and perhaps most important) question is how to handle
> the win32 build vis-a-vis Numeric/numarray?
> 
> I ran some very rough profiling numbers. image_demo.py and
> image_demo_na.py are identical except the latter defines
> rcParams['numerix'] = 'numarray'. 
> 
> # build with Numeric
> hunter:> time python image_demo.py -dAgg
> 0.460u 0.070s 0:00.61 86.8% 0+0k 0+0io 5040pf+0w
> hunter:> time python image_demo_na.py -dAgg 
> 2.550u 0.080s 0:02.79 94.2% 0+0k 0+0io 5211pf+0w
> 
> # build with numarray
> hunter:> time python image_demo.py -dAgg
> 0.560u 0.140s 0:00.78 89.7% 0+0k 0+0io 5226pf+0w
> hunter:> time python image_demo_na.py -dAgg 
> 0.540u 0.120s 0:00.72 91.6% 0+0k 0+0io 5197pf+0w
> 
> The basic result is that numarray users pay a heavy performance price
> if the image module is built with Numeric, but if built with numarray
> both types of arrays perform comparably (and are performance
> competitive with the pure numeric case)
I'll try to find out why there's a difference here.
> 
> Finally, if any of you stsci folks on the list have a nice color image
> of the heavens you could produce with imshow, that would make a
> stellar screenshot for the website :-)
Perry probably has ideas about more appropriate images for this
application, but here is one of the coolest images I know of. (check it
out even if you don't want a jpeg):
http://imgsrc.hubblesite.org/hu/db/2004/07/images/m/formats/full_jpg.jpg
I believe the deepest optical image ever taken, The Deepest. It's
called the Hubble Ultra Deep Field (HUDF). Almost everything in the
picture are galaxies. The picture itself represents a very small region
of sky. Each little spec is billions of suns. 
Regards,
Todd
> 
> JDH
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Todd Miller <jm...@st...>