I created a digital full screen Clock in Processing. I also created a executable file to run it directly via double click. My OS is MacOS High Sierra. When I run it, my laptop goes to sleep after some time. I want to disable sleeping while my clock is running. Is there a programming way to do this.
One option would be to use Amphetamine to do this. It's not programmatic though, which might not be possible from Processing (unless you can do Objective C style calls).
Related
I need to receive notifications about number of monitors plugged in to the Mac laptop from my launch daemon (written in C++). In particular I'm using CGDisplayRegisterReconfigurationCallback function and some others (see below).
If I implement it in my launch daemon, it works in a kinda strange way. Most times it works OK, but sometimes crashes the daemon with SIGABRT and weird callstacks.
I did some research and it turns out that I can't use certain frameworks from a launch daemon.
The question is then, how can I call that CGDisplayRegisterReconfigurationCallback function, along with CGMainDisplayID, CGGetActiveDisplayList, CGDisplayIsActive, etc that are needed for the functionality of my app? Any suggestions?
I need to include hardware WDTs on both ESP32 and rp Pico based systems running micropython. I am using the Thonny IDE and with an 8s timeout on the Pico I can interrupt (Cntrl-C) the system and quickly delete the main from the board. This then allows me to continue development of the code. This approach works with an 8s timeout but if I was working with much shorter delays I am not so sure that it would. My concern is getting stuck with a main.py I can't change? Is there a better way anyone can recommend to handle this.
Harry
PS: Relative beginner with Python. The more I know, the more I know I don't!
What works for me: add time.sleep() for 5 seconds in the beginning of your code where you can kill script from Thonny using CTRL+C before WDT has been initiated. This way you dont need to delete file manually from board, you just stop it's execution before WDT
How would I go about detecting if my go CLI program is in focus or minimized?
Current program based off https://github.com/jroimartin/gocui
I require the functionality as it is a chat program and I would like to send OS notifications but only when the program is not in focus or is minimized.
Your help/direction is much appreciated as of right now unsure where to start.
This is not possible from the library itself. A command line program does now have a focus, but the terminal program it is running in.
To implement that (if possible at all) would be dependent on os, window manager etc.
To refine the answer provided by #mbuechmann, I suggest the OP not to try to resort to APIs etc.
The reasoning is simple.
"Contemporary" users are used to running programs in terminal emulators which are typically presented as separate windows, and so the users naturally think of these programs as not really different from GUI apps.
But the reality is different: a terminal emulator—whether graphical or not (for instance, so-called "virtual consoles" provided by the Linux kernel running on an x86/amd64 hardware are terminal emulators as well)—really emulates a typical work session on a real hardware terminal, and there, a program would work in foreground solely, and the only means of "switching" to another program was using the shell's job control (those jobs, bg and fg commands).
In other words, the whole concept of a program working in a terminal has an inbuilt assumption that the terminal is always "foreground"—since at the time the concept was developed, a terminal was a physical device.
Now please also consider that "terminal emulation" may be more pervasive on a contemporary system than you might think: screen and tmux on a Unix-like OS are multiplexing terminal emulators—which may themselves be run in a terminal emulator, and a console window on Windows™ may be considered to be a terminal emulator of sorts as well.
So, "resorting to APIs" have several technical problems:
Terminal emulation tries to actually decouple the program which uses this facility from being aware of how the facility is actually provided.
To put it simple, there's, say, no easy way on X Window System, to know what window is used by the terminal emulator running your program.
You'd need to cover diverse set of APIs in order for your program to still be useful: X Window System on Unix-like systems, Mac OS, Windows™. And contemporary GUI stacks running on Linux tend to be switching to Wayland instead of X.
In certain cases, like running a program in a "nested" terminal emulation sessions (for example, a pane in a "window" of a tmux running in xterm), figuring out such facts about the environment might be next to impossible.
And still the crucial problem is that if your program really needs to know whether it's focused or not, it actually wants to be aware about the concepts currently hardly accessible to it. I mean, it wants to be GUI. And if so, just make it GUI.
In fact, it may be simpler than you think. The core of your program might still be a CLI app with a thin GUI wrapper around it which uses any sort of IPC to talk with the app (which might be two-way, if needed).
The simplest is to write some (usually line-wise) data to the program's standard input.
I'm looking for a function which will get called when a macOS machine wakes up from sleep.
What are some ways to achieve this?
I'm looking to run code in my Swift application when the computer awakens. I'm trying to open a new websocket when this happens. If I open the lid -> new websocket, if I press the any key -> new websocket.
What I've found useful so far is this which stems from what #Rob Napier has suggested (didWakeNotification)
You'll need to give more information than this. Is this an user-level (GUI?) application that will be running when the machine goes to sleep? Is this a daemon? Do you expect your program to be launched if it isn't already running? Is the program sandboxed? Do you expect to have root access? What if no one is logged in? "Wakes up from sleep" has many subtle corner cases (for example, it includes a "dark wake" mode which are not quite sleep and not quite wake).
That said, the high-level answer is "observe NSWorkspace.didWakeNotification" and the low-level answer is "call IORegisterForSystemPower." But whether either of those help you depends a lot on what problem you're solving.
I built an application using openframeworks that is live 24/7 on a kiosk. Every now and then (every few weeks) it will randomly go unresponsive and I still can't get to the bottom of it because it's so random and infrequent it is hard to debug.
I wrote a ruby script that looks for the application running and if it doesn't exist it will start it up. This works in all cases where the application name doesn't show up in activity monitor. Meaning if the app crashes and completely force quits itself or something. It works just fine.
However, if the app just freezes and goes unresponsive (red highlight in activity monitor) the app doesn't quit out completely unless I force quit manually. Is there some kind of script I can write to look for all "unresponsive apps/processes" every few seconds and force quits them automatically? That way my app launcher script will be able to detect that the app isn't running and boot it up again.
I suggest you look at Monit because it's solid, well tested, well documented, and easy to learn.
If you still want to write your own monitoring script, Monit is a good example to follow.
The most reliable way to detect an unresponsive app is to have a "vital sign" which is a generic term for a signal that an app emit to prove it's healthy. Some people call this a "pulse" or "heartbeat" or "brainwave". Your external script watches the vital sign. If your external script sees the vital sign flatline, then the script takes action to cure the app or restart it.
An alternate way is to have a "ping" which is a generic term for your external script sending a signal to the app or the system, then listening for a reply. You can use tools such as the Unix ps command for processes, or AppleScript Activity Monitor. As far as I know, these do a pretty good job of catching common cases, but have trouble catching apps that are soaking up resources, such as being caught in endless loops.