On Friday 16 November 2007 04:23:41 pm Rob Hetland wrote:
> __version__ = '3.0.0b1'
>
>
> So, no version, rather __version__.
This is fixed in svn.
< traits-2: no version report (that I can find)
traits-2: version.version
traits-3: version.__version__
traits-4: stay tuned :)
Darren
On Nov 16, 2007, at 6:10 PM, Darren Dale wrote:
> Hi Rob,
>
> On Friday 16 November 2007 11:14:50 am Rob Hetland wrote:
>> Some recent changes (in the last few days) have caused my build to
>> break. Three things:
>>
>> First of all, the line in setupext.py: if version.version.endswith
>> ('m
On Friday 16 November 2007 01:46:25 pm Rob Hetland wrote:
> On Nov 16, 2007, at 6:10 PM, Darren Dale wrote:
> > Hi Rob,
> >
> > On Friday 16 November 2007 11:14:50 am Rob Hetland wrote:
> >> Some recent changes (in the last few days) have caused my build to
> >> break. Three things:
> >>
> >> Firs
Darren Dale wrote:
> I think nan's and inf's are a fact of life. They sometimes pop up in my work,
> and would prefer that matplotlib handle them properly. But I haven't
> contributed much to the actual plotting functions and don't know much about
> the advantages of masked arrays, so I'll defe
Hi Rob,
On Friday 16 November 2007 11:14:50 am Rob Hetland wrote:
> Some recent changes (in the last few days) have caused my build to
> break. Three things:
>
> First of all, the line in setupext.py: if version.version.endswith
> ('mpl'):
> fails. I can comment this block out, and set the retu
Some recent changes (in the last few days) have caused my build to
break. Three things:
First of all, the line in setupext.py: if version.version.endswith
('mpl'):
fails. I can comment this block out, and set the return of
check_provide_traits(): to True, and things seem to work well.
Se
On Thursday 15 November 2007 08:51:11 pm Eric Firing wrote:
> Darren Dale wrote:
> > On Thursday 15 November 2007 06:12:32 pm Eric Firing wrote:
> >> [EMAIL PROTECTED] wrote:
> >>> Revision: 4325
> >>>
> >>> http://matplotlib.svn.sourceforge.net/matplotlib/?rev=4325&view=rev
> >>> Author: dsdale
In any case, I think it's dangerous to set numpy's global error handling
mode permanently. Is it feasible to do this on a need-to-protect basis
by wrapping just the cases where this is needed with:
npy_orig_err = npy.seterr(invalid='ignore')
try:
do_potentially_risky_stuff()
finally:
n
