Inconsistent `BITPOS`: BITPOS bit=0 unaligned+full word+reminder
Steps to reproduce
Run the commands mentioned in the test on Line 296 in the file https://github.com/AshwinKul28/dice-tests/blob/main/tcltests/unit/bitpos.tcl#L296
Expected output
The expected output when the above set of commands when run on Redis
Expected [r bitpos str 0]
Observed output
The observed output when the above set of commands when run on DiceDB
216 (context: type eval line 10 cmd {assert {[r bitpos str 0]
The steps to run the test cases are mentioned in the README of the dice-tests repository.
Expectations for resolution
This issue will be considered resolved when the following things are done:
- Changes in the
dicerepository code to meet the expected behavior. - Successful run of the tcl test behavior.
You can find the tests under the tests directory of the dice repository and the steps to run are in the README file. Refer to the following links to set up DiceDB and Redis 7.2.5 locally
Hi @lucifercr07 , can you assign this task to me?
Hi @lucifercr07 Can I take this up ? Would love to work on it. Thanks
@Nijin-P-S @jainbhavya53 Assigned other issues to both of you. Let's have a single issue on your plate at a time. Once that's completed you can pick other opened issues.
Hi @lucifercr07 Can I take this up?
Hi @AshwinKul28 @lucifercr07 , can I please pick this up?
@dankot12 assigned, thanks for contributing.
For this issue the asserts are
test {BITPOS bit=0 unaligned+full word+reminder} {
r del str
r set str "\xff\xff\xff" ; # Prefix
# Followed by two (or four in 32 bit systems) full words
r append str "\xff\xff\xff\xff\xff\xff\xff\xff"
r append str "\xff\xff\xff\xff\xff\xff\xff\xff"
r append str "\xff\xff\xff\xff\xff\xff\xff\xff"
# First zero bit.
r append str "\x0f"
assert {[r bitpos str 0] == 216}
assert {[r bitpos str 0 1] == 216}
assert {[r bitpos str 0 2] == 216}
assert {[r bitpos str 0 3] == 216}
assert {[r bitpos str 0 4] == 216}
assert {[r bitpos str 0 5] == 216}
assert {[r bitpos str 0 6] == 216}
assert {[r bitpos str 0 7] == 216}
assert {[r bitpos str 0 8] == 216}
assert {[r bitpos str 0 1 -1 bit] == 216}
assert {[r bitpos str 0 9 -1 bit] == 216}
assert {[r bitpos str 0 17 -1 bit] == 216}
assert {[r bitpos str 0 25 -1 bit] == 216}
assert {[r bitpos str 0 33 -1 bit] == 216}
assert {[r bitpos str 0 41 -1 bit] == 216}
assert {[r bitpos str 0 49 -1 bit] == 216}
assert {[r bitpos str 0 57 -1 bit] == 216}
assert {[r bitpos str 0 65 -1 bit] == 216}
}
I think it need an APPEND command to get implemented first to test. @lucifercr07
Created issue for APPEND command.
For this issue the asserts are
test {BITPOS bit=0 unaligned+full word+reminder} { r del str r set str "\xff\xff\xff" ; # Prefix # Followed by two (or four in 32 bit systems) full words r append str "\xff\xff\xff\xff\xff\xff\xff\xff" r append str "\xff\xff\xff\xff\xff\xff\xff\xff" r append str "\xff\xff\xff\xff\xff\xff\xff\xff" # First zero bit. r append str "\x0f" assert {[r bitpos str 0] == 216} assert {[r bitpos str 0 1] == 216} assert {[r bitpos str 0 2] == 216} assert {[r bitpos str 0 3] == 216} assert {[r bitpos str 0 4] == 216} assert {[r bitpos str 0 5] == 216} assert {[r bitpos str 0 6] == 216} assert {[r bitpos str 0 7] == 216} assert {[r bitpos str 0 8] == 216} assert {[r bitpos str 0 1 -1 bit] == 216} assert {[r bitpos str 0 9 -1 bit] == 216} assert {[r bitpos str 0 17 -1 bit] == 216} assert {[r bitpos str 0 25 -1 bit] == 216} assert {[r bitpos str 0 33 -1 bit] == 216} assert {[r bitpos str 0 41 -1 bit] == 216} assert {[r bitpos str 0 49 -1 bit] == 216} assert {[r bitpos str 0 57 -1 bit] == 216} assert {[r bitpos str 0 65 -1 bit] == 216} }I think it need an APPEND command to get implemented first to test. @lucifercr07
Yeah that's the RCA
Hello @dankot12,
There has been no activity on this issue for the past 5 days. It would be awesome if you keep posting updates to this issue so that we know you are actively working on it.
We are really eager to close this issue at the earliest, hence if we continue to see the inactivity, we will have to reassign the issue to someone else. We are doing this to ensure that the project maintains its momentum and others are not blocked on this work.
Just drop a comment with the current status of the work or share any issues you are facing. We can always chip in to help you out.
Thanks again.
Hi @arpitbbhayani , thanks for reaching out. This issue was blocked due to #638 which was merged a couple of days ago. Please allow me one more day to complete this issue. Thanks
Hi @lucifercr07, I ran the tcl test for the unit test case that was failing and after the addition of APPEND cmd (#638), the unit test now passes.
Output:
[ok]: BITPOS bit=0 starting at unaligned address (0 ms)
[ok]: BITPOS bit=1 starting at unaligned address (0 ms)
**[ok]: BITPOS bit=0 unaligned+full word+reminder (2 ms)**
[ok]: BITPOS bit=1 unaligned+full word+reminder (2 ms)
[ok]: BITPOS bit=1 returns -1 if string is all 0 bits (5 ms)
[ok]: BITPOS bit=0 works with intervals (4 ms)
[ok]: BITPOS bit=1 works with intervals (2 ms)
In order to run the tcl tests, I made changes to the patch file (PR here: https://github.com/AshwinKul28/dice-tests/pull/11) as the patch file was outdated. @AshwinKul28, please review the changes when possible.
I think we can now close this issue. Please let me know what you think.
Hello @dankot12,
There has been no activity on this issue for the past 5 days. It would be awesome if you keep posting updates to this issue so that we know you are actively working on it.
We are really eager to close this issue at the earliest, hence if we continue to see the inactivity, we will have to reassign the issue to someone else. We are doing this to ensure that the project maintains its momentum and others are not blocked on this work.
Just drop a comment with the current status of the work or share any issues you are facing. We can always chip in to help you out.
Thanks again.
Hi @arpitbbhayani @lucifercr07 @AshwinKul28 , this issue is already solved with other PRs. This issue can be closed now as I already mentioned above with appropriate tests.
Closing, merged as part of #638