-
-
Notifications
You must be signed in to change notification settings - Fork 10
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
Robot Name tests pass locally but timeout after submission #46
Comments
The seen names will never include duplicates, so this should be deterministic. The number of times the same name is created should be immaterial (and discarded). Is this causing an intermittent failure for your solution? |
The test does seem strange though, because there should be only unique robot names (I will read the description, I have not looked at it for years.) |
This test looks correct to me. The number of names will be different if the code fails to generate all names within 60 seconds. |
That is what I am seeing too @SleeplessByte . I am going to close it. @sanevillain can comment still though. Let us know what the doubts are, and a test to maybe prove the issue, if you can. |
Okay. This is super weird. Yesterday the problem for me with this last test case was that on every run a different number of robots was created and that number was unpredictable. What I mean by that is that the number of unique names that the However, today this last test case passes without a problem. I haven't changed my solution, but for some reason, it's passing every time I run it. I uploaded my solution again, but it seems to be failing on the website now. Will appreciate it if you can tell me if it's something in my code that leads to this weird behaviour class Robot
@@NAMES = []
attr_reader :name
def initialize
self.class.generate_names if @@NAMES.empty?
reset
end
def reset
@name = @@NAMES.pop
end
class << self
def forget
@@NAMES = []
end
def generate_names
('A'..'Z').each do |a|
('A'..'Z').each do |b|
(0...10).each do |c|
(0...10).each do |d|
(0...10).each do |e|
@@NAMES << "#{a}#{b}#{c}#{d}#{e}"
end
end
end
end
end
@@NAMES.shuffle!
end
end
end |
This solution looks like it would work (albeit the |
I really don't understand how this issue is already closed when every correct solution that passes the test locally times out once uploaded to the platform. (Including the example solution to the problem) |
I closed it because the title of the problem states that it is non-deterministic last test case. I believed that you indicated this is not the case. Would you want to change the title of the issue to match the problem that you are seeing, and perhaps reopen and comment? If this is the message that we get every time, then we have a different issue, I think. Can you make the adjustments that you think are needed for this issue, if it is no longer a "non-deterministic last test" and a timing problem perhaps on the server. Then we can move this issue to the test runner repository and address it there. |
I agree that this issue has to be moved to the test runner repository. Edited: Output of test runner on local machine
|
That is excellent. Thank you @sanevillain . |
I have confirmed that it runs against the test runner as well, just fine. @ErikSchierboom can you confirm what the report is for this exercise? |
This is due to the Ruby test runner having a lower timeout than other tracks: https://github.com/exercism/tooling-invoker/blob/main/tools.json#L17 @iHiD do we want to keep that timeout? |
It times out on the test runner. |
Bumping this. |
@ErikSchierboom Can individual exercises have increased timeouts yet? |
Nope |
I believe that the
while
loop here leads to non-deterministic behavior. The amount of robots generated is almost always different than the expected number because the loop uses the length of theseen_names
keys and fails to take into consideration the total number of times a name was createdThe text was updated successfully, but these errors were encountered: