Ready whenever. I did a test 10.5 bulid a few days ago
targeting 10.4 with the latest libpng and freetype statically linked
in. All went pretty well. I'll write up build instructions similar
to yours when I go through the motions again.
- Charlie
On Nov 26, 2007, at 4:55 PM, John H
Eric Firing wrote:
> Christopher Barker wrote:
>> Not that I've used one myself, but wouldn't this be most easily
>> accomplished with a SVN commit hook
> That would be ideal, but it looks like sourceforge doesn't allow this,
> so we would have to move the project to another host.
>
> http://s
Christopher Barker wrote:
> Not that I've used one myself, but wouldn't this be most easily
> accomplished with a SVN commit hook -- i.e. whitespace would be stripped
> on every commit, rather than trying to enforce all developers setting up
> their editors correctly?
>
> -Chris
>
>
>
That
Not that I've used one myself, but wouldn't this be most easily
accomplished with a SVN commit hook -- i.e. whitespace would be stripped
on every commit, rather than trying to enforce all developers setting up
their editors correctly?
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emerg
A couple of weeks ago we talked about doing a release, but with the
deluge of changes (stix fonts, site.cfg, and others) I thought it
might be a good idea to shake the tree for bugs. I think enough time
has elapsed since these changes went in that we should proceed with
the plan to release 0.91 if
On Nov 26, 2007 3:49 PM, Christopher Barker <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I just noticed this in axes.py in SVN head, line 185:
>
> def __call__(self, *args, **kwargs):
>
> if self.axes.xaxis is not None and self.axes.xaxis is not None:
>
>
> I imagine that's supposed to ch
Hi all,
I just noticed this in axes.py in SVN head, line 185:
def __call__(self, *args, **kwargs):
if self.axes.xaxis is not None and self.axes.xaxis is not None:
I imagine that's supposed to check for xaxis and yaxis, not xaxis twice!
-Chris
--
Christopher Barker, Ph.D.
Ocea
Michael Droettboom wrote:
> Jeff Whitaker wrote:
>> Michael Droettboom wrote:
>>> Actually, this is the inverse error to the other one ;) Keeping
>>> track of which APIs are "current" is proving difficult.
>>>
>>> Try r4448... Thanks for your patience.
>>>
>>> Cheers,
>>> Mike
>>
>> Mike: That
Jeff Whitaker wrote:
> Michael Droettboom wrote:
>> Actually, this is the inverse error to the other one ;) Keeping track
>> of which APIs are "current" is proving difficult.
>>
>> Try r4448... Thanks for your patience.
>>
>> Cheers,
>> Mike
>
> Mike: That did it now, thanks!
Phew!
> Now t
Michael Droettboom wrote:
> Actually, this is the inverse error to the other one ;) Keeping track
> of which APIs are "current" is proving difficult.
>
> Try r4448... Thanks for your patience.
>
> Cheers,
> Mike
Mike: That did it now, thanks! Now trying the basemap examples, I see
that very
Actually, this is the inverse error to the other one ;) Keeping track
of which APIs are "current" is proving difficult.
Try r4448... Thanks for your patience.
Cheers,
Mike
Jeff Whitaker wrote:
> Michael Droettboom wrote:
>> Sorry. Try now (r4447). I realised I have to skip even one more lev
Michael Droettboom wrote:
> Sorry. Try now (r4447). I realised I have to skip even one more level.
>
> Cheers,
> Mike
Mike: Got a bit further this time, then hit the same error in
backend_agg.cpp:
src/backend_agg.cpp: In member function 'Py::Object
RendererAgg::draw_quad_mesh(const Py::Tuple
Sorry. Try now (r4447). I realised I have to skip even one more level.
Cheers,
Mike
Jeff Whitaker wrote:
> Michael Droettboom wrote:
>> [Jeff -- I don't know why your original e-mail never got delivered to
>> me, but I was able to see it in the archive.]
>>
>> The problem arises on platforms w
Should be fixed now.
Cheers,
Mike
John Hunter wrote:
> On Nov 26, 2007 9:48 AM, Jeff Whitaker <[EMAIL PROTECTED]> wrote:
>> Michael: I'm seeing the following error on OS X (Tiger) with numpy
>> 1.0.4 when building the latest svn transforms branch:
>
> And in mostly unrelated news, I'm seeing th
Michael Droettboom wrote:
> [Jeff -- I don't know why your original e-mail never got delivered to
> me, but I was able to see it in the archive.]
>
> The problem arises on platforms with 64-bit pointers -- in Numpy the
> datatype used to store the shape of an array is different from the
> dataty
[Jeff -- I don't know why your original e-mail never got delivered to
me, but I was able to see it in the archive.]
The problem arises on platforms with 64-bit pointers -- in Numpy the
datatype used to store the shape of an array is different from the
datatype used to specify the shape of an ar
On Nov 26, 2007 9:48 AM, Jeff Whitaker <[EMAIL PROTECTED]> wrote:
>
> Michael: I'm seeing the following error on OS X (Tiger) with numpy
> 1.0.4 when building the latest svn transforms branch:
And in mostly unrelated news, I'm seeing the following traceback on
zoom-to-rect from the toolbar in gtk
Michael: I'm seeing the following error on OS X (Tiger) with numpy
1.0.4 when building the latest svn transforms branch:
src/path.cpp: In member function 'Py::Object
_path_module::affine_transform(const Py::Tuple&)':
src/path.cpp:700: error: invalid conversion from 'npy_intp*' to 'int*'
cc1plu
Jeff Whitaker wrote:
> Vincent Schut wrote:
>> Jeff Whitaker wrote:
>>
>>
>>> There is an extra dependency on the GEOS (Geometry Engine) library
>>> (http://geos.refractions.net). The source code is included with
>>> basemap,
>>> but requires a separate ./configure; make ;make install step befor
Vincent Schut wrote:
> Jeff Whitaker wrote:
>
>
>> There is an extra dependency on the GEOS (Geometry Engine) library
>> (http://geos.refractions.net). The source code is included with basemap,
>> but requires a separate ./configure; make ;make install step before running
>> setup.py. Using th
20 matches
Mail list logo
