headers
Nils Wagner | 1 Aug 09:16
Picon
Favicon

Cannot build matplotlib from latest svn

Hi all,

I cannot build matplotlib from latest svn. I am using SuSE Linux 10.0 on
x86_64.

  python setup.py install
============================================================================
BUILDING MATPLOTLIB
            matplotlib: 0.90.1 (r3634)
              platform: linux2

REQUIRED DEPENDENCIES
                 numpy: 1.0.4.dev3937
             freetype2: 9.8.3

OPTIONAL DEPENDENCIES
Traceback (most recent call last):
  File "setup.py", line 223, in ?
    if check_for_gtk() and (BUILD_GTK or BUILD_GTKAGG):
  File "/usr/local/svn/matplotlib/setupext.py", line 411, in check_for_gtk
    print_status("Gtk+", "gtk+: %s, glib: %s, pygtk: %s, pygobject: %s" %
AttributeError: 'module' object has no attribute 'pygobject_version'

Nils

-------------------------------------------------------------------------
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/
(Continue reading)

Permalink | Reply | 2 comments |
headers
Michael Droettboom | 1 Aug 14:21

Re: Cannot build matplotlib from latest svn

I suspect you're running an earlier version of pygtk than I am that 
doesn't have pygobject_version.

Please update matplotlib and try again.

Thanks for finding this bug.

Cheers,
Mike

Nils Wagner wrote:
> Hi all,
>
> I cannot build matplotlib from latest svn. I am using SuSE Linux 10.0 on
> x86_64.
>
>   python setup.py install
> ============================================================================
> BUILDING MATPLOTLIB
>             matplotlib: 0.90.1 (r3634)
>               platform: linux2
>
> REQUIRED DEPENDENCIES
>                  numpy: 1.0.4.dev3937
>              freetype2: 9.8.3
>
> OPTIONAL DEPENDENCIES
> Traceback (most recent call last):
>   File "setup.py", line 223, in ?
>     if check_for_gtk() and (BUILD_GTK or BUILD_GTKAGG):
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nils Wagner | 1 Aug 14:29
Picon
Favicon

Re: Cannot build matplotlib from latest svn

Michael Droettboom wrote:
> I suspect you're running an earlier version of pygtk than I am that
> doesn't have pygobject_version.
>
> Please update matplotlib and try again.
>
> Thanks for finding this bug.
>
> Cheers,
> Mike
>
> Nils Wagner wrote:
>> Hi all,
>>
>> I cannot build matplotlib from latest svn. I am using SuSE Linux 10.0 on
>> x86_64.
>>
>>   python setup.py install
>> ============================================================================
>>
>> BUILDING MATPLOTLIB
>>             matplotlib: 0.90.1 (r3634)
>>               platform: linux2
>>
>> REQUIRED DEPENDENCIES
>>                  numpy: 1.0.4.dev3937
>>              freetype2: 9.8.3
>>
>> OPTIONAL DEPENDENCIES
>> Traceback (most recent call last):
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Firing | 1 Aug 20:14
Favicon
Gravatar

Profiling. was Re: Experimental, traited config module available in svn

Fernando,

Here is some more information about profiling that others may find useful:

1) The profile module reports times that are much longer than normal; I 
don't know to what extent the relative times are still correct; my 
impression is that they do still give a decent idea of where the 
bottlenecks and resource hogs are.

2) The combination of hotshot and hotshot2calltree (or similar) gets 
badly confused by duplicate function names such as __init__, so the 
kcachegrind view can be quite misleading.

3) A solution is to use the cProfile module in Python 2.5 with an 
appropriate reformatter.  The following script runs a python script 
through cProfile and generates a *.log file that kcachegrind reads:

http://www.gnome.org/~johan/lsprofcalltree.py

So the sequence is simply

python lsprofcalltree.py testscript.py
kcachegrind testscript.py.log &

Here are a couple of relevant Google results:

https://lists.dulug.duke.edu/pipermail/yum-devel/2007-January/003045.html
http://ddaa.net/blog/python/lsprof-calltree

Eric
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Droettboom | 2 Aug 16:31

Re: Mathtext improvements (merging into trunk)

I don't know if we ever reached consensus on how to specify math text 
vs. regular text.  I agree with Eric that it's down to two options: 
using a new kw argument (probably format="math" to be most future-proof) 
or Math('string').  I don't think I have enough "historical perspective" 
to really make the call but I do have a concern about the second option 
that it may be confusing depending on how "Math" is imported.  (It may 
have to be pylab.Math in some instances but not in others.)  But I don't 
have a strong objection.

Any last objections to going with the new keyword argument?

Cheers,
Mike

Eric Firing wrote:
> That leaves some variant of 2 [a keyword argument] and the Math('string') idea.  I find the 
> latter quite pythonic; it is a very concise, readable, and general way 
> of attaching extra information to a string object, and it does not 
> require passing yet another kwarg through a sequence of function and 
> method calls.  But if it is judged to be too out-of-character with the 
> rest of the mpl api, or if in practice it would cause trouble that I 
> don't see yet, then I am happy to let it go.  I have not thought it 
> through carefully, and I am not attached to it.
>
> If a variant of 2 is chosen, one might shorten the kwarg to "math".  Or 
> use "format='math'" or something like that.  This is more flexible than 
> a boolean kwarg, leaving the door open to additional options for 
> interpretation of strings--but not quite as flexible and powerful as the 
> math('string') idea.
>
(Continue reading)

Permalink | Reply | 10 comments |
headers
John Hunter | 2 Aug 16:42
Picon
Gravatar

Re: Mathtext improvements (merging into trunk)

On 8/2/07, Michael Droettboom <mdroe@...> wrote:
> I don't know if we ever reached consensus on how to specify math text
> vs. regular text.  I agree with Eric that it's down to two options:
> using a new kw argument (probably format="math" to be most future-proof)
> or Math('string').  I don't think I have enough "historical perspective"
> to really make the call but I do have a concern about the second option
> that it may be confusing depending on how "Math" is imported.  (It may
> have to be pylab.Math in some instances but not in others.)  But I don't
> have a strong objection.
>
> Any last objections to going with the new keyword argument?

I'm +1 on the kwarg approach -- it seems most consistent with our other usage.

-------------------------------------------------------------------------
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/
Permalink | Reply | 4 comments |
headers
Darren Dale | 2 Aug 17:02
Picon
Favicon

Re: Mathtext improvements (merging into trunk)

On Thursday 02 August 2007 10:42:17 am John Hunter wrote:
> On 8/2/07, Michael Droettboom <mdroe@...> wrote:
> > I don't know if we ever reached consensus on how to specify math text
> > vs. regular text.  I agree with Eric that it's down to two options:
> > using a new kw argument (probably format="math" to be most future-proof)
> > or Math('string').  I don't think I have enough "historical perspective"
> > to really make the call but I do have a concern about the second option
> > that it may be confusing depending on how "Math" is imported.  (It may
> > have to be pylab.Math in some instances but not in others.)  But I don't
> > have a strong objection.
> >
> > Any last objections to going with the new keyword argument?
>
> I'm +1 on the kwarg approach -- it seems most consistent with our other
> usage.

Maybe the keyword should be format="TeX"? Or texformatting=True? Maybe it 
would be appropriate to have the kwarg default to None, and if None reference 
an rcoption like text.texformatting? That might be the least disruptive all 
around.

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/
Permalink | Reply | 3 comments |
headers
Michael Droettboom | 2 Aug 17:03

Re: Mathtext improvements (merging into trunk)

Darren Dale wrote:
> On Thursday 02 August 2007 10:42:17 am John Hunter wrote:
>   
>> On 8/2/07, Michael Droettboom <mdroe@...> wrote:
>>     
>>> I don't know if we ever reached consensus on how to specify math text
>>> vs. regular text.  I agree with Eric that it's down to two options:
>>> using a new kw argument (probably format="math" to be most future-proof)
>>> or Math('string').  I don't think I have enough "historical perspective"
>>> to really make the call but I do have a concern about the second option
>>> that it may be confusing depending on how "Math" is imported.  (It may
>>> have to be pylab.Math in some instances but not in others.)  But I don't
>>> have a strong objection.
>>>
>>> Any last objections to going with the new keyword argument?
>>>       
>> I'm +1 on the kwarg approach -- it seems most consistent with our other
>> usage.
>>     
>
> Maybe the keyword should be format="TeX"? Or texformatting=True? Maybe it 
> would be appropriate to have the kwarg default to None, and if None reference 
> an rcoption like text.texformatting? That might be the least disruptive all 
> around.
>   
I think format="TeX" may be a bit misleading, since it uses something 
TeX-like, but not really TeX (as the usetex stuff does).  That said, I 
don't really have a better suggestion ;)

The idea also is that in the future this could support other values,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Darren Dale | 2 Aug 17:16
Picon
Favicon

Re: Mathtext improvements (merging into trunk)

On Thursday 02 August 2007 11:03:09 am Michael Droettboom wrote:
> Darren Dale wrote:
> > On Thursday 02 August 2007 10:42:17 am John Hunter wrote:
> >> On 8/2/07, Michael Droettboom <mdroe@...> wrote:
> >>> I don't know if we ever reached consensus on how to specify math text
> >>> vs. regular text.  I agree with Eric that it's down to two options:
> >>> using a new kw argument (probably format="math" to be most
> >>> future-proof) or Math('string').  I don't think I have enough
> >>> "historical perspective" to really make the call but I do have a
> >>> concern about the second option that it may be confusing depending on
> >>> how "Math" is imported.  (It may have to be pylab.Math in some
> >>> instances but not in others.)  But I don't have a strong objection.
> >>>
> >>> Any last objections to going with the new keyword argument?
> >>
> >> I'm +1 on the kwarg approach -- it seems most consistent with our other
> >> usage.
> >
> > Maybe the keyword should be format="TeX"? Or texformatting=True? Maybe it
> > would be appropriate to have the kwarg default to None, and if None
> > reference an rcoption like text.texformatting? That might be the least
> > disruptive all around.
>
> I think format="TeX" may be a bit misleading, since it uses something
> TeX-like, but not really TeX (as the usetex stuff does).  That said, I
> don't really have a better suggestion ;)
>
> The idea also is that in the future this could support other values,
> e.g. format="html" might support "<b>bold</b>" for instance, so
> texformatting=True would be less extensible overall.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Xuedong Zhang | 2 Aug 17:26
Favicon

copy a line from one figure to another

Hi,

  I wonder if there is any example to copy a line belong to one figure 
to another figure?

Thanks
Xuedong

-------------------------------------------------------------------------
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/
Permalink | Reply | 0 comments |

Gmane