style settings configuration

[AnderEnder]

Work in progress: implementing some of arguments setting from #16

[jonhoo]

Just a note that you should probably do your work on top of @JordiChauzi's changes in #32, since they affect a lot of the style code!

[AnderEnder]

@jonhoo, lets wait #32 to be merged then I will rebase and rework the code

This is a still experimental change, so I may to rethink the implementation, so any comments are welcome.

[jonhoo]

Sounds like a good plan!

I just had a skim, and the move to SVGWriter is interesting.. I see why you did it, but I'm wondering if the types are actually used enough that it's worth the extra abstraction? I think this is particularly true if we land #50, since that also moves a bunch of user-defined values out of each element. I'll have to think a little more on it.

I think we'll also want to try to be a bit more helpful with descriptions of the flags than flamegraph.pl is. We don't need to stick to the very terse format that they use :) Also, I think structopt/clap will automatically mark a flag as optional if it's an Option<T>, so we don't also need to say that in the flag help text.

[jonhoo]

@AnderEnder #32 has now landed!

[jonhoo]

Also, just as a side note, now that we have comments pending, it'd be great if you can avoid force pushing. That way I can review just what has changed, rather than having to review the whole thing all over again :) We'll squash before merging anyway so the history remains clean!

[jonhoo]

Oh, now that we've had some other PRs land, there are also some conflicts with master that'll have to be resolved. I don't think any of them should be too bad though. If you get stuck on any of them, please let me know and I'll take a look! :)

[codecov-io]

Codecov Report

Merging #52 into master will increase coverage by 0.9%.
The diff coverage is 100%.

@@            Coverage Diff            @@
##           master      #52     +/-   ##
=========================================
+ Coverage   89.66%   90.57%   +0.9%     
=========================================
  Files          16       16             
  Lines        1558     1708    +150     
=========================================
+ Hits         1397     1547    +150     
  Misses        161      161

Impacted Files	Coverage Δ
src/flamegraph/svg.rs	98.71% <100%> (+0.3%)	⬆️
tests/flamegraph.rs	96.75% <100%> (+2.1%)	⬆️
src/flamegraph/mod.rs	95.78% <100%> (+0.18%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bd1fe47...cfefd3c. Read the comment docs.

[jonhoo]

@AnderEnder this is looking really good now! Only the one typo ("Chart" vs "Graph") and the JavaScript escaping left I think :)

[AnderEnder]

and test cases :)

[jasonrhansen]

@AnderEnder I reorganized and removed the duplication in the flamegraph tests in 59a9dac. It might be easier to revert your changes to the testing code, then merge master before adding any new tests.

[jasonrhansen]

@jonhoo I agree that we shouldn't need to include the JavaScript in all of the tests since it's static. Do you think we should just add a no-javascript flag that test_flamegraph could set?

[jonhoo]

Yeah, something like that. Probably make it #[doc(hidden)] since it's not something users should ever set. It has to be pub so that we can use it in integration tests sadly.

[AnderEnder]

@jonhoo and @jasonrhansen
I found that writing tests(working with xml) and finding difference is not an easy and pleasant task, so I think about using prettified(human readable with indentation) xml for tests.

[jasonrhansen]

@AnderEnder I agree that finding differences in the XML isn't nice since it's all on one line. For collapse-perf tests pretty_assertions works really well, but not for flamegraph. I wouldn't mind comparing prettified versions in tests. What do you think, @jonhoo?

[jonhoo]

pretty_assertions plus prettified XML seems like a great idea! I think we'll then definitely want to strip out the JavaScript for tests though.

[jasonrhansen]

We can use quick_xml::Writer::new_with_indent instead of quick_xml::Writer::new to pretty format the XML. Is this something we want to do always, or only for tests?

If we do it for tests only, should we add another flag for pretty-printed XML, or just add one flag for testing that both prettifies the XML and doesn't include the JavaScript?

The way I see it, a user would never want to generate a flame graph without JavaScript, but they might want to generate one with pretty XML. We could have the no-javascript flag use #[doc(hidden)], but make the pretty-xml flag a documented feature.

What are your thoughts?

[jasonrhansen]

Also, we probably want to still include the JavaScript output of this in the tests since the values are dynamic.

    svg.write_event(Event::CData(BytesText::from_escaped_str(&format!(
        "\
var nametype = '{}';
var fontsize = {};
var fontwidth = {};
var xpad = {};
var inverted = {};
var searchcolor = 'rgb(230,0,230)';",
        opt.name_type.replace("'", "\\'"),
        opt.font_size,
        opt.font_width,
        super::XPAD,
        opt.direction == Direction::Inverted
    ))))?;

[jonhoo]

pretty-xml seems like a good idea for a public flag, I agree! And no-javascript should be #[doc(hidden)].

And yes, we want that segment of JavaScript to be included, just not the giant JS file that's loaded with include_str!.

[jasonrhansen]

So in the library we can use #[doc(hidden)] for no-javascript and in the CLI we can make the flag hidden like this.

    #[structopt(raw(hidden = "true"), long = "no-javascript")]
    no_javascript: bool

[jonhoo]

I don't think we need the flag to be present at all in the CLI. All the tests operate directly on the library, no?

[jasonrhansen]

We don't necessarily need the flag on the CLI, but it would make it easier to create the test SVG files that our tests compare to. I suppose removing the JavaScript manually from the SVGs is easy enough though.

[jonhoo]

Hmm, I suppose that's a good point. I think I'd be okay with a hidden CLI flag too then. Maybe with a help text that explains exactly what the intended use-case is.

[jasonrhansen]

@AnderEnder I'm working on reorganizing the test data files. While I'm at it I can add the no-javascript and pretty-xml flags and modify all of the existing tests to use them. You could then update your tests to use those flags as well. I just want to make sure you're not already working on these specific changes. If you are, let me know.

[jasonrhansen]

I've made those changes in #70.

[jonhoo]

@AnderEnder a gentle ping on this -- it's a pretty wide change, and it will probably only get more painful to try to merge as time goes on. I think the only real remaining comment now is whether we simply import the escape function directly so we don't need the extra dependency? What do you think?

Also, I think @jasonrhansen's changes in #70 may let you simplify the tests somewhat, but he can advise on that better than I can.

[jasonrhansen]

@AnderEnder #70 changes the flamegraph tests to not include JavaScript and to pretty-print the XML so it's easy to see diffs when there is a test failure. Because of this, you'll need to regenerate the test SVGs using the following flags --no-javascript --pretty-xml.

The tests directory structure has also been altered. The files in tests/data are now organized into subdirectories for flamegraph, collapse-perf, etc. You'll want to put the test SVGs in a subdirectory inside tests/data/flamegraph.

[jonhoo]

I just did the merge with master, and realized that there were a bunch of other smaller changes. I'll open PRs for each of those changes separately, and will force-push this soon to contain only the relevant changes.

[jonhoo]

@jasonrhansen I believe this is now finally ready for review 🎉

[jasonrhansen]

It all looks good to me, except for my comment about putting DEFAULT_TITLE in quotes for structopt. But that could still be done in a separate PR.

[jonhoo]

👍 Filed as #91.

[jonhoo]

🎉

[jonhoo]

Thanks for all your work on this @AnderEnder !