Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix sorting of multiple keys and misc #93

Merged
merged 19 commits into from
Oct 31, 2020
Merged

Fix sorting of multiple keys and misc #93

merged 19 commits into from
Oct 31, 2020

Conversation

Vindaar
Copy link
Owner

@Vindaar Vindaar commented Oct 5, 2020

Mainly fixes a bug messing up sorting by multiple keys. The last row was not sorted and remained the unsorted last row.

Note to self: should spend more time writing tests...

Full changelog:

* v0.3.20
- fix a bug that causes the =arrange= proc to mess up sorting if more
  than one key is used. The last row of the DF was not sorted before
  and thus remained in unsorted order at the end of the sorted result.
- =geom_errorbar= now takes an =errorBarKind= field to set the kind of
  errorbar to draw
  - =ebLinesT=, =ebLines= are the only two options atm
- add =scale_fill_continuous= to force the fill scale to be
  interpreted as continuous values
- =ggsave= will now create the directories contained in the path given
  to it instead of silently not creating a plot if the path to the
  given file does not exist yet.
- attempt to get rid of duplicate legends in case of certain ggplot calls

@Vindaar
Copy link
Owner Author

Vindaar commented Oct 5, 2020

Did I seriously manage to bake in bugs into the tests or did I also break something at the same time?

Will investigate in the coming days.

facepalm: I guess I did. Who decided I get to code this?
edit2: oh no, haha. I didn't after all. I just confused the buggy number with the tests number. So I only broke something after all.
edit3: fixed it. Nothing too bad, just me misunderstanding my own code... :)

The old bug was that I misunderstood my own logic a few months after
writing. Hence the notes now.
The problem was just that I didn't realize that `i == df.high` and any
other case before that where we want to sort (`last != cur`) are
different in terms of the last idx to be sorted.
This happens for instance for a facet wrap, where we don't draw the
tick labels on the plots not on the left side (y axis). Then we ended
up with a wrong number of elements in the `labs` sequence, which
caused a index error when accessing the labs later (it `must` have as
many elements as `filterIdx` here)
This only performs a permutation so the user needs to be aware of the
correct order of the legend.
It's an experimental feature, which will either be rewritten or at
least improved on.
Due to the introduction of wrapping of the titles the placement and
name of the resulting GraphObjects changes slighlty.
@Vindaar Vindaar merged commit 4cc5cbd into master Oct 31, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant