Menu
▾
▴
matplotlib-devel — matplotlib developers
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(33) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(7) |
Feb
(44) |
Mar
(51) |
Apr
(43) |
May
(43) |
Jun
(36) |
Jul
(61) |
Aug
(44) |
Sep
(25) |
Oct
(82) |
Nov
(97) |
Dec
(47) |
| 2005 |
Jan
(77) |
Feb
(143) |
Mar
(42) |
Apr
(31) |
May
(93) |
Jun
(93) |
Jul
(35) |
Aug
(78) |
Sep
(56) |
Oct
(44) |
Nov
(72) |
Dec
(75) |
| 2006 |
Jan
(116) |
Feb
(99) |
Mar
(181) |
Apr
(171) |
May
(112) |
Jun
(86) |
Jul
(91) |
Aug
(111) |
Sep
(77) |
Oct
(72) |
Nov
(57) |
Dec
(51) |
| 2007 |
Jan
(64) |
Feb
(116) |
Mar
(70) |
Apr
(74) |
May
(53) |
Jun
(40) |
Jul
(519) |
Aug
(151) |
Sep
(132) |
Oct
(74) |
Nov
(282) |
Dec
(190) |
| 2008 |
Jan
(141) |
Feb
(67) |
Mar
(69) |
Apr
(96) |
May
(227) |
Jun
(404) |
Jul
(399) |
Aug
(96) |
Sep
(120) |
Oct
(205) |
Nov
(126) |
Dec
(261) |
| 2009 |
Jan
(136) |
Feb
(136) |
Mar
(119) |
Apr
(124) |
May
(155) |
Jun
(98) |
Jul
(136) |
Aug
(292) |
Sep
(174) |
Oct
(126) |
Nov
(126) |
Dec
(79) |
| 2010 |
Jan
(109) |
Feb
(83) |
Mar
(139) |
Apr
(91) |
May
(79) |
Jun
(164) |
Jul
(184) |
Aug
(146) |
Sep
(163) |
Oct
(128) |
Nov
(70) |
Dec
(73) |
| 2011 |
Jan
(235) |
Feb
(165) |
Mar
(147) |
Apr
(86) |
May
(74) |
Jun
(118) |
Jul
(65) |
Aug
(75) |
Sep
(162) |
Oct
(94) |
Nov
(48) |
Dec
(44) |
| 2012 |
Jan
(49) |
Feb
(40) |
Mar
(88) |
Apr
(35) |
May
(52) |
Jun
(69) |
Jul
(90) |
Aug
(123) |
Sep
(112) |
Oct
(120) |
Nov
(105) |
Dec
(116) |
| 2013 |
Jan
(76) |
Feb
(26) |
Mar
(78) |
Apr
(43) |
May
(61) |
Jun
(53) |
Jul
(147) |
Aug
(85) |
Sep
(83) |
Oct
(122) |
Nov
(18) |
Dec
(27) |
| 2014 |
Jan
(58) |
Feb
(25) |
Mar
(49) |
Apr
(17) |
May
(29) |
Jun
(39) |
Jul
(53) |
Aug
(52) |
Sep
(35) |
Oct
(47) |
Nov
(110) |
Dec
(27) |
| 2015 |
Jan
(50) |
Feb
(93) |
Mar
(96) |
Apr
(30) |
May
(55) |
Jun
(83) |
Jul
(44) |
Aug
(8) |
Sep
(5) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(3) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(7) |
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
1
(7) |
2
(15) |
3
(6) |
4
(13) |
5
(5) |
6
(2) |
|
7
(8) |
8
(23) |
9
(1) |
10
(11) |
11
(20) |
12
(33) |
13
(18) |
|
14
(16) |
15
(11) |
16
(25) |
17
(25) |
18
(3) |
19
(8) |
20
|
|
21
|
22
(4) |
23
|
24
(2) |
25
|
26
(1) |
27
|
|
28
|
29
(2) |
30
(1) |
31
(1) |
|
|
|
|
From: John H. <jd...@gm...> - 2008-12-13 21:24:20
|
Because several people are reporting problems with the OS X egg, I grabbed matplotlib-0.98.5-py2.5-macosx-10.3.egg from sourceforge and unzipped it to see what was in there. It seems to contain no of the extension code and no object files. What exactly is this thing? I am no egg expert, but I don't see how this thing *could* work ... I think the src egg approach for os x is hopeless because too many people are having problems with architecture on png and zlib dependencies, and we don't have a lot of control over this because they are getting these dependencies from a variety of providers. I think we need a binary installer, eg using bdist_mpkg, with the freetype, png and zlib dependencies built in, as we have on windows. Any takers? JDH |
|
From: Darren D. <dsd...@gm...> - 2008-12-13 18:27:23
|
On Sat, Dec 13, 2008 at 12:01 PM, Charlie Moad <cw...@gm...> wrote: > I had all the build opts explicitly set, so I am not quite sure what > happened. I'm a little more worried about the error two people have > reported involving matplotlib.conf.template. This file is present in > the source. > Did you delete the build directory before you rebuilt for the installer? |
|
From: Darren D. <dsd...@gm...> - 2008-12-13 18:25:01
|
On Sat, Dec 13, 2008 at 10:53 AM, John Hunter <jd...@gm...> wrote: > On Sat, Dec 13, 2008 at 4:52 AM, Darren Dale <dsd...@gm...> wrote: > > The 0.98.5 windows installer is still overwriting existing installations > of > > configobj. This package is not needed by matplotlib and should not be > > installed on windows, nor should traits. > > > > I have removed configobj and enthought.traits from the trunk, but it is > > still present on the maintenance branches. On build systems, setup.cfg > for > > the maintenance branches should be configured to not install configobj or > > traits under any circumstances. Once it has been so configured, the build > > directory needs to be deleted, because it probably contains a cached copy > of > > configobj that will get incorporated into the installer the next time it > is > > built, regardless of the settings in setup.cfg. > > > > This bug has been assigned to me, but it is out of my hands at this > point. > > Since config obj is removed, it is mostly moot going forward, but it > appears that something still went wrong with the win32 build process. > Charlie, are you maintaining a setup.cfg file you use for the win32 > builds that has configobj and traits off? You also need to make sure > that you delete the build dir after any changes to setup.cfg before > rebuilding since cruft in the builddir can get carried along. I will > add this to the devel release notes, > I think it should not be an issue for new releases from the trunk, as long as the build directory has been deleted so there is no chance of a cached configobj finding its way into the installer. |
|
From: Charlie M. <cw...@gm...> - 2008-12-13 17:01:59
|
I had all the build opts explicitly set, so I am not quite sure what happened. I'm a little more worried about the error two people have reported involving matplotlib.conf.template. This file is present in the source. - Charlie On Sat, Dec 13, 2008 at 10:53 AM, John Hunter <jd...@gm...> wrote: > On Sat, Dec 13, 2008 at 4:52 AM, Darren Dale <dsd...@gm...> wrote: >> The 0.98.5 windows installer is still overwriting existing installations of >> configobj. This package is not needed by matplotlib and should not be >> installed on windows, nor should traits. >> >> I have removed configobj and enthought.traits from the trunk, but it is >> still present on the maintenance branches. On build systems, setup.cfg for >> the maintenance branches should be configured to not install configobj or >> traits under any circumstances. Once it has been so configured, the build >> directory needs to be deleted, because it probably contains a cached copy of >> configobj that will get incorporated into the installer the next time it is >> built, regardless of the settings in setup.cfg. >> >> This bug has been assigned to me, but it is out of my hands at this point. > > Since config obj is removed, it is mostly moot going forward, but it > appears that something still went wrong with the win32 build process. > Charlie, are you maintaining a setup.cfg file you use for the win32 > builds that has configobj and traits off? You also need to make sure > that you delete the build dir after any changes to setup.cfg before > rebuilding since cruft in the builddir can get carried along. I will > add this to the devel release notes, > > JDH > |
|
From: John H. <jd...@gm...> - 2008-12-13 15:53:15
|
On Sat, Dec 13, 2008 at 4:52 AM, Darren Dale <dsd...@gm...> wrote: > The 0.98.5 windows installer is still overwriting existing installations of > configobj. This package is not needed by matplotlib and should not be > installed on windows, nor should traits. > > I have removed configobj and enthought.traits from the trunk, but it is > still present on the maintenance branches. On build systems, setup.cfg for > the maintenance branches should be configured to not install configobj or > traits under any circumstances. Once it has been so configured, the build > directory needs to be deleted, because it probably contains a cached copy of > configobj that will get incorporated into the installer the next time it is > built, regardless of the settings in setup.cfg. > > This bug has been assigned to me, but it is out of my hands at this point. Since config obj is removed, it is mostly moot going forward, but it appears that something still went wrong with the win32 build process. Charlie, are you maintaining a setup.cfg file you use for the win32 builds that has configobj and traits off? You also need to make sure that you delete the build dir after any changes to setup.cfg before rebuilding since cruft in the builddir can get carried along. I will add this to the devel release notes, JDH |
|
From: John H. <jd...@gm...> - 2008-12-13 15:32:37
|
On Sat, Dec 13, 2008 at 9:22 AM, Darren Dale <dsd...@gm...> wrote: >> I haven't been able to get to the root of this problem, but an "svn-clean" >> in the doc directory always fixes it for me. > > I tried that but the problem persists. I have sphinx-0.4.2 installed, are > you using the same version? Can you post the full traceback sphinx is pointing you to,o: /tmp/sphinx-err-qaZ8fg.log as of your earlier post |
|
From: Darren D. <dsd...@gm...> - 2008-12-13 15:22:28
|
On Sat, Dec 13, 2008 at 8:48 AM, Michael Droettboom <md...@st...> wrote: > Darren Dale wrote: > >> I am seeing some errors when I build the docs, including import errors for >> nonexistent date_support and basic_units modules, and: >> > I added the ability for explicitly setting sys.path so that modules in the > same directory as an example would be importable. It looks likes that has > somehow broken again. I'll look into it. > >> >> >> WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: >> (WARNING/2) error while formatting signature for >> matplotlib.patches.ArrowStyle.BracketB: arg is not a Python function >> WARNING: >> /home/darren/src/matplotlib/doc/api/artist_api.rst:37: (WARNING/2) error >> while formatting signature for matplotlib.patches.ArrowStyle.Curve: arg is >> not a Python function >> WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: >> (WARNING/2) error while formatting signature for >> matplotlib.patches.ArrowStyle.CurveA: arg is not a Python function >> WARNING: >> /home/darren/src/matplotlib/doc/api/artist_api.rst:37: (WARNING/2) error >> while formatting signature for matplotlib.patches.ArrowStyle.CurveAB: arg is >> not a Python function >> WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: >> (WARNING/2) error while formatting signature for >> matplotlib.patches.ArrowStyle.CurveB: arg is not a Python function >> WARNING: >> /home/darren/src/matplotlib/doc/api/artist_api.rst:37: (WARNING/2) error >> while formatting signature for matplotlib.patches.ArrowStyle.Fancy: arg is >> not a Python function >> WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: >> (WARNING/2) error while formatting signature for >> matplotlib.patches.ArrowStyle.Simple: arg is not a Python function >> WARNING: >> /home/darren/src/matplotlib/doc/api/artist_api.rst:37: (WARNING/2) error >> while formatting signature for matplotlib.patches.ArrowStyle.Wedge: arg is >> not a Python function >> WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: >> (WARNING/2) error while formatting signature for >> matplotlib.patches.BoxStyle.LArrow: arg is not a Python function >> WARNING: >> /home/darren/src/matplotlib/doc/api/artist_api.rst:37: (WARNING/2) error >> while formatting signature for matplotlib.patches.BoxStyle.RArrow: arg is >> not a Python function >> WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: >> (WARNING/2) error while formatting signature for >> matplotlib.patches.BoxStyle.Round: arg is not a Python function >> WARNING: >> /home/darren/src/matplotlib/doc/api/artist_api.rst:37: (WARNING/2) error >> while formatting signature for matplotlib.patches.BoxStyle.Round4: arg is >> not a Python function >> WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: >> (WARNING/2) error while formatting signature for >> matplotlib.patches.BoxStyle.Roundtooth: arg is not a Python function >> WARNING: >> /home/darren/src/matplotlib/doc/api/artist_api.rst:37: (WARNING/2) error >> while formatting signature for matplotlib.patches.BoxStyle.Sawtooth: arg is >> not a Python function >> WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: >> (WARNING/2) error while formatting signature for >> matplotlib.patches.BoxStyle.Square: arg is not a Python function >> WARNING: >> /home/darren/src/matplotlib/doc/api/artist_api.rst:37: (WARNING/2) error >> while formatting signature for matplotlib.patches.ConnectionStyle.Angle: arg >> is not a Python function >> WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: >> (WARNING/2) error while formatting signature for >> matplotlib.patches.ConnectionStyle.Angle3: arg is not a Python function >> WARNING: >> /home/darren/src/matplotlib/doc/api/artist_api.rst:37: (WARNING/2) error >> while formatting signature for matplotlib.patches.ConnectionStyle.Arc: arg >> is not a Python function >> WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: >> (WARNING/2) error while formatting signature for >> matplotlib.patches.ConnectionStyle.Arc3: arg is not a Python function >> >> > I have never had any idea what this warning means, > >> WARNING: /usr/lib/python2.5/site-packages/matplotlib/patches.py:docstring >> of matplotlib.patches.FancyBboxPatch.set_width:2: (WARNING/2) Block quote >> ends without a blank line; unexpected unindent. >> WARNING: >> /usr/lib/python2.5/site-packages/matplotlib/axes.py:docstring of >> matplotlib.axes.Axes.acorr:22: (ERROR/3) Unexpected indentation. >> WARNING: >> /usr/lib/python2.5/site-packages/matplotlib/axes.py:docstring of >> matplotlib.axes.Axes.semilogy:3: (ERROR/3) Inconsistent literal block >> quoting. WARNING: :0: (ERROR/3) Unexpected indentation. >> WARNING: >> /home/darren/src/matplotlib/doc/api/backend_wxagg_api.rst:5: (WARNING/2) >> autodoc can't import/find module 'matplotlib.backends.backend_wxagg', it >> reported error: "No module named wx",please check your spelling and sys.path >> WARNING: /home/darren/src/matplotlib/doc/api/cbook_api.rst:9: >> (WARNING/2) error while formatting signature for matplotlib.cbook.Xlator: >> arg is not a Python function >> >> WARNING: /home/darren/src/matplotlib/doc/api/font_manager_api.rst:: >> (WARNING/2) Duplicate explicit target name: "fontconfig". >> WARNING: >> /home/darren/src/matplotlib/doc/api/mathtext_api.rst:11: (WARNING/2) error >> while formatting signature for matplotlib.mathtext.Parser.State: arg is not >> a Python function >> WARNING: /home/darren/src/matplotlib/doc/api/mathtext_api.rst:11: >> (WARNING/2) error while formatting signature for >> matplotlib.mathtext.TruetypeFonts.CachedFont: arg is not a Python function >> WARNING: >> /home/darren/src/matplotlib/doc/api/path_api.rst:9: (WARNING/2) error while >> formatting signature for matplotlib.path.Path.code_type: arg is not a Python >> function >> >> WARNING: /usr/lib/python2.5/site-packages/matplotlib/pyplot.py:docstring >> of matplotlib.pyplot.acorr:41: (ERROR/3) Unexpected indentation. >> WARNING: :0: (ERROR/3) Inconsistent literal block quoting. >> WARNING: >> /usr/lib/python2.5/site-packages/matplotlib/pyplot.py:docstring of >> matplotlib.pyplot.annotate:19: (ERROR/3) Unexpected indentation. >> WARNING: /home/darren/src/matplotlib/doc/api/pyplot_api.rst:6380: >> (ERROR/3) Unknown interpreted text role "module". >> WARNING: >> /home/darren/src/matplotlib/doc/api/ticker_api.rst:9: (WARNING/2) error >> while formatting signature for matplotlib.ticker.TickHelper.DummyAxis: arg >> is not a Python function >> WARNING: >> /home/darren/src/matplotlib/doc/devel/add_new_projection.rst:132: >> (WARNING/2) error while formatting signature for >> matplotlib.projections.polar.PolarAxes.InvertedPolarTransform: arg is not a >> Python function WARNING: >> /home/darren/src/matplotlib/doc/devel/add_new_projection.rst:132: >> (WARNING/2) error while formatting signature for >> matplotlib.projections.polar.PolarAxes.PolarAffine: arg is not a Python >> function WARNING: >> /home/darren/src/matplotlib/doc/devel/add_new_projection.rst:132: >> (WARNING/2) error while formatting signature for >> matplotlib.projections.polar.PolarAxes.PolarTransform: arg is not a Python >> function WARNING: >> /home/darren/src/matplotlib/doc/devel/add_new_projection.rst:132: >> (WARNING/2) error while formatting signature for >> matplotlib.projections.polar.PolarAxes.RadialLocator: arg is not a Python >> function WARNING: >> /home/darren/src/matplotlib/doc/devel/add_new_projection.rst:132: >> (WARNING/2) error while formatting signature for >> matplotlib.projections.polar.PolarAxes.ThetaFormatter: arg is not a Python >> function >> >> and: >> >> checking consistency... >> WARNING: /home/darren/src/matplotlib/doc/examples/index.rst:: document >> isn't included in any toctree >> > This one is deliberate -- it's there to help the search engine, but we > don't actually want to include it in the doc. > >> WARNING: >> /home/darren/src/matplotlib/doc/faq/environment_variables_faq.rst:: document >> isn't included in any toctree >> WARNING: /home/darren/src/matplotlib/doc/users/arraydata.rst:: document >> isn't included in any toctree >> > These (I believe) are unfinished documents, that should be added to the > index once they are. > >> >> Most importantly: >> >> copying static files... >> Exception occurred: >> File "/usr/lib/python2.5/shutil.py", line 165, in rmtree >> names = os.listdir(path) >> OSError: [Errno 2] No such file or directory: >> '/home/darren/src/matplotlib/doc/build/html/_static/plot_directive' >> The full traceback has been saved in /tmp/sphinx-err-qaZ8fg.log, if you >> want toreport the issue to the author. >> Please also report this if it was a user error, so that a better error >> message can be provided next time. >> Send reports to sph...@go... <mailto: >> sph...@go...>. Thanks! >> Building HTML failed. >> > I haven't been able to get to the root of this problem, but an "svn-clean" > in the doc directory always fixes it for me. > I tried that but the problem persists. I have sphinx-0.4.2 installed, are you using the same version? |
|
From: Sandro T. <mo...@de...> - 2008-12-13 14:16:00
|
> I get a similar error that I assumed was caused by the docs being
> generated by the version of matplotlib that is currently installed,
> rather than the new version that has just been compiled. I know the
> debian package has a workaround for this.
Of course we have one :)
We build doc this way:
( cd doc ; MATPLOTLIBDATA=../lib/matplotlib/mpl-data/ \
PYTHONPATH=../build/lib.$(PY_PLATFORM)-$(DEFPY) ./make.py )
after having built mpl module. $(PY_PLATFORM)-$(DEFPY) is to be
generic on the arch and the python version we are using to build the
package, so you can replace it with the dir where the module was
compiled.
Cheers,
--
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
|
|
From: Chris W. <ch...@ch...> - 2008-12-13 14:05:02
|
Michael Droettboom <md...@st...> writes:
> Darren Dale wrote:
> > I am seeing some errors when I build the docs, including import errors
> > for nonexistent date_support and basic_units modules, and:
> I added the ability for explicitly setting sys.path so that modules in
> the same directory as an example would be importable. It looks likes
> that has somehow broken again. I'll look into it.
> >
> > Most importantly:
> >
> > copying static files...
> > Exception occurred:
> > File "/usr/lib/python2.5/shutil.py", line 165, in rmtree
> > names = os.listdir(path)
> > OSError: [Errno 2] No such file or directory:
> > '/home/darren/src/matplotlib/doc/build/html/_static/plot_directive'
> > The full traceback has been saved in /tmp/sphinx-err-qaZ8fg.log, if
> > you want toreport the issue to the author.
> > Please also report this if it was a user error, so that a better error
> > message can be provided next time.
> > Send reports to sph...@go...
> > <mailto:sph...@go...>. Thanks!
> > Building HTML failed.
> I haven't been able to get to the root of this problem, but an
> "svn-clean" in the doc directory always fixes it for me.
I get a similar error that I assumed was caused by the docs being
generated by the version of matplotlib that is currently installed,
rather than the new version that has just been compiled. I know the
debian package has a workaround for this.
I get:
Sphinx v0.5, building html
loading pickled environment... not found
building [html]: targets for 369 source files that are out of date
updating environment: 369 added, 0 changed, 0 removed
reading sources... api/afm_api api/api_changes api/artist_api makefig: fullpath=../mpl_examples/pylab_examples/findobj_demo.py, outdir=_static/plot_directive/../mpl_examples/pylab_examples
Exception occurred:
File "/usr/lib/python2.5/shutil.py", line 46, in copyfile
fsrc = open(src, 'rb')
IOError: [Errno 2] No such file or directory: '../mpl_examples/pylab_examples/findobj_demo.py'
The full traceback has been saved in /tmp/sphinx-err-L8wLV6.log, if you want to report the issue to the author.
Please also report this if it was a user error, so that a better error message can be provided next time.
Send reports to sph...@go.... Thanks!
Building HTML failed.
There is an examples directory, but no mpl_examples directory. Nb this
error is from the 0.98.4 tarfile compiled on debian lenny with the
sphinx 0.5 from debian's experimental packages.
Chris
|
|
From: Michael D. <md...@st...> - 2008-12-13 13:49:08
|
Darren Dale wrote: > I am seeing some errors when I build the docs, including import errors > for nonexistent date_support and basic_units modules, and: I added the ability for explicitly setting sys.path so that modules in the same directory as an example would be importable. It looks likes that has somehow broken again. I'll look into it. > > > WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: > (WARNING/2) error while formatting signature for > matplotlib.patches.ArrowStyle.BracketB: arg is not a Python > function > WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: > (WARNING/2) error while formatting signature for > matplotlib.patches.ArrowStyle.Curve: arg is not a Python > function > WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: > (WARNING/2) error while formatting signature for > matplotlib.patches.ArrowStyle.CurveA: arg is not a Python > function > WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: > (WARNING/2) error while formatting signature for > matplotlib.patches.ArrowStyle.CurveAB: arg is not a Python > function > WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: > (WARNING/2) error while formatting signature for > matplotlib.patches.ArrowStyle.CurveB: arg is not a Python > function > WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: > (WARNING/2) error while formatting signature for > matplotlib.patches.ArrowStyle.Fancy: arg is not a Python > function > WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: > (WARNING/2) error while formatting signature for > matplotlib.patches.ArrowStyle.Simple: arg is not a Python > function > WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: > (WARNING/2) error while formatting signature for > matplotlib.patches.ArrowStyle.Wedge: arg is not a Python > function > WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: > (WARNING/2) error while formatting signature for > matplotlib.patches.BoxStyle.LArrow: arg is not a Python > function > WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: > (WARNING/2) error while formatting signature for > matplotlib.patches.BoxStyle.RArrow: arg is not a Python > function > WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: > (WARNING/2) error while formatting signature for > matplotlib.patches.BoxStyle.Round: arg is not a Python > function > WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: > (WARNING/2) error while formatting signature for > matplotlib.patches.BoxStyle.Round4: arg is not a Python > function > WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: > (WARNING/2) error while formatting signature for > matplotlib.patches.BoxStyle.Roundtooth: arg is not a Python > function > WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: > (WARNING/2) error while formatting signature for > matplotlib.patches.BoxStyle.Sawtooth: arg is not a Python > function > WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: > (WARNING/2) error while formatting signature for > matplotlib.patches.BoxStyle.Square: arg is not a Python > function > WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: > (WARNING/2) error while formatting signature for > matplotlib.patches.ConnectionStyle.Angle: arg is not a Python > function > WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: > (WARNING/2) error while formatting signature for > matplotlib.patches.ConnectionStyle.Angle3: arg is not a Python > function > WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: > (WARNING/2) error while formatting signature for > matplotlib.patches.ConnectionStyle.Arc: arg is not a Python > function > WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: > (WARNING/2) error while formatting signature for > matplotlib.patches.ConnectionStyle.Arc3: arg is not a Python > function I have never had any idea what this warning means, > WARNING: > /usr/lib/python2.5/site-packages/matplotlib/patches.py:docstring of > matplotlib.patches.FancyBboxPatch.set_width:2: (WARNING/2) Block quote > ends without a blank line; unexpected > unindent. > WARNING: /usr/lib/python2.5/site-packages/matplotlib/axes.py:docstring > of matplotlib.axes.Axes.acorr:22: (ERROR/3) Unexpected > indentation. > WARNING: /usr/lib/python2.5/site-packages/matplotlib/axes.py:docstring > of matplotlib.axes.Axes.semilogy:3: (ERROR/3) Inconsistent literal > block quoting. > WARNING: :0: (ERROR/3) Unexpected > indentation. > WARNING: /home/darren/src/matplotlib/doc/api/backend_wxagg_api.rst:5: > (WARNING/2) autodoc can't import/find module > 'matplotlib.backends.backend_wxagg', it reported error: "No module > named wx",please check your spelling and sys.path > WARNING: /home/darren/src/matplotlib/doc/api/cbook_api.rst:9: > (WARNING/2) error while formatting signature for > matplotlib.cbook.Xlator: arg is not a Python > function > > WARNING: /home/darren/src/matplotlib/doc/api/font_manager_api.rst:: > (WARNING/2) Duplicate explicit target name: > "fontconfig". > WARNING: /home/darren/src/matplotlib/doc/api/mathtext_api.rst:11: > (WARNING/2) error while formatting signature for > matplotlib.mathtext.Parser.State: arg is not a Python > function > WARNING: /home/darren/src/matplotlib/doc/api/mathtext_api.rst:11: > (WARNING/2) error while formatting signature for > matplotlib.mathtext.TruetypeFonts.CachedFont: arg is not a Python > function > WARNING: /home/darren/src/matplotlib/doc/api/path_api.rst:9: > (WARNING/2) error while formatting signature for > matplotlib.path.Path.code_type: arg is not a Python > function > > WARNING: > /usr/lib/python2.5/site-packages/matplotlib/pyplot.py:docstring of > matplotlib.pyplot.acorr:41: (ERROR/3) Unexpected > indentation. > WARNING: :0: (ERROR/3) Inconsistent literal block > quoting. > WARNING: > /usr/lib/python2.5/site-packages/matplotlib/pyplot.py:docstring of > matplotlib.pyplot.annotate:19: (ERROR/3) Unexpected > indentation. > WARNING: /home/darren/src/matplotlib/doc/api/pyplot_api.rst:6380: > (ERROR/3) Unknown interpreted text role > "module". > WARNING: /home/darren/src/matplotlib/doc/api/ticker_api.rst:9: > (WARNING/2) error while formatting signature for > matplotlib.ticker.TickHelper.DummyAxis: arg is not a Python > function > WARNING: > /home/darren/src/matplotlib/doc/devel/add_new_projection.rst:132: > (WARNING/2) error while formatting signature for > matplotlib.projections.polar.PolarAxes.InvertedPolarTransform: arg is > not a Python function > WARNING: > /home/darren/src/matplotlib/doc/devel/add_new_projection.rst:132: > (WARNING/2) error while formatting signature for > matplotlib.projections.polar.PolarAxes.PolarAffine: arg is not a > Python function > WARNING: > /home/darren/src/matplotlib/doc/devel/add_new_projection.rst:132: > (WARNING/2) error while formatting signature for > matplotlib.projections.polar.PolarAxes.PolarTransform: arg is not a > Python function > WARNING: > /home/darren/src/matplotlib/doc/devel/add_new_projection.rst:132: > (WARNING/2) error while formatting signature for > matplotlib.projections.polar.PolarAxes.RadialLocator: arg is not a > Python function > WARNING: > /home/darren/src/matplotlib/doc/devel/add_new_projection.rst:132: > (WARNING/2) error while formatting signature for > matplotlib.projections.polar.PolarAxes.ThetaFormatter: arg is not a > Python function > > and: > > checking > consistency... > WARNING: /home/darren/src/matplotlib/doc/examples/index.rst:: document > isn't included in any toctree This one is deliberate -- it's there to help the search engine, but we don't actually want to include it in the doc. > > WARNING: > /home/darren/src/matplotlib/doc/faq/environment_variables_faq.rst:: > document isn't included in any > toctree > WARNING: /home/darren/src/matplotlib/doc/users/arraydata.rst:: > document isn't included in any toctree These (I believe) are unfinished documents, that should be added to the index once they are. > > Most importantly: > > copying static files... > Exception occurred: > File "/usr/lib/python2.5/shutil.py", line 165, in rmtree > names = os.listdir(path) > OSError: [Errno 2] No such file or directory: > '/home/darren/src/matplotlib/doc/build/html/_static/plot_directive' > The full traceback has been saved in /tmp/sphinx-err-qaZ8fg.log, if > you want toreport the issue to the author. > Please also report this if it was a user error, so that a better error > message can be provided next time. > Send reports to sph...@go... > <mailto:sph...@go...>. Thanks! > Building HTML failed. I haven't been able to get to the root of this problem, but an "svn-clean" in the doc directory always fixes it for me. Cheers, Mike > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > ------------------------------------------------------------------------ > > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
|
From: Darren D. <dsd...@gm...> - 2008-12-13 13:32:24
|
I am seeing some errors when I build the docs, including import errors for
nonexistent date_support and basic_units modules, and:
WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: (WARNING/2)
error while formatting signature for matplotlib.patches.ArrowStyle.BracketB:
arg is not a Python
function
WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: (WARNING/2)
error while formatting signature for matplotlib.patches.ArrowStyle.Curve:
arg is not a Python
function
WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: (WARNING/2)
error while formatting signature for matplotlib.patches.ArrowStyle.CurveA:
arg is not a Python
function
WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: (WARNING/2)
error while formatting signature for matplotlib.patches.ArrowStyle.CurveAB:
arg is not a Python
function
WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: (WARNING/2)
error while formatting signature for matplotlib.patches.ArrowStyle.CurveB:
arg is not a Python
function
WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: (WARNING/2)
error while formatting signature for matplotlib.patches.ArrowStyle.Fancy:
arg is not a Python
function
WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: (WARNING/2)
error while formatting signature for matplotlib.patches.ArrowStyle.Simple:
arg is not a Python
function
WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: (WARNING/2)
error while formatting signature for matplotlib.patches.ArrowStyle.Wedge:
arg is not a Python
function
WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: (WARNING/2)
error while formatting signature for matplotlib.patches.BoxStyle.LArrow: arg
is not a Python
function
WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: (WARNING/2)
error while formatting signature for matplotlib.patches.BoxStyle.RArrow: arg
is not a Python
function
WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: (WARNING/2)
error while formatting signature for matplotlib.patches.BoxStyle.Round: arg
is not a Python
function
WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: (WARNING/2)
error while formatting signature for matplotlib.patches.BoxStyle.Round4: arg
is not a Python
function
WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: (WARNING/2)
error while formatting signature for matplotlib.patches.BoxStyle.Roundtooth:
arg is not a Python
function
WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: (WARNING/2)
error while formatting signature for matplotlib.patches.BoxStyle.Sawtooth:
arg is not a Python
function
WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: (WARNING/2)
error while formatting signature for matplotlib.patches.BoxStyle.Square: arg
is not a Python
function
WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: (WARNING/2)
error while formatting signature for
matplotlib.patches.ConnectionStyle.Angle: arg is not a Python
function
WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: (WARNING/2)
error while formatting signature for
matplotlib.patches.ConnectionStyle.Angle3: arg is not a Python
function
WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: (WARNING/2)
error while formatting signature for matplotlib.patches.ConnectionStyle.Arc:
arg is not a Python
function
WARNING: /home/darren/src/matplotlib/doc/api/artist_api.rst:37: (WARNING/2)
error while formatting signature for
matplotlib.patches.ConnectionStyle.Arc3: arg is not a Python
function
WARNING: /usr/lib/python2.5/site-packages/matplotlib/patches.py:docstring of
matplotlib.patches.FancyBboxPatch.set_width:2: (WARNING/2) Block quote ends
without a blank line; unexpected
unindent.
WARNING: /usr/lib/python2.5/site-packages/matplotlib/axes.py:docstring of
matplotlib.axes.Axes.acorr:22: (ERROR/3) Unexpected
indentation.
WARNING: /usr/lib/python2.5/site-packages/matplotlib/axes.py:docstring of
matplotlib.axes.Axes.semilogy:3: (ERROR/3) Inconsistent literal block
quoting.
WARNING: :0: (ERROR/3) Unexpected
indentation.
WARNING: /home/darren/src/matplotlib/doc/api/backend_wxagg_api.rst:5:
(WARNING/2) autodoc can't import/find module
'matplotlib.backends.backend_wxagg', it reported error: "No module named
wx",please check your spelling and sys.path
WARNING: /home/darren/src/matplotlib/doc/api/cbook_api.rst:9: (WARNING/2)
error while formatting signature for matplotlib.cbook.Xlator: arg is not a
Python
function
WARNING: /home/darren/src/matplotlib/doc/api/font_manager_api.rst::
(WARNING/2) Duplicate explicit target name:
"fontconfig".
WARNING: /home/darren/src/matplotlib/doc/api/mathtext_api.rst:11:
(WARNING/2) error while formatting signature for
matplotlib.mathtext.Parser.State: arg is not a Python
function
WARNING: /home/darren/src/matplotlib/doc/api/mathtext_api.rst:11:
(WARNING/2) error while formatting signature for
matplotlib.mathtext.TruetypeFonts.CachedFont: arg is not a Python
function
WARNING: /home/darren/src/matplotlib/doc/api/path_api.rst:9: (WARNING/2)
error while formatting signature for matplotlib.path.Path.code_type: arg is
not a Python
function
WARNING: /usr/lib/python2.5/site-packages/matplotlib/pyplot.py:docstring of
matplotlib.pyplot.acorr:41: (ERROR/3) Unexpected
indentation.
WARNING: :0: (ERROR/3) Inconsistent literal block
quoting.
WARNING: /usr/lib/python2.5/site-packages/matplotlib/pyplot.py:docstring of
matplotlib.pyplot.annotate:19: (ERROR/3) Unexpected
indentation.
WARNING: /home/darren/src/matplotlib/doc/api/pyplot_api.rst:6380: (ERROR/3)
Unknown interpreted text role
"module".
WARNING: /home/darren/src/matplotlib/doc/api/ticker_api.rst:9: (WARNING/2)
error while formatting signature for matplotlib.ticker.TickHelper.DummyAxis:
arg is not a Python
function
WARNING: /home/darren/src/matplotlib/doc/devel/add_new_projection.rst:132:
(WARNING/2) error while formatting signature for
matplotlib.projections.polar.PolarAxes.InvertedPolarTransform: arg is not a
Python function
WARNING: /home/darren/src/matplotlib/doc/devel/add_new_projection.rst:132:
(WARNING/2) error while formatting signature for
matplotlib.projections.polar.PolarAxes.PolarAffine: arg is not a Python
function
WARNING: /home/darren/src/matplotlib/doc/devel/add_new_projection.rst:132:
(WARNING/2) error while formatting signature for
matplotlib.projections.polar.PolarAxes.PolarTransform: arg is not a Python
function
WARNING: /home/darren/src/matplotlib/doc/devel/add_new_projection.rst:132:
(WARNING/2) error while formatting signature for
matplotlib.projections.polar.PolarAxes.RadialLocator: arg is not a Python
function
WARNING: /home/darren/src/matplotlib/doc/devel/add_new_projection.rst:132:
(WARNING/2) error while formatting signature for
matplotlib.projections.polar.PolarAxes.ThetaFormatter: arg is not a Python
function
and:
checking
consistency...
WARNING: /home/darren/src/matplotlib/doc/examples/index.rst:: document isn't
included in any
toctree
WARNING: /home/darren/src/matplotlib/doc/faq/environment_variables_faq.rst::
document isn't included in any
toctree
WARNING: /home/darren/src/matplotlib/doc/users/arraydata.rst:: document
isn't included in any toctree
Most importantly:
copying static files...
Exception occurred:
File "/usr/lib/python2.5/shutil.py", line 165, in rmtree
names = os.listdir(path)
OSError: [Errno 2] No such file or directory:
'/home/darren/src/matplotlib/doc/build/html/_static/plot_directive'
The full traceback has been saved in /tmp/sphinx-err-qaZ8fg.log, if you want
toreport the issue to the author.
Please also report this if it was a user error, so that a better error
message can be provided next time.
Send reports to sph...@go.... Thanks!
Building HTML failed.
|
|
From: Darren D. <dsd...@gm...> - 2008-12-13 10:52:18
|
The 0.98.5 windows installer is still overwriting existing installations of configobj. This package is not needed by matplotlib and should not be installed on windows, nor should traits. I have removed configobj and enthought.traits from the trunk, but it is still present on the maintenance branches. On build systems, setup.cfg for the maintenance branches should be configured to not install configobj or traits under any circumstances. Once it has been so configured, the build directory needs to be deleted, because it probably contains a cached copy of configobj that will get incorporated into the installer the next time it is built, regardless of the settings in setup.cfg. This bug has been assigned to me, but it is out of my hands at this point. Darren |
|
From: Sandro T. <mat...@gm...> - 2008-12-13 08:36:54
|
Hi John, On Sat, Dec 13, 2008 at 01:49, John Hunter <jd...@gm...> wrote: > On Fri, Dec 12, 2008 at 6:21 PM, Sandro Tosi <mo...@de...> wrote: >> Hello guys, >> since I'm going to update debian matplotlib pkg to 0.98.5 I'd like to >> know how much dvipng lib is needed to let matplotlib work. > > It's strictly optional, for the "usetex" mode, which is not turned on > by default. Our native mathtext is good enough for most use cases, > and those who want tex rendering can "apt-get install dvipng" Thanks for the quick reply! I moved dvipng to Suggests (so that it remains a trace of it in the package, for the users who want to install it manually): the net result would be much less packages to download (and install) to use mpl on Debian/Ubuntu. Cheers, -- Sandro Tosi (aka morph, Morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi |
|
From: John H. <jd...@gm...> - 2008-12-13 00:49:12
|
On Fri, Dec 12, 2008 at 6:21 PM, Sandro Tosi <mo...@de...> wrote: > Hello guys, > since I'm going to update debian matplotlib pkg to 0.98.5 I'd like to > know how much dvipng lib is needed to let matplotlib work. It's strictly optional, for the "usetex" mode, which is not turned on by default. Our native mathtext is good enough for most use cases, and those who want tex rendering can "apt-get install dvipng" JDH |
|
From: Neal B. <ndb...@gm...> - 2008-12-13 00:21:51
|
Charlie Moad wrote: > I'm not seeing this on OSX. Is anyone else experiencing this issue? > > - Charlie Please see http://permalink.gmane.org/gmane.comp.python.matplotlib.general/15425 |
|
From: Sandro T. <mo...@de...> - 2008-12-13 00:21:19
|
Hello guys, since I'm going to update debian matplotlib pkg to 0.98.5 I'd like to know how much dvipng lib is needed to let matplotlib work. This is because adding a strong dependency on it (so that it's installed everytime you install mpl) will take in even texlive, and all its dependency, amounting in more than 200mb of space (an issue presents even in ubuntu). If dvipng (+texlive) is only needed for some "not-so-common" situations (for example only to print complex math expression) then we can move it to a wicker dependency, so that it's installed only if expressly requested by the user (we'll inform users about this change). Thanks for the attention, -- Sandro Tosi (aka morph, Morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi |
|
From: Charlie M. <cw...@gm...> - 2008-12-13 00:11:04
|
I'm not seeing this on OSX. Is anyone else experiencing this issue? - Charlie On Fri, Dec 12, 2008 at 2:39 PM, Neal Becker <ndb...@gm...> wrote: > sudo easy_install -U matplotlib > Searching for matplotlib > Reading http://pypi.python.org/simple/matplotlib/ > Reading http://matplotlib.sourceforge.net > Reading https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194 > Reading https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=82474 > Reading http://sourceforge.net/project/showfiles.php?group_id=80706 > Best match: matplotlib 0.98.5 > Downloading http://downloads.sourceforge.net/matplotlib/matplotlib-0.98.5.tar.gz?modtime=1229034572&big_mirror=0 > Processing matplotlib-0.98.5.tar.gz > Running matplotlib-0.98.5/setup.py -q bdist_egg --dist-dir /tmp/easy_install-CC1jw7/matplotlib-0.98.5/egg-dist-tmp-NSNvcC > ============================================================================ > BUILDING MATPLOTLIB > matplotlib: 0.98.5 > python: 2.5.2 (r252:60911, Sep 30 2008, 15:42:03) [GCC > 4.3.2 20080917 (Red Hat 4.3.2-4)] > platform: linux2 > > REQUIRED DEPENDENCIES > numpy: 1.2.0 > freetype2: 9.18.3 > > OPTIONAL BACKEND DEPENDENCIES > libpng: 1.2.33 > Tkinter: Tkinter: 50704, Tk: 8.5, Tcl: 8.5 > * Guessing the library and include directories for > * Tcl and Tk because the tclConfig.sh and > * tkConfig.sh could not be found and/or parsed. > wxPython: 2.8.9.1 > * WxAgg extension not required for wxPython >= 2.8 > Gtk+: gtk+: 2.14.4, glib: 2.18.3, pygtk: 2.13.0, > pygobject: 2.15.4 > Mac OS X native: no > Qt: Qt: 3.3.8, PyQt: 3.17.4 > Qt4: Qt: 4.4.1, PyQt4: 4.4.3 > Cairo: 1.4.12 > > OPTIONAL DATE/TIMEZONE DEPENDENCIES > datetime: present, version unknown > dateutil: 1.4 > pytz: 2006p > > OPTIONAL USETEX DEPENDENCIES > dvipng: 1.11 > ghostscript: 8.63 > latex: 3.141592 > > EXPERIMENTAL CONFIG PACKAGE DEPENDENCIES > configobj: 4.5.2 > enthought.traits: no > > [Edit setup.cfg to suppress the above messages] > ============================================================================ > error: lib/matplotlib/mpl-data/matplotlib.conf.template: No such file or directory > Exception exceptions.OSError: (2, 'No such file or directory', 'src/image.cpp') in <bound method CleanUpFile.__del__ of <setupext.CleanUpFile instance at 0x7fc85b3c51b8>> ignored > Exception exceptions.OSError: (2, 'No such file or directory', 'src/path.cpp') in <bound method CleanUpFile.__del__ of <setupext.CleanUpFile instance at 0x7fc85b3c4638>> ignored > Exception exceptions.OSError: (2, 'No such file or directory', 'src/backend_gdk.c') in <bound method CleanUpFile.__del__ of <setupext.CleanUpFile instance at 0x7fc85978c7a0>> ignored > Exception exceptions.OSError: (2, 'No such file or directory', 'src/backend_agg.cpp') in <bound method CleanUpFile.__del__ of <setupext.CleanUpFile instance at 0x7fc85b3c4fc8>> ignored > > > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
|
From: Darren D. <dsd...@gm...> - 2008-12-12 22:01:52
|
On Fri, Dec 12, 2008 at 3:55 PM, Michael Droettboom <md...@st...> wrote:
> <snip>
>
> Darren Dale wrote:
>
>>
>> And I forgot that because mathtext used to be an all-or-nothing
>> enterprise, there was no reason to escape the $ in regular text. Once you
>> made it possible to embed mathtext in a regular string, I think it would
>> have been better in the long run to require \$, but the powerful financial
>> interests and their fat-cat lobbyists won the day.
>>
> lol ... I'm ready for my payout now... :)
>
>>
>> What I would prefer is to raise a deprecation warning when an odd number
>> of dollar signs are encountered, giving people time to learn to escape their
>> $ and modify their code. I wonder how disruptive this would be to people
>> using mpl for finance? If that is unacceptable, I guess the best solution is
>> as you propose, but maybe usetex should issue a warning that it has modified
>> the string rather than strictly interpret it.
>>
> That sounds like a good solution going forward.
>
>>
>> Do you know if there are any other inconsistencies between the
>> text/mathtext markup and latex?
>>
>> Doh! That's actually a very illuminating question... One which, had I
> thought of it earlier, I might have never thought of dealing with $ at
> all... ;)
>
> Basically anything that is meaningful markup in TeX would have to be
> escaped for usetex, but not for regular text. In that sense, $ is just one
> of many. Think of "{brackets}", for instance. You get "{brackets}" with
> regular text, and "brackets" with usetex. I'm sure the list of these things
> is fairly long.
What else is there that is likely to cause problems going from mpltext to
usetex? math: \( \). displaymath (which is not supported in mathtext and
strongly discouraged in usetex): \[ \], $$ $$ . \( \) are probably so rarely
used in regular text that they could be made to mean the same thing in
mathtext as they do in usetex. displaymath could raise an error in both
usetex and mathtext. ^ and _ render in regular text but raises an error
outside of mathmode with usetex (my installation of texlive actually
attempts to do the right thing and insert the missing mathmode characters in
the case of ^ and _.) %. ~ (nonbreaking space). #. Unicode? Ugh.
> We don't want to start implicitly escaping those for usetex. All this
> supports the theory that perhaps the gap between regular text and usetex is
> too wide to reasonably bridge.
>
> While originally this morning thought "let's just fix the inconsistencies",
> I'm now leaning to just adding a note to the docs that "regular text and
> usetex is fundamentally incompatible in a lot of ways" and leaving it at
> that.
>
I think it would be worth stating in the docs that # $ % & ~ _ ^ \ { } \( \)
\[ \] have special meaning in latex but not in regular mpl text, so buyer
beware. It might be nice if mpl regular text rendered the escaped version of
all these characters the same way latex does, that would make it easier to
go from text to usetex.
Speaking of implicitly doing the right thing, last night I was in the middle
of working through a difficult bug when Windows Vista *kicked me out without
asking or issuing a warning*, installed updates, and rebooted. I'm still
mumbling under my breath about it. Friggin jerks.
|
|
From: Michael D. <md...@st...> - 2008-12-12 20:55:36
|
<snip>
Darren Dale wrote:
>
> And I forgot that because mathtext used to be an all-or-nothing
> enterprise, there was no reason to escape the $ in regular text. Once
> you made it possible to embed mathtext in a regular string, I think it
> would have been better in the long run to require \$, but the powerful
> financial interests and their fat-cat lobbyists won the day.
lol ... I'm ready for my payout now... :)
>
>
> What I would prefer is to raise a deprecation warning when an odd
> number of dollar signs are encountered, giving people time to learn to
> escape their $ and modify their code. I wonder how disruptive this
> would be to people using mpl for finance? If that is unacceptable, I
> guess the best solution is as you propose, but maybe usetex should
> issue a warning that it has modified the string rather than strictly
> interpret it.
That sounds like a good solution going forward.
>
> Do you know if there are any other inconsistencies between the
> text/mathtext markup and latex?
>
Doh! That's actually a very illuminating question... One which, had I
thought of it earlier, I might have never thought of dealing with $ at
all... ;)
Basically anything that is meaningful markup in TeX would have to be
escaped for usetex, but not for regular text. In that sense, $ is just
one of many. Think of "{brackets}", for instance. You get "{brackets}"
with regular text, and "brackets" with usetex. I'm sure the list of
these things is fairly long. We don't want to start implicitly escaping
those for usetex. All this supports the theory that perhaps the gap
between regular text and usetex is too wide to reasonably bridge.
While originally this morning thought "let's just fix the
inconsistencies", I'm now leaning to just adding a note to the docs that
"regular text and usetex is fundamentally incompatible in a lot of ways"
and leaving it at that.
Mike
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
|
|
From: John H. <jd...@gm...> - 2008-12-12 20:49:08
|
On Fri, Dec 12, 2008 at 2:41 PM, Darren Dale <dsd...@gm...> wrote: > What I would prefer is to raise a deprecation warning when an odd number of > dollar signs are encountered, giving people time to learn to escape their $ > and modify their code. I wonder how disruptive this would be to people using > mpl for finance? Well, we used to need lots of dollar signs, but with the market crash and credit crunch, we will probably get by with fewer going forward <wink> This is fine with me -- I suspect it is a very rare corner case. JDH |
|
From: Darren D. <dsd...@gm...> - 2008-12-12 20:42:03
|
On Fri, Dec 12, 2008 at 2:22 PM, Michael Droettboom <md...@st...> wrote: > Darren Dale wrote: > >> On Fri, Dec 12, 2008 at 1:06 PM, Michael Droettboom <md...@st...<mailto: >> md...@st...>> wrote: >> >> Darren Dale wrote: >> >> On Fri, Dec 12, 2008 at 9:46 AM, Michael Droettboom >> <md...@st... <mailto:md...@st...> >> <mailto:md...@st... <mailto:md...@st...>>> wrote: >> >> Manuel Metz wrote: >> > Michael Droettboom wrote: >> > >> >> There was a discussion on this list around a year ago about >> this. The >> >> concern was that not rendering $ as $ would break >> (matplotlib) >> backward >> >> compatibility with scripts that don't care about math at all >> but use a >> >> lot of dollar signs (e.g. financial plots). This is one >> of the few >> >> places where we deliberately broke usetex compatibility in >> favour of >> >> matplotlib compatibility. >> >> >> >> That said, it's probably a bug that the escaped dollar >> sign in >> non-math >> >> context is not rendered as a dollar sign. >> >> >> >> As a workaround "$\$%1.2f$" works with usetex on or off, >> with the >> >> proviso that it uses math- rather than text-rendering >> for the >> numbers. >> >> >> >> Mike >> >> >> > >> > In that case I suggest to note this somewhere in the docs >> (and User >> > Guide) with three exclamation marks (or is it ???). >> > >> So there's really two sub-bugs here: >> >> 1) '\$8' gives '\$8' in mathtext (well, actually it gets >> sent verbatim >> to the non-math text renderer, which is a bug). This, >> IMHO, is a >> "must-fix". >> >> 2) '$8' gives '$8' in mathtext and an error in usetex. >> This could be >> solved in two ways: >> >> a) document the difference >> b) make '$8' give '$8' in usetex as well >> >> I realise b) is technically making usetex accept a string >> that is not >> normally valid TeX -- but it's not like a user would ever enter >> '$8' and >> *want* to get a TeX error back. And usetex strings aren't >> perfectly TeX >> anyway. >> >> Personally, I'm leaning toward b), because it requires less >> mental >> effort for the user turning usetex on/off. And it doesn't >> force us to >> backtrack on the idea of supporting "$100.00" easily. >> >> But before I commit -- any feedback? >> >> I opposed to b). If we go that route, we can look forward to >> advertising usetex as "a latex backend, with familiar, >> standard latex markup, except when it isnt." >> >> It's not as bad as that. '\$8' will still work as in LaTeX as it >> always has and as a LaTeX expert would expect it to. All I'm >> proposing is that '$8', which is currently a LaTeX syntax error, >> will behave as it does when usetex is turned off. So it's not >> breaking anything that's already valid. >> >> It's a question of which pain is worse, I guess. >> >> The deeper question is -- should usetex even strive to have any >> compatibility with standard text? If not, then I can see your point. >> >> >> http://matplotlib.sourceforge.net/users/mathtext.html advertises \$ as >> markup for $. >> > That's always worked and still worked -- that's not the bug at hand. > >> I think it was unwise to accept $ for $ in mathtext in the first place, >> since mathtext uses tex markup anyway. >> > I'm not proposing that at all. I think we're running into a > misunderstanding about what I mean by "mathtext" and the scope of the > proposed change. By mathtext, I mean "the text between a pair of $ $ when > usetex is off". mathtext aims to be TeX-compatible (for a subset). Regular > text does not (and in fact has no markup whatsoever). That last point, I > believe, is the root of this problem and why reconciling usetex with > non-usetex may be a losing battle, as you're starting to convince me. > usetex is simply not the same thing as regular matplotlib text. > > I'll clarify anyway -- but I'm starting to think that unless there is > someone doing financial plots with usetex that is dying for this feature, > I'll just leave it. > > The bug at hand deals with regular text, not math text. There has been a > test in the non-usetex code path for a long time to determine if there is > any math in the string (by looking for an even number of non-escaped $) and > allow the simple monetary case to work without needing to escape the $. Right. I'm not criticizing the work you did on mathtext, which I think is amazing and could not have done myself. And I forgot that because mathtext used to be an all-or-nothing enterprise, there was no reason to escape the $ in regular text. Once you made it possible to embed mathtext in a regular string, I think it would have been better in the long run to require \$, but the powerful financial interests and their fat-cat lobbyists won the day. > It used to be impossible to interleave math and regular text in the same > string and I needed a way to add support for interleaving without breaking > existing usage, and without requiring an explicit flag saying "my string has > math". It's not perfect -- if you want to have math *and* use a dollar > sign, you still have to know what you're doing and do some sort of escaping. > But it's served well for over a year. > Thanks for reminding me, I forgot the context. > > The question, then, is whether to bring those smarts over to usetex, and > whether any sort of usetex/non-usetex consistency is a goal. > >> >> If we went with b), how sure are you that you can identify when a dollar >> sign is intended and when mathmode is intended? Does "$A-$100+B*$200$" mean >> $(A-100+200B) or A-100+200 or ..., I know this is an unlikely example, I'm >> just trying to think of the unintended consequences of circumventing one of >> the least buggy pieces of software in existence (I mean tex, not latex). >> >> It means [A-]100+B*[200] (where the contents in brackets is math, > otherwise text), just like in TeX. An example where there is ambiguity is > when you have an odd number, such as "$A-$100+B$". In TeX, that's a syntax > error, but with my proposed change (and in non-usetex already) it would > render as "$A-$100+B$". So at best, it's a "does the right thing", and at > worst is a "silent fail", depending on your perspective. > > Hope that clears things up. > What I would prefer is to raise a deprecation warning when an odd number of dollar signs are encountered, giving people time to learn to escape their $ and modify their code. I wonder how disruptive this would be to people using mpl for finance? If that is unacceptable, I guess the best solution is as you propose, but maybe usetex should issue a warning that it has modified the string rather than strictly interpret it. Do you know if there are any other inconsistencies between the text/mathtext markup and latex? |
|
From: Neal B. <ndb...@gm...> - 2008-12-12 19:40:00
|
sudo easy_install -U matplotlib Searching for matplotlib Reading http://pypi.python.org/simple/matplotlib/ Reading http://matplotlib.sourceforge.net Reading https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194 Reading https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=82474 Reading http://sourceforge.net/project/showfiles.php?group_id=80706 Best match: matplotlib 0.98.5 Downloading http://downloads.sourceforge.net/matplotlib/matplotlib-0.98.5.tar.gz?modtime=1229034572&big_mirror=0 Processing matplotlib-0.98.5.tar.gz Running matplotlib-0.98.5/setup.py -q bdist_egg --dist-dir /tmp/easy_install-CC1jw7/matplotlib-0.98.5/egg-dist-tmp-NSNvcC ============================================================================ BUILDING MATPLOTLIB matplotlib: 0.98.5 python: 2.5.2 (r252:60911, Sep 30 2008, 15:42:03) [GCC 4.3.2 20080917 (Red Hat 4.3.2-4)] platform: linux2 REQUIRED DEPENDENCIES numpy: 1.2.0 freetype2: 9.18.3 OPTIONAL BACKEND DEPENDENCIES libpng: 1.2.33 Tkinter: Tkinter: 50704, Tk: 8.5, Tcl: 8.5 * Guessing the library and include directories for * Tcl and Tk because the tclConfig.sh and * tkConfig.sh could not be found and/or parsed. wxPython: 2.8.9.1 * WxAgg extension not required for wxPython >= 2.8 Gtk+: gtk+: 2.14.4, glib: 2.18.3, pygtk: 2.13.0, pygobject: 2.15.4 Mac OS X native: no Qt: Qt: 3.3.8, PyQt: 3.17.4 Qt4: Qt: 4.4.1, PyQt4: 4.4.3 Cairo: 1.4.12 OPTIONAL DATE/TIMEZONE DEPENDENCIES datetime: present, version unknown dateutil: 1.4 pytz: 2006p OPTIONAL USETEX DEPENDENCIES dvipng: 1.11 ghostscript: 8.63 latex: 3.141592 EXPERIMENTAL CONFIG PACKAGE DEPENDENCIES configobj: 4.5.2 enthought.traits: no [Edit setup.cfg to suppress the above messages] ============================================================================ error: lib/matplotlib/mpl-data/matplotlib.conf.template: No such file or directory Exception exceptions.OSError: (2, 'No such file or directory', 'src/image.cpp') in <bound method CleanUpFile.__del__ of <setupext.CleanUpFile instance at 0x7fc85b3c51b8>> ignored Exception exceptions.OSError: (2, 'No such file or directory', 'src/path.cpp') in <bound method CleanUpFile.__del__ of <setupext.CleanUpFile instance at 0x7fc85b3c4638>> ignored Exception exceptions.OSError: (2, 'No such file or directory', 'src/backend_gdk.c') in <bound method CleanUpFile.__del__ of <setupext.CleanUpFile instance at 0x7fc85978c7a0>> ignored Exception exceptions.OSError: (2, 'No such file or directory', 'src/backend_agg.cpp') in <bound method CleanUpFile.__del__ of <setupext.CleanUpFile instance at 0x7fc85b3c4fc8>> ignored |
|
From: Michael D. <md...@st...> - 2008-12-12 19:22:58
|
Thanks. These are really helpful pointers. For me, this is the one missing piece that would help me use git full-time, particularly with the way matplotlib and other projects I work on are laid out in SVN. So I'm pretty motivated to figure this out. I'll certainly share any findings in this regard. Cheers, Mike Andrew Straw wrote: > Hi Mike, > > I have not imported the branches. ( IIRC, this was there were several > that weren't MPL but other parts of the repo such as py4science, > toolkits and so on). It may be possible to add just the 0.98.5 > maintenance branch without the others, but I won't have a chance > immediately to play around with that. > > To add all the branches to your git repo, you might be able to add > something like "branches = branches/*:refs/remotes/branches/*" to the > [svn-remote "svn"] section of .git/config and re-do "git svn fetch"... > This will grab all the branches over all svn history, which will, I > think, pull in py4science and toolkits branches... And I guess the > download time from svn will be extremely long... In that case it's > probably better to rsync from sourceforge's server to a local disk and > do the git svn checkout that way making a whole new git repo. > > It may be worth attempting to talk to some real git/svn gurus at this > point about tracking (only one or a couple) svn branches with git > branches. So far, I've only dealt with the trunk in my git/svn > interoperation experience. > > -Andrew > > Michael Droettboom wrote: > >> Thanks. I've incorporated your docs into the developer documentation. >> >> My next experiment will be to see if I can track the 0.98.5 maintenance >> branch with git. SVN tags/* show up as available remote branches, but >> not branches/*, which leaves me a bit stumped? If you've done this and >> there's a quick answer, let me know, otherwise I'll do a little digging >> to see if it's possible. >> >> Mike >> >> Andrew Straw wrote: >> >>> Hi Michael, >>> >>> The main issue is that we can't use git "normally" because the main >>> history will be kept with svn. Thus, there's going to be a lot of >>> history rewriting going on through the rebase command. (These >>> complications are obviously not the ideal scenario for git newbies...) >>> Rather than answer your questions directly, I'll walk you through how I >>> do things. (This is not tried on the MPL svn repo, but some a private >>> svn repo. I don't see any fundamental differences, though. So this >>> should work.) >>> >>> (Hopefully this will be cut-and-pasteable ReST, which could go in the >>> docs somewhere): >>> >>> Making a git feature branch and committing to svn trunk >>> ------------------------------------------------------- >>> >>> Start with a virgin tree in sync with the svn trunk on the git branch >>> "master":: >>> >>> git checkout master >>> git svn rebase >>> >>> To create a new, local branch called "whizbang-branch":: >>> >>> git checkout -b whizbang-branch >>> >>> Do make commits to the local branch:: >>> >>> # hack on a bunch of files >>> git add bunch of files >>> git commit -m "modified a bunch of files" >>> # repeat this as necessary >>> >>> Now, go back to the master branch and append the history of your branch >>> to the master branch, which will end up as the svn trunk:: >>> >>> git checkout master >>> git svn rebase # Ensure we have most recent svn >>> git rebase whizbang-branch # Append whizbang changes to master branch >>> git svn dcommit -n # Check that this will apply to svn >>> git svn dcommit # Actually apply to svn >>> >>> Finally, you may want to continue working on your whizbang-branch, so >>> rebase it to the new master:: >>> >>> git checkout whizbang-branch >>> git rebase master >>> >>> Michael Droettboom wrote: >>> >>> >>>> This is mostly for Andrew Straw, but thought anyone else experimenting >>>> with git may be interested. I'm going through some real newbie pains >>>> here, and I don't think what I'm doing is all that advanced. >>>> >>>> So, I've had a local git repository cloned from github (as per Andrew's >>>> instructions), made a branch, started hacking, all is well. Now, I >>>> would like to update my master branch from SVN to get some of the recent >>>> changes others have been making. >>>> >>>> Following the instructions in the FAQ, >>>> >>>> git svn rebase >>>> >>>> actually results in a number of conflicts in files I didn't touch. I >>>> shouldn't have to resolve this conflicts, right? 'git status' shows no >>>> local changes, nothing staged -- nothing that should conflict. >>>> >>>> It turns out, if I do >>>> >>>> git pull >>>> >>>> then, >>>> >>>> git svn rebase >>>> >>>> all is well. >>>> >>>> Any idea why? Should I add that to the instructions in the FAQ? >>>> >>>> Now, here's where I'm really stumped. I finished my experimental >>>> branch, and I would like to commit it back to SVN. >>>> >>>> This is what I did, with comments preceded by '#' >>>> >>>> # Go back to the master branch >>>> >>>> >>>>> git checkout master >>>>> >>>>> >>>> # Merge in experimental >>>> >>>> >>>>> git merge experimental >>>>> >>>>> >>>> # Ok -- looks good: experimental new feature is integrated, there were >>>> no conflicts >>>> # However... >>>> >>>> >>>>> git svn dcommit >>>>> >>>>> >>>> Committing to >>>> https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib >>>> ... >>>> Merge conflict during commit: File or directory >>>> 'doc/users/whats_new.rst' is out of date; try updating: resource out of >>>> date; try updating at /home/mdroe/usr/libexec/git-core//git-svn line 467 >>>> # 1) I didn't change that file, why should I care >>>> # 2) I don't know who to update it >>>> >>>> >>>>> git pull >>>>> >>>>> >>>> Already up-to-date. >>>> >>>> >>>>> git svn rebase >>>>> >>>>> >>>> First, rewinding head to replay your work on top of it... >>>> Applying: more doc adds >>>> /home/mdroe/builds/matplotlib.git/.git/rebase-apply/patch:14: trailing >>>> whitespace. >>>> a lot of new features and bug-fixes. warning: 1 line adds whitespace >>>> errors. >>>> Applying: added some docs for linestyles and markers >>>> Applying: Remove trailing whitespace. >>>> Applying: figure/subplot and font_manager bugfixes >>>> Applying: added support for xlwt in exceltools >>>> Applying: fixed a typo in whats_new_98_4_legend.py >>>> Applying: fixed typo in Line2D.set_marker doc. >>>> Applying: /matplotlib/__init__.py: catch OSError when calling subprocess. >>>> Applying: more doc adds >>>> /home/mdroe/builds/matplotlib.git/.git/rebase-apply/patch:14: trailing >>>> whitespace. >>>> a lot of new features and bug-fixes. error: patch failed: >>>> doc/users/whats_new.rst:10 >>>> error: doc/users/whats_new.rst: patch does not apply >>>> Using index info to reconstruct a base tree... >>>> <stdin>:14: trailing whitespace. >>>> a lot of new features and bug-fixes. warning: 1 line adds whitespace >>>> errors. >>>> Falling back to patching base and 3-way merge... >>>> No changes -- Patch already applied. >>>> Applying: added some docs for linestyles and markers >>>> error: patch failed: doc/devel/coding_guide.rst:62 >>>> error: doc/devel/coding_guide.rst: patch does not apply >>>> error: patch failed: doc/matplotlibrc:43 >>>> error: doc/matplotlibrc: patch does not apply >>>> error: patch failed: doc/pyplots/whats_new_98_4_legend.py:4 >>>> error: doc/pyplots/whats_new_98_4_legend.py: patch does not apply >>>> error: patch failed: lib/matplotlib/lines.py:313 >>>> error: lib/matplotlib/lines.py: patch does not apply >>>> Using index info to reconstruct a base tree... >>>> Falling back to patching base and 3-way merge... >>>> Auto-merged doc/pyplots/whats_new_98_4_legend.py >>>> CONFLICT (content): Merge conflict in doc/pyplots/whats_new_98_4_legend.py >>>> Auto-merged lib/matplotlib/lines.py >>>> Failed to merge in the changes. >>>> Patch failed at 0010. >>>> >>>> When you have resolved this problem run "git rebase --continue". >>>> If you would prefer to skip this patch, instead run "git rebase --skip". >>>> To restore the original branch and stop rebasing run "git rebase --abort". >>>> >>>> rebase refs/remotes/trunk: command returned error: 1 >>>> # Ok, I'm back to merging files that don't conflict with my changes! # I >>>> shouldn't have to do that, right? >>>> # And FYI: >>>> >>>> >>>>> git status >>>>> >>>>> >>>> doc/pyplots/whats_new_98_4_legend.py: needs merge >>>> # Not currently on any branch. >>>> # Changes to be committed: >>>> # (use "git reset HEAD <file>..." to unstage) >>>> # >>>> # modified: lib/matplotlib/lines.py >>>> # >>>> # Changed but not updated: >>>> # (use "git add <file>..." to update what will be committed) >>>> # >>>> # unmerged: doc/pyplots/whats_new_98_4_legend.py >>>> # >>>> # Untracked files: >>>> # (use "git add <file>..." to include in what will be committed) >>>> # >>>> # lib/matplotlib/mpl-data/matplotlib.conf >>>> # lib/matplotlib/mpl-data/matplotlibrc >>>> # setupext.pyc >>>> # src/backend_agg.cpp~ >>>> >>>> Now I feel stuck. How do I "undo" the merge from experimental to master? >>>> >>>> Sorry if these are obvious questions, but I think I've followed the >>>> git-svn instructions -- I must have made a mistake somewhere along the >>>> way, but I'm not sure how to debug and/or fix it. >>>> >>>> Mike >>>> >>>> >>> >>> >> ------------------------------------------------------------------------------ >> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. >> The future of the web can't happen without you. Join us at MIX09 to help >> pave the way to the Next Web now. Learn more and register at >> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA |
|
From: Michael D. <md...@st...> - 2008-12-12 19:22:28
|
Darren Dale wrote: > On Fri, Dec 12, 2008 at 1:06 PM, Michael Droettboom <md...@st... > <mailto:md...@st...>> wrote: > > Darren Dale wrote: > > On Fri, Dec 12, 2008 at 9:46 AM, Michael Droettboom > <md...@st... <mailto:md...@st...> > <mailto:md...@st... <mailto:md...@st...>>> wrote: > > Manuel Metz wrote: > > Michael Droettboom wrote: > > > >> There was a discussion on this list around a year ago about > this. The > >> concern was that not rendering $ as $ would break > (matplotlib) > backward > >> compatibility with scripts that don't care about math at all > but use a > >> lot of dollar signs (e.g. financial plots). This is one > of the few > >> places where we deliberately broke usetex compatibility in > favour of > >> matplotlib compatibility. > >> > >> That said, it's probably a bug that the escaped dollar > sign in > non-math > >> context is not rendered as a dollar sign. > >> > >> As a workaround "$\$%1.2f$" works with usetex on or off, > with the > >> proviso that it uses math- rather than text-rendering > for the > numbers. > >> > >> Mike > >> > > > > In that case I suggest to note this somewhere in the docs > (and User > > Guide) with three exclamation marks (or is it ???). > > > So there's really two sub-bugs here: > > 1) '\$8' gives '\$8' in mathtext (well, actually it gets > sent verbatim > to the non-math text renderer, which is a bug). This, > IMHO, is a > "must-fix". > > 2) '$8' gives '$8' in mathtext and an error in usetex. > This could be > solved in two ways: > > a) document the difference > b) make '$8' give '$8' in usetex as well > > I realise b) is technically making usetex accept a string > that is not > normally valid TeX -- but it's not like a user would ever enter > '$8' and > *want* to get a TeX error back. And usetex strings aren't > perfectly TeX > anyway. > > Personally, I'm leaning toward b), because it requires less > mental > effort for the user turning usetex on/off. And it doesn't > force us to > backtrack on the idea of supporting "$100.00" easily. > > But before I commit -- any feedback? > > I opposed to b). If we go that route, we can look forward to > advertising usetex as "a latex backend, with familiar, > standard latex markup, except when it isnt." > > It's not as bad as that. '\$8' will still work as in LaTeX as it > always has and as a LaTeX expert would expect it to. All I'm > proposing is that '$8', which is currently a LaTeX syntax error, > will behave as it does when usetex is turned off. So it's not > breaking anything that's already valid. > > It's a question of which pain is worse, I guess. > > The deeper question is -- should usetex even strive to have any > compatibility with standard text? If not, then I can see your point. > > > http://matplotlib.sourceforge.net/users/mathtext.html advertises \$ as > markup for $. That's always worked and still worked -- that's not the bug at hand. > I think it was unwise to accept $ for $ in mathtext in the first > place, since mathtext uses tex markup anyway. I'm not proposing that at all. I think we're running into a misunderstanding about what I mean by "mathtext" and the scope of the proposed change. By mathtext, I mean "the text between a pair of $ $ when usetex is off". mathtext aims to be TeX-compatible (for a subset). Regular text does not (and in fact has no markup whatsoever). That last point, I believe, is the root of this problem and why reconciling usetex with non-usetex may be a losing battle, as you're starting to convince me. usetex is simply not the same thing as regular matplotlib text. I'll clarify anyway -- but I'm starting to think that unless there is someone doing financial plots with usetex that is dying for this feature, I'll just leave it. The bug at hand deals with regular text, not math text. There has been a test in the non-usetex code path for a long time to determine if there is any math in the string (by looking for an even number of non-escaped $) and allow the simple monetary case to work without needing to escape the $. It used to be impossible to interleave math and regular text in the same string and I needed a way to add support for interleaving without breaking existing usage, and without requiring an explicit flag saying "my string has math". It's not perfect -- if you want to have math *and* use a dollar sign, you still have to know what you're doing and do some sort of escaping. But it's served well for over a year. The question, then, is whether to bring those smarts over to usetex, and whether any sort of usetex/non-usetex consistency is a goal. > > If we went with b), how sure are you that you can identify when a > dollar sign is intended and when mathmode is intended? Does > "$A-$100+B*$200$" mean $(A-100+200B) or A-100+200 or ..., I know this > is an unlikely example, I'm just trying to think of the unintended > consequences of circumventing one of the least buggy pieces of > software in existence (I mean tex, not latex). > It means [A-]100+B*[200] (where the contents in brackets is math, otherwise text), just like in TeX. An example where there is ambiguity is when you have an odd number, such as "$A-$100+B$". In TeX, that's a syntax error, but with my proposed change (and in non-usetex already) it would render as "$A-$100+B$". So at best, it's a "does the right thing", and at worst is a "silent fail", depending on your perspective. Hope that clears things up. Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA |
|
From: Andrew S. <str...@as...> - 2008-12-12 18:44:54
|
Hi Mike, I have not imported the branches. ( IIRC, this was there were several that weren't MPL but other parts of the repo such as py4science, toolkits and so on). It may be possible to add just the 0.98.5 maintenance branch without the others, but I won't have a chance immediately to play around with that. To add all the branches to your git repo, you might be able to add something like "branches = branches/*:refs/remotes/branches/*" to the [svn-remote "svn"] section of .git/config and re-do "git svn fetch"... This will grab all the branches over all svn history, which will, I think, pull in py4science and toolkits branches... And I guess the download time from svn will be extremely long... In that case it's probably better to rsync from sourceforge's server to a local disk and do the git svn checkout that way making a whole new git repo. It may be worth attempting to talk to some real git/svn gurus at this point about tracking (only one or a couple) svn branches with git branches. So far, I've only dealt with the trunk in my git/svn interoperation experience. -Andrew Michael Droettboom wrote: > Thanks. I've incorporated your docs into the developer documentation. > > My next experiment will be to see if I can track the 0.98.5 maintenance > branch with git. SVN tags/* show up as available remote branches, but > not branches/*, which leaves me a bit stumped? If you've done this and > there's a quick answer, let me know, otherwise I'll do a little digging > to see if it's possible. > > Mike > > Andrew Straw wrote: >> Hi Michael, >> >> The main issue is that we can't use git "normally" because the main >> history will be kept with svn. Thus, there's going to be a lot of >> history rewriting going on through the rebase command. (These >> complications are obviously not the ideal scenario for git newbies...) >> Rather than answer your questions directly, I'll walk you through how I >> do things. (This is not tried on the MPL svn repo, but some a private >> svn repo. I don't see any fundamental differences, though. So this >> should work.) >> >> (Hopefully this will be cut-and-pasteable ReST, which could go in the >> docs somewhere): >> >> Making a git feature branch and committing to svn trunk >> ------------------------------------------------------- >> >> Start with a virgin tree in sync with the svn trunk on the git branch >> "master":: >> >> git checkout master >> git svn rebase >> >> To create a new, local branch called "whizbang-branch":: >> >> git checkout -b whizbang-branch >> >> Do make commits to the local branch:: >> >> # hack on a bunch of files >> git add bunch of files >> git commit -m "modified a bunch of files" >> # repeat this as necessary >> >> Now, go back to the master branch and append the history of your branch >> to the master branch, which will end up as the svn trunk:: >> >> git checkout master >> git svn rebase # Ensure we have most recent svn >> git rebase whizbang-branch # Append whizbang changes to master branch >> git svn dcommit -n # Check that this will apply to svn >> git svn dcommit # Actually apply to svn >> >> Finally, you may want to continue working on your whizbang-branch, so >> rebase it to the new master:: >> >> git checkout whizbang-branch >> git rebase master >> >> Michael Droettboom wrote: >> >>> This is mostly for Andrew Straw, but thought anyone else experimenting >>> with git may be interested. I'm going through some real newbie pains >>> here, and I don't think what I'm doing is all that advanced. >>> >>> So, I've had a local git repository cloned from github (as per Andrew's >>> instructions), made a branch, started hacking, all is well. Now, I >>> would like to update my master branch from SVN to get some of the recent >>> changes others have been making. >>> >>> Following the instructions in the FAQ, >>> >>> git svn rebase >>> >>> actually results in a number of conflicts in files I didn't touch. I >>> shouldn't have to resolve this conflicts, right? 'git status' shows no >>> local changes, nothing staged -- nothing that should conflict. >>> >>> It turns out, if I do >>> >>> git pull >>> >>> then, >>> >>> git svn rebase >>> >>> all is well. >>> >>> Any idea why? Should I add that to the instructions in the FAQ? >>> >>> Now, here's where I'm really stumped. I finished my experimental >>> branch, and I would like to commit it back to SVN. >>> >>> This is what I did, with comments preceded by '#' >>> >>> # Go back to the master branch >>> >>>> git checkout master >>>> >>> # Merge in experimental >>> >>>> git merge experimental >>>> >>> # Ok -- looks good: experimental new feature is integrated, there were >>> no conflicts >>> # However... >>> >>>> git svn dcommit >>>> >>> Committing to >>> https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib >>> ... >>> Merge conflict during commit: File or directory >>> 'doc/users/whats_new.rst' is out of date; try updating: resource out of >>> date; try updating at /home/mdroe/usr/libexec/git-core//git-svn line 467 >>> # 1) I didn't change that file, why should I care >>> # 2) I don't know who to update it >>> >>>> git pull >>>> >>> Already up-to-date. >>> >>>> git svn rebase >>>> >>> First, rewinding head to replay your work on top of it... >>> Applying: more doc adds >>> /home/mdroe/builds/matplotlib.git/.git/rebase-apply/patch:14: trailing >>> whitespace. >>> a lot of new features and bug-fixes. warning: 1 line adds whitespace >>> errors. >>> Applying: added some docs for linestyles and markers >>> Applying: Remove trailing whitespace. >>> Applying: figure/subplot and font_manager bugfixes >>> Applying: added support for xlwt in exceltools >>> Applying: fixed a typo in whats_new_98_4_legend.py >>> Applying: fixed typo in Line2D.set_marker doc. >>> Applying: /matplotlib/__init__.py: catch OSError when calling subprocess. >>> Applying: more doc adds >>> /home/mdroe/builds/matplotlib.git/.git/rebase-apply/patch:14: trailing >>> whitespace. >>> a lot of new features and bug-fixes. error: patch failed: >>> doc/users/whats_new.rst:10 >>> error: doc/users/whats_new.rst: patch does not apply >>> Using index info to reconstruct a base tree... >>> <stdin>:14: trailing whitespace. >>> a lot of new features and bug-fixes. warning: 1 line adds whitespace >>> errors. >>> Falling back to patching base and 3-way merge... >>> No changes -- Patch already applied. >>> Applying: added some docs for linestyles and markers >>> error: patch failed: doc/devel/coding_guide.rst:62 >>> error: doc/devel/coding_guide.rst: patch does not apply >>> error: patch failed: doc/matplotlibrc:43 >>> error: doc/matplotlibrc: patch does not apply >>> error: patch failed: doc/pyplots/whats_new_98_4_legend.py:4 >>> error: doc/pyplots/whats_new_98_4_legend.py: patch does not apply >>> error: patch failed: lib/matplotlib/lines.py:313 >>> error: lib/matplotlib/lines.py: patch does not apply >>> Using index info to reconstruct a base tree... >>> Falling back to patching base and 3-way merge... >>> Auto-merged doc/pyplots/whats_new_98_4_legend.py >>> CONFLICT (content): Merge conflict in doc/pyplots/whats_new_98_4_legend.py >>> Auto-merged lib/matplotlib/lines.py >>> Failed to merge in the changes. >>> Patch failed at 0010. >>> >>> When you have resolved this problem run "git rebase --continue". >>> If you would prefer to skip this patch, instead run "git rebase --skip". >>> To restore the original branch and stop rebasing run "git rebase --abort". >>> >>> rebase refs/remotes/trunk: command returned error: 1 >>> # Ok, I'm back to merging files that don't conflict with my changes! # I >>> shouldn't have to do that, right? >>> # And FYI: >>> >>>> git status >>>> >>> doc/pyplots/whats_new_98_4_legend.py: needs merge >>> # Not currently on any branch. >>> # Changes to be committed: >>> # (use "git reset HEAD <file>..." to unstage) >>> # >>> # modified: lib/matplotlib/lines.py >>> # >>> # Changed but not updated: >>> # (use "git add <file>..." to update what will be committed) >>> # >>> # unmerged: doc/pyplots/whats_new_98_4_legend.py >>> # >>> # Untracked files: >>> # (use "git add <file>..." to include in what will be committed) >>> # >>> # lib/matplotlib/mpl-data/matplotlib.conf >>> # lib/matplotlib/mpl-data/matplotlibrc >>> # setupext.pyc >>> # src/backend_agg.cpp~ >>> >>> Now I feel stuck. How do I "undo" the merge from experimental to master? >>> >>> Sorry if these are obvious questions, but I think I've followed the >>> git-svn instructions -- I must have made a mistake somewhere along the >>> way, but I'm not sure how to debug and/or fix it. >>> >>> Mike >>> >> > > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel |
