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

[Kotlin Migration] SchedTest #11837

Closed
wants to merge 2 commits into from

Conversation

Prince-kushwaha
Copy link
Contributor

Pull Request template

Purpose / Description

Kotlin Migration of SchedTest

@Prince-kushwaha Prince-kushwaha marked this pull request as draft July 11, 2022 17:04
@dae
Copy link
Contributor

dae commented Jul 11, 2022

This looks like it's not based on latest main, as some of these changes were already made in #11802

@Prince-kushwaha Prince-kushwaha force-pushed the sched branch 4 times, most recently from ccc8207 to 190fb4b Compare July 12, 2022 04:57
@Prince-kushwaha Prince-kushwaha marked this pull request as ready for review July 12, 2022 05:14
@lukstbit lukstbit added the Needs Author Reply Waiting for a reply from the original author label Jul 13, 2022
Copy link
Member

@lukstbit lukstbit left a comment

Choose a reason for hiding this comment

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

Ok!

@lukstbit lukstbit added Needs Second Approval Has one approval, one more approval to merge and removed Needs Author Reply Waiting for a reply from the original author labels Jul 14, 2022
@mikehardy
Copy link
Member

This is an area of really fast change - which is both unfortunate (it keeps blowing up the PR, I'm so sorry) but also rare and amazing (as Damien has taken the time to make really big/important advances in the scheduler support with #10411 ) - it means this needs another scan though since I just merged #10411 so now scheduler code changed up again. I'm not aware of any other PRs against the scheduler at the moment, at least

@mikehardy mikehardy added the Needs Author Reply Waiting for a reply from the original author label Jul 30, 2022
@Arthur-Milchior
Copy link
Member

And now there is a conflict, sorry

@Prince-kushwaha Prince-kushwaha force-pushed the sched branch 2 times, most recently from 7c17954 to e4db70b Compare August 1, 2022 02:33
Copy link
Member

@Arthur-Milchior Arthur-Milchior left a comment

Choose a reason for hiding this comment

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

Thanks a lot. A few nit if you please.

Your assertEqual longs, make me thought about #11965

@@ -124,7 +123,7 @@ interface LimitMethod {
/** Given a deck, compute the number of cards to see today, taking its pre-computed limit into consideration. It
* considers either review or new cards. Used by WalkingCount to consider all subdecks and parents of a specific
* decks. */

Copy link
Member

Choose a reason for hiding this comment

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

Can you revert changes on AnkiDroid/src/main/java/com/ichi2/libanki/sched/SchedV2.java ? Or explain in the commit message why they are required (I think they are not)

for (TreeNode<DeckDueTreeNode> node : tree) {
if (node.getValue().getDid() == didToFind) {
return node.getValue();
for ((value) in tree) {
Copy link
Member

Choose a reason for hiding this comment

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

It took me some time to understand that (value) assigns value to what used to be node.getValue().
I'd prefer if we could remain closer to java and just add a KotlinCleanup to improve later.

Also, I don't like value as name here. It's far too vague. In this case, maybe something such as topLevelDeckNode would be better, since this value is one node representing a top level deck I believe

}

private fun getCountsForDid(didToFind: Double): DeckDueTreeNode {
Copy link
Member

Choose a reason for hiding this comment

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

Can you add a kotlin cleanup. There is no reason for did to be Double. It should be a long

// first card we get comes from parent
Card c = getCard();
assertEquals(1, c.getDid());
val c = card!!
Copy link
Member

Choose a reason for hiding this comment

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

I'm not fan of this rewritting. getCard may not be an ideal name to indicate that it actually does a non trivial access work, but at least, it's a function, so it's clear it can occur. On the other hand, c = card!! seems to be really a copy of the reference from a member to a local variable. If it ever needs to be debugged, it'll be hard to realize that some non-trivial action is actually occurring here.
So please keep getCard everywhere.

Maybe a KotlinCleanup to change getCard to some more precise name such as findNextCard()

conf1.getJSONObject("new").put("perDay", 10)
col.decks.save(conf1)
col.reset()
assertEquals(10, col.sched.counts().new.toLong())
Copy link
Member

Choose a reason for hiding this comment

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

Maybe also replace 10 by 10L so that at least it's very clear both are long.
And maybe add a comment in the commit message that you made this change because there is no assertEquals(int, int) and Kotlin rules would default to Object, Object where Java defaulted to long, long

assertEquals("2 d", without_unicode_isolation(col.getSched().nextIvlStr(getTargetContext(), c, BUTTON_TWO)));
assertEquals("3 d", without_unicode_isolation(col.getSched().nextIvlStr(getTargetContext(), c, BUTTON_THREE)));
assertEquals("4 d", without_unicode_isolation(col.getSched().nextIvlStr(getTargetContext(), c, BUTTON_FOUR)));
assertEquals(
Copy link
Member

Choose a reason for hiding this comment

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

Add a cleanup to avoid code repetition here. With newlines it really becomes useful here

@mikehardy mikehardy removed the Needs Second Approval Has one approval, one more approval to merge label Aug 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Author Reply Waiting for a reply from the original author
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants