problems with shared axis

Hello list (especially Erik, who can fix this I hope) -

I have had problems with shared axes, especially when one of the axis has an aspect ratio that is set ‘equal’. It has been discussed on the list before (mostly with Erik Firing), but it hasn’t been fixed yet. What I want to do is have two plots. The top plot has an aspect ratio that is ‘equal’. The idea is to have a contour plot in the top figure, while the bottom figure gives a cross-sectional picture of what I am plotting. This used to work well (quite some time ago), including zooming and such. But now I cannot plot it at all, let alone zoom.

My first problem is when I add a subplot with a shared x-axis, it changes the limits on the original x-axis. That seems to be a bug:
ax1 = subplot(211)
plot([1,2,3]) # Now the limits of the x-axis go from 0 to 2.

subplot(212,sharex=ax1) # Now the limits of both x-axis go from 0 to 1.

After all, the new subplot shares the axis with the existing subplot, so why doesn’t it copy the axis limits from that subplot?

But the bigger problem occurs when I want the aspect ratio of one of the first axis to be ‘equal’.

ax1 = subplot(211,aspect=‘equal’)

plot([1,2,3])

subplot(212,sharex=ax1)

The second subplot is added, but the length of the graph is not the same as for the first subplot. It also resets the xlimits to go from 0 to 1, as before, which means the first subplot becomes unreadable (it still enforces ‘equal’ in the first subplot by changing the limits of the y-axis). When I now change the limits on the x-axis, the aspect ratio is not equal anymore

ax1.set_xlim(0,2)
draw()

Thanks for your help. I am willing to help in testing any changes.

Best regards, Mark

Mark Bakker wrote:

Hello list (especially Erik, who can fix this I hope) -

I have had problems with shared axes, especially when one of the axis has an aspect ratio that is set 'equal'. It has been discussed on the list before (mostly with Erik Firing), but it hasn't been fixed yet. What I want to do is have two plots. The top plot has an aspect ratio that is 'equal'. The idea is to have a contour plot in the top figure, while the bottom figure gives a cross-sectional picture of what I am plotting. This used to work well (quite some time ago), including zooming and such. But now I cannot plot it at all, let alone zoom.

My first problem is when I add a subplot with a shared x-axis, it changes the limits on the original x-axis. That seems to be a bug:
ax1 = subplot(211)
plot([1,2,3]) # Now the limits of the x-axis go from 0 to 2.
subplot(212,sharex=ax1) # Now the limits of both x-axis go from 0 to 1.

After all, the new subplot shares the axis with the existing subplot, so why doesn't it copy the axis limits from that subplot?

I may have the fix for this, but I need more time to check and refine it--and try to make sure that I don't break anything else in the process.

But the bigger problem occurs when I want the aspect ratio of one of the first axis to be 'equal'.

ax1 = subplot(211,aspect='equal')
plot([1,2,3]) subplot(212,sharex=ax1)

The second subplot is added, but the length of the graph is not the same as for the first subplot. It also resets the xlimits to go from 0 to 1, as before, which means the first subplot becomes unreadable (it still enforces 'equal' in the first subplot by changing the limits of the y-axis). When I now change the limits on the x-axis, the aspect ratio is not equal anymore

I will see what I can do. There are definitely some bugs that need to be squashed.

Eric

···

ax1.set_xlim(0,2)
draw()

Thanks for your help. I am willing to help in testing any changes.

Best regards, Mark

Thanks Eric.

You know that this has been on my wish list for a long time.

Let me know if I can test anything or help in any other way,

Mark

···

On Wed, Oct 22, 2008 at 10:54 AM, Eric Firing <efiring@…229…> wrote:

Mark Bakker wrote:

Hello list (especially Erik, who can fix this I hope) -

I have had problems with shared axes, especially when one of the axis has an aspect ratio that is set ‘equal’. It has been discussed on the list before (mostly with Erik Firing), but it hasn’t been fixed yet. What I want to do is have two plots. The top plot has an aspect ratio that is ‘equal’. The idea is to have a contour plot in the top figure, while the bottom figure gives a cross-sectional picture of what I am plotting. This used to work well (quite some time ago), including zooming and such. But now I cannot plot it at all, let alone zoom.

My first problem is when I add a subplot with a shared x-axis, it changes the limits on the original x-axis. That seems to be a bug:

ax1 = subplot(211)

plot([1,2,3]) # Now the limits of the x-axis go from 0 to 2.

subplot(212,sharex=ax1) # Now the limits of both x-axis go from 0 to 1.

After all, the new subplot shares the axis with the existing subplot, so why doesn’t it copy the axis limits from that subplot?

I may have the fix for this, but I need more time to check and refine it–and try to make sure that I don’t break anything else in the process.

But the bigger problem occurs when I want the aspect ratio of one of the first axis to be ‘equal’.

ax1 = subplot(211,aspect=‘equal’)

plot([1,2,3]) subplot(212,sharex=ax1)

The second subplot is added, but the length of the graph is not the same as for the first subplot. It also resets the xlimits to go from 0 to 1, as before, which means the first subplot becomes unreadable (it still enforces ‘equal’ in the first subplot by changing the limits of the y-axis). When I now change the limits on the x-axis, the aspect ratio is not equal anymore

I will see what I can do. There are definitely some bugs that need to be squashed.

Eric

ax1.set_xlim(0,2)

draw()

Thanks for your help. I am willing to help in testing any changes.

Best regards, Mark

Hi,

Eric, I will be happy to test your possible fix too. I have similar
problem with autoscaling shared axes like you Mark.

David

Mark Bakker a �crit :

···

Thanks Eric.

You know that this has been on my wish list for a long time.

Let me know if I can test anything or help in any other way,

Mark

On Wed, Oct 22, 2008 at 10:54 AM, Eric Firing <efiring@...229... > <mailto:efiring@…229…>> wrote:

    Mark Bakker wrote:

        Hello list (especially Erik, who can fix this I hope) -

        I have had problems with shared axes, especially when one of the
        axis has an aspect ratio that is set 'equal'. It has been
        discussed on the list before (mostly with Erik Firing), but it
        hasn't been fixed yet. What I want to do is have two plots. The
        top plot has an aspect ratio that is 'equal'. The idea is to
        have a contour plot in the top figure, while the bottom figure
        gives a cross-sectional picture of what I am plotting. This used
        to work well (quite some time ago), including zooming and such.
        But now I cannot plot it at all, let alone zoom.

        My first problem is when I add a subplot with a shared x-axis,
        it changes the limits on the original x-axis. That seems to be a
        bug:
        ax1 = subplot(211)
        plot([1,2,3]) # Now the limits of the x-axis go from 0 to 2.
        subplot(212,sharex=ax1) # Now the limits of both x-axis go from
        0 to 1.

        After all, the new subplot shares the axis with the existing
        subplot, so why doesn't it copy the axis limits from that subplot?

    I may have the fix for this, but I need more time to check and
    refine it--and try to make sure that I don't break anything else in
    the process.

        But the bigger problem occurs when I want the aspect ratio of
        one of the first axis to be 'equal'.

        ax1 = subplot(211,aspect='equal')
        plot([1,2,3]) subplot(212,sharex=ax1)

        The second subplot is added, but the length of the graph is not
        the same as for the first subplot. It also resets the xlimits to
        go from 0 to 1, as before, which means the first subplot becomes
        unreadable (it still enforces 'equal' in the first subplot by
        changing the limits of the y-axis). When I now change the limits
        on the x-axis, the aspect ratio is not equal anymore

    I will see what I can do. There are definitely some bugs that need
    to be squashed.

    Eric

        ax1.set_xlim(0,2)
        draw()

        Thanks for your help. I am willing to help in testing any changes.

        Best regards, Mark

------------------------------------------------------------------------

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

------------------------------------------------------------------------

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

David Trem wrote:

Hi,

Eric, I will be happy to test your possible fix too. I have similar
problem with autoscaling shared axes like you Mark.

David

I have committed to svn some changes to support autoscaling with shared axes, so please test. I have done only very simple and cursory checking. You might try reversed axes, log axes, etc.

I have not yet addressed the aspect ratio part of Mark's original post, below, but I think my changes have fixed the first of the two problems, in addition to adding autoscaling support, which I don't think we ever had before.

At present, autoscaling does not work with shared axes if an aspect ratio is specified.

Eric

···

Mark Bakker a écrit :

Thanks Eric.

You know that this has been on my wish list for a long time.

Let me know if I can test anything or help in any other way,

Mark

On Wed, Oct 22, 2008 at 10:54 AM, Eric Firing <efiring@...229... >> <mailto:efiring@…229…>> wrote:

    Mark Bakker wrote:

        Hello list (especially Erik, who can fix this I hope) -

        I have had problems with shared axes, especially when one of the
        axis has an aspect ratio that is set 'equal'. It has been
        discussed on the list before (mostly with Erik Firing), but it
        hasn't been fixed yet. What I want to do is have two plots. The
        top plot has an aspect ratio that is 'equal'. The idea is to
        have a contour plot in the top figure, while the bottom figure
        gives a cross-sectional picture of what I am plotting. This used
        to work well (quite some time ago), including zooming and such.
        But now I cannot plot it at all, let alone zoom.

        My first problem is when I add a subplot with a shared x-axis,
        it changes the limits on the original x-axis. That seems to be a
        bug:
        ax1 = subplot(211)
        plot([1,2,3]) # Now the limits of the x-axis go from 0 to 2.
        subplot(212,sharex=ax1) # Now the limits of both x-axis go from
        0 to 1.

        After all, the new subplot shares the axis with the existing
        subplot, so why doesn't it copy the axis limits from that subplot?

    I may have the fix for this, but I need more time to check and
    refine it--and try to make sure that I don't break anything else in
    the process.

        But the bigger problem occurs when I want the aspect ratio of
        one of the first axis to be 'equal'.

        ax1 = subplot(211,aspect='equal')
        plot([1,2,3]) subplot(212,sharex=ax1)

        The second subplot is added, but the length of the graph is not
        the same as for the first subplot. It also resets the xlimits to
        go from 0 to 1, as before, which means the first subplot becomes
        unreadable (it still enforces 'equal' in the first subplot by
        changing the limits of the y-axis). When I now change the limits
        on the x-axis, the aspect ratio is not equal anymore

    I will see what I can do. There are definitely some bugs that need
    to be squashed.

    Eric

        ax1.set_xlim(0,2)
        draw()

        Thanks for your help. I am willing to help in testing any changes.

        Best regards, Mark

------------------------------------------------------------------------

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

------------------------------------------------------------------------

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

Mark Bakker wrote:

Hello list (especially Erik, who can fix this I hope) -

I have had problems with shared axes, especially when one of the axis has an aspect ratio that is set 'equal'. It has been discussed on the list before (mostly with Erik Firing), but it hasn't been fixed yet. What I want to do is have two plots. The top plot has an aspect ratio that is 'equal'. The idea is to have a contour plot in the top figure, while the bottom figure gives a cross-sectional picture of what I am plotting. This used to work well (quite some time ago), including zooming and such. But now I cannot plot it at all, let alone zoom.

My first problem is when I add a subplot with a shared x-axis, it changes the limits on the original x-axis. That seems to be a bug:
ax1 = subplot(211)
plot([1,2,3]) # Now the limits of the x-axis go from 0 to 2.
subplot(212,sharex=ax1) # Now the limits of both x-axis go from 0 to 1.

After all, the new subplot shares the axis with the existing subplot, so why doesn't it copy the axis limits from that subplot?

But the bigger problem occurs when I want the aspect ratio of one of the first axis to be 'equal'.

ax1 = subplot(211,aspect='equal')
plot([1,2,3]) subplot(212,sharex=ax1)

Mark,

I made some more changes so that the above works by changing the adjustable to 'datalim'. Have I broken anything? Does this work for your applications?

Eric

···

The second subplot is added, but the length of the graph is not the same as for the first subplot. It also resets the xlimits to go from 0 to 1, as before, which means the first subplot becomes unreadable (it still enforces 'equal' in the first subplot by changing the limits of the y-axis). When I now change the limits on the x-axis, the aspect ratio is not equal anymore

ax1.set_xlim(0,2)
draw()

Thanks for your help. I am willing to help in testing any changes.

Best regards, Mark

------------------------------------------------------------------------

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

------------------------------------------------------------------------

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

Thank you very much Eric !

It basically works for me but I think there is still a small bug
related to sharing y axes. I attach a small script that reproduce the
problem.
The end of the related error message is the following:

  File "*/lib/python2.5/site-packages/matplotlib/axes.py", line 515, in
__init__
    if sharex._adjustable == 'box':
AttributeError: 'NoneType' object has no attribute '_adjustable'

Hope it could help.

David

Eric Firing a �crit :

shared_yaxes_problem.py (359 Bytes)

···

David Trem wrote:

Hi,

Eric, I will be happy to test your possible fix too. I have similar
problem with autoscaling shared axes like you Mark.

David

I have committed to svn some changes to support autoscaling with shared
axes, so please test. I have done only very simple and cursory
checking. You might try reversed axes, log axes, etc.

I have not yet addressed the aspect ratio part of Mark's original post,
below, but I think my changes have fixed the first of the two problems,
in addition to adding autoscaling support, which I don't think we ever
had before.

At present, autoscaling does not work with shared axes if an aspect
ratio is specified.

Eric

Mark Bakker a �crit :

Thanks Eric.

You know that this has been on my wish list for a long time.

Let me know if I can test anything or help in any other way,

Mark

On Wed, Oct 22, 2008 at 10:54 AM, Eric Firing <efiring@...229... >>> <mailto:efiring@…229…>> wrote:

    Mark Bakker wrote:

        Hello list (especially Erik, who can fix this I hope) -

        I have had problems with shared axes, especially when one of the
        axis has an aspect ratio that is set 'equal'. It has been
        discussed on the list before (mostly with Erik Firing), but it
        hasn't been fixed yet. What I want to do is have two plots. The
        top plot has an aspect ratio that is 'equal'. The idea is to
        have a contour plot in the top figure, while the bottom figure
        gives a cross-sectional picture of what I am plotting. This used
        to work well (quite some time ago), including zooming and such.
        But now I cannot plot it at all, let alone zoom.

        My first problem is when I add a subplot with a shared x-axis,
        it changes the limits on the original x-axis. That seems to be a
        bug:
        ax1 = subplot(211)
        plot([1,2,3]) # Now the limits of the x-axis go from 0 to 2.
        subplot(212,sharex=ax1) # Now the limits of both x-axis go from
        0 to 1.

        After all, the new subplot shares the axis with the existing
        subplot, so why doesn't it copy the axis limits from that
subplot?

    I may have the fix for this, but I need more time to check and
    refine it--and try to make sure that I don't break anything else in
    the process.

        But the bigger problem occurs when I want the aspect ratio of
        one of the first axis to be 'equal'.

        ax1 = subplot(211,aspect='equal')
        plot([1,2,3]) subplot(212,sharex=ax1)

        The second subplot is added, but the length of the graph is not
        the same as for the first subplot. It also resets the xlimits to
        go from 0 to 1, as before, which means the first subplot becomes
        unreadable (it still enforces 'equal' in the first subplot by
        changing the limits of the y-axis). When I now change the limits
        on the x-axis, the aspect ratio is not equal anymore

    I will see what I can do. There are definitely some bugs that need
    to be squashed.

    Eric

        ax1.set_xlim(0,2)
        draw()

        Thanks for your help. I am willing to help in testing any
changes.

        Best regards, Mark

------------------------------------------------------------------------

-------------------------------------------------------------------------

This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win
great prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

------------------------------------------------------------------------

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

David Trem wrote:

Thank you very much Eric !

It basically works for me but I think there is still a small bug
related to sharing y axes. I attach a small script that reproduce the
problem.
The end of the related error message is the following:

  File "*/lib/python2.5/site-packages/matplotlib/axes.py", line 515, in
__init__
    if sharex._adjustable == 'box':
AttributeError: 'NoneType' object has no attribute '_adjustable'

Hope it could help.

It certainly does, thank you. In a cut'n'paste operation, I had neglected to change a couple of 'x's to 'y's. Fixed in svn.

Thanks again, and keep testing!

Eric

Thanks Eric,

It works perfectly for me now!
Actually, autoscale of shared axes simplify a lot
my own code so I'm really really pleased to see this functionality
is now directly integrated in matplotlib.
I'll do me best to test the svn version regularly.

Thanks again,

David

Eric Firing a �crit :

···

David Trem wrote:

Thank you very much Eric !

It basically works for me but I think there is still a small bug
related to sharing y axes. I attach a small script that reproduce the
problem.
The end of the related error message is the following:

  File "*/lib/python2.5/site-packages/matplotlib/axes.py", line 515, in
__init__
    if sharex._adjustable == 'box':
AttributeError: 'NoneType' object has no attribute '_adjustable'

Hope it could help.

It certainly does, thank you. In a cut'n'paste operation, I had
neglected to change a couple of 'x's to 'y's. Fixed in svn.

Thanks again, and keep testing!

Eric

I was gone for the weekend (sorry, but that ‘life’ thing gets in the way of getting things done sometimes). I don’t have a way to build stuff at the moment. Can I just check out the axes.py and replace my current one, or are there too many changes?

Mark

···

On Fri, Oct 24, 2008 at 7:57 AM, Eric Firing <efiring@…229…> wrote:

Mark Bakker wrote:

Hello list (especially Erik, who can fix this I hope) -

I have had problems with shared axes, especially when one of the axis has an aspect ratio that is set ‘equal’. It has been discussed on the list before (mostly with Erik Firing), but it hasn’t been fixed yet. What I want to do is have two plots. The top plot has an aspect ratio that is ‘equal’. The idea is to have a contour plot in the top figure, while the bottom figure gives a cross-sectional picture of what I am plotting. This used to work well (quite some time ago), including zooming and such. But now I cannot plot it at all, let alone zoom.

My first problem is when I add a subplot with a shared x-axis, it changes the limits on the original x-axis. That seems to be a bug:

ax1 = subplot(211)

plot([1,2,3]) # Now the limits of the x-axis go from 0 to 2.

subplot(212,sharex=ax1) # Now the limits of both x-axis go from 0 to 1.

After all, the new subplot shares the axis with the existing subplot, so why doesn’t it copy the axis limits from that subplot?

But the bigger problem occurs when I want the aspect ratio of one of the first axis to be ‘equal’.

ax1 = subplot(211,aspect=‘equal’)

plot([1,2,3]) subplot(212,sharex=ax1)

Mark,

I made some more changes so that the above works by changing the adjustable to ‘datalim’. Have I broken anything? Does this work for your applications?

Eric

The second subplot is added, but the length of the graph is not the same as for the first subplot. It also resets the xlimits to go from 0 to 1, as before, which means the first subplot becomes unreadable (it still enforces ‘equal’ in the first subplot by changing the limits of the y-axis). When I now change the limits on the x-axis, the aspect ratio is not equal anymore

ax1.set_xlim(0,2)

draw()

Thanks for your help. I am willing to help in testing any changes.

Best regards, Mark



This SF.Net email is sponsored by the Moblin Your Move Developer’s challenge

Build the coolest Linux based applications with Moblin SDK & win great prizes

Grand prize is a trip for two to an Open Source event anywhere in the world

http://moblin-contest.org/redirect.php?banner_id=100&url=/



Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Mark Bakker wrote:

I was gone for the weekend (sorry, but that 'life' thing gets in the way of getting things done sometimes). I don't have a way to build stuff at the moment. Can I just check out the axes.py and replace my current one, or are there too many changes?

The changes were in ticker.py and axes.py. Whether plugging in the current versions would work depends on the age of the other files you have. If you have a fairly recent svn build, then updating those two files probably would work. You could use svn to get the diffs specifically for my changes related to shared axes.

Eric

···

Mark

On Fri, Oct 24, 2008 at 7:57 AM, Eric Firing <efiring@...229... > <mailto:efiring@…229…>> wrote:

    Mark Bakker wrote:

        Hello list (especially Erik, who can fix this I hope) -

        I have had problems with shared axes, especially when one of the
        axis has an aspect ratio that is set 'equal'. It has been
        discussed on the list before (mostly with Erik Firing), but it
        hasn't been fixed yet. What I want to do is have two plots. The
        top plot has an aspect ratio that is 'equal'. The idea is to
        have a contour plot in the top figure, while the bottom figure
        gives a cross-sectional picture of what I am plotting. This used
        to work well (quite some time ago), including zooming and such.
        But now I cannot plot it at all, let alone zoom.

        My first problem is when I add a subplot with a shared x-axis,
        it changes the limits on the original x-axis. That seems to be a
        bug:
        ax1 = subplot(211)
        plot([1,2,3]) # Now the limits of the x-axis go from 0 to 2.
        subplot(212,sharex=ax1) # Now the limits of both x-axis go from
        0 to 1.

        After all, the new subplot shares the axis with the existing
        subplot, so why doesn't it copy the axis limits from that subplot?

        But the bigger problem occurs when I want the aspect ratio of
        one of the first axis to be 'equal'.

        ax1 = subplot(211,aspect='equal')
        plot([1,2,3]) subplot(212,sharex=ax1)

    Mark,

    I made some more changes so that the above works by changing the
    adjustable to 'datalim'. Have I broken anything? Does this work
    for your applications?

    Eric

        The second subplot is added, but the length of the graph is not
        the same as for the first subplot. It also resets the xlimits to
        go from 0 to 1, as before, which means the first subplot becomes
        unreadable (it still enforces 'equal' in the first subplot by
        changing the limits of the y-axis). When I now change the limits
        on the x-axis, the aspect ratio is not equal anymore

        ax1.set_xlim(0,2)
        draw()

        Thanks for your help. I am willing to help in testing any changes.

        Best regards, Mark

        ------------------------------------------------------------------------

        -------------------------------------------------------------------------
        This SF.Net email is sponsored by the Moblin Your Move
        Developer's challenge
        Build the coolest Linux based applications with Moblin SDK & win
        great prizes
        Grand prize is a trip for two to an Open Source event anywhere
        in the world
        http://moblin-contest.org/redirect.php?banner_id=100&url=/
        <http://moblin-contest.org/redirect.php?banner_id=100&url=/&gt;

        ------------------------------------------------------------------------

        _______________________________________________
        Matplotlib-devel mailing list
        Matplotlib-devel@lists.sourceforge.net
        <mailto:Matplotlib-devel@lists.sourceforge.net>
        matplotlib-devel List Signup and Options

Dang, I looked at it, but so much has changed since 0.98.3 release that I have little chance of getting any changes implemented.
Any plans for a new release that you know of?
Thanks, Mark

···

On Mon, Oct 27, 2008 at 7:29 PM, Eric Firing <efiring@…229…> wrote:

Mark Bakker wrote:

I was gone for the weekend (sorry, but that ‘life’ thing gets in the way of getting things done sometimes). I don’t have a way to build stuff at the moment. Can I just check out the axes.py and replace my current one, or are there too many changes?

The changes were in ticker.py and axes.py. Whether plugging in the current versions would work depends on the age of the other files you have. If you have a fairly recent svn build, then updating those two files probably would work. You could use svn to get the diffs specifically for my changes related to shared axes.

Eric

Mark

On Fri, Oct 24, 2008 at 7:57 AM, Eric Firing <efiring@…229… mailto:efiring@...229...> wrote:

Mark Bakker wrote:



    Hello list (especially Erik, who can fix this I hope) -



    I have had problems with shared axes, especially when one of the

    axis has an aspect ratio that is set 'equal'. It has been

    discussed on the list before (mostly with Erik Firing), but it

    hasn't been fixed yet. What I want to do is have two plots. The

    top plot has an aspect ratio that is 'equal'. The idea is to

    have a contour plot in the top figure, while the bottom figure

    gives a cross-sectional picture of what I am plotting. This used

    to work well (quite some time ago), including zooming and such.

    But now I cannot plot it at all, let alone zoom.



    My first problem is when I add a subplot with a shared x-axis,

    it changes the limits on the original x-axis. That seems to be a

    bug:

    ax1 = subplot(211)

    plot([1,2,3])  # Now the limits of the x-axis go from 0 to 2.

    subplot(212,sharex=ax1)  # Now the limits of both x-axis go from

    0 to 1.



    After all, the new subplot shares the axis with the existing

    subplot, so why doesn't it copy the axis limits from that subplot?



    But the bigger problem occurs when I want the aspect ratio of

    one of the first axis to be 'equal'.



    ax1 = subplot(211,aspect='equal')

    plot([1,2,3]) subplot(212,sharex=ax1)





Mark,



I made some more changes so that the above works by changing the

adjustable to 'datalim'.  Have I broken anything?  Does this work

for your applications?



Eric





    The second subplot is added, but the length of the graph is not

    the same as for the first subplot. It also resets the xlimits to

    go from 0 to 1, as before, which means the first subplot becomes

    unreadable (it still enforces 'equal' in the first subplot by

    changing the limits of the y-axis). When I now change the limits

    on the x-axis, the aspect ratio is not equal anymore



    ax1.set_xlim(0,2)

    draw()



    Thanks for your help. I am willing to help in testing any changes.



    Best regards, Mark







    ------------------------------------------------------------------------



    -------------------------------------------------------------------------

    This SF.Net email is sponsored by the Moblin Your Move

    Developer's challenge

    Build the coolest Linux based applications with Moblin SDK & win

    great prizes

    Grand prize is a trip for two to an Open Source event anywhere

    in the world

    [http://moblin-contest.org/redirect.php?banner_id=100&url=/](http://moblin-contest.org/redirect.php?banner_id=100&url=/)

    <[http://moblin-contest.org/redirect.php?banner_id=100&url=/](http://moblin-contest.org/redirect.php?banner_id=100&url=/)>





    ------------------------------------------------------------------------



    _______________________________________________

    Matplotlib-devel mailing list

    Matplotlib-devel@lists.sourceforge.net

mailto:Matplotlib-devel@lists.sourceforge.net

    [https://lists.sourceforge.net/lists/listinfo/matplotlib-devel](https://lists.sourceforge.net/lists/listinfo/matplotlib-devel)

Mark Bakker wrote:

Dang, I looked at it, but so much has changed since 0.98.3 release that I have little chance of getting any changes implemented.
Any plans for a new release that you know of?
Thanks, Mark

None that I know of. It would certainly be nice if we had the release package-building completely automated; or automated daily svn builds of the Win and OSX packages. Since I don't work with either Win or OSX, I don't know how hard this would be to set up.

Eric

Nightly builds would be excellent -- Charlie, to what extent do you
think this is feasible from a scripting perspective? Ie, ignoring the
hardware side for a minute, and assuming we had access to a build farm
with OS X and win32, how hard would it be to setup a build bot for
nightly builds?

JDH

···

On Mon, Oct 27, 2008 at 4:09 PM, Eric Firing <efiring@...229...> wrote:

None that I know of. It would certainly be nice if we had the release
package-building completely automated; or automated daily svn builds of the
Win and OSX packages. Since I don't work with either Win or OSX, I don't
know how hard this would be to set up.

This may not be necessary if we can get a Windows box, but I thought I'd mention it.

I wrote a distutils extension a couple of years ago to build Windows installers on a Linux box with Mingw32. This has been working perfectly for nightly builds on my home machine since around September 2007 for a project with much the same build requirements as matplotlib. It's really easy to install Mingw32 on Debian derivatives (maybe other dists as well.)

See here:

Mike

John Hunter wrote:

···

On Mon, Oct 27, 2008 at 4:09 PM, Eric Firing <efiring@...229...> wrote:

None that I know of. It would certainly be nice if we had the release
package-building completely automated; or automated daily svn builds of the
Win and OSX packages. Since I don't work with either Win or OSX, I don't
know how hard this would be to set up.
    
Nightly builds would be excellent -- Charlie, to what extent do you
think this is feasible from a scripting perspective? Ie, ignoring the
hardware side for a minute, and assuming we had access to a build farm
with OS X and win32, how hard would it be to setup a build bot for
nightly builds?

JDH

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
  
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom wrote:

This may not be necessary if we can get a Windows box, but I thought I'd mention it.

I wrote a distutils extension a couple of years ago to build Windows installers on a Linux box with Mingw32. This has been working perfectly for nightly builds on my home machine since around September 2007 for a project with much the same build requirements as matplotlib. It's really easy to install Mingw32 on Debian derivatives (maybe other dists as well.)

Mike,

Thank you! I had no idea that mingw32 was available as an ubuntu package, for example, and never would have thought to look for it. Now I will have to try it out. Do you know if there is an scons builder that uses it? That might be the sticking point for my non-mpl C code, which is now all built with scons.

I think that if your distutils extension works for building mpl for Win on a Linux box, then we should use it. Anything that reduces dependence o having an actual Windows machine around is a win.

On second thought, there is one disadvantage: an automated build on a Win box could also run an automated test.

I have some dim impression of having seen a caution regarding compatibility between mingw extensions and present or future official python.org Python builds. Does this ring any bells?

Eric

···

See here:

Gamera download | SourceForge.net

Mike

John Hunter wrote:

On Mon, Oct 27, 2008 at 4:09 PM, Eric Firing <efiring@...229...> wrote:

None that I know of. It would certainly be nice if we had the release
package-building completely automated; or automated daily svn builds of the
Win and OSX packages. Since I don't work with either Win or OSX, I don't
know how hard this would be to set up.
    
Nightly builds would be excellent -- Charlie, to what extent do you
think this is feasible from a scripting perspective? Ie, ignoring the
hardware side for a minute, and assuming we had access to a build farm
with OS X and win32, how hard would it be to setup a build bot for
nightly builds?

JDH

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
  

Eric Firing wrote:

Michael Droettboom wrote:

This may not be necessary if we can get a Windows box, but I thought I'd mention it.

I wrote a distutils extension a couple of years ago to build Windows installers on a Linux box with Mingw32. This has been working perfectly for nightly builds on my home machine since around September 2007 for a project with much the same build requirements as matplotlib. It's really easy to install Mingw32 on Debian derivatives (maybe other dists as well.)

Mike,

Thank you! I had no idea that mingw32 was available as an ubuntu package, for example, and never would have thought to look for it. Now I will have to try it out. Do you know if there is an scons builder that uses it? That might be the sticking point for my non-mpl C code, which is now all built with scons.

No idea. Haven't spent much time with scons myself.

I think that if your distutils extension works for building mpl for Win on a Linux box, then we should use it. Anything that reduces dependence o having an actual Windows machine around is a win.

On second thought, there is one disadvantage: an automated build on a Win box could also run an automated test.

True. But there is always wine -- though I fear my head would start to spin. I'll admit that the advantages of cross-compiling can quickly be outweighed by the complexity of debugging and testing.

I have some dim impression of having seen a caution regarding compatibility between mingw extensions and present or future official python.org Python builds. Does this ring any bells?

It does. I haven't had problems up to Py2.5 -- but I don't know what's coming in that respect, and I don't closely follow Python-on-Windows development.

Mike

···

Eric

See here:

Gamera download | SourceForge.net

Mike

John Hunter wrote:

On Mon, Oct 27, 2008 at 4:09 PM, Eric Firing <efiring@...229...> >>> wrote:

None that I know of. It would certainly be nice if we had the release
package-building completely automated; or automated daily svn builds of the
Win and OSX packages. Since I don't work with either Win or OSX, I don't
know how hard this would be to set up.
    
Nightly builds would be excellent -- Charlie, to what extent do you
think this is feasible from a scripting perspective? Ie, ignoring the
hardware side for a minute, and assuming we had access to a build farm
with OS X and win32, how hard would it be to setup a build bot for
nightly builds?

JDH

-------------------------------------------------------------------------

This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
  
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA