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

add fromList tests #663

Merged
merged 2 commits into from
Aug 14, 2020
Merged

add fromList tests #663

merged 2 commits into from
Aug 14, 2020

Conversation

int-e
Copy link
Contributor

@int-e int-e commented Jul 8, 2019

This is adding some test cases that were previously part of #658.

Note that one test is currently failing because Data.IntMap.fromAscList is a bit lazier than expected.

@int-e int-e changed the title fromList tests add fromList tests Jul 8, 2019
--
-- Uses `reallyUnsafePtrEquality#`.
isUnit :: () -> Bool
isUnit = same ()
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm wondering whether I'm reinventing a wheel here. This seems closely related to what ChasingBottoms is doing, but I didn't find anything like this there.

Copy link
Contributor

Choose a reason for hiding this comment

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

This smells funny/fragile to me. I would generally feel more comfortable with an approach that uses unsafePerformIO to find out when/how many times things are evaluated.

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, but of course we can't always do that .... Hrmmm. Could you at least rename same to match our internal pointer equality function?

Copy link
Contributor Author

@int-e int-e Jul 15, 2019

Choose a reason for hiding this comment

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

Oh I wasn't aware of ptrEq, or I would have used that; will change.

I should probably make the tests conditional on __GLASGOW_HASKELL__ being defined... and maybe make isUnit tristate? (Yes | No | Maybe; the last indicating that the result is unknown.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh I wasn't aware of ptrEq, or I would have used that; will change.

Ah it's not so easy because the module is hidden, and we probably want to keep the library parts of containers-tests and containers the same.

I should probably make the tests conditional on __GLASGOW_HASKELL__ being defined... and maybe make isUnit tristate? (Yes | No | Maybe; the last indicating that the result is unknown.)

I will go with Maybe Bool.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Given your later comment, I stuck with Bool. I did add some logic to deal with non-ghc implementations though.

@treeowl
Copy link
Contributor

treeowl commented Jul 14, 2019

Do you consider the test or the code correct? Or neither?

@int-e
Copy link
Contributor Author

int-e commented Jul 14, 2019

I believe the test is correct (it will pass once #658 is merged).

@treeowl
Copy link
Contributor

treeowl commented Jul 15, 2019 via email

@int-e
Copy link
Contributor Author

int-e commented Jul 15, 2019

Can you rebase please?

Done. (I don't know whether the force-push itself causes a notification.)

@treeowl
Copy link
Contributor

treeowl commented Jul 15, 2019 via email

@sjakobi
Copy link
Member

sjakobi commented Aug 1, 2020

@int-e, @treeowl, what's the status here?

@int-e
Copy link
Contributor Author

int-e commented Aug 2, 2020

Nothing new from my side... the branch rebased cleanly on current master, and the tests currently pass (for me).

Copy link
Member

@sjakobi sjakobi left a comment

Choose a reason for hiding this comment

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

Cool! I see a few wibbles, but nothing big. I hope we can get this merged soon! :)

containers-tests/tests/intmap-strictness.hs Outdated Show resolved Hide resolved
containers-tests/tests/intmap-strictness.hs Outdated Show resolved Hide resolved
containers-tests/tests/intmap-strictness.hs Outdated Show resolved Hide resolved
containers-tests/tests/intmap-strictness.hs Outdated Show resolved Hide resolved
Copy link
Member

@sjakobi sjakobi left a comment

Choose a reason for hiding this comment

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

One last wibble.

These tests look really useful to me!

containers-tests/tests/intmap-strictness.hs Outdated Show resolved Hide resolved
int-e added 2 commits August 4, 2020 09:15
- the function is rather peculiar in that in the presence of
  duplicate keys, the first value is not evaluated, but all
  the others are evaluated. See also #473.
- we check most functions that create or update entries, namely
  singleton, insert, insertWith, fromList, fromListWith,
  fromAscList, fromDistinctAscList, and fromAscListWith
Copy link
Member

@sjakobi sjakobi left a comment

Choose a reason for hiding this comment

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

LGTM and many thanks! :)

@treeowl, please review!

@sjakobi
Copy link
Member

sjakobi commented Aug 14, 2020

@treeowl, please review!

Ping @treeowl! :)

@treeowl treeowl merged commit b64a103 into haskell:master Aug 14, 2020
@int-e int-e deleted the fromlist-tests branch August 14, 2020 16:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants