Loading collection data...
Collections are a way for you to organize kata so that you can create your own training routines. Every collection you create is public and automatically sharable with other warriors. After you have added a few kata to a collection you and others can train on the kata contained within the collection.
Get started now by creating a new collection.
How many random test are there?
Thanks, I know this. The question was: Why the execution completion is printed out to be 8987ms and there is timeout despite the limit of 16000ms
Anyway as I wrote, I've managed to pass the tests on next execution
Thank you for your reply :)
Ok. I see, the variables are case insensitive as the keywords...
It's noted in the description I see, I've missed it, my bad.
There is a problem with language grammar (on Kotlin at least):
For instance in this test
[ FixedTest 0 | Basic 1 | Works for set, inc, dec ]
the a argument at line 3 suppose to be a VarName (@see lexical syntax) so this test must fail since there is no such variable definedIn case there is an exception for
[msg]
keyword, then the output must bea\u00abkF
and nota\u0000a2kF
(@see line 5)I've managed to pass the timeout by executing several times afterwards. But the question remains - what eactly 16000 msec timeout includes?
How come?
I can give you my logs for that test cse, hope it helps
Just did it on kotlin everything is correct.
Many thanks to @docgunthrop for the kata and especially that he/she puts an examples of explicit test cases in description otherwise debugging would be frustrating
Hello everyone. Many thanks to @KenKamau for this kata.
The major difficulty of this kata is debugging, the numbers become enormous very swiftly that you are unable to follow them.
So, my advice is: writhe a brute force solution execute them in paralel for comperasion with optimized one, use random numbers for debugging purpuses
No, the solution is straight forward without any special tricks. Only optimization needed.
This comment is hidden because it contains spoiler information about the solution
No, you are right, it happens only when you try to add velue printout to exception
I've tried but compiler escapes values printouts, at lest in kotlin
Something wrong with the test itself: expected:<1234567908> but was:<1234567980>
If the expected is: 1234567980 the original should be
1234567098 -> 1234567890
1234567980 -> 1234569780
1234567908 -> 1234567980
1234567890 -> 1234567980
None of these results with 1234567908