-
-
Notifications
You must be signed in to change notification settings - Fork 6
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
[Bug] using f'format strings in tight loop blocks and triggers watchdog timer #1668
Comments
Good find! When not connected, it is supposed to ignore printed output but that clearly isn't happening. |
Did you try this on any other hub? |
Up to now only the Spike and Inventor. Will "do" others. |
More minimal program and method below. Run this on SPIKE Prime and press the disconnect button in Pybricks Code. No need to restart anything. while True:
print(f'hello - hello - hello - hello - hello - hello - hello')
print(f'hello - hello - hello - hello - hello - hello - hello') The hub doesn't quite crash all the way, but the animation still visibly stutters. Just for less than it needs for the watchdog timer to trigger. |
Yet this is OK. So I guess we'll have to have a look at the format-string source code: while True:
print('hello - hello - hello - hello - hello - hello - hello')
print('hello - hello - hello - hello - hello - hello - hello') |
This one stutters: while True:
print(f'{"hello":>10} -{"hello":>10} {"hello":>10} {"hello":>10} {"hello":>10}')
print(f'{"hello":>10} -{"hello":>10} {"hello":>10} {"hello":>10} {"hello":>10}')
print(f'{"hello":>10} -{"hello":>10} {"hello":>10} {"hello":>10} {"hello":>10}')
print(f'{"hello":>10} -{"hello":>10} {"hello":>10} {"hello":>10} {"hello":>10}') |
Yes, any long |
How to "see" the stutter the other hubs? |
Thanks for having a look! Since it seems to be specifically related to these format strings, I think it's OK to stick to just the primehub for now to keep it simple. Thanks for bringing it to our attention. I haven't used these f-strings much in Pybricks for some reason. |
I like the f-strings more and more. Just getting to know the formatting characters. BTW this was the issue I found while testing the BT-on/off change in build 3380. |
You know me, I keep fiddling 😄 Idea was does the f-string pose the problem or the print doing the formatting. This snippet: formatted1 = f'{"hello" * 3:>20} - {"wow"[:2]:>10} {"hello":>10} {"hello":>10} {"hello":>10}'
print(type(formatted1))
formatted2 = f'{formatted1[:10]:>20}'
while True:
formatted2 = f'{formatted1[:10]:>20}'
print(type(formatted1), formatted1)
print(formatted2)
print(type(formatted1), formatted1) with an f-string in the loop makes the animation stutter. The same program but the formatting commented out within the loop does not stutter: formatted1 = f'{"hello" * 3:>20} - {"wow"[:2]:>10} {"hello":>10} {"hello":>10} {"hello":>10}'
print(type(formatted1))
formatted2 = f'{formatted1[:10]:>20}'
while True:
# formatted2 = f'{formatted1[:10]:>20}'
print(type(formatted1), formatted1)
print(formatted2)
print(type(formatted1), formatted1) The watchdog is not triggered. The 3 print commands are needed to see the stutter. [EDIT] The boolean SLICE determines which loop runs: f-strings with or without slices# SLICE = False # normal animation
SLICE = True # animation skips frames; my term: it stutters
if SLICE:
while True: # loop with only f-string formatting and slices
formatted1 = f'{"hello?"[:-1] * 3:>20} - {"wow"[:2]:>10} {"hello"[:4]:>10} {"hello":>10} {"hello":>10}'
formatted2 = f'{formatted1[6:]:<20}'
else:
while True: # loop with only f-string formatting and NO slices
formatted1 = f'{"hello" * 3:>20} - {"wow":>10} {"hello":>10} {"hello":>10} {"hello":>10}'
formatted2 = f'{formatted1:<20}' Movies:SLICE_False_connected.mp4SLICE_False_not_connected.mp4SLICE_True_connected.mp4SLICE_True_not_connected.mp4 |
Describe the bug
Program is a tight loop printing f-strings. Within seconds the hub does a shutdown (somehow)
The display animation is no longer smooth but has large hickups.
Might this be related to #436 ?
To reproduce
Steps to reproduce the behavior:
Aditional info
Connected the hub before the test to USB to keep the power on.
After the crash connect to the hub and go to the REPL.
Showed:
Expected behavior
You'd expect the program to just keep running and not to power-off.
Screenshots
There is a saying that a picture is worth a 1000 words. Screenshots really help to identify and solve problems.
test program for this issue
The text was updated successfully, but these errors were encountered: