matplotlib-devel Mailing List for matplotlib (Page 3)

Hi,
I've been playing with matplotlib to check if it can produce graphics like:
http://www.thebuzzmedia.com/wp-content/uploads/2010/03/anandtech-nvidia-geforce-480-ati-benchmark2.png
Here is the result:
http://www.loria.fr/~rougier/tmp/benchmark.png
and the script (as attachment)
I do not know if it's worth adding it to examples ?
Nicolas

Have your changes to axes.py, namely breakx and breaky, been accepted? If
not, could you post your axes.py file.
Thanks in advance,
yuffa
klukas wrote:
> 
> I have implemented breakx and breaky methods for the Axes class and
> attached the diff for axes.py to this message.
> 
> You can test out the function with the following examples:
> ------------------
> import numpy as np
> import matplotlib as mpl
> import matplotlib.pyplot as plt
> 
> # Broken y
> fig = plt.figure()
> main_axes = plt.axes()
> plt.title('Broken x-axis example')
> plt.xlabel('x-axis label')
> subaxes = main_axes.breaky([0., 1.9, 5.1, 6.9, 9.1, 12])
> for axes in subaxes:
> axes.plot(np.linspace(0,12,13),np.linspace(0,12,13))
> plt.ylabel('y-axis label')
> plt.show()
> 
> ------------------
> import numpy as np
> import matplotlib as mpl
> import matplotlib.pyplot as plt
> # Broken x
> fig = plt.figure()
> main_axes = plt.axes()
> plt.title('Broken x-axis example')
> plt.ylabel('y-axis label')
> subaxes = main_axes.breakx([0., 1.9, 5.1, 6.9, 9.1, 12])
> for axes in subaxes:
> axes.plot(np.linspace(0,12,13),np.linspace(0,12,13))
> plt.xlabel('x-axis label')
> plt.show()
> ---------------------
> 
> I've included in the docstrings some of the TODO items, but this is
> pretty stable in its current form.
> 
> Cheers,
> Jeff
> 
> || Jeff Klukas, Research Assistant, Physics
> || University of Wisconsin -- Madison
> || jeff.klukas@gmail | jeffyklukas@aim | jeffklukas@skype
> || http://www.hep.wisc.edu/~jklukas/
> 
> 
> On Tue, Mar 16, 2010 at 1:08 PM, Jeff Klukas wrote:
>>> What would be great is if you could refactor the basic functionality
>>> into a matplotlib.Axes.breaky method (and possibly breakx but most
>>> people request a broken y axis), which would resize the "self" axes
>>> and return the broken compliment which could be plotted onto. Then
>>> you could provide a thin pyplot wrapper much like pyplot.twinx, so
>>> that pyplot as well as API users could benefit.
>>
>> I can try to do this. I think I would prefer, however, not to resize
>> the "self" axes and continue with my current approach of creating two
>> new axes within the original axes. On the user end, I think it makes
>> more sense to set the title and ylabel of the main axes, rather than
>> setting them for the individual upper and lower axes. More on that
>> below.
>>
>>>> The only real problems here is that you need to
>>>> explicitly plot things on both the upper and lower axes, and then I
>>>> haven't
>>>> figured out how to push out the y-axis label of the main axes object so
>>>> it
>>>> doesn't overlap with the tick labels of the upper and lower axes. So,
>>>> I
>>>> instead moved the y-labels of the upper and lower axes so that they
>>>> appear
>>>> at the center of the axis, but this is problematic. Any thoughts on
>>>> how to
>>>> do that part better?
>>>
>>> klukas, I'm afraid I don't understand your issue... Can you explain
>>> using it differently?
>>
>> In my approach, you end up with a main axes object that is invisible,
>> and then two visible axes objects (upper and lower) within the main
>> axes. I would ideally like to have the y label display in the middle
>> of the main y-axis, independent of where the break lies. If I place a
>> y label on the main axes (which has ticks or tick labels), though, it
>> appears right up against the axis line. I'd like it to be placed
>> further to the left, clear of the tick labels that appear on the upper
>> and lower axes. So, I'd like to be able to access whatever algorithm
>> is used to choose the offset of the axis label, and explicitly set the
>> offset of the ylabel for the main axes so that it clears the tick
>> labels.
>>
>> // Jeff
>>
> 
> 
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
-- 
View this message in context: http://old.nabble.com/Proposal-for-Broken-Axes-tp27909750p32016821.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Looks good. Does matplotlib still pass all regression tests with this 
change?
(See here for information on running the regression tests: 
http://matplotlib.sourceforge.net/devel/coding_guide.html?highlight=nosetests#testing).
Cheers,
Mike
On 07/06/2011 08:33 AM, Martin Teichmann wrote:
> Dear list,
>
> I was just trying to shear an image to be plotted with
> matplotlib (to get some snazzy 3D effect) and realized
> that it's apparently not possible. Investigating further,
> I realized that the underlying agg library indeed supports
> shearing, as it simply uses an affine matrix for its
> transforms (very much like the rest of matplotlib),
> but it does not export that feature to matplotlib.
>
> So, I just quickly added some code to actually
> access the transformation matrix in the C++ code,
> so that one can use it from within python. The next
> step would be to hook that up to the usual code used
> in matplotlib.
>
> A patch is attached at the end of this post.
>
> Greetings
>
> Martin
>
> --------------- patch follows -----------------------
>
> commit b7d0d23d90460ee790f1e94f387070a69be661c8
> Author: Martin Teichmann<martin@renoir.(none)>
> Date: Wed Jul 6 14:04:44 2011 +0200
>
> Make affine transformations work for images
>
> The current code only supports scaling and maybe rotation of
> images, but not all affine transformations, although it is
> already prepared to do so.
>
> This patch adds a method set_matrix to the C++ image handling code,
> so that one can set (and thus perform) arbitrary affine transformations.
>
> It also fixes a little bug which introduced weird side effects
> if images were resized more than once.
>
> diff --git a/src/_image.cpp b/src/_image.cpp
> index 3278b6c..7d40664 100644
> --- a/src/_image.cpp
> +++ b/src/_image.cpp
> @@ -92,7 +92,6 @@ Image::apply_rotation(const Py::Tuple& args)
>
> agg::trans_affine M = agg::trans_affine_rotation(r * agg::pi / 180.0);
> srcMatrix *= M;
> - imageMatrix *= M;
> return Py::Object();
> }
>
> @@ -156,7 +155,6 @@ Image::apply_scaling(const Py::Tuple& args)
> //printf("applying scaling %1.2f, %1.2f\n", sx, sy);
> agg::trans_affine M = agg::trans_affine_scaling(sx, sy);
> srcMatrix *= M;
> - imageMatrix *= M;
>
> return Py::Object();
> }
> @@ -179,7 +177,6 @@ Image::apply_translation(const Py::Tuple& args)
> //printf("applying translation %1.2f, %1.2f\n", tx, ty);
> agg::trans_affine M = agg::trans_affine_translation(tx, ty);
> srcMatrix *= M;
> - imageMatrix *= M;
>
> return Py::Object();
> }
> @@ -285,7 +282,6 @@ Image::reset_matrix(const Py::Tuple& args)
>
> args.verify_length(0);
> srcMatrix.reset();
> - imageMatrix.reset();
>
> return Py::Object();
> }
> @@ -316,6 +312,31 @@ Image::get_matrix(const Py::Tuple& args)
> return ret;
> }
>
> +char Image::set_matrix__doc__[] =
> + "set_matrix(m11,m21,m12,m22,m13,m23)\n"
> + "\n"
> + "Set the affine transformation matrix\n"
> + " /m11,m12,m13\\\n"
> + " /m21,m22,m23|\n"
> + " \\ 0 , 0 , 1 /"
> + ;
> +
> +Py::Object
> +Image::set_matrix(const Py::Tuple& args)
> +{
> + _VERBOSE("Image::set_matrix");
> +
> + args.verify_length(6);
> +
> + double m[6];
> + for (int i = 0;i< 6;i++)
> + {
> + m[i] = Py::Float(args[i]);
> + }
> + srcMatrix.load_from(m);
> + return Py::Object();
> +}
> +
> char Image::resize__doc__[] =
> "resize(width, height, norm=1, radius=4.0)\n"
> "\n"
> @@ -376,8 +397,7 @@ Image::resize(const Py::Tuple& args, const Py::Dict& kwargs)
>
> ras.clip_box(0, 0, numcols, numrows);
>
> - //srcMatrix *= resizingMatrix;
> - //imageMatrix *= resizingMatrix;
> + imageMatrix = srcMatrix;
> imageMatrix.invert();
> interpolator_type interpolator(imageMatrix);
>
> @@ -733,6 +753,7 @@ Image::init_type()
> add_varargs_method("get_size_out",&Image::get_size_out,
> Image::get_size_out__doc__);
> add_varargs_method("reset_matrix",&Image::reset_matrix,
> Image::reset_matrix__doc__);
> add_varargs_method("get_matrix",&Image::get_matrix,
> Image::get_matrix__doc__);
> + add_varargs_method("set_matrix",&Image::set_matrix,
> Image::set_matrix__doc__);
> add_keyword_method("resize",&Image::resize, Image::resize__doc__);
> add_varargs_method("set_interpolation",
> &Image::set_interpolation, Image::set_interpolation__doc__);
> add_varargs_method("set_resample",&Image::set_resample,
> Image::set_resample__doc__);
> diff --git a/src/_image.h b/src/_image.h
> index 8a3be54..89a923c 100644
> --- a/src/_image.h
> +++ b/src/_image.h
> @@ -34,6 +34,7 @@ public:
> Py::Object buffer_rgba(const Py::Tuple& args);
> Py::Object reset_matrix(const Py::Tuple& args);
> Py::Object get_matrix(const Py::Tuple& args);
> + Py::Object set_matrix(const Py::Tuple& args);
> Py::Object resize(const Py::Tuple& args, const Py::Dict& kwargs);
> Py::Object get_aspect(const Py::Tuple& args);
> Py::Object get_size(const Py::Tuple& args);
> @@ -105,6 +106,7 @@ private:
> static char buffer_rgba__doc__[];
> static char reset_matrix__doc__[];
> static char get_matrix__doc__[];
> + static char set_matrix__doc__[];
> static char resize__doc__[];
> static char get_aspect__doc__[];
> static char get_size__doc__[];
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Wednesday, July 6, 2011, Maximilian Trescher <fa...@tr...> wrote:
> Hi,
>
> i just committed a fix for issue #135, which is about timedelta rounding.
>
> The problem was in drange:
> before the fix it used numpy.arange which resulted in rounding issues,
> the numpy doc says about arange:
> "When using a non-integer step, such as 0.1, the results will often not
> be consistent. It is better to use linspace for these cases."
>
> So i tried to create a fix involving linspace,
> you can see it here:
> https://github.com/faucon/matplotlib/commit/06195c35f4348f37002e850d1cee992d07f5a29c
>
> it works (and is the only way i found to avoid the roundig issues) but
> it feels somehow "hackish".
>
> An alternative would be the following implementation, which is quite
> readable but much slower:
>
> def drange(dstart, dend, delta): # its very slow
>  """
>  Return a date range as float Gregorian ordinals. *dstart* and
>  *dend* are :class:`datetime` instances. *delta* is a
>  :class:`datetime.timedelta` instance.
>  """
>  dloop = dstart
>  datelist = []
>  while dloop < dend:
>    datelist.append(dloop)
>    dloop += delta
>  return dates.date2num(datelist)
>
>
> i will try to add a test the next days. Then i would create a
> pull-request if the fix looks reasonable to you.
>
> thanks,
>
> Maximilian
>
>
Thanks for patching. I haven't tested it yet, but the linspace
solution is probably the best way to go. I would avoid drange because
I believe numpy will soon be implementing such a function and I
wouldn't want the possible confusion that comes from that.
Ben Root

Dear list,
I was just trying to shear an image to be plotted with
matplotlib (to get some snazzy 3D effect) and realized
that it's apparently not possible. Investigating further,
I realized that the underlying agg library indeed supports
shearing, as it simply uses an affine matrix for its
transforms (very much like the rest of matplotlib),
but it does not export that feature to matplotlib.
So, I just quickly added some code to actually
access the transformation matrix in the C++ code,
so that one can use it from within python. The next
step would be to hook that up to the usual code used
in matplotlib.
A patch is attached at the end of this post.
Greetings
Martin
--------------- patch follows -----------------------
commit b7d0d23d90460ee790f1e94f387070a69be661c8
Author: Martin Teichmann <martin@renoir.(none)>
Date: Wed Jul 6 14:04:44 2011 +0200
 Make affine transformations work for images
 The current code only supports scaling and maybe rotation of
 images, but not all affine transformations, although it is
 already prepared to do so.
 This patch adds a method set_matrix to the C++ image handling code,
 so that one can set (and thus perform) arbitrary affine transformations.
 It also fixes a little bug which introduced weird side effects
 if images were resized more than once.
diff --git a/src/_image.cpp b/src/_image.cpp
index 3278b6c..7d40664 100644
--- a/src/_image.cpp
+++ b/src/_image.cpp
@@ -92,7 +92,6 @@ Image::apply_rotation(const Py::Tuple& args)
 agg::trans_affine M = agg::trans_affine_rotation(r * agg::pi / 180.0);
 srcMatrix *= M;
- imageMatrix *= M;
 return Py::Object();
 }
@@ -156,7 +155,6 @@ Image::apply_scaling(const Py::Tuple& args)
 //printf("applying scaling %1.2f, %1.2f\n", sx, sy);
 agg::trans_affine M = agg::trans_affine_scaling(sx, sy);
 srcMatrix *= M;
- imageMatrix *= M;
 return Py::Object();
 }
@@ -179,7 +177,6 @@ Image::apply_translation(const Py::Tuple& args)
 //printf("applying translation %1.2f, %1.2f\n", tx, ty);
 agg::trans_affine M = agg::trans_affine_translation(tx, ty);
 srcMatrix *= M;
- imageMatrix *= M;
 return Py::Object();
 }
@@ -285,7 +282,6 @@ Image::reset_matrix(const Py::Tuple& args)
 args.verify_length(0);
 srcMatrix.reset();
- imageMatrix.reset();
 return Py::Object();
 }
@@ -316,6 +312,31 @@ Image::get_matrix(const Py::Tuple& args)
 return ret;
 }
+char Image::set_matrix__doc__[] =
+ "set_matrix(m11,m21,m12,m22,m13,m23)\n"
+ "\n"
+ "Set the affine transformation matrix\n"
+ " /m11,m12,m13\\\n"
+ " /m21,m22,m23|\n"
+ " \\ 0 , 0 , 1 /"
+ ;
+
+Py::Object
+Image::set_matrix(const Py::Tuple& args)
+{
+ _VERBOSE("Image::set_matrix");
+
+ args.verify_length(6);
+
+ double m[6];
+ for (int i = 0;i < 6;i++)
+ {
+ m[i] = Py::Float(args[i]);
+ }
+ srcMatrix.load_from(m);
+ return Py::Object();
+}
+
 char Image::resize__doc__[] =
 "resize(width, height, norm=1, radius=4.0)\n"
 "\n"
@@ -376,8 +397,7 @@ Image::resize(const Py::Tuple& args, const Py::Dict& kwargs)
 ras.clip_box(0, 0, numcols, numrows);
- //srcMatrix *= resizingMatrix;
- //imageMatrix *= resizingMatrix;
+ imageMatrix = srcMatrix;
 imageMatrix.invert();
 interpolator_type interpolator(imageMatrix);
@@ -733,6 +753,7 @@ Image::init_type()
 add_varargs_method("get_size_out", &Image::get_size_out,
Image::get_size_out__doc__);
 add_varargs_method("reset_matrix", &Image::reset_matrix,
Image::reset_matrix__doc__);
 add_varargs_method("get_matrix", &Image::get_matrix,
Image::get_matrix__doc__);
+ add_varargs_method("set_matrix", &Image::set_matrix,
Image::set_matrix__doc__);
 add_keyword_method("resize", &Image::resize, Image::resize__doc__);
 add_varargs_method("set_interpolation",
&Image::set_interpolation, Image::set_interpolation__doc__);
 add_varargs_method("set_resample", &Image::set_resample,
Image::set_resample__doc__);
diff --git a/src/_image.h b/src/_image.h
index 8a3be54..89a923c 100644
--- a/src/_image.h
+++ b/src/_image.h
@@ -34,6 +34,7 @@ public:
 Py::Object buffer_rgba(const Py::Tuple& args);
 Py::Object reset_matrix(const Py::Tuple& args);
 Py::Object get_matrix(const Py::Tuple& args);
+ Py::Object set_matrix(const Py::Tuple& args);
 Py::Object resize(const Py::Tuple& args, const Py::Dict& kwargs);
 Py::Object get_aspect(const Py::Tuple& args);
 Py::Object get_size(const Py::Tuple& args);
@@ -105,6 +106,7 @@ private:
 static char buffer_rgba__doc__[];
 static char reset_matrix__doc__[];
 static char get_matrix__doc__[];
+ static char set_matrix__doc__[];
 static char resize__doc__[];
 static char get_aspect__doc__[];
 static char get_size__doc__[];

Hi,
i just committed a fix for issue #135, which is about timedelta rounding.
The problem was in drange:
before the fix it used numpy.arange which resulted in rounding issues,
the numpy doc says about arange:
"When using a non-integer step, such as 0.1, the results will often not
be consistent. It is better to use linspace for these cases."
So i tried to create a fix involving linspace,
you can see it here:
https://github.com/faucon/matplotlib/commit/06195c35f4348f37002e850d1cee992d07f5a29c
it works (and is the only way i found to avoid the roundig issues) but
it feels somehow "hackish".
An alternative would be the following implementation, which is quite
readable but much slower:
def drange(dstart, dend, delta): # its very slow
 """
 Return a date range as float Gregorian ordinals. *dstart* and
 *dend* are :class:`datetime` instances. *delta* is a
 :class:`datetime.timedelta` instance.
 """
 dloop = dstart
 datelist = []
 while dloop < dend:
 datelist.append(dloop)
 dloop += delta
 return dates.date2num(datelist)
i will try to add a test the next days. Then i would create a
pull-request if the fix looks reasonable to you.
thanks,
Maximilian

On 07/04/2011 09:42 PM, Eric Firing wrote:
>
> I updated mpl pull request #390 and added ipython pull request #550 with
That should have been ipython pull request #556.
Eric

On 07/04/2011 06:51 PM, MinRK wrote:
> On Mon, Jul 4, 2011 at 20:57, Eric Firing<ef...@ha...> wrote:
>> On 07/04/2011 04:26 PM, Darren Dale wrote:
>>> On Mon, Jul 4, 2011 at 9:17 PM, Fernando Perez<fpe...@gm...> wrote:
>>>> Hi folks,
>>>>
>>>> Eric Firing, Darren Dale and others in the MPL team are trying to work
>>>> out the Qt API selection issues after our own updates, but there are
>>>> some technical questions in there that require more knowledge about Qt
>>>> than I have. The MPL pull request is:
>>>>
>>>> https://github.com/matplotlib/matplotlib/pull/390
>>>>
>>>> which follows our own recent changes:
>>>>
>>>> https://github.com/ipython/ipython/pull/550#issuecomment-1490217
>>>>
>>>> Evan has already done the lion's share of the work on this topic, but
>>>> I figured I'd ping the list in case someone else can also jump in,
>>>> since I myself am kind of useless on the details of Qt itself.
>>>
>>> Note that this is probably not specific to matplotlib, but rather
>>> IPython's qt gui support. IPython.external.qt is setting the sip api
>>> level for PyQt4 to api version 2. Version 2 is not the default for
>>> python-2, which means that ipython would not be able to run PyQt4 apps
>>> or scripts that use QString or QVariant, both of which are officially
>>> supported in the default PyQt4 api. It will impact a lot of users and
>>> a lot of projects.
>>
>> Reference:
>>
>> http://developer.qt.nokia.com/wiki/Differences_Between_PySide_and_PyQt
>>
>> It seems that the mpl qt4 backend works with Version 1 or 2 (and with
>> PyQt4 or PySide) given just a little bit of compatibility shimming. If
>> ipython can similarly get by with a few shims, so that it does not need
>> to set the Version, then the problem is solved once those shims are
>> identified and installed.
>>
>> If I remove the version-setting from qt.py, then ipython still works
>> with mpl and PyQt4 via "ipython pylab=qt", but it does not work with
>> qtconsole or with PySide.
>
> I don't think we are going to rewrite the whole qtconsole to support
> version 1 for 0.11 this week. What we can do is change the default
> behavior in qt_for_kernel,
> (https://github.com/ipython/ipython/blob/master/IPython/external/qt_for_kernel.py)
> which is where code that interacts with other applications gets
> imported. Currently, we use our v2 import unless matplotlib<= 1.0.1
> is detected. However, we can change that default to be more
> conservative. User code (e.g. matplotlib code, integration with other
> apps) is not in the same process as the QtConsole, so we can have v1
> code in the kernel with v2 in the frontend.
I updated mpl pull request #390 and added ipython pull request #550 with 
a strawman plan based on mpl rcParams. A quick test indicates that it 
makes qtconsole work with pylab=qt with either PyQt4 or PySide selected 
in mpl, and it also works with the ipython console with PyQt4, but not 
with PySide. I don't know why the latter does not work.
Eric
>
> -MinRK
>
>>
>> Eric
>> _______________________________________________
>> IPython-dev mailing list
>> IPy...@sc...
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>

On Mon, Jul 4, 2011 at 2:31 PM, Eric Firing <ef...@ha...> wrote:
> See https://github.com/matplotlib/matplotlib/pull/390.
>
Excellent, thanks! Ran tests and commented on the PR.
Cheers,
f

On 07/02/2011 12:21 PM, Fernando Perez wrote:
> Hi folks,
>
> as indicated here:
>
> https://github.com/ipython/ipython/pull/550#issuecomment-1490217
>
> our Qt-handling logic has recently changed a little bit, so it would
> be great if on the mpl side things could be updated to match the
> current code. If nobody has time to do it I can look into making a
> PR, but I'm pretty swamped for the next couple of weeks so it won't
> happen right away... This should be an easy fix though.
>
> Feel free to ping us if there are any questions.
>
> Thanks!
>
> f
See https://github.com/matplotlib/matplotlib/pull/390.
Eric
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi folks,
as indicated here:
https://github.com/ipython/ipython/pull/550#issuecomment-1490217
our Qt-handling logic has recently changed a little bit, so it would
be great if on the mpl side things could be updated to match the
current code. If nobody has time to do it I can look into making a
PR, but I'm pretty swamped for the next couple of weeks so it won't
happen right away... This should be an easy fix though.
Feel free to ping us if there are any questions.
Thanks!
f

On 07/02/2011 02:37 AM, Xavier Gnata wrote:
> Hi,
>
> I'm use to compile the mpl git tree but I get an error with the current one:
>
>
> running build_ext
> building 'matplotlib.backends._tkagg' extension
> C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2
> -Wall -fPIC
>
> compile options: '-DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API
> -DPYCXX_ISO_CPP_LIB=1 -I/usr/include/tcl8.5
> -I/usr/include/tcl8.5 -I/usr/local/include -I/usr/include -I.
> -I/usr/local/lib/python2.7/dist-packages/numpy/core/include -Isrc
> -Iagg24/include -I.
> -I/usr/local/lib/python2.7/dist-packages/numpy/core/include
> -I/usr/include/freetype2 -I/usr/local/include -I/usr/include -I.
> -I/usr/include/python2.7 -c'
> gcc: CXX/cxxextensions.c
> gcc: no input files
> sh: -I/usr/include/tcl8.5: not found
> gcc: no input files
> sh: -I/usr/include/tcl8.5: not found
> error: Command "gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv
> -O2 -Wall -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API
> -DPYCXX_ISO_CPP_LIB=1 -I/usr/include/tcl8.5
> -I/usr/include/tcl8.5 -I/usr/local/include -I/usr/include -I.
> -I/usr/local/lib/python2.7/dist-packages/numpy/core/include -Isrc
> -Iagg24/include -I.
> -I/usr/local/lib/python2.7/dist-packages/numpy/core/include
> -I/usr/include/freetype2 -I/usr/local/include -I/usr/include -I.
> -I/usr/include/python2.7 -c CXX/cxxextensions.c -o
> build/temp.linux-x86_64-2.7/CXX/cxxextensions.o" failed with exit status 127
>
> Is it a known issue?
This is now fixed by 984d83ed9 in v1.0.x-maint and master.
Eric
>
> Xavier

On 07/02/2011 02:37 AM, Xavier Gnata wrote:
> Hi,
>
> I'm use to compile the mpl git tree but I get an error with the current one:
>
>
> running build_ext
> building 'matplotlib.backends._tkagg' extension
> C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2
> -Wall -fPIC
>
> compile options: '-DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API
> -DPYCXX_ISO_CPP_LIB=1 -I/usr/include/tcl8.5
> -I/usr/include/tcl8.5 -I/usr/local/include -I/usr/include -I.
> -I/usr/local/lib/python2.7/dist-packages/numpy/core/include -Isrc
> -Iagg24/include -I.
> -I/usr/local/lib/python2.7/dist-packages/numpy/core/include
> -I/usr/include/freetype2 -I/usr/local/include -I/usr/include -I.
> -I/usr/include/python2.7 -c'
> gcc: CXX/cxxextensions.c
> gcc: no input files
> sh: -I/usr/include/tcl8.5: not found
> gcc: no input files
> sh: -I/usr/include/tcl8.5: not found
> error: Command "gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv
> -O2 -Wall -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API
> -DPYCXX_ISO_CPP_LIB=1 -I/usr/include/tcl8.5
> -I/usr/include/tcl8.5 -I/usr/local/include -I/usr/include -I.
> -I/usr/local/lib/python2.7/dist-packages/numpy/core/include -Isrc
> -Iagg24/include -I.
> -I/usr/local/lib/python2.7/dist-packages/numpy/core/include
> -I/usr/include/freetype2 -I/usr/local/include -I/usr/include -I.
> -I/usr/include/python2.7 -c CXX/cxxextensions.c -o
> build/temp.linux-x86_64-2.7/CXX/cxxextensions.o" failed with exit status 127
>
> Is it a known issue?
No. It looks like a spurious newline is getting into the command 
string. I see it on my linux system, but for me it is not having any 
effect on the compilation--I don't know why not.
Definitely a bug, probably associated with the most recent attempts to 
navigate the ever-changing waters of Tk/Tcl installations.
Eric
>
> Xavier
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi,
I'm use to compile the mpl git tree but I get an error with the current one:
running build_ext
building 'matplotlib.backends._tkagg' extension
C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 
-Wall -fPIC
compile options: '-DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API 
-DPYCXX_ISO_CPP_LIB=1 -I/usr/include/tcl8.5
 -I/usr/include/tcl8.5 -I/usr/local/include -I/usr/include -I. 
-I/usr/local/lib/python2.7/dist-packages/numpy/core/include -Isrc 
-Iagg24/include -I. 
-I/usr/local/lib/python2.7/dist-packages/numpy/core/include 
-I/usr/include/freetype2 -I/usr/local/include -I/usr/include -I. 
-I/usr/include/python2.7 -c'
gcc: CXX/cxxextensions.c
gcc: no input files
sh: -I/usr/include/tcl8.5: not found
gcc: no input files
sh: -I/usr/include/tcl8.5: not found
error: Command "gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv 
-O2 -Wall -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API 
-DPYCXX_ISO_CPP_LIB=1 -I/usr/include/tcl8.5
 -I/usr/include/tcl8.5 -I/usr/local/include -I/usr/include -I. 
-I/usr/local/lib/python2.7/dist-packages/numpy/core/include -Isrc 
-Iagg24/include -I. 
-I/usr/local/lib/python2.7/dist-packages/numpy/core/include 
-I/usr/include/freetype2 -I/usr/local/include -I/usr/include -I. 
-I/usr/include/python2.7 -c CXX/cxxextensions.c -o 
build/temp.linux-x86_64-2.7/CXX/cxxextensions.o" failed with exit status 127
Is it a known issue?
Xavier