General strategy question: do you expect to be able to get to the test-and-fix stage (4) with one or a few traits at a time, or do you have to get everything in place before you can make anything work?

@efiring I'm hoping to be able to do things in batches. Right now I'm working with stale, transform_set, transform. The only reason I'm not doing large batches is to make tracing bugs easier.

I would start with something simpler, like color or zorder rather than
transform

On Thu, Jul 23, 2015, 2:44 PM Ryan Morshead notifications@github.com
wrote:

@efiring https://github.com/efiring I'm hoping to be able to do things
in batches. Right now I'm working with stale, transform_set, transform.
The only reason I'm not doing large batches is to make tracing bugs easier.

—
Reply to this email directly or view it on GitHub
#4762 (comment)
.

On 2015年07月23日 8:44 AM, Ryan Morshead wrote:

@efiring https://github.com/efiring I'm hoping to be able to do things
in batches. Right now I'm working with |stale|, |transform_set|,
|transform|. The only reason I'm not doing large batches is to make
tracing bugs easier.

Good. I advocate small batches for exactly that reason: much easier to
find and fix bugs. Better to keep it simple while gaining experience.
These are massively intrusive changes. It would be nice to get a sense
of what they involve, and what sorts of consequences they have, sooner
rather than later.

Do you have any way of evaluating the performance consequences of these
changes?

On 2015年07月23日 8:46 AM, Thomas A Caswell wrote:

I would start with something simpler, like color or zorder rather than
transform

Good idea, though I think that color is actually one of the most
complicated parameters--maybe the most complicated.

One argument for doing "stale", "transform", etc first is that these are
typically not user-facing, and they have fairly well defined interactions,
yet they have major performance implications. I would think that changes
here would be less intrusive, and fairly obvious if something has gone
wrong.

On Thu, Jul 23, 2015 at 2:55 PM, Eric Firing notifications@github.com
wrote:

On 2015年07月23日 8:46 AM, Thomas A Caswell wrote:

I would start with something simpler, like color or zorder rather than
transform

Good idea, though I think that color is actually one of the most
complicated parameters--maybe the most complicated.

—
Reply to this email directly or view it on GitHub
#4762 (comment)
.

examples/pylab_examples/simple_plot_fps.py
run against master and traitlets branches
(origin/master is up to date with the upstream/master)

-- Master Results --
avg wallclock: 0.0145939850807
avg user: 0.014611467
avg fps: 6852.13801761
-- Traitlets Results --
avg wallclock: 0.0166525568962
avg user: 0.0166520915
avg fps: 6005.08382126
Active TraitTypes:
+ transform
+ transform_set
+ stale
+ axes
* averaged over 2000 iterations

Thanks for the benchmark results. About a 14% penalty so far, in this
test. What kind of a plot was it?

On 8/2/15, Ryan Morshead notifications@github.com wrote:

-- Master Results --
avg wallclock: 0.0145939850807
avg user: 0.014611467
avg fps: 6852.13801761
-- TRAITLET RESULTS --
avg wallclock: 0.0166525568962
avg user: 0.0166520915
avg fps: 6005.08382126
Active TraitTypes:
+ transform
+ transform_set
+ stale
+ axes
* averaged over 2000 iterations

---

Reply to this email directly or view it on GitHub:
#4762 (comment)

@efiring test code was taken directly from simple_plot_fps.py

Rebased origin/traitlets on top of commits to #4694 made by @AndreLobato for the color TraitType. Updated origin/master to upstream/master then rebased origin/traitlets on top of origin/master. Ran the begining of the test suite again and the first error I encountered occurred when writing to a png from the pdf backend:

File "/Users/RyanMorshead/Coding/GitHub/matplotlib/lib/matplotlib/backends/backend_pdf.py", line 1288, in _writePng
 _png.write_png(data, buffer)
ValueError: Buffer must be RGBA NxMx4 array

Haven't investigated yet, but any chance that's coming from the changes to upstream/master? I wouldn't really expect the TraitTypes to influence that sort of thing.

@rmorshea If that is happening locally, then the problem is out-dated c-cextensions (there was some recent work to improve the pdf backends handling of raster data).

Is that something that requires work on your end to fix? Also, I'm presuming that Travis CI won't be able to build this branch until traitlets is officially supported?

Try deleting the build directory and rebuilding. distutils doesn't do proper dependency resolution for C++ headers.

I got the same sort of getattr error three times (once like travis and twice on a different test), but have not been able to reproduce it and get a debugger on it. The failure on the scatter test probably is inducing the other 3 failures.

I can reproduce the sphinx issue locally, but no real guess at what is causing it. I don't think it is something maformed with that intermediate output of the rst file, but I don't know where shpnix keeps them to check...

Frustratingly, I can't reproduce the getattr error either. What version of traitlets are @rmorshea or @tacaswell running? Maybe that's relevant.

I'm looking into the Sphinx issue now...

I'm running Traitlets off master right now.

I copy-pasted the pip source install from .travis.yml.

I'm going to finish rebasing (as best I can), and see where I'm at:

I feel like I've learned so much since I began this that it might be worth tearing everything down to start again with better practices and better ideas. If I had the time, I'd start from a fresh fork, but since I don't I'm hesitant.

I'll try to figure that out this week though.

@tacaswell

@rmorshea my impression is that there have been some big changes in traitlets since you started. Is this correct, and if so were they early enough in the process that you were able to take advantage of them? In any case, I'm glad you are able to get back to this now.

Answering my own question, it looks like the major change was the introduction of decorators, which you are already using. So the difficulties are because of all the mpl changes in the interim.

@efiring, yes. The main outward change to Traitlets has been the new decorator API.

Current plan: rebuild from the ground up, but repurpose my past work wherever possible.

There are three reasons that I want to do this (in order of importance):

1. My rebase has been pretty painful.
2. I can write cleaner, and more effective code than when I started this project.
3. There have been some internal changes to Traitlets that could allow me to build custom tools for Matplotlib that will streamline certain validation, and notification pathways.

Rebase is unreasonably hairy - closing pending #8035 corresponding PR.

This can be revisited if someone takes up the traitlets torch