Skip to content

Added serde1 feature to Serialize/Deserialize WeightedIndex#974

Merged
dhardy merged 14 commits into
rust-random:masterfrom
CGMossa:add_serde_feature
May 18, 2020
Merged

Added serde1 feature to Serialize/Deserialize WeightedIndex#974
dhardy merged 14 commits into
rust-random:masterfrom
CGMossa:add_serde_feature

Conversation

@CGMossa

@CGMossa CGMossa commented May 1, 2020

Copy link
Copy Markdown
Contributor

It required adding serde as an optional dependency.
Also added a test using bincode like in the other crate.

Referering to this: #967

I hope this is up to standard, otherwise I'll take all of your feedback and ensure it is as correct
as possible.

It required adding serde as an optional dependency.
Also added a test using bincode like in the other crate.
@dhardy

dhardy commented May 1, 2020

Copy link
Copy Markdown
Member

Thanks @CGMossa. Hmm, would it be possible to do the reformatting first in its own commit? Also please add a note to the changelog.

https://rust-random.github.io/book/contributing.html

@CGMossa

CGMossa commented May 1, 2020 via email

Copy link
Copy Markdown
Contributor Author

@dhardy

dhardy commented May 1, 2020

Copy link
Copy Markdown
Member

I thought you'd suggest more things to add the derive attribute to. I'd be
happy to add it everywhere needed. But I don't know which places.

It crossed my mind that this might be a good idea, but I didn't look into where yet. Probably would only be applicable to distributions.

@CGMossa

CGMossa commented May 2, 2020 via email

Copy link
Copy Markdown
Contributor Author

@vks

vks commented May 2, 2020

Copy link
Copy Markdown
Contributor

It looks like the minimal supported serde version is incorrectly specified.

@CGMossa

CGMossa commented May 3, 2020

Copy link
Copy Markdown
Contributor Author

I wrote it exactly like it is written in rand_core and rand_pcg. Which version should I write instead?
Should I use this

serde = "1.0.106"

or

serde = "1.0.*"

?

Hopefully this will do it.
@CGMossa

CGMossa commented May 3, 2020

Copy link
Copy Markdown
Contributor Author

I see that tha CI stuff is resulting in an error. I am unable to see the same error here. I've added a version number to one of the Cargo.toml and I'll wait and see. Even if I run the command that is making the error cargo test --features=serde1,log I don't get an error. But I have serde 1.0.105 installed and the latest is 1.0.106 and maybe the thing on the here has an earlier version?

@CGMossa

CGMossa commented May 3, 2020

Copy link
Copy Markdown
Contributor Author

This worked. I've no idea why, since the other crates in the rand-workspace also indicated serde with "1". Maybe they fixed a bug? Although, not this works.

@dhardy

dhardy commented May 4, 2020

Copy link
Copy Markdown
Member

We test with the minimal version of Serde which crates say they support — but this must be unified across all dependencies, so will be the highest minimum version. The idea is to find the real minimum version, but I think most people only care that it's high enough to work. That said, 1.0.105 is less than two months old. If an older version suffices that would be preferable. You can test locally via cargo generate-lockfile -Z minimal-versions

@dhardy

dhardy commented May 4, 2020

Copy link
Copy Markdown
Member

For completeness's sake (if you don't mind), we should also consider: Bernoulli, Uniform, UniformFloat, UniformDuration, StepRng, IndexVec (maybe).
The following structs have zero size (thus don't need serialising), but doing so might ease deriving of other types: OpenClosed01, Open01, Standard, Alphanumeric.

@CGMossa

CGMossa commented May 4, 2020 via email

Copy link
Copy Markdown
Contributor Author

@CGMossa

CGMossa commented May 4, 2020

Copy link
Copy Markdown
Contributor Author

Minimal supported serde version is 1.0.103. Release note says:

Support deserializing untagged unit variants from formats that treat unit as None (#1668)

Test command:

rustup run nightly cargo generate-lockfile -Z minimal-versions & cargo test --features=serde1,log

CGMossa added 4 commits May 4, 2020 12:12
#TODO: Test of equality between ser/de is needed.
#TODO: Unable to test equality in mode between de-serialized and original UniformDuration
@dhardy

dhardy commented May 4, 2020

Copy link
Copy Markdown
Member

1.0.103

This version is almost six months old. Since we're developing against the master branch (will be a breaking release), this is fine IMO.

@CGMossa

CGMossa commented May 4, 2020

Copy link
Copy Markdown
Contributor Author

I've added the serialize and deserialize annotations. I also wanted to add tests using bincode, but some of these types have no fields I can test equality against, and PartialEq is not implemented for them so.. I don't know.

I've left some skeleton code, awaiting further feedback.

(this is like my biggest attempt at contributing yet! Thanks for the PR-mentoring!!)

@CGMossa

CGMossa commented May 14, 2020

Copy link
Copy Markdown
Contributor Author

Am I missing more things here?

@dhardy

dhardy commented May 14, 2020

Copy link
Copy Markdown
Member

Sorry, I'll try to review in the next couple of days.

@dhardy dhardy left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Sorry, I haven't been paying this project much attention lately!

Your PR looks good. Those unfinished bits shouldn't be hard (I gave a couple hints).

Comment thread src/seq/index.rs Outdated
Comment thread src/distributions/uniform.rs Outdated
@CGMossa

CGMossa commented May 15, 2020

Copy link
Copy Markdown
Contributor Author

I've added the tests based on your suggestions.

Do I resolve them or do I wait for you to click that they are resolved?

@dhardy dhardy left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Looks good to me. (There are some over-long lines, and you didn't need to match cases which can't occur in the tests, but it's still good enough.)

I'll wait a couple of days in case @vks wishes to review, then merge.

Comment thread Cargo.toml
Comment thread src/seq/index.rs Outdated

@vks vks left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Looks good!

@vks

vks commented May 15, 2020

Copy link
Copy Markdown
Contributor

This should probably be squashed before merging. I think this is technically a breaking change.

@CGMossa

CGMossa commented May 15, 2020

Copy link
Copy Markdown
Contributor Author

I don't know how to squash?

@vks

vks commented May 15, 2020

Copy link
Copy Markdown
Contributor

I think GitHub offers this option to the maintainers, but it seems like it is disabled for this repository.

Edit: I just enabled it, you don't have to do anything, we can let GitHub do it.

If you want to do that yourself, you can use git rebase -i to specify which commits should be squashed.

@vks vks changed the title Added serde1 feature to Serialize/Deseriaslize WeightedIndex Added serde1 feature to Serialize/Deserialize WeightedIndex May 15, 2020
@dhardy

dhardy commented May 16, 2020

Copy link
Copy Markdown
Member

master already contains breaking changes, so no problem there.

@CGMossa

CGMossa commented May 17, 2020

Copy link
Copy Markdown
Contributor Author

I've added the missing spaces. Thanks for enabling that feature, as I've got no training in using rebase or squashing. I'd appreciate a link to learn about this.

@dhardy

dhardy commented May 18, 2020

Copy link
Copy Markdown
Member

Thanks for the PR!

git rebase is quite useful. Also git add -p. You may want to test them out on a dummy repo!

@dhardy dhardy merged commit 7ede440 into rust-random:master May 18, 2020
kazcw added a commit to kazcw/rand that referenced this pull request May 19, 2020
Implements rust-random#974. As in rust-random#975, but defining equality such that the user is
not exposed to the fact that one logical state may have different
representations in an implementation-specific way.
kazcw added a commit to kazcw/rand that referenced this pull request May 28, 2020
Implements rust-random#974. As in rust-random#975, but defining equality such that the user is
not exposed to the fact that one logical state may have different
representations in an implementation-specific way.
dhardy pushed a commit that referenced this pull request May 29, 2020
Implements #974. As in #975, but defining equality such that the user is
not exposed to the fact that one logical state may have different
representations in an implementation-specific way.
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.

3 participants