headers
Pierre Raybaut | 1 Jan 10:46

Re: Qt4 backend: critical bug with PyQt4 v4.6+

2009/12/31 Fernando Perez <fperez.net <at> gmail.com>:
> On Thu, Dec 31, 2009 at 4:54 AM, Darren Dale <dsdale24 <at> gmail.com> wrote:
>> I have been resistant to committing this patch because (in my opinion)
>> mpl should not have to provide workarounds for bugs in package X on OS
>> Y, distribution Z. I think this particular issue was fixed when
>> PyQt4-4.6.2 was released. But its time to get practical, I suppose.
>> The patch looks fine, I just checked it into the trunk.
>
> Thanks!  As the zen goes, practicality beats purity :)  I understand
> your reluctance though, it's annoying to pepper mpl's code with this
> kind of junk.
>
> Happy New Year!
>
> f
>

I completely agree. If developers were all doing their "job" in time,
this should not be necessary and Darren's position would be perfectly
right and justified. However, especially on certain open-source
libraries, things are not moving as fast as they should. For example,
in Spyder I had to re-implement a console-oriented text editor widget
with Scintilla-like features because QScintilla's widget had a
performance issue with very long lines (which is almost undectectable
when using it as a simple text editor but it may slow down display
when using it as a console widget). This bug was fixed just a few days
after being reported but there has been no release since then (August
2009). So, to make it work, I had to do this big workaround until the
next release of QScintilla has spread on every platform (i.e. not
until a year I guess). In terms of code refactoring (or purity...),
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Cournapeau | 2 Jan 03:32
Picon

Re: [SciPy-dev] [Numpy-discussion] Announcing toydist, improving distribution and packaging situation

On Thu, Dec 31, 2009 at 6:06 AM, Darren Dale <dsdale24@...> wrote:

>
> I should defer to the description of extras in the setuptools
> documentation. It is only a few paragraphs long:
>
> http://peak.telecommunity.com/DevCenter/setuptools#declaring-extras-optional-features-with-their-own-dependencies

Ok, so there are two issues related to this feature:
  - supporting variant at the build stage
  - supporting different variants of the same package in the
dependency graph at install time

The first issue is definitely supported - I fixed a bug in toydist to
support this correctly, and this will be used when converting
setuptools-based setup.py which use the features argument.

The second issue is more challenging. It complicates the dependency
handling quite a bit, and may cause difficult situations to happen at
dependency resolution time. This becomes particularly messy if you mix
packages you build yourself with packages grabbed from a repository. I
wonder if there is a simpler solution which would give a similar
feature set.

cheers,

David

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
(Continue reading)

Permalink | Reply | 5 comments |
headers
Eric Firing | 2 Jan 05:09
Favicon
Gravatar

doc build problem with axes_grid

I wanted to make a small fix to the contour docstring, and test it 
before committing, so I tried building the docs from scratch.  It fails 
with the last part of the traceback being:

   File 
"/usr/local/lib/python2.6/dist-packages/matplotlib/sphinxext/plot_directive.py", 
line 414, in plot_directive
     options, state_machine)
   File 
"/usr/local/lib/python2.6/dist-packages/matplotlib/sphinxext/plot_directive.py", 
line 337, in _plot_directive
     shutil.copyfile(plot_path, os.path.join(destdir, fname))
   File "/usr/lib/python2.6/shutil.py", line 52, in copyfile
     fsrc = open(src, 'rb')
IOError: [Errno 2] No such file or directory: 
u'/home/efiring/programs/py/mpl/mpl_trunk/doc/mpl_examples/axes_grid/demo_fixed_size_axes.py'
 > /usr/lib/python2.6/shutil.py(52)copyfile()
-> fsrc = open(src, 'rb')

I suspect the problem is that doc/examples/axes_grid has many .rst files 
for .py scripts that are no longer present, at least on my svn checkout. 
I have a demo_fixed_size_axes.pyc sitting around, but no corresponding 
.py, again indicating that the .py was removed from svn.

Is there some step I am missing, or is there a need to remove from the 
svn tree those .rst files that lack corresponding .py?

Eric

------------------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 5 comments |
headers
Jae-Joon Lee | 2 Jan 05:48
Picon
Gravatar

Re: doc build problem with axes_grid

The error happens because of the *.rst files under doc/examples that
are not in sync with examples/*.py.
Removing that directory (doc/examples) will solve the problem (the
directory will be repopulated when you run make.py again). Here is a
related link.

http://old.nabble.com/python-make.py-html-failure-tt26894350.html

Maybe we need something like "python make.py clean"?

Regards,

-JJ

On Fri, Jan 1, 2010 at 11:09 PM, Eric Firing <efiring <at> hawaii.edu> wrote:
> I wanted to make a small fix to the contour docstring, and test it
> before committing, so I tried building the docs from scratch.  It fails
> with the last part of the traceback being:
>
>   File
> "/usr/local/lib/python2.6/dist-packages/matplotlib/sphinxext/plot_directive.py",
> line 414, in plot_directive
>     options, state_machine)
>   File
> "/usr/local/lib/python2.6/dist-packages/matplotlib/sphinxext/plot_directive.py",
> line 337, in _plot_directive
>     shutil.copyfile(plot_path, os.path.join(destdir, fname))
>   File "/usr/lib/python2.6/shutil.py", line 52, in copyfile
>     fsrc = open(src, 'rb')
> IOError: [Errno 2] No such file or directory:
(Continue reading)

Permalink | Reply | 4 comments |
headers
Eric Firing | 2 Jan 07:34
Favicon
Gravatar

Re: doc build problem with axes_grid

Jae-Joon Lee wrote:
> The error happens because of the *.rst files under doc/examples that
> are not in sync with examples/*.py.
> Removing that directory (doc/examples) will solve the problem (the
> directory will be repopulated when you run make.py again). Here is a
> related link.
> 
> http://old.nabble.com/python-make.py-html-failure-tt26894350.html

Thank you for the quick response.  That was it, exactly.  There are 
still some example script failures, but nothing that stops the build in 
its tracks.

> 
> Maybe we need something like "python make.py clean"?

Yes, if the generated files can't all land in the "build" directory (as 
would seem preferable), then the next-best thing would be to have 
make.py able to do a thorough cleaning.

Eric

> 
> Regards,
> 
> -JJ
> 
> 
> On Fri, Jan 1, 2010 at 11:09 PM, Eric Firing <efiring@...> wrote:
>> I wanted to make a small fix to the contour docstring, and test it
(Continue reading)

Permalink | Reply | 3 comments |
headers
Andrew Straw | 2 Jan 08:06
Picon
Gravatar

docs are now built after every commit & sphinx latex output error

Hi all,

I added a recipe for to build a copy of the documentation after every
svn commit. The results may be seen at
http://matplotlib.sourceforge.net/trunk-docs/ (we can change the
location easily if desired).

This is just the result of another buildbot recipe, so any troubles that
crop up when building the docs should trigger an email on the
matplotlib-buildbot mailing list. For now, this is disabled because
compiling the latex document is failing. (Our buildbot is configured to
send email only on the first failure.)

In fact, does anyone know what could be wrong? The last lines of the
LaTeX output are below.

Happy New Year!

-Andrew

Package Fancyhdr Warning: \headheight is too small (12.0pt):
 Make it at least 13.59999pt.
 We now make it that large for the rest of the document.
 This may cause the page layout to be inconsistent, however.

[4]
Chapter 2.
(/usr/share/texmf-texlive/tex/latex/txfonts/ot1txr.fd)
(/usr/share/texmf-texlive/tex/latex/txfonts/utxsya.fd)
(/usr/share/texmf-texlive/tex/latex/txfonts/utxsyb.fd)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Andrew Straw | 2 Jan 19:27
Picon
Gravatar

Re: [SciPy-dev] [Numpy-discussion] Announcing toydist, improving distribution and packaging situation

David Cournapeau wrote:
> On Sat, Jan 2, 2010 at 4:58 PM, Gael Varoquaux
> <gael.varoquaux@...> wrote:
>   
>> On Sat, Jan 02, 2010 at 11:32:00AM +0900, David Cournapeau wrote:
>>     
>>> [snip]
>>>   - supporting different variants of the same package in the
>>> dependency graph at install time
>>>       
>>> [snip]
>>>       
>>> The second issue is more challenging. It complicates the dependency
>>> handling quite a bit, and may cause difficult situations to happen at
>>> dependency resolution time. This becomes particularly messy if you mix
>>> packages you build yourself with packages grabbed from a repository. I
>>> wonder if there is a simpler solution which would give a similar
>>> feature set.
>>>       
>> AFAICT, in Debian, the same feature is given via virtual packages: you
>> would have:
>>     
>
> I don't think virtual-packages entirely fix the issue. AFAIK, virtual
> packages have two uses:
>  - handle dependencies where several packages may resolve one
> particular dependency in an equivalent way (one good example is
> LAPACK: both liblapack and libatlas provides the lapack feature)
>  - closer to this discussion, you can build several variants of the
> same package, and each variant would resolve the dependency on a
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrew Straw | 2 Jan 19:47
Picon
Gravatar

Re: docs are now built after every commit & sphinx latex output error

Andrew Straw wrote:
> In fact, does anyone know what could be wrong? The last lines of the
> LaTeX output are below.
>   
OK, this cropped up on another buildbot for another project of mine --
it looks with a Sphinx dependency, Pygments 1.2.1 (just released), there
is some issue that wasn't there with Pygments 1.1.1. I'll try to isolate
the issue and report it to the appropriate tracker, but at this point I
don't think it's an MPL issue.

-Andrew

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
Permalink | Reply | 1 comment |
headers
Andrew Straw | 2 Jan 22:08
Picon
Gravatar

Re: docs are now built after every commit & sphinx latex output error

Andrew Straw wrote:
> Andrew Straw wrote:
>   
>> In fact, does anyone know what could be wrong? The last lines of the
>> LaTeX output are below.
>>   
>>     
> OK, this cropped up on another buildbot for another project of mine --
> it looks with a Sphinx dependency, Pygments 1.2.1 (just released), there
> is some issue that wasn't there with Pygments 1.1.1. I'll try to isolate
> the issue and report it to the appropriate tracker, but at this point I
> don't think it's an MPL issue.
>   
For the record, I reported it here:
http://dev.pocoo.org/projects/pygments/ticket/463

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
Permalink | Reply | 0 comments |
headers
David Cournapeau | 3 Jan 12:24
Picon

Re: [SciPy-dev] [Numpy-discussion] Announcing toydist, improving distribution and packaging situation

On Sun, Jan 3, 2010 at 3:27 AM, Andrew Straw <strawman@...> wrote:

>>
> Typically, the dependencies only depend on the smallest subset of what
> they require (if they don't need lapack, they'd only depend on
> python-numpy-core in your example), but yes, if there's an unsatisfiable
> condition, then apt-get will raise an error and abort. In practice, this
> system seems to work quite well, IMO.

Yes, but:
  - debian dependency resolution is complex. I think many people don't
realize how complex the problem really is (AFAIK, any correct scheme
to resolve dependencies in debian requires an algorithm which is
NP-complete )
  - introducing a lot of variants significantly slow down the whole thing.

I think it worths thinking whether our problems warrant such a complexity.

>
> Anyhow, here's the full Debian documentation:
> http://www.debian.org/doc/debian-policy/ch-relationships.html

This is not the part I am afraid of. This is:
http://people.debian.org/~dburrows/model.pdf

cheers,

David

------------------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |

Gmane