Re: [matplotlib-devel] Qt4 backend: critical bug with PyQt4 v4.6+
2009/12/31 Fernando Perez : > On Thu, Dec 31, 2009 at 4:54 AM, Darren Dale 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...), this was not very satisfying but now Spyder works perfectly because I stopped saying "it's not my fault, it's QScintilla's". So even if I agree with Darren on the fact that libraries such as matplotlib should not provide this kind of workaround, I also think that -at some point- one has to get practical indeed! Happy new year guys! Cheers, Pierre -- 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 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Numpy-discussion] Announcing toydist, improving distribution and packaging situation
Hi David, Following your announcement for the 'toydist' module, I think that your project is very promising: this is certainly a great idea and it will be very controversial but that's because people expectactions are great on this matter (distutils is so disappointing indeed). Anyway, if I may be useful, I'll gladly contribute to it. In time, I could change the whole Python(x,y) packaging system (which is currently quite ugly... but easy/quick to manage/maintain) to use/promote this new module. Happy New Year! and Long Live Scientific Python! ;-) Cheers, Pierre -- 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 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [SciPy-dev] [Numpy-discussion] Announcing toydist, improving distribution and packaging situation
On Thu, Dec 31, 2009 at 6:06 AM, Darren Dale 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 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 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] 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 -- 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 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 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 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: > 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 > > -- > 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 > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- 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 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 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 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: >> 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 >> >> -- >> 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 >> ___ >> Matplotlib-devel mailing list >> Matplotlib-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> -- 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 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] 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.5pt. 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) (/usr/share/texmf-texlive/tex/latex/txfonts/utxmia.fd) (/usr/share/texmf-texlive/tex/latex/txfonts/utxsyc.fd) ! Undefined control sequence. johnh\PYGZat []flag:\textasciitilde []\textgreater [] ipython -pylab l.260 ...asciitild...@textgreater[] ipython -pylab ? ! Emergency stop. johnh\PYGZat []flag:\textasciitilde []\textgreater [] ipython -pylab l.260 ...asciitild...@textgreater[] ipython -pylab ! ==> Fatal error occurred, no output PDF file produced! Transcript written on Matplotlib.log. -- 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 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [SciPy-User] [Numpy-discussion] Announcing toydist, improving distribution and packaging situation
On Fri, Jan 1, 2010 at 10:43 PM, Pierre Raybaut wrote: > Hi David, > > Following your announcement for the 'toydist' module, I think that > your project is very promising: this is certainly a great idea and it > will be very controversial but that's because people expectactions are > great on this matter (distutils is so disappointing indeed). > > Anyway, if I may be useful, I'll gladly contribute to it. > In time, I could change the whole Python(x,y) packaging system (which > is currently quite ugly... but easy/quick to manage/maintain) to > use/promote this new module. That would be a good way to test toydist on a real, complex package. I am not familiar at all with python(x,y) internals. Do you have some explanation I could look at somewhere ? In the meantime, I will try to clean-up the code to have a first experimental release. cheers, David -- 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 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Numpy-discussion] [SciPy-dev] Announcing toydist, improving distribution and packaging situation
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: python-matplotlib python-matplotlib-basemap for instance. It is interesting to note that the same source package may be used to generate both binary, end-user, packages. And happy new year! Gaël -- 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 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
