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

Rebase on OrderedCollections #448

Merged
merged 2 commits into from
Sep 21, 2018
Merged

Rebase on OrderedCollections #448

merged 2 commits into from
Sep 21, 2018

Conversation

timholy
Copy link
Member

@timholy timholy commented Sep 19, 2018

This removes the OrderedDict/OrderedSet functionality in favor of the implementation in OrderedCollections. Sorry this took so long.

@oxinabox oxinabox self-assigned this Sep 19, 2018
@@ -4,6 +4,7 @@ version = "0.12.0"

[deps]
InteractiveUtils = "b77e0a4c-d291-57a0-90e8-8db25a27a240"
OrderedCollections = "bac558e1-5e72-5ebc-8fee-abe8a469f55d"

Copy link
Member

@oxinabox oxinabox Sep 19, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to set a [compat] here?
It might make things more orthogonal.
Or it might not

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it's necessary, since the latest tagged version of OrderedCollections works here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since I was making other changes, I added the compat

_tablesz(x::Integer) = x < 16 ? 16 : one(x)<<((sizeof(x)<<3)-leading_zeros(x-1))
hashindex(key, sz) = (reinterpret(Int,(hash(key))) & (sz-1)) + 1

function not_iterator_of_pairs(kv)
Copy link
Member

@oxinabox oxinabox Sep 19, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not thrilled at the idea of depending on importing this from
OrderedCollections,
because out other dicts need it,
and ideally we'ld be able to cut them out into their own packages,
which would also not depend on OrderedCollections

I see two alternative options.

  1. just duplicate the code. I don't mind this, while it is not DRY, it does let us evolve the remainind dicts independently of OrderedCollections
  2. make a micro package DataStructuresUtil.jl or some such, and have both import this.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interestingly, I think OrderedCollections doesn't even use that function. So I can put it back here and delete it from there.

@codecov
Copy link

codecov bot commented Sep 19, 2018

Codecov Report

Merging #448 into master will increase coverage by 0.65%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #448      +/-   ##
==========================================
+ Coverage   98.07%   98.73%   +0.65%     
==========================================
  Files          30       28       -2     
  Lines        1558     1342     -216     
==========================================
- Hits         1528     1325     -203     
+ Misses         30       17      -13
Impacted Files Coverage Δ
src/dict_support.jl 100% <ø> (ø) ⬆️

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 bdd7aa0...1d50fce. Read the comment docs.

@oxinabox
Copy link
Member

Checking others
is_ordered is a trait, (exists reL #237)
and it conceptually belongs to the OrderedCollection namespace

using InteractiveUtils: methodswith
using OrderedCollections
using OrderedCollections: not_iterator_of_pairs, rehash!
import OrderedCollections: filter, filter!, isordered
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

filter and filter! both come from Base
Why are they being imported?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, they have to be imported because DataStructures extends them. I imported them from OrderedCollections instead of Base due to the Iterators.filter separation---I basically thought "this should be the same filter that OrderedCollections uses, whatever version of filter that is."

@@ -16,7 +16,9 @@ module DataStructures
eachindex, keytype, valtype
import Base: iterate

using InteractiveUtils: methodswith
using OrderedCollections
using OrderedCollections: not_iterator_of_pairs, rehash!
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rehash! AFAICT is only used by OrderedCollections
so I don't think we need it to be used.
(or did I miss an usage?)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah,
I thought that file had been moved over.
I think it should be moved over.
It uses only Base and OrderedCollections types, no?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, you're absolutely right.

Oddly, these comments only show up if I access this page in certain ways. Weird GitHub bug?

@oxinabox
Copy link
Member

Ok, I am done with my look over.
Thanks for doing this.

(Complete sidenote; thanks for the recommendation of Gopen and Swan's "The Science of Scientific Writing". I wish I'ld read it at the start of my PhD, but reading it before writing my thesis intro/conclusion is definitely better than never.)

@timholy timholy force-pushed the teh/fork_orderedcollections branch 3 times, most recently from a573b51 to 64807f6 Compare September 19, 2018 13:17
@timholy
Copy link
Member Author

timholy commented Sep 19, 2018

Good to go? EDIT: nvm, just noticed your comment above.

@@ -1 +1,2 @@
julia 0.7
OrderedCollections 1.0.1
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we just get rid of this file now?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope, I checked this morning.
Attobot won't talk to you if you don't have a REQUIRE file.

@timholy
Copy link
Member Author

timholy commented Sep 20, 2018

Good to go? The appveyor failure seems independent.

@timholy
Copy link
Member Author

timholy commented Sep 20, 2018

Unless there are objections I'm going to merge this soon because in the current situation we are causing problems: see JuliaCollections/OrderedCollections.jl#10

Copy link
Member

@oxinabox oxinabox left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@timholy timholy merged commit 525f990 into master Sep 21, 2018
@timholy timholy deleted the teh/fork_orderedcollections branch September 21, 2018 10:05
@timholy
Copy link
Member Author

timholy commented Sep 21, 2018

Thanks! Sorry this took more review from you than it should have.

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.

None yet

2 participants