matplotlib-devel Mailing List for matplotlib

Dale: something is wrong with the way you are closing out issues on the 
old matplotlib tracker because the two of mine you closed out are 
getting an ever accumulating number of copies of the same closeout 
message from you.

This is needless clutter on the old system, and means a lot of garbage 
emails for folks to reported the bugs.

I hope you can fix this quickly. Though I suppose by the time you get to 
it most users will have stopped tracking their issues in sourceforge in 
self defense.

-- Russell

On Fri, Jun 24, 2011 at 4:02 PM, Eric Firing <ef...@ha...> wrote:
>
>>>
>>> Darren,
>>>
>>> I thought the Sourceforge tracker was supposed to be closed to new
>>> entries
>>> after your transition to github--is that not the case?
>>
>> Unfortunately, disabling the sourceforge tracker makes the links I
>> created in the github issues unreachable.
>
> Then we have a real mess.  Any ideas?  Continuing with a couple hundred
> issues duplicated in the two trackers, and with people still filing issues
> in both, is completely unacceptable.  I'm inclined to think that having gone
> this far, we have to simply shut off the sourceforge tracker and accept the
> loss of some information.  As it is, conversation about issues that have
> been transferred to github is effectively disconnected from the original
> posters, without their having been notified.  Ideally, all open issues on
> sourceforge would be closed with a final comment noting the transfer to
> github, but I suspect this is not feasible.
>
> You may switch any replies to matplotlib-devel if you like; maybe someone
> else has an idea.

I'm working on a mass-closing of issues at the sourceforge tracker. I
made a canned response that will direct to the github issues site.

Darren

On Fri, Jun 24, 2011 at 9:56 AM, Benjamin Root <ben...@ou...> wrote:

> Hello again,
>
> I am trying to figure out a regression in mplot3d code where the plot's
> ability to rotate and zoom are severely hindered.  I want to do some
> profiling comparisons, but I need identical runs to do this.  I know I
> probably could figure out how to properly simulate the motion of a mouse and
> button presses through the callback system, but I wanted to first see if
> anybody else has done anything like this.
>
> Thanks,
> Ben Root
>

Solved.  I figured out how to use ldtp and use it to interact with an
example script.  For future reference, I am attaching a script that
demonstrates this usage.

I hope it helps someone in the future!  (Maybe we might even want to
consider it as an option to turn on in our test suite for a full test
system?).

Ben Root

Hello again,

I am trying to figure out a regression in mplot3d code where the plot's
ability to rotate and zoom are severely hindered.  I want to do some
profiling comparisons, but I need identical runs to do this.  I know I
probably could figure out how to properly simulate the motion of a mouse and
button presses through the callback system, but I wanted to first see if
anybody else has done anything like this.

Thanks,
Ben Root

On Thu, Jun 23, 2011 at 6:55 PM, Benjamin Root <ben...@ou...> wrote:

> On Thu, Jun 23, 2011 at 4:29 PM, Eric Firing <ef...@ha...> wrote:
>
>> On 06/23/2011 10:53 AM, John Hunter wrote:
>> > On Thu, Jun 23, 2011 at 3:11 PM, Michael Droettboom<md...@st...>
>>  wrote:
>> >> On 06/23/2011 03:49 PM, Benjamin Root wrote:
>> >>
>> >> Hello all,
>> >>
>> >> I am working to make mplot3d feature-parity with regular axes objects.
>>  I
>> >> have come across a possible design flaw with the CallbackRegistry.
>> >>
>> >> Many of the Axes3D methods are merely wrappers around Axes methods
>> letting
>> >> it do the work for x and y axis and then let Axes3D do the same for the
>> z
>> >> axis.  In Axes.cla(), self.callbacks gets a CallbackRegistry of signals
>> >> named "xlim_changed" and "ylim_changed".  However, once that is set, it
>> does
>> >> not appear to be a way for me to add another signal of "zlim_changed"
>> in
>> >> Axes3D.cla().  I could replace self.callbacks with a new
>> CallbackRegistry,
>> >> but since there is a lot of interveaning code between that first
>> >> initialization of self.callbacks and coming back out of Axes.cla(), I
>> worry
>> >> that some callbacks may have been registered by then and would get
>> >> eliminated in the process.
>> >>
>> >> Is there a recommended way around this?  Or maybe this is more evidence
>> that
>> >> we should move towards the use of a dictionary of axis objects and make
>> Axes
>> >> functions more agnostic to the number of axis?
>> >>
>> >> I don't know if there is a way around it as the code currently stands.
>>  Your
>> >> proposal here:
>> >>
>> >> https://github.com/matplotlib/matplotlib/issues/379
>> >>
>> >> seems like one way out.  Then the code that creates the
>> CallbackRegistry in
>> >> Axes.cla() could iterate through all the axes and create a callback
>> type for
>> >> each of them.
>> >>
>> >> However, to step back from this, I've never quite understood why it was
>> >> necessary to have a fixed set of callback types in the CallbackRegistry
>> to
>> >> begin with.  It seems to me it comes from a history of callback
>> registry
>> >> classes I've seen in more static languages (such as libsigc++).  We
>> could
>> >> just as easily create new signal types on the fly as they are
>> registered.
>> >> You lose some error checking, I suppose, if the caller and receiver
>> don't
>> >> agree on the names, but seems like a small price to pay.
>> >
>> > CallbackRegistry.signals is a "public" attribute, so is there anything
>> > preventing you Ben from just doing
>> >
>> >    self.callbacks.signals.add('zlim_changed')
>> >
>> > and then connecting your desired callback?
>>
>> Yes, it requires some modification to the CallbackRegistry:
>>
>>     def __init__(self, signals):
>>         '*signals* is a sequence of valid signals'
>>         self.signals = set(signals)
>>         self.callbacks = dict([(s, dict()) for s in signals])
>>         self._cid = 0
>>
>> So adding to the set of signals is not enough.  It would be easy to made
>> an add_signal() method to take care of the two necessary steps.  It
>> would seem simpler, however, to just let the signals be added
>> automatically as needed, as I believe Mike is suggesting.
>>
>> Actually, it looks like self.signals could be replaced by a property
>> that, upon reading, would return self.callbacks.keys().  Why use two
>> data structures if one will do?  Of course, since signals is public,
>> that would represent API breakage--but of a rather obscure sort.
>>
>> (Shooting from the hip; I haven't looked closely.)
>>
>> Eric
>>
>>
> I am willing to go with whatever makes everyone happy.  I have a limited
> amount of time, and my goal with the feature-parity branch (found here:
> https://github.com/WeatherGod/matplotlib/tree/mplot3d/consistency ) is to
> get a z-version of every single axis-related function into Axes3D, and make
> sure that most other functions that operate on arbitrary axis are capable of
> acting on the z-axis.
>
> However, I do not intend to make sure that everything works (only that
> there are no regressions).  For example, setting axis label properties
> ('right', 'left', etc.) make little sense in the current context, and
> working with minor ticks do nothing in mplot3d.  The idea is that if the
> added functions work, then that is good news.  If the added functions do not
> work, then that can be a bug report.
>
> Therefore, anything that gets me to that goal would be fine.  Heck, doing
> nothing about this might also work because there never was a callback for
> zlim_changed before, so not having it now will be no loss of function.
>
> Sorry for rambling,
> Ben Root
>
>

I put up a pull request for adding the method "add_signal" to the
CallbackRegistry here: https://github.com/matplotlib/matplotlib/pull/381

Ben Root