[matplotlib-devel] SciPy 2009 Call for Papers

[Jarrod Millman]

==
SciPy 2009 Call for Papers
==

SciPy 2009, the 8th Python in Science conference, will be held
from August 18-23, 2009 at Caltech in Pasadena, CA, USA.

Each year SciPy attracts leading figures in research and scientific
software development with Python from a wide range of scientific and
engineering disciplines. The focus of the conference is both on scientific
libraries and tools developed with Python and on scientific or engineering
achievements using Python.

We welcome contributions from the industry as well as the academic world.
Indeed, industrial research and development as well academic research
face the challenge of mastering IT tools for exploration, modeling and
analysis.

We look forward to hearing your recent breakthroughs using Python!

Submission of Papers


The program features tutorials, contributed papers, lightning talks, and
bird-of-a-feather sessions. We are soliciting talks and accompanying
papers (either formal academic or magazine-style articles) that discuss
topics which center around scientific computing using Python. These
include applications, teaching, future development directions, and
research. A collection of peer-reviewed articles will be published as
part of the proceedings.

Proposals for talks are submitted as extended abstracts. There are two
categories of talks:

 Paper presentations

 These talks are 35 minutes in duration (including questions). A one page
 abstract of no less than 500 words (excluding figures and references)
 should give an outline of the final paper. Proceeding papers are due two
 weeks after the conference, and may be in a formal academic style, or in
 a more relaxed magazine-style format.

 Rapid presentations

 These talks are 10 minutes in duration. An abstract of between
 300 and 700 words should describe the topic and motivate its
 relevance to scientific computing.

In addition, there will be an open session for lightning talks during which
any attendee willing to do so is invited to do a couple-of-minutes-long
presentation.

If you wish to present a talk at the conference, please create an account
on the website (http://conference.scipy.org). You may then submit an abstract
by logging in, clicking on your profile and following the "Submit an
abstract" link.

Submission Guidelines
-

* Submissions should be uploaded via the online form.
* Submissions whose main purpose is to promote a commercial product or
  service will be refused.
* All accepted proposals must be presented at the SciPy conference by
  at least one author.
* Authors of an accepted proposal can provide a final paper for
  publication in the conference proceedings. Final papers are limited
  to 7 pages, including diagrams, figures, references, and appendices.
  The papers will be reviewed to help ensure the high-quality of the
  proceedings.

For further information, please visit the conference homepage:
http://conference.scipy.org.

Important Dates
===

* Friday, June 26: Abstracts Due
* Saturday, July 4: Announce accepted talks, post schedule
* Friday, July 10: Early Registration ends
* Tuesday-Wednesday, August 18-19: Tutorials
* Thursday-Friday, August 20-21: Conference
* Saturday-Sunday, August 22-23: Sprints
* Friday, September 4: Papers for proceedings due

Tutorials
=

Two days of tutorials to the scientific Python tools will precede the
conference. There will be two tracks:  one for introduction of the basic
tools to beginners and one for more advanced tools. Tutorials will be
announced later.

Birds of a Feather Sessions
===

If you wish to organize a birds-of-a-feather session to discuss some
specific area of scientific development with Python, please contact the
organizing committee.

Executive Committee
===

* Jarrod Millman, UC Berkeley, USA (Conference Chair)
* Gaël Varoquaux, INRIA Saclay, France (Program Co-Chair)
* Stéfan van der Walt, University of Stellenbosch, South Africa
(Program Co-Chair)
* Fernando Pérez, UC Berkeley, USA (Tutorial Chair)

--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables 
unlimited royalty-free distribution of the report engine 
for externally facing server and web deployment. 
http://p.sf.net/sfu/businessobjects
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Error building from source - Ubuntu

[Sandro Tosi]

On Mon, May 18, 2009 at 16:49, M Uhlenhuth  wrote:
> ./CXX/WrapPython.h:42:20: error: Python.h: No such file or directory

is python-dev and all other build dependencies installed?

$ sudo apt-get build-dep matplotlib

should help

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

--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables 
unlimited royalty-free distribution of the report engine 
for externally facing server and web deployment. 
http://p.sf.net/sfu/businessobjects
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] traits?

[Andrew Straw]

I've been hacking away at adding support for "dropped spines" to MPL
(e.g. http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 ) and
have come to the conclusion that there is a fundamental issue in the
code base that the traits package has solved -- many values that depend
on other values with complicated stuff that happens when one of the
parent values changes. For example, the location of the text from the
xaxis depends on the padding value in addition to the xaxis location.
Now I'm trying to add another element to the mix -- namely an axis spine
that can change location -- and things are going to spiral into a
(further) collection of special-cased updates unless there's some
reworking of the infrastructure.

So, the question is, should I attempt to use traits for this? I guess
that I won't have the time to re-write the entire code base to use
traits, but I'd like make a stab a stab at dropped spine support with
the knowledge that, should I be successful, there's at least a chance we
would again ship traits with MPL. I imagine we could incrementally move
more and more to traits if I'm successful, particularly now that we have
the beginnings of a unit test infrastructure (thanks James!).

-Andrew

--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables 
unlimited royalty-free distribution of the report engine 
for externally facing server and web deployment. 
http://p.sf.net/sfu/businessobjects
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] traits?

[william ratcliff]

If you switch to traits, will things still build with py2exe?  Are there
speed costs?  Startup time?

Cheers,
William

On Mon, May 18, 2009 at 8:07 PM, Andrew Straw  wrote:

> I've been hacking away at adding support for "dropped spines" to MPL
> (e.g. http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 ) and
> have come to the conclusion that there is a fundamental issue in the
> code base that the traits package has solved -- many values that depend
> on other values with complicated stuff that happens when one of the
> parent values changes. For example, the location of the text from the
> xaxis depends on the padding value in addition to the xaxis location.
> Now I'm trying to add another element to the mix -- namely an axis spine
> that can change location -- and things are going to spiral into a
> (further) collection of special-cased updates unless there's some
> reworking of the infrastructure.
>
> So, the question is, should I attempt to use traits for this? I guess
> that I won't have the time to re-write the entire code base to use
> traits, but I'd like make a stab a stab at dropped spine support with
> the knowledge that, should I be successful, there's at least a chance we
> would again ship traits with MPL. I imagine we could incrementally move
> more and more to traits if I'm successful, particularly now that we have
> the beginnings of a unit test infrastructure (thanks James!).
>
> -Andrew
>
>
> --
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables
> unlimited royalty-free distribution of the report engine
> for externally facing server and web deployment.
> http://p.sf.net/sfu/businessobjects
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables 
unlimited royalty-free distribution of the report engine 
for externally facing server and web deployment. 
http://p.sf.net/sfu/businessobjects___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] traits?

[Darren Dale]

Hi Andrew,

On Mon, May 18, 2009 at 8:07 PM, Andrew Straw  wrote:

> I've been hacking away at adding support for "dropped spines" to MPL
> (e.g. http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 ) and
> have come to the conclusion that there is a fundamental issue in the
> code base that the traits package has solved -- many values that depend
> on other values with complicated stuff that happens when one of the
> parent values changes. For example, the location of the text from the
> xaxis depends on the padding value in addition to the xaxis location.
> Now I'm trying to add another element to the mix -- namely an axis spine
> that can change location -- and things are going to spiral into a
> (further) collection of special-cased updates unless there's some
> reworking of the infrastructure.
>
> So, the question is, should I attempt to use traits for this? I guess
> that I won't have the time to re-write the entire code base to use
> traits, but I'd like make a stab a stab at dropped spine support with
> the knowledge that, should I be successful, there's at least a chance we
> would again ship traits with MPL. I imagine we could incrementally move
> more and more to traits if I'm successful, particularly now that we have
> the beginnings of a unit test infrastructure (thanks James!).
>

A couple summers back I wrote the config subpackage for mpl, which is based
on Fernando's traited configobj package TConfig. It hasn't been used or
tested in a while, but the other devs had been pretty good about keeping it
up to date with changes to the regular rcparams. If there is any push to use
Traits in mpl, I would really like to see the config package ressurrected.
To use it, there is a global variable in matplotlib's __init__.py that needs
to be set to True.

Darren
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables 
unlimited royalty-free distribution of the report engine 
for externally facing server and web deployment. 
http://p.sf.net/sfu/businessobjects___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] traits?

[Robert Kern]

On 2009-05-18 19:07, Andrew Straw wrote:
> I've been hacking away at adding support for "dropped spines" to MPL
> (e.g. http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 ) and
> have come to the conclusion that there is a fundamental issue in the
> code base that the traits package has solved -- many values that depend
> on other values with complicated stuff that happens when one of the
> parent values changes. For example, the location of the text from the
> xaxis depends on the padding value in addition to the xaxis location.
> Now I'm trying to add another element to the mix -- namely an axis spine
> that can change location -- and things are going to spiral into a
> (further) collection of special-cased updates unless there's some
> reworking of the infrastructure.
>
> So, the question is, should I attempt to use traits for this? I guess
> that I won't have the time to re-write the entire code base to use
> traits, but I'd like make a stab a stab at dropped spine support with
> the knowledge that, should I be successful, there's at least a chance we
> would again ship traits with MPL. I imagine we could incrementally move
> more and more to traits if I'm successful, particularly now that we have
> the beginnings of a unit test infrastructure (thanks James!).

If you do, *please* either depend on Traits or, if you must include the code in 
matplotlib itself, stick it under matplotlib's namespace. I really don't want 
to 
go back to having to fix people's broken installations again.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco


--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables 
unlimited royalty-free distribution of the report engine 
for externally facing server and web deployment. 
http://p.sf.net/sfu/businessobjects
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] traits?

[Darren Dale]

On Mon, May 18, 2009 at 8:41 PM, Robert Kern  wrote:

> On 2009-05-18 19:07, Andrew Straw wrote:
> > I've been hacking away at adding support for "dropped spines" to MPL
> > (e.g. http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 ) and
> > have come to the conclusion that there is a fundamental issue in the
> > code base that the traits package has solved -- many values that depend
> > on other values with complicated stuff that happens when one of the
> > parent values changes. For example, the location of the text from the
> > xaxis depends on the padding value in addition to the xaxis location.
> > Now I'm trying to add another element to the mix -- namely an axis spine
> > that can change location -- and things are going to spiral into a
> > (further) collection of special-cased updates unless there's some
> > reworking of the infrastructure.
> >
> > So, the question is, should I attempt to use traits for this? I guess
> > that I won't have the time to re-write the entire code base to use
> > traits, but I'd like make a stab a stab at dropped spine support with
> > the knowledge that, should I be successful, there's at least a chance we
> > would again ship traits with MPL. I imagine we could incrementally move
> > more and more to traits if I'm successful, particularly now that we have
> > the beginnings of a unit test infrastructure (thanks James!).
>
> If you do, *please* either depend on Traits or, if you must include the
> code in
> matplotlib itself, stick it under matplotlib's namespace.


We stopped shipping traits with mpl a long time ago, when that issue was
identified.


> I really don't want to
> go back to having to fix people's broken installations again.
>

Was that comment really necessary?

Darren
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables 
unlimited royalty-free distribution of the report engine 
for externally facing server and web deployment. 
http://p.sf.net/sfu/businessobjects___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] traits?

[Robert Kern]

On 2009-05-18 20:05, Darren Dale wrote:
> On Mon, May 18, 2009 at 8:41 PM, Robert Kern  > wrote:
>
> On 2009-05-18 19:07, Andrew Straw wrote:
>  > I've been hacking away at adding support for "dropped spines" to MPL
>  > (e.g. http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 ) and
>  > have come to the conclusion that there is a fundamental issue in the
>  > code base that the traits package has solved -- many values that
> depend
>  > on other values with complicated stuff that happens when one of the
>  > parent values changes. For example, the location of the text from the
>  > xaxis depends on the padding value in addition to the xaxis location.
>  > Now I'm trying to add another element to the mix -- namely an
> axis spine
>  > that can change location -- and things are going to spiral into a
>  > (further) collection of special-cased updates unless there's some
>  > reworking of the infrastructure.
>  >
>  > So, the question is, should I attempt to use traits for this? I guess
>  > that I won't have the time to re-write the entire code base to use
>  > traits, but I'd like make a stab a stab at dropped spine support with
>  > the knowledge that, should I be successful, there's at least a
> chance we
>  > would again ship traits with MPL. I imagine we could
> incrementally move
>  > more and more to traits if I'm successful, particularly now that
> we have
>  > the beginnings of a unit test infrastructure (thanks James!).
>
> If you do, *please* either depend on Traits or, if you must include
> the code in
> matplotlib itself, stick it under matplotlib's namespace.
>
>
> We stopped shipping traits with mpl a long time ago, when that issue was
> identified.

But part of that calculation was that Traits wasn't being used for anything 
non-experimental. Since that is being revisited, and since you still do 
distribute other packages like dateutils and pytz (which also cause similar 
installation headaches) the same way, I would like this to be kept in mind.

> I really don't want to
> go back to having to fix people's broken installations again.
>
>
> Was that comment really necessary?

Was it really offensive? People would install matplotlib, then they would try 
to 
install other parts of ETS, the ETS stuff wouldn't work, thus they had a broken 
installation. I do not want to go back to having to fix their broken 
installations. This isn't a jab at the matplotlib team.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco


--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables 
unlimited royalty-free distribution of the report engine 
for externally facing server and web deployment. 
http://p.sf.net/sfu/businessobjects
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] traits?

[Darren Dale]

On Mon, May 18, 2009 at 9:37 PM, Robert Kern  wrote:

> On 2009-05-18 20:05, Darren Dale wrote:
> > On Mon, May 18, 2009 at 8:41 PM, Robert Kern  > > wrote:
> >
> > On 2009-05-18 19:07, Andrew Straw wrote:
> >  > I've been hacking away at adding support for "dropped spines" to
> MPL
> >  > (e.g. http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 )
> and
> >  > have come to the conclusion that there is a fundamental issue in
> the
> >  > code base that the traits package has solved -- many values that
> > depend
> >  > on other values with complicated stuff that happens when one of
> the
> >  > parent values changes. For example, the location of the text from
> the
> >  > xaxis depends on the padding value in addition to the xaxis
> location.
> >  > Now I'm trying to add another element to the mix -- namely an
> > axis spine
> >  > that can change location -- and things are going to spiral into a
> >  > (further) collection of special-cased updates unless there's some
> >  > reworking of the infrastructure.
> >  >
> >  > So, the question is, should I attempt to use traits for this? I
> guess
> >  > that I won't have the time to re-write the entire code base to use
> >  > traits, but I'd like make a stab a stab at dropped spine support
> with
> >  > the knowledge that, should I be successful, there's at least a
> > chance we
> >  > would again ship traits with MPL. I imagine we could
> > incrementally move
> >  > more and more to traits if I'm successful, particularly now that
> > we have
> >  > the beginnings of a unit test infrastructure (thanks James!).
> >
> > If you do, *please* either depend on Traits or, if you must include
> > the code in
> > matplotlib itself, stick it under matplotlib's namespace.
> >
> >
> > We stopped shipping traits with mpl a long time ago, when that issue was
> > identified.
>
> But part of that calculation was that Traits wasn't being used for anything
> non-experimental. Since that is being revisited, and since you still do
> distribute other packages like dateutils and pytz (which also cause similar
> installation headaches) the same way, I would like this to be kept in mind.
>
> > I really don't want to
> > go back to having to fix people's broken installations again.
> >
> >
> > Was that comment really necessary?
>
> Was it really offensive?


The whole situation was just really embarrassing for me. Who would want to
go back to having to fix people's broken installations? It just opened an
old wound.


> People would install matplotlib, then they would try to
> install other parts of ETS, the ETS stuff wouldn't work, thus they had a
> broken
> installation. I do not want to go back to having to fix their broken
> installations. This isn't a jab at the matplotlib team.
>

I had tried to work things out so mpl would only install traits if traits
wasn't already installed, or if the installed version had also been provided
by mpl. That turned out to be insufficient to avoid the problems you and
Gael had to deal with, because if setup.py was ever run when Traits was not
installed, distutils would copy traits into the build/ directory. Once it
ended up in build/, "setup.py install" would install it regardless of what
checks were in place in setup.py, thus overwriting existing Traits and
breaking environments.

To make a long story short, it won't happen again.

Darren
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables 
unlimited royalty-free distribution of the report engine 
for externally facing server and web deployment. 
http://p.sf.net/sfu/businessobjects___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] traits?

[Gael Varoquaux]

On Mon, May 18, 2009 at 10:41:22PM -0400, Darren Dale wrote:
>I had tried to work things out so mpl would only install traits if traits
>wasn't already installed, or if the installed version had also been
>provided by mpl. That turned out to be insufficient to avoid the problems
>[...]

>To make a long story short, it won't happen again.

Excellent. 

I do agree with both of you that shipping Traits with matplotlib is very
likely to get all of us in trouble.

If there are issue with having Traits as a dependency, they must be
adressed in the Traits codebase.

Gaël

--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables 
unlimited royalty-free distribution of the report engine 
for externally facing server and web deployment. 
http://p.sf.net/sfu/businessobjects
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel