matplotlib-devel Mailing List for matplotlib

I would suggest create a new branch, though. You can create a new branch
from the old one, then make your changes there. That way if you mess up
something you still have the original to fall back on.
On Thu, Jul 31, 2014 at 5:15 PM, Thomas Caswell <tca...@gm...> wrote:
> Git lets you re-write history pretty extensively. If you use a tool
> on top of git (I use magit in emacs) you can selectively commit hunks
> one or two at a time. At a minimum split it up by file. You are
> going to have to do some force-pushing anyway.
>
> Making the PRs as small as reasonable makes reviewing much easier. It
> makes it possible to go through the entire PR in one sitting and it
> allows the un-controversial stuff to be merged as quickly as possible
> without being held up by other parts. The longer large PRs hang
> around the greater the chance they will accumulate conflicts with
> other PRs and require a re-base (re-basing a 500+ line diff is
> _incredibly_ painful).
>
> Tom
>
> On Thu, Jul 31, 2014 at 11:09 AM, jamesramm <jam...@gm...> wrote:
> > Thomas Caswell wrote
> >> I only took a brief look at that branch, but two comments
> >>
> >> 1) can you clean up your git history, you are adding 20k new lines (of
> >> mostly freetype and random files that should not be tracked)
> >> 2) can you split the propertify work up into chunks that are easier to
> >> review?
> >
> > Yes. This is mostly my inability to use git (I've not particular used it
> > before). I'll have to look up how to clean the history and 'unversion'
> the
> > unneeded freetype stuff.
> >
> > As it is already committed to my branch, im not sure the existing stuff
> can
> > be split into chunks? But I will make issues and split up the next lumps
> of
> > work.
> >
> > I'll post back when it is (hopefully) cleaner
> >
> >
> >
> > --
> > View this message in context:
> http://matplotlib.1069221.n5.nabble.com/MEP13-python-containers-tp40248p43732.html
> > Sent from the matplotlib - devel mailing list archive at Nabble.com.
> >
> >
> ------------------------------------------------------------------------------
> > Infragistics Professional
> > Build stunning WinForms apps today!
> > Reboot your WinForms applications with our WinForms controls.
> > Build a bridge from your legacy apps to the future.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
> --
> Thomas Caswell
> tca...@gm...
>
>
> ------------------------------------------------------------------------------
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls.
> Build a bridge from your legacy apps to the future.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Git lets you re-write history pretty extensively. If you use a tool
on top of git (I use magit in emacs) you can selectively commit hunks
one or two at a time. At a minimum split it up by file. You are
going to have to do some force-pushing anyway.
Making the PRs as small as reasonable makes reviewing much easier. It
makes it possible to go through the entire PR in one sitting and it
allows the un-controversial stuff to be merged as quickly as possible
without being held up by other parts. The longer large PRs hang
around the greater the chance they will accumulate conflicts with
other PRs and require a re-base (re-basing a 500+ line diff is
_incredibly_ painful).
Tom
On Thu, Jul 31, 2014 at 11:09 AM, jamesramm <jam...@gm...> wrote:
> Thomas Caswell wrote
>> I only took a brief look at that branch, but two comments
>>
>> 1) can you clean up your git history, you are adding 20k new lines (of
>> mostly freetype and random files that should not be tracked)
>> 2) can you split the propertify work up into chunks that are easier to
>> review?
>
> Yes. This is mostly my inability to use git (I've not particular used it
> before). I'll have to look up how to clean the history and 'unversion' the
> unneeded freetype stuff.
>
> As it is already committed to my branch, im not sure the existing stuff can
> be split into chunks? But I will make issues and split up the next lumps of
> work.
>
> I'll post back when it is (hopefully) cleaner
>
>
>
> --
> View this message in context: http://matplotlib.1069221.n5.nabble.com/MEP13-python-containers-tp40248p43732.html
> Sent from the matplotlib - devel mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls.
> Build a bridge from your legacy apps to the future.
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Thomas Caswell
tca...@gm...

Thomas Caswell wrote
> I only took a brief look at that branch, but two comments
> 
> 1) can you clean up your git history, you are adding 20k new lines (of
> mostly freetype and random files that should not be tracked)
> 2) can you split the propertify work up into chunks that are easier to
> review?
Yes. This is mostly my inability to use git (I've not particular used it
before). I'll have to look up how to clean the history and 'unversion' the
unneeded freetype stuff. 
As it is already committed to my branch, im not sure the existing stuff can
be split into chunks? But I will make issues and split up the next lumps of
work.
I'll post back when it is (hopefully) cleaner
--
View this message in context: http://matplotlib.1069221.n5.nabble.com/MEP13-python-containers-tp40248p43732.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

I only took a brief look at that branch, but two comments
1) can you clean up your git history, you are adding 20k new lines (of
mostly freetype and random files that should not be tracked)
2) can you split the propertify work up into chunks that are easier to review?
On Thu, Jul 31, 2014 at 7:16 AM, jamesramm <jam...@gm...> wrote:
> It seens that discussion of properties has died off, but I see it as a very
> important implementation for 2 reasons:
>
> 1. It will help with the implementation of stylsheets and a DOM-type model
> as proposed in MEP25 and MEP26
>
> 2. The act of working through the code to add properties exposes any
> inconsistencies and vulnerabilities.
>
> I have been adding properties to my fork of MPL as part of the development
> of a visualisation tool.
> https://github.com/JamesRamm/matplotlib/tree/master/lib/matplotlib
>
> text.py and font-manager.py are completely 'propertyfied' and I have done a
> fair amount of work on artist.py, _axes.py, _base.py and axis.py
>
> Axis.py in particular is a sticking point, which has been difficult to add
> properties to. In any case, the fact that the Ticker() class exists points
> to some problems with this part of the code in particular. Ticker holds
> references too (or rather, the locator and formatter properties of Ticker)
> the axis object, yet is initialised within the initialisation of the axis
> class...
> This can be a problem.
>
> Looking through ticker.py, it seems that in most places, the need for a
> reference to axis is not necessary.
>
> Functions such as zoom and pan, which are within the Locator class in
> ticker, should actually be implemented in axis.py (as I have in my fork) as
> they have no dependency on Locator.
>
> Anyway, adding properties is a large job. I will probably implement them
> completely as part of my work, but:
>
> - Backwards compatibility will be broken
> - The resulting library will probably look a whole lot different to MPL.
>
> For those reasons, I doubt I will ever make a pull request for my fork and I
> will neglect areas such as the pyplot/pylab interfaces. IMO, have a nice
> simple, object oriented API negates the need for such interfaces and I am
> not concerned with keeping a 'matlab-user' community happy...
>
> I don't see the API of MPL changing this much anytime soon (or anytime
> really), but in order to keep up with newer libraries it probably should,
> and should not be concerned about backwards compatibility when it does...
>
>
>
> --
> View this message in context: http://matplotlib.1069221.n5.nabble.com/MEP13-python-containers-tp40248p43730.html
> Sent from the matplotlib - devel mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls.
> Build a bridge from your legacy apps to the future.
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Thomas Caswell
tca...@gm...

It seens that discussion of properties has died off, but I see it as a very
important implementation for 2 reasons:
1. It will help with the implementation of stylsheets and a DOM-type model
as proposed in MEP25 and MEP26
2. The act of working through the code to add properties exposes any
inconsistencies and vulnerabilities.
I have been adding properties to my fork of MPL as part of the development
of a visualisation tool.
https://github.com/JamesRamm/matplotlib/tree/master/lib/matplotlib
text.py and font-manager.py are completely 'propertyfied' and I have done a
fair amount of work on artist.py, _axes.py, _base.py and axis.py
Axis.py in particular is a sticking point, which has been difficult to add
properties to. In any case, the fact that the Ticker() class exists points
to some problems with this part of the code in particular. Ticker holds
references too (or rather, the locator and formatter properties of Ticker)
the axis object, yet is initialised within the initialisation of the axis
class...
This can be a problem.
Looking through ticker.py, it seems that in most places, the need for a
reference to axis is not necessary.
Functions such as zoom and pan, which are within the Locator class in
ticker, should actually be implemented in axis.py (as I have in my fork) as
they have no dependency on Locator.
Anyway, adding properties is a large job. I will probably implement them
completely as part of my work, but:
- Backwards compatibility will be broken
- The resulting library will probably look a whole lot different to MPL.
For those reasons, I doubt I will ever make a pull request for my fork and I
will neglect areas such as the pyplot/pylab interfaces. IMO, have a nice
simple, object oriented API negates the need for such interfaces and I am
not concerned with keeping a 'matlab-user' community happy...
I don't see the API of MPL changing this much anytime soon (or anytime
really), but in order to keep up with newer libraries it probably should,
and should not be concerned about backwards compatibility when it does...
--
View this message in context: http://matplotlib.1069221.n5.nabble.com/MEP13-python-containers-tp40248p43730.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

On Wed, Jul 30, 2014 at 11:20 AM, Gary Setter <gar...@ya...> wrote:
> Thank you for all the responds concerning Html Help. If someone would
> build using *class *sphinx.builders.htmlhelp.HTMLHelpBuilder and upload
> the outputs were I can get them,
>
It would probably be easier to clone the repo, install sphinx, and do that
step yourself...
But thanks for offering, this would be nice for some folks.
-Chris
> I have a HTML Help workshop installed on my desktop. I would gladly
> setup the project and build the dot chm file. I'll send the results were
> ever you wish.
> Best regards,
> Gary Setter
>
>
>
> ------------------------------------------------------------------------------
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls.
> Build a bridge from your legacy apps to the future.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

On 7/30/2014 11:20 AM, Gary Setter wrote:
> Thank you for all the responds concerning Html Help. If someone would
> build using /class /sphinx.builders.htmlhelp.HTMLHelpBuilder and upload
> the outputs were I can get them, I have a HTML Help workshop installed
> on my desktop. I would gladly setup the project and build the dot chm
> file. I'll send the results were ever you wish.
> Best regards,
> Gary Setter
>
Try Matplotlib-1.4.x.chm from 
<http://www.lfd.uci.edu/~gohlke/pythonlibs/#matplotlib>.
If the content appears empty, "unblock" the file in Windows Explorer 
before viewing.
Please post issues at <https://github.com/matplotlib/matplotlib/pull/3325>
Christoph

Thank you for all the responds concerning Html Help. If someone would build using class sphinx.builders.htmlhelp.HTMLHelpBuilder and upload the outputs were I can get them, I have a HTML Help workshop installed on my desktop. I would gladly setup the project and build the dot chm file. I'll send the results were ever you wish.
Best regards,
Gary Setter

On 7/28/2014 11:32 AM, Thomas Kluyver wrote:
> On 28 July 2014 11:27, Benjamin Root <ben...@ou...
> <mailto:ben...@ou...>> wrote:
>
> Going to the sourceforge page you have, I see that you mean "HTML
> Help" as in ".chm" files. That is something different that I am not
> familiar with. All of our documentation is generated from sphinx, so
> whatever sphinx supports, we can generate.
>
>
> Sphinx does support CHM as the 'htmlhelp' target, though the docs seem
> to say that you need another application ("Microsoft HTML Help
> Workshop") to finish compiling it.
>
> http://sphinx-doc.org/builders.html#sphinx.builders.htmlhelp.HTMLHelpBuilder
>
> Thomas
>
I created a PR at <https://github.com/matplotlib/matplotlib/pull/3325>
The resulting document, Matplotlibdoc.chm, is currently 124 MB, probably 
because of the many hires gallery images. In general the document looks 
usable.
Christoph

Hi,
Sorry for the repost - just in case OSX users out there missed it...
We have automatically built OSX wheels for the upcoming release here:
http://wheels.scikit-image.org/
Wheels built via travis-ci from
https://github.com/matthew-brett/matplotlib-wheels.
Usual procedure:
pip install -f http://wheels.scikit-image.org --pre matplotlib
Please do send feedback.
Cheers,
Matthew

Just as a side note, it is indeed possible to view the html docs offline by having a copy of the directory Ben mentioned, and depending on which Unix system you are using, it is possible that this doc is already packaged. I'm thinking of Debian : https://packages.debian.org/jessie/python-matplotlib-doc (python and bumpy docs are also packaged the same way and I use them a lot.)
Best,
Pierre
On 28 juillet 2014 18:11:18 UTC, Gary Setter <gar...@ya...> wrote:
>Monday, July 28,
>2014 08:16 AM
>Dear Sirs,
>Please consider
>including Html Help as a third format for MatPlotLib documentation. I
>was first
>introduced to MatPlotLib at an online class in programming which used
>Python
>and MatPlotLib. I was impressed by MatPlotLib but believed that the
>help system
>could be better for someone like me.
> 
>At the time, only
>PDF was available, which has these problems:
>- The index page
>is difficult to navigate
>- You cannot move
>backwards and forwards as you follow hyperlinks
>- Being page
>oriented, text that spans pages has a distracting page break
>- In some places,
>text spills off the page and is not visible.
> 
>You added Html
>support online, which is was a great improvement. However it has a
>fatal flaw
>for someone like me:
>- It is
>unavailable to people without an internet connection when then they are
>working.
> 
>Of the help
>documents that I used or written, (plain text, UNIX man pages, LaTex,
>WinHelp
>and Html Help), Html Help is by far the best system. Html help is:
>- Self contained
>- Available off
>line
>- Easy to
>navigate
>- Easy to use
>index
>- Easy to use
>table of contents
> 
>There is only one
>problem that I know of concerning using Html Help for MatPlotLib
>documentation,
>support for it on UNIX systems. Rather than rejecting Html Help, why
>not work
>on supporting it on UNIX systems?
> 
>To see what I'm
>talking about, please take a look at the Html Help version of
>MatPlotLib 1.3.0
>which I converted from the PDF file. It is a sourceforge project which
>you can
>access here:
>https://sourceforge.net/projects/matplotlibashtmlhelp/?source=directory
>
> 
>What do you
>think? Is Html Help a format for offline documentation that you are
>willing to
>support or at least accept? Please reply here or to
>gar...@ya....
> 
>Gary Setter
>
>
>------------------------------------------------------------------------
>
>------------------------------------------------------------------------------
>Infragistics Professional
>Build stunning WinForms apps today!
>Reboot your WinForms applications with our WinForms controls. 
>Build a bridge from your legacy apps to the future.
>http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Pierre Haessig

On 28 July 2014 11:27, Benjamin Root <ben...@ou...> wrote:
> Going to the sourceforge page you have, I see that you mean "HTML Help" as
> in ".chm" files. That is something different that I am not familiar with.
> All of our documentation is generated from sphinx, so whatever sphinx
> supports, we can generate.
Sphinx does support CHM as the 'htmlhelp' target, though the docs seem to
say that you need another application ("Microsoft HTML Help Workshop") to
finish compiling it.
http://sphinx-doc.org/builders.html#sphinx.builders.htmlhelp.HTMLHelpBuilder
Thomas

Going to the sourceforge page you have, I see that you mean "HTML Help" as
in ".chm" files. That is something different that I am not familiar with.
All of our documentation is generated from sphinx, so whatever sphinx
supports, we can generate.
On Mon, Jul 28, 2014 at 2:25 PM, Benjamin Root <ben...@ou...> wrote:
> Technically speaking, we do support HTML Help, as that is the format of
> our online documentation. So, I think what you are really asking for is a
> packaged version of the HTML documentation that you find online that one
> can just simply download for themselves?
>
> As a quick solution for the moment, you can go to the following link:
> https://github.com/matplotlib/matplotlib.github.com
> and click on the "Download .zip" button on the right side. That will get
> you the online documentation that should work off-line.
>
> Ben Root
>
>
> On Mon, Jul 28, 2014 at 2:11 PM, Gary Setter <gar...@ya...> wrote:
>
>> Monday, July 28, 2014 08:16 AM
>> Dear Sirs,
>> Please consider including Html Help as a third format for MatPlotLib
>> documentation. I was first introduced to MatPlotLib at an online class in
>> programming which used Python and MatPlotLib. I was impressed by MatPlotLib
>> but believed that the help system could be better for someone like me.
>>
>> At the time, only PDF was available, which has these problems:
>> - The index page is difficult to navigate
>> - You cannot move backwards and forwards as you follow hyperlinks
>> - Being page oriented, text that spans pages has a distracting page break
>> - In some places, text spills off the page and is not visible.
>>
>> You added Html support online, which is was a great improvement. However
>> it has a fatal flaw for someone like me:
>> - It is unavailable to people without an internet connection when then
>> they are working.
>>
>> Of the help documents that I used or written, (plain text, UNIX man
>> pages, LaTex, WinHelp and Html Help), Html Help is by far the best system.
>> Html help is:
>> - Self contained
>> - Available off line
>> - Easy to navigate
>> - Easy to use index
>> - Easy to use table of contents
>>
>> There is only one problem that I know of concerning using Html Help for
>> MatPlotLib documentation, support for it on UNIX systems. Rather than
>> rejecting Html Help, why not work on supporting it on UNIX systems?
>>
>> To see what I'm talking about, please take a look at the Html Help
>> version of MatPlotLib 1.3.0 which I converted from the PDF file. It is a
>> sourceforge project which you can access here:
>> https://sourceforge.net/projects/matplotlibashtmlhelp/?source=directory
>>
>> What do you think? Is Html Help a format for offline documentation that
>> you are willing to support or at least accept? Please reply here or to
>> gar...@ya....
>>
>> Gary Setter
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Infragistics Professional
>> Build stunning WinForms apps today!
>> Reboot your WinForms applications with our WinForms controls.
>> Build a bridge from your legacy apps to the future.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>

Technically speaking, we do support HTML Help, as that is the format of our
online documentation. So, I think what you are really asking for is a
packaged version of the HTML documentation that you find online that one
can just simply download for themselves?
As a quick solution for the moment, you can go to the following link:
https://github.com/matplotlib/matplotlib.github.com
and click on the "Download .zip" button on the right side. That will get
you the online documentation that should work off-line.
Ben Root
On Mon, Jul 28, 2014 at 2:11 PM, Gary Setter <gar...@ya...> wrote:
> Monday, July 28, 2014 08:16 AM
> Dear Sirs,
> Please consider including Html Help as a third format for MatPlotLib
> documentation. I was first introduced to MatPlotLib at an online class in
> programming which used Python and MatPlotLib. I was impressed by MatPlotLib
> but believed that the help system could be better for someone like me.
>
> At the time, only PDF was available, which has these problems:
> - The index page is difficult to navigate
> - You cannot move backwards and forwards as you follow hyperlinks
> - Being page oriented, text that spans pages has a distracting page break
> - In some places, text spills off the page and is not visible.
>
> You added Html support online, which is was a great improvement. However
> it has a fatal flaw for someone like me:
> - It is unavailable to people without an internet connection when then
> they are working.
>
> Of the help documents that I used or written, (plain text, UNIX man pages,
> LaTex, WinHelp and Html Help), Html Help is by far the best system. Html
> help is:
> - Self contained
> - Available off line
> - Easy to navigate
> - Easy to use index
> - Easy to use table of contents
>
> There is only one problem that I know of concerning using Html Help for
> MatPlotLib documentation, support for it on UNIX systems. Rather than
> rejecting Html Help, why not work on supporting it on UNIX systems?
>
> To see what I'm talking about, please take a look at the Html Help version
> of MatPlotLib 1.3.0 which I converted from the PDF file. It is a
> sourceforge project which you can access here:
> https://sourceforge.net/projects/matplotlibashtmlhelp/?source=directory
>
> What do you think? Is Html Help a format for offline documentation that
> you are willing to support or at least accept? Please reply here or to
> gar...@ya....
>
> Gary Setter
>
>
>
> ------------------------------------------------------------------------------
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls.
> Build a bridge from your legacy apps to the future.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Monday, July 28,
2014 08:16 AM
Dear Sirs,
Please consider
including Html Help as a third format for MatPlotLib documentation. I was first
introduced to MatPlotLib at an online class in programming which used Python
and MatPlotLib. I was impressed by MatPlotLib but believed that the help system
could be better for someone like me.
 
At the time, only
PDF was available, which has these problems:
- The index page
is difficult to navigate
- You cannot move
backwards and forwards as you follow hyperlinks
- Being page
oriented, text that spans pages has a distracting page break
- In some places,
text spills off the page and is not visible.
 
You added Html
support online, which is was a great improvement. However it has a fatal flaw
for someone like me:
- It is
unavailable to people without an internet connection when then they are
working.
 
Of the help
documents that I used or written, (plain text, UNIX man pages, LaTex, WinHelp
and Html Help), Html Help is by far the best system. Html help is:
- Self contained
- Available off
line
- Easy to
navigate
- Easy to use
index
- Easy to use
table of contents
 
There is only one
problem that I know of concerning using Html Help for MatPlotLib documentation,
support for it on UNIX systems. Rather than rejecting Html Help, why not work
on supporting it on UNIX systems?
 
To see what I'm
talking about, please take a look at the Html Help version of MatPlotLib 1.3.0
which I converted from the PDF file. It is a sourceforge project which you can
access here:
https://sourceforge.net/projects/matplotlibashtmlhelp/?source=directory 
 
What do you
think? Is Html Help a format for offline documentation that you are willing to
support or at least accept? Please reply here or to gar...@ya....
 
Gary Setter

Hi,
On Sun, Jul 27, 2014 at 7:52 PM, Thomas Caswell <tca...@gm...> wrote:
> https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.4.0rc2/
>
> Thanks to Christoph Gohlike the widows binaries now posted on sourceforge.
>
Also automatically built OSX wheels here:
http://wheels.scikit-image.org/
Wheels built via travis-ci from
https://github.com/matthew-brett/matplotlib-wheels.
Usual procedure:
pip install -f http://wheels.scikit-image.org --pre matplotlib
Please do send feedback.
Cheers,
Matthew

https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.4.0rc2/
Thanks to Christoph Gohlike the widows binaries now posted on sourceforge.
Tom
-- 
Thomas Caswell
tca...@gm...

Hi all,
I just did the version bump and tagged 1.4.0rc2.
There is one outstanding issue with possible memory corruption, but we
do not have a reproducible example.
Everything else we have left for 1.4.0 is documentation.
Tom
-- 
Thomas Caswell
tca...@gm...

When dealing with the C/C++ layer and switching back and forth between
upstream master and your branch, I would suggest running "git clean -fxd"
and then do a complete rebuild. We have recently fixed a number of memory
leaks that may or may not have merged well with your code as it involved
the CXX layer.
On Tue, Jul 22, 2014 at 5:41 AM, Stefan H. <shm...@gm...> wrote:
> Hi! Last year, I have been working on making matplotlib compatible with
> PyPy
> here:
>
> https://github.com/shmuller/matplotlib.git
>
> I succeeded to get the svg and pdf backends working, but then had to drop
> the ball. My changes involve mostly the C++ parts in src, in particular
> replacing some PyCXX (which didn't work with PyPy) with the plain Python C
> API. I also needed some minor fixes in .py files.
>
> I understand that it is desirable to remove the PyCXX layer altogether from
> matplotlib, and I have come a good deal along this route. I would also be
> happy to continue working in this direction.
>
> I have a bit of time now, and so I merged my branch with upstream/master.
> The few conflicts were easy to resolve. However, then I tried to run the
> test suites (python tests.py), both on the current master and my branch, to
> see if I broke anything.
>
> Unfortunately, the test suites randomly segfault on my computer (Macbook
> Air
> 2011), at the latest when I try to run them 10 times in a row. Not only on
> my branch, but also on upstream/master. I ran the Apple Hardware Test,
> which
> didn't report any issues, so my Mac seems to be fine. I went back to the
> state of my branch before merging, which i have been using in production
> for
> a year now without any issues, and noticed that even there the test suite
> segfaulted if I try to run it 10 times in a loop. I haven't noticed this
> before (and didn't have any issues in production use of matplotlib for a
> year). The crashes occur randomly and not always at one specific test.
>
> - Did anyone have this issue before?
>
> - Could someone pull my branch and run the test suite on a different
> computer, so that I can exclude that my hardware is at fault after all?
>
> - Could someone please guide me to get my work pulled into the main
> repository?
>
> Many thanks,
> Stefan
>
>
>
> --
> View this message in context:
> http://matplotlib.1069221.n5.nabble.com/Trying-to-prepare-a-pull-request-but-tests-py-keeps-crashing-on-master-tp43680.html
> Sent from the matplotlib - devel mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hello everybody
I was wondering if you had the chance to try the PR
https://github.com/matplotlib/matplotlib/pull/2759
I am waiting for comments, suggestions, critics etc.. To keep moving
I would like to finish this MEP22 and have it merged to continue with my
main goal... The MEP23
Thanks
Federico

Hi! Last year, I have been working on making matplotlib compatible with PyPy
here:
https://github.com/shmuller/matplotlib.git
I succeeded to get the svg and pdf backends working, but then had to drop
the ball. My changes involve mostly the C++ parts in src, in particular
replacing some PyCXX (which didn't work with PyPy) with the plain Python C
API. I also needed some minor fixes in .py files.
I understand that it is desirable to remove the PyCXX layer altogether from
matplotlib, and I have come a good deal along this route. I would also be
happy to continue working in this direction.
I have a bit of time now, and so I merged my branch with upstream/master.
The few conflicts were easy to resolve. However, then I tried to run the
test suites (python tests.py), both on the current master and my branch, to
see if I broke anything.
Unfortunately, the test suites randomly segfault on my computer (Macbook Air
2011), at the latest when I try to run them 10 times in a row. Not only on
my branch, but also on upstream/master. I ran the Apple Hardware Test, which
didn't report any issues, so my Mac seems to be fine. I went back to the
state of my branch before merging, which i have been using in production for
a year now without any issues, and noticed that even there the test suite
segfaulted if I try to run it 10 times in a loop. I haven't noticed this
before (and didn't have any issues in production use of matplotlib for a
year). The crashes occur randomly and not always at one specific test.
- Did anyone have this issue before?
- Could someone pull my branch and run the test suite on a different
computer, so that I can exclude that my hardware is at fault after all?
- Could someone please guide me to get my work pulled into the main
repository?
Many thanks,
Stefan
--
View this message in context: http://matplotlib.1069221.n5.nabble.com/Trying-to-prepare-a-pull-request-but-tests-py-keeps-crashing-on-master-tp43680.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Once #3277 and #3284 get merged I think we will have squashed all the
reported code bugs from rc1 (both are from me and need a second set of
eyes).
Can someone who understands the freetype code take a look at #3262 to
see if we can relax the version requirement on the installation?
Everything else outstanding is documentation related, if those three
things get taken care of tomorrow, I will tag rc2 tomorrow night.
Tom
-- 
Thomas Caswell
tca...@gm...

On 21 July 2014 17:40, R Hattersley <rha...@gm...> wrote:
> In the case of two Axes, the CSS version would be:
>
> Axes#axes1 {
> border: 1px solid black;
> }
>
> Axes#axes2 {
> border: 2px dashed green;
> }
>
>
Or if you want to borrow from more advanced selector syntax, you could do
fun stuff like:
Axes:nth-child(odd) {
 border: 1px solid black;
}
Axes:nth-child(even) {
 border: 2px dashed green;
}

On 21 July 2014 14:48, jamesramm <jam...@gm...> wrote:
> You've just noted it: Line2D isn't a CSS selector
CSS doesn't define any particular element names - it just operates on
element names in a document tree. So a standard CSS parser will work just
as well with "line2d { ... }" as it would with "h1 { ... }".
On 21 July 2014 14:48, jamesramm <jam...@gm...> wrote:
> ..likewise, the properties we want to call upon (like linewidth) are not
> CSS attributes.
Agreed - not all properties are standard CSS properties, so I was
suggesting borrowing SVG properties to augment the list. NB. That would
make the property controlling line width be called "stroke-width". But
whatever names we choose, a CSS parser doesn't care what the names are.
But really the issue is not so much about CSS and SVG-styling-properties -
it is whether to use existing standards or not. Clearly I'm in favour of
adopting standards. But perhaps there is another standard set of CSS
styling properties which would be a closer match to matplotlib? Perhaps CSS
is not the answer at all, and something like SLD/SE would be better? (I
suspect not! But there could easily be other technologies I'm not aware of!)
 Axes {
> gid: 'axes1';
> autoscalex_on: True;
> ::ylabel {
> text: 'Y-Axis';
> font-size: 10;
> }
> }
>
> I think this would be easier to parse and slightly clearer to read as it
> can be 'attached' to the artist container it refers to (imagine if there
> were 2 axes in a figure...)
In the case of two Axes, the CSS version would be:
Axes#axes1 {
 border: 1px solid black;
}
Axes#axes2 {
 border: 2px dashed green;
}

As a side note, SVG already has specs which extend css to apply to 2D graphics:
www.w3.org/TR/SVGTiny12/styling.html
so we don't need to entirely re-inventing the wheel.
On Mon, Jul 21, 2014 at 9:48 AM, jamesramm <jam...@gm...> wrote:
> R Hattersley wrote
> I'm not sure what it is about CSS syntax that isn't up to the job. For
> example, SVG works with standard CSS syntax (see
> http://www.w3.org/TR/SVG/styling.html#StylingWithCSS). Perhaps we just have
> a different view of what constitutes CSS vs. HTML/SVG/whatever. The example
> in the SVG spec is:
>
> rect {
> fill: red;
> stroke: blue;
> stroke-width: 3
> }
>
> But if we define the element name for a Line2D instance as "line2d" then CSS
> snippet could just become:
>
> line2d {
> stroke: blue;
> stroke-width: 3
> }
>
> You've just noted it: Line2D isn't a CSS selector..likewise, the properties
> we want to call upon (like linewidth) are not CSS attributes. There are many
> matplotlib properties that don't have an analogous CSS property/attribute
> (that I know of); we might aswell define the mpl properties in our 'CSS'
> subset. So we could base our language on CSS rules, but we need to define
> new tokens. This means writing, or more likely, extending a parser. Not
> huge, but not trivial.
>
> R Hattersley wrote
> The DOM facade could help bridge the gap. For example, a "DOM" instance
> returned by an Axes object could pretend to have "text" element children.
> Styling those would route the style information back to the underlying Axes
> object. For example:
>
> text {
> font-size: 12pt;
> }
>
> axes text.ylabel {
> font-size: 10pt;
> }
>
> This could be one way. Another way that would fit and I quite like is
> similar to what is employed by mapnik/the tilemill, in that we simply have
> nested declaration blocks, e.g:
>
> Axes {
> gid: 'axes1';
> autoscalex_on: True;
> ::ylabel {
> text: 'Y-Axis';
> font-size: 10;
> }
> }
>
> I think this would be easier to parse and slightly clearer to read as it can
> be 'attached' to the artist container it refers to (imagine if there were 2
> axes in a figure...). It is also easy to write in BNF, by just adding
> another option to the Declaration block:
>
> Rule := Selector '{' [Declaration] '}'
>
> Declaration := Attribute':' Value';' | Rule
>
> ...
>
> But...small steps. I would start by introducing something for artist
> primitives and for selectively applying to primitives using the gid
> ________________________________
> View this message in context: Re: MEP26: Artist-level stylesheets
>
> Sent from the matplotlib - devel mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
-- 
Thomas Caswell
tca...@gm...