Java #qm8 - Bell does not ring on tester

Hi! I’ve added the code to ring the bell on failed autocompletion. It seems to be working fine on my macOS, but unfortunately tester does not recognize the ‘\007’ bell control symbol. Anyone else had similar problem?

1 Like

I am having the same problem but in tab key , you have handle it using \t or 9 or something else

Given that the previous stage about autocompletion passsed, I suspect the problem is in something else. I would also say I am using the bell symbol as code 7 also correctly, according to other code example on the site.

1 Like

(Un)fortunately, tests passed after I’ve done small refactoring. Don’t know what was causing issues, as I haven’t changed either the bell control symbol or its destination (standard out)

Even more unfortunate, problem reappeared on the next stage. But there are no changes since previous passing one :frowning:

To pass the stage I opted for repeatedly submitting the code without changes until tests pass. It actually worked on Nth try. What I noticed shortly after, it seems the tester was using your_program.sh script. It could be that the script didn’t work for the tester, because I’ve recently modified it for local purposes. I assumed it is safe to do, because it is stated so here Program Interface - CodeCrafters. If anyone could clarify, why is the tester using your_program.sh script instead of compile.sh and run.sh?

1 Like

I experience the same issue (Golang if it’s of any relevance at all). Except the test consistently fails for me after having passed on the Bell Testing stage previously.

We’re looking into this, thanks for reporting everyone!

@maximtereshchenko to answer your question - yep, we do run ./codecrafters/run.sh. You should see a log at the top that says “copying ./codecrafters/run.sh to ./your_program.sh”

2 Likes

Thank you for attention. Currently I am stuck with the same problem on #WF6. Locally my program behaves as expected (at least it seems to me)

Hello! Finally, it seems I’ve found the cause of my issues with bell not detected on the tester. I’ve stumbled across another person’s repository with the code passing tests. I’ve spent a couple of days going through the tester’s source code, virtual terminal library used by it and comparing my solution with a working one. At some point I’ve decided to ring the bell no matter what to see the output on the tester, because I was not sure if my code prints what’s expected. After observing the output actually displayed (and it was correct), I’ve opted to the last resort of debugging - print statements everywhere. And it helped in a way that I didn’t see some of them. Then I got the idea that my code is too slow. With the help of this little utility:

final class Timer {
    
    private static Instant instant;
    
    public  static void start(){
        instant=Instant.now();
    }
    
    public static void end(){
        System.out.println(Duration.between(instant,Instant.now()).toMillis());
    }
}

I’ve measured the execution time of ~55ms. Looking at tester’s code, it waits for a bell only 50 ms:

func checkIfBellReceived(shell *shell_executable.ShellExecutable) bool {
	select {
	case <-shell.VTBellChannel():
		return true
	case <-time.After(50 * time.Millisecond): // Add reasonable timeout
		return false
	}
}

@rohitpaulk @andy1li Sorry for bothering you, but would it be more forgiving to give 1 second of a timeout instead?

1 Like

To identify the bottleneck I’ve used async-profiler. In the resulted flamegraph, I saw that most of the time the CPU is busy with Java Stream API. After replacing streams with simple for loops, unfortunately, didn’t noticed any improvement.

The next idea was to warm up the JVM before the main loop specifically for autocompletion executions with invoking the most problematic method:

for (var i = 0; i < 100; i++) {
    autocomplete.completions("");
}

And indeed it worked:


which concludes the initial assumption of the bell check timeout correct.

Wow, thanks so much for sharing these details @maximtereshchenko!

We’ll confirm + try to get a fix for this out this week.

Thanks, man! After hours of debugging, I came here, did some repetitive submissions, and the test cases passed. What a relief! Uuh!

1 Like

Thank you all for reporting, and especially to @maximtereshchenko for taking so much time to debug!
There was a bug in how we were checking for the bell. We have fixed it in this PR: #109.

@Knight-Kaizen / @maximtereshchenko / @Kristina-Pianykh - could you folks give this a try and let us know if the fix works? We did test against one user submission that exhibited flakiness but would love to have more confirmation.

I’ve removed the part related to a previously described JVM warm up (invoking a part of code to make the JVM execute it faster). All codecrafters’ tests were still passing after that. The fix helped me! Thank you

2 Likes

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.