Google Colab: What does a spinning play button with broken line mean? - google-colaboratory

Recently, I have seen the play button (the one to execute the cell) will have a spinning state with broken line as border and staying like this for a long time. But eventually, the line will turn solid and the thing will execute relatively fast after that. I would like to understand what the "broken" boundary mean? It seems to me it just hangs there waiting for something before actually running any code.
See image attach on that play button.

The spinning dashed line means the execution of the cell is queued behind an earlier execution.
(If you haven't yet executed a cell, it's likely that the backend is blocked by attempting to generate a completion or objection inspection. These should finish within a few seconds.)

Related

Jitbit Macro Recorder - IF Image statement, why it is not waiting until the image appears?

I am using Jitbit MacroRecorder and it is a really helpful tool. The problem is this: By using the IF image found feature, I want the program to execute 2 sequential commands as soon as the image I selected on my screen appears. However, the program is putting too much load on the CPU by running thousands of times until the IF statement is true. What I want is for the program to WAIT until the image in the IF image found statement appears on the screen, that is, not to run thousands of times.
My simple code
The only way for the program to know when the image appears is to continuously "scan" the screen until it sees it. You may be able to use the image NOT found feature inside a loop with a delay. You would look for the image, and if not found, delay a second, and then look for it again. The tradeoff is you will have that delay in there which will keep your program from running the following commands immediately.

Can micro:bit read while in another while?

so i have got a problem programming micro:bit. I code it in internet page, then download the hex file and transfer it into the micro:bit. On the internet simulator everything works. Apparently when i transfer it to micro:bit code is not working. The code is really simple, it looks something like this.
animation repeats while variable is 0 (this part works perfectly)
A button makes the variable 1, B makes it 2 (this part works)
when variable is not 0, it breaks first animation loop. (this part also works)
then goes to second loop which repeats while variable is NOT 0 (it will never be a 0 because there is no button which makes variable 0) so it repeats for ever (this works)
in second loop, there are 2 more loops. First repeats when the variable is 1, second when the variable is 2. That makes me able to switch between these 2 loops any time i want. (Problem appears here: i am in loop 2 for example, i cant switch to first loop and otherwise.)
All these errors occurs in micro:bit robot, when code is transferred. In internet simulator code works perfectly. Is it possible to do that code in micro:bit, have i reached limit? Or is robot defective? Thanks for answers and inform me if something is not clear.
This is of course very hard to debug without seeing any blocks/code as I don't know how you are detecting the buttons being pressed when in the second loop.
However, this may be a scheduling issue due to the way you are changing the variable upon a button being pressed. Perhaps consider restructuring your blocks such that they are more event driven, utilising blocks such as on button A Pressed a bit better, infinite while loops are always best to avoid. Also, maybe consider putting a pause(100) in the while loops.
Hope this helps ;)
Edit:
OP confirmed that the pause(100) worked (see comments of this answer), demonstrating that it was a scheduling problem!
For those who are interested ;)...this is because the CPU is busy executing the while loop and doesn't have time to think about the buttons being pressed. The pause(100) allows the CPU to rest for a bit and not think about the while loop, giving it the time needed to deal with the button press. This is known as Cooperative Scheduling!
You can find out more about Cooperative Scheduling at:
https://www.microbit.co.uk/device/reactive
If your code looks like this, you will never be able to change your state variable. You'll get stuck in one of the inner loops, with no option to change the control variable.:
while (unset):
Animate
Check for button
While (set): // Intend to be stuck in this loop forever
While (one):
Do first
While (two):
Do Second
What you need is to be able to update your state:
...
While (one):
Do First
if (button_b.was_pressed()):
state = two
...
This still isn't perfect, you might want to think about what happens if the buttons are pressed in 'unusual' sequences. The simulator should be identical, but there might be something unusual about the way that button presses are handled and your code that have broken the simulator. If the simulator really is broken, you'll need to share a testcase with the micro:bit team.

Event-case management in while-loop

If I put the blocks showed in the picture in a while-loop everything fail, fo example the stop button does not working!
Someone could explain to me how use events correctly?
thanks
Also try to avoid coercion dots (small red dots near some blocks like add) the data type is changed dynamically (I32 to double) but it is not efficient and the convention in LabVIEW is to change the data type mostly manually.
You have not connected the timeout terminal.
How it always waits for an event and will not allow you to stop the loop. As it does not iterate, it waits.
To stop the loop you should specify Stop button Event, so your loop will iterate upon clicking on stop and you will be able to stop it. OR you can just specify timeout let say 100 ms and Loop will iterate on timeout case once every 100ms, even there is no event.
The other answers tell you how to patch your code so that your current architecture continues working. But that architecture is fundamentally flawed if your application gets larger -- you're going to waste lots of CPU redrawing needlessly and you're going to end up with lags in your UI. A proper LV separation of business logic from graphics logic would look like the image shown below. This image is a LV clip from LV 2015, meaning if you save the image to disk and then drop it directly onto LV 2015 or later, the code will just drop directly. Sorry, I don't have an earlier version of LV with me at the moment so I can't give you a clip for a previous version, but the code below should work all the way back to LV 6.1 (circa 2001a.d.) if you recode it.

Keep my app as responder while calling activateWithOptions:NSApplicationActivateIgnoringOtherApps

I am making a vim-style "window manager" that takes text input, much like Alfred or Spotlight in Mavericks (in a floating panel).
The problem I'm having is when I call activateWithOptions: on a running application it steals focus from my window. I was hoping the problem would be solved by simply bring my app to the foreground again, however it seems the activation is running on a separate thread, and I end up activating my app before the original app gets activated.
I have tried reactivating when I receive NSWorkspaceDidActivateApplicationNotification, but that doesn't work either.
Ideally I'd like to pause execution until the application is focused for multiple reasons, since that would be the window I manipulate further.
Does anyone have any suggestions?

How can Sikuli be used to wait for a button for a long time, with perhaps some maintenance task in between?

I have a webpage where I am waiting for a button to appear, and when it appears I would like to click it. The button is on a timer and may take as long as an hour to appear. Also, if the button takes longer than a certain length of time to appear, I'd like to move the mouse (otherwise the website will log me out automatically).
So, to wait for a button to appear I devised this Sikuli script:
button = "button.png"
while(1):
if exists(button):
print("found it")
click(button)
break
else:
print("wait longer")
wait(button,30*60)
# do a regular task
print "all done!"
The above does not seem to be functional. If the button is on screen, the script will find it... However, if it has to wait it will simply time out quickly with a FindFailed exception (on the click() even though the button does not exist on screen). I considered writing a handler, but seems like overkill.
What am I doing wrong and what is the best way to wait a long period for a visual event like this?
Some other thoughts for you...
while(1):
wait(Button, 30*60) # This will spinlock for 30 minutes for the button to appear
if exists(Button):
hover(Button) # Debug statement allowing user to see what Sikuli has matched to
click (Button)
else:
mouseMove(Location(50,100))
mouseMove(Location(50,200))
Links:
wait
mouse movement link
Location
Maybe Sikuli recognizes something that looks quite your button, and tries to click it.
If you right click in the IDE your button pattern, you can fine tune the tolerance level for recognition. Try to cut the image exactly around your button and increase the value to be more precise.
I suggest you to read this tutorial
http://doc.sikuli.org/tutorials/surveillance/surveillance.html
and to set up a event handler to manage your button when it appears
http://doc.sikuli.org/region.html#Region.onAppear
http://doc.sikuli.org/region.html#observingvisualeventsinaregion
It is not much code to write.
You can get a nice example with full source code in Sikuli's Blog here
http://sikuli.org/blog/2011/08/15/sikuli-plays-angry-birds-on-google-games/
I think you can just set up your handlers and go with
observe(FOREVER)
If you want sikuli to do stuff while your waiting for an image i would use the onAppear(pic, function) and observe(FOREVER, true) methods this is how it works
event = Sikuli.event
def function(event):
click(yourButton.png)
onAppear(picYourWaitingFor.png, function)
observe(FOREVER, true)
basically what this does is onAppear will continuously scan the screen for picYourWaitingFor.png. sikuli continues execution after words so it's scanning while its working. on the appearance of said pic it will jump to the function you put down as the second parameter of onAppear.
I have this same issue as described. Its not about waiting forever. And Observe won't work either, because that does watch forever. Think about wanting to check for event only for a certain period of time say 60 seconds. If it doesn't occur, move on. This could be happening in a specific series of events. If the image doesn't appear in the 60 seconds, move on to do another series.
wait(image,60)
...will crash after 60 seconds if it doesn't find the image, which isn't what is wanted at all in my case.
So I did something like this:
attempt = 1
count=0
while attempt:
if exists(image):
attempt=0
else:
count=count+1
if count>60:
attempt=0
else:
wait(1)
Probably a better way and doesn't give an exact time, but approach doesn't crash the script.
You could also try: except it.. Should be shorter.