matplotlib-devel Mailing List for matplotlib

Hi list,

Once again, we are looking for a junior developer to work on the
scikit-learn. Below is the official job posting. Unofficially I would
like to stress that this is a unique opportunity to be payed for two
years to work on learning and improving the scientific Python toolstack. 

Gael

________________________________________________________________________________

**Job Description**

INRIA is looking to hire a young graduate on a 2-year position to help
with the community-driven development of the open source machine learning
in Python library, scikit-learn. The scikit-learn is one of the major
machine-learning libraries in Python. It aims to be state-of-the-art on
mid-size to large datasets by harnessing the power of the scientific
Python toolstack.

Speaking French is not a requirement, as it is an international team.

**Requirements**

* Programming skills in Python and C/C++
* Understanding of quality assurance in software development: test-driven programming, version control, technical documentation.
* Some knowledge of Linux/Unix
* Software design skills
* Knowledge of open-source development and community-driven environments
* Good technical English level
* An experience in statistical learning or a mathematical-oriented mindset is a plus
* We can only hire a young-graduate that has received a masters or equivalent degree at most a year ago.

**About the company**

INRIA is the French computer science research institute. It recognized
word-wide as one of the leading research institutions and has a strong
expertise in machine learning. You will be working in the `Parietal team
<https://parietal.saclay.inria.fr/>`_ that makes a heavy use of Python
for brain imaging analysis.

Parietal is a small research team (around 10 people) with an excellent
technical knowledge of scientific and numerical computing in Python as
well as a fine understanding of algorithmic issues in machine learning
and statistics. Parietal is committed to investing in scikit-learn.

Working at Parietal is a unique opportunity to improve your skills in
machine learning and numerical computing in Python. In addition, working
full time on the scikit-learn, a very active open-source project, will
give you premium experience of open source community management and 
collaborative project development.

 
**Contact Info:**

* **Technical Contact**: Bertand Thirion
* **E-mail contact**: ber...@in...
* **HR Contact**: Marie Domingues
* **E-mail Contact**: mar...@in... 
* **No telecommuting**

On Fri, Sep 2, 2011 at 2:16 PM, Eric Firing <ef...@ha...> wrote:

> On 09/02/2011 08:54 AM, Eric Firing wrote:
>
> > Now I see it: all the other backends are simply setting constants in
> > their cursord, so they are not calling the functions that create the
> > cursors until runtime; backend_gtk is calling the functions at import
> > time.  This is a design deficiency that will be easy to fix, and will
> > help prevent quite a few problems (including problems I have run into
> > myself).
> >
> > I will take care of it today or tomorrow.
> >
> > Eric
>
> I was too optimistic.  Moving the cursor creation to runtime is easy,
> but it triggers an avalanche of warnings and errors, sometimes ending in
> a segfault, if one tries to plot anything when there is no X display.
> Better to leave it the way it is, failing at import.
>
> Eric
>
>
That's too bad.  Actually, a better, more generic solution would be if there
was some way for sphinx to create documentation without actually performing
an import.  This would be valuable for backends like cocoaagg and macosx
backends as those two require PyObjC which (AFAICT) can't be installed on a
non-mac system.

Anyway, I had some free time and did some grunt-work.  Please see my branch
here:

https://github.com/WeatherGod/matplotlib/compare/docfix%2Fbackends

The entires in the TOCs probably need some smarter reorganizatiion (fltkagg
got added to the wrong place...), and I didn't try building these docs in a
headless environment, so I don't know which ones would fail in that
situation.

Cheers!
Ben Root

On 09/02/2011 08:54 AM, Eric Firing wrote:

> Now I see it: all the other backends are simply setting constants in
> their cursord, so they are not calling the functions that create the
> cursors until runtime; backend_gtk is calling the functions at import
> time.  This is a design deficiency that will be easy to fix, and will
> help prevent quite a few problems (including problems I have run into
> myself).
>
> I will take care of it today or tomorrow.
>
> Eric

I was too optimistic.  Moving the cursor creation to runtime is easy, 
but it triggers an avalanche of warnings and errors, sometimes ending in 
a segfault, if one tries to plot anything when there is no X display. 
Better to leave it the way it is, failing at import.

Eric

On 09/02/2011 04:48 AM, Benjamin Root wrote:
> On Wed, Aug 31, 2011 at 10:51 PM, Eric Firing <ef...@ha...
> <mailto:ef...@ha...>> wrote:
>
>     On 08/31/2011 05:00 PM, Trevor J Christensen wrote:
>      > I went here:
>      >
>      > http://matplotlib.sourceforge.net/api/index_backend_api.html
>      >
>      > and didn't see tkagg listed.
>      >
>      > Trevor
>
>     Trevor,
>
>     Thank you.  It is still missing from the devel branch, along with
>     several others.  I can see how this could cause some confusion.  Maybe
>     we can get it fixed before the next release, maybe not.
>
>     Part of the problem here is that auto-generation of docs saves a huge
>     amount of work, but can also lead to problems, of which this is just one
>     example.
>
>     Eric
>
>
> It wouldn't be that difficult to add references to those other backends,
> however I do not know how complete their documentations are.  As an
> interesting note, the GTKAgg API docs are currently commented out with a
> note saying that an active X-window session is needed to import the GTK
> backends.  Was this preventing the GTK docs from building?  How come do
> other GUI backends still build fine?

Now I see it: all the other backends are simply setting constants in 
their cursord, so they are not calling the functions that create the 
cursors until runtime; backend_gtk is calling the functions at import 
time.  This is a design deficiency that will be easy to fix, and will 
help prevent quite a few problems (including problems I have run into 
myself).

I will take care of it today or tomorrow.

Eric

>
> Ben Root
>
>
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 09/02/2011 04:48 AM, Benjamin Root wrote:
> On Wed, Aug 31, 2011 at 10:51 PM, Eric Firing <ef...@ha...
> <mailto:ef...@ha...>> wrote:
>
>     On 08/31/2011 05:00 PM, Trevor J Christensen wrote:
>      > I went here:
>      >
>      > http://matplotlib.sourceforge.net/api/index_backend_api.html
>      >
>      > and didn't see tkagg listed.
>      >
>      > Trevor
>
>     Trevor,
>
>     Thank you.  It is still missing from the devel branch, along with
>     several others.  I can see how this could cause some confusion.  Maybe
>     we can get it fixed before the next release, maybe not.
>
>     Part of the problem here is that auto-generation of docs saves a huge
>     amount of work, but can also lead to problems, of which this is just one
>     example.
>
>     Eric
>
>
> It wouldn't be that difficult to add references to those other backends,
> however I do not know how complete their documentations are.  As an
> interesting note, the GTKAgg API docs are currently commented out with a
> note saying that an active X-window session is needed to import the GTK
> backends.  Was this preventing the GTK docs from building?  How come do
> other GUI backends still build fine?

That seems to be just a peculiarity of the particular gui toolkits.  It 
is possible to import the others without a display; they don't fail 
until one tries to plot something.

Eric

>
> Ben Root
>

On Wed, Aug 31, 2011 at 10:51 PM, Eric Firing <ef...@ha...> wrote:

> On 08/31/2011 05:00 PM, Trevor J Christensen wrote:
> > I went here:
> >
> > http://matplotlib.sourceforge.net/api/index_backend_api.html
> >
> > and didn't see tkagg listed.
> >
> > Trevor
>
> Trevor,
>
> Thank you.  It is still missing from the devel branch, along with
> several others.  I can see how this could cause some confusion.  Maybe
> we can get it fixed before the next release, maybe not.
>
> Part of the problem here is that auto-generation of docs saves a huge
> amount of work, but can also lead to problems, of which this is just one
> example.
>
> Eric
>
>
It wouldn't be that difficult to add references to those other backends,
however I do not know how complete their documentations are.  As an
interesting note, the GTKAgg API docs are currently commented out with a
note saying that an active X-window session is needed to import the GTK
backends.  Was this preventing the GTK docs from building?  How come do
other GUI backends still build fine?

Ben Root

Hello,
I'm trying to download basemap examples tarball from SF but it seems
to be corrupted - could you confirm/fix it?

Thanks,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

John Hunter wrote:

> On Wed, Aug 31, 2011 at 8:49 PM, John Hunter <jd...@gm...> wrote:
> 
> >> Note that I'm not subscribed to this list, so please CC me on replies.
> >
> > That won't work because mpl converts all tex png raster to black and
> > white and handles color on its own in post-processing.  The following
> > does work:
[...]
> But since you set usetex, you shouldn't need the $ escapes and the
> literal rm font.  It should be enough to do:
> 
> pylab.title( r'colored title wanted 2.5', color='blue' )\

Hi,

Thanks for the insight.  What I'm really trying to get is multiple
colors in the title text.  For example, if mpl didn't convert all text
to black, I would want the following to produce blue and red text:

  pylab.rc( 'text' , usetex=True )
  pylab.rc( 'text.latex' , preamble='\usepackage[usenames]{color}' )
  pylab.title( '\\textcolor{Blue}{blue part} \\textcolor{Red}{red part}')

Is there a particular reason why mpl has to convert png colored text
to black and white?

Best wishes,
Mike