Html representation of processor and metadata in notebooks

[zain-sohail]

This PR introduces an expandable representation of the data and metadata, and perhaps plots. We can discuss what should be included and what not.
Just type sp in a notebook after processor class has been instantiated and it will output the html version.

But also the metadata repr is interesting:
To test: you can write sp.attributes in a notebook and that will give the html representation.
If print(sp.attributes) is used, it gives a yaml representation, which is also more human readable than json.

closes #35

[zain-sohail]

Similar additions were attempted in #305 but those are more specific to loaders with runs and maybe to Flash. We can see how to include those.

[coveralls]

Pull Request Test Coverage Report for Build 8987621591

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 86 of 98 (87.76%) changed or added relevant lines in 4 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.2%) to 91.704%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
sed/core/metadata.py	26	27	96.3%
sed/core/processor.py	5	16	31.25%

Totals
Change from base Build 8920863876:	0.2%
Covered Lines:	6113
Relevant Lines:	6666

---

💛 - Coveralls

[rettigl]

I generally like this a lot, however computing the head takes quite some time apparently, making the output quite slow.
Maybe we should discuss which parts of the beamtime addition to the representation we want to add.
Also, we should have tests for this as well (to see that it runs correctly for the different loaders, without a dataframe loaded, etc.).

[rettigl]

Part of the long processing time apparently comes from the metadata conversion:

This is probably due to large arrays being converted into html, so we should maybe exclude these and replace them with an information about the array shape or so.

[rettigl]

I'd also suggest to move the first layer of metadata one inset in already:

Because the expandable elements then look like first-layer elements. Maybe generally for all entries (also the dataframe etc.).

[rettigl]

Part of the long processing time apparently comes from the metadata conversion: This is probably due to large arrays being converted into html, so we should maybe exclude these and replace them with an information about the array shape or so.

It mostly is due to the large deformation fields:

[zain-sohail]

Part of the long processing time apparently comes from the metadata conversion:
This is probably due to large arrays being converted into html, so we should maybe exclude these and replace them with an information about the array shape or so.

Seems to not be the case. Even with shape, it is slow.

I tried to check directly with a test class and it outputs the html in 0 s

I am trying to figure out where the slowdown is.

[zain-sohail]

The problem has been resolved. It was the __repr__ dumping to yaml that took so long. And somehow when _repr_html is called, it also calls __repr__

[zain-sohail]

we should have tests for this as well (to see that it runs correctly for the different loaders, without a dataframe loaded, etc.).

I have added tests to the Metadata class and it's repr/repr_html but not sure how to test what you suggested.

[rettigl]

LGTM now.
We can still add part of Steinn's code, or do this in a later PR (add issue then).