How to save the life of my process? - matlab

I have the following problem: I want to run a really cumbersome calculation on a server via Putty in Matlab. Now I do not want to keep my notebook the whole time connected to this server, which is why I am searching for a solution to this problem. I know that screen in general works but I am not sure whether this could help me here too. The problem is the following: Each time I start this Matlab program I have no longer control over the terminal, since the Matlab program is still running. Therefore I am always forced to abort the process, which is what I do not want to happen. Is there anything that could help me.
What I need this:
1.)Start Matlab Application on server
2.)Disconnect from Server
3.)Connect to Server
4.)Have access to Matlab again
I would highly appreciate it, if somebody could give me a reference to some commands that might be helpful in this situation.

As #Peter said, screen is one good solution. A brief tutorial:
Connect to server
screen -S SectionName
matlab -nosplash -nodesktop or -nodisplay or -nojvm depending if you have allowed X11 forwarding on putty (you can check this by simply open a figure and check if you can see it with -nodesktop option)
Ctrl+a d to detach
Log out
Reconnect to server
If you are using X11 forwarding, you may need to update your display on the screen, so: echo $DISPLAY, copy its result
screen -rd SectionName
If you are using X11 forward, update display on screen export DISPLAY="value echoed outside screen" (I think the opposite also works, you set the log display into the screen display)
Finish Screen
Exit matlab and type exit
List open screens
screen -ls
Terminate unresponsive screen
Ctrl+a Ctrl+k and answer y
Navigate through screen screen:
Ctrl+esc and then use arrows or: ctrl+u to go half screen up and ctrl+d to half screen down
Exit broken connection screen
~ .
Note: You can have more than one screen section running, or you can open multiple screen windows by using Ctrl+a Ctrl+c
Note2: screen command may be very addicting, use it with cautious. Don't forget to read its man page.

Related

Issues with irrecord lirc function

I am trying to setup a remote to work with an IR reciever that I recently purchased using my raspberry pi, I've installed LIRC according to the following tutorial
https://www.digikey.com/en/maker/blogs/2021/how-to-send-and-receive-ir-signals-with-a-raspberry-pi
now the problem arises when I try and record to setup a specific remote, it saves all the values as 0x0,
here is the console output when setting up the remote that doesn't work
Running as regular user pi
Using driver default on device /dev/lirc0
irrecord: could not open logfile "/home/pi/.cache/irrecord.log"
irrecord: Permission denied
irrecord - application for recording IR-codes for usage with lirc
Copyright (C) 1998,1999 Christoph Bartelmus(lirc#bartelmus.de)
This program will record the signals from your remote control
and create a config file for lircd.
A proper config file for lircd is maybe the most vital part of this
package, so you should invest some time to create a working config
file. Although I put a good deal of effort in this program it is often
not possible to automatically recognize all features of a remote
control. Often short-comings of the receiver hardware make it nearly
impossible. If you have problems to create a config file READ THE
DOCUMENTATION at https://sf.net/p/lirc-remotes/wiki
If there already is a remote control of the same brand available at
http://sf.net/p/lirc-remotes you might want to try using such a
remote as a template. The config files already contains all
parameters of the protocol used by remotes of a certain brand and
knowing these parameters makes the job of this program much
easier. There are also template files for the most common protocols
available. Templates can be downloaded using irdb-get(1). You use a
template file by providing the path of the file as a command line
parameter.
Please take the time to finish the file as described in
https://sourceforge.net/p/lirc-remotes/wiki/Checklist/ an send it
to <lirc#bartelmus.de> so it can be made available to others.
Press RETURN to continue.
Checking for ambient light creating too much disturbances.
Please don't press any buttons, just wait a few seconds...
No significant noise (received 0 bytes)
Enter name of remote (only ascii, no spaces) :notworking
Using notworking.lircd.conf as output filename
Now start pressing buttons on your remote control.
It is very important that you press many different buttons randomly
and hold them down for approximately one second. Each button should
generate at least one dot but never more than ten dots of output.
Don't stop pressing buttons until two lines of dots (2x80) have
been generated.
Press RETURN now to start recording.
................................................................................
Got gap (108172 us)}
Please keep on pressing buttons like described above.
.....................................................................................................................................................Cannot find any gap, using an arbitrary 50 ms one. If you have a
regular remote for e. g., a TV or such this is probably a point
where you hit control-C. However, technical hardware like air
condition gear often works without any gap. If you think it's
reasonable that your remote lacks gap you can proceed.
Press RETURN to continue.
Please enter the name for the next button (press <ENTER> to finish recording)
KEY_UP
Now hold down button "KEY_UP".
Please enter the name for the next button (press <ENTER> to finish recording)
KEY_DOWN
Now hold down button "KEY_DOWN".
Please enter the name for the next button (press <ENTER> to finish recording)
KEY_LEFT
Now hold down button "KEY_LEFT".
Please enter the name for the next button (press <ENTER> to finish recording)
KEY_RIGHT
Now hold down button "KEY_RIGHT".
Please enter the name for the next button (press <ENTER> to finish recording)
KEY_OK
Now hold down button "KEY_OK".
Please enter the name for the next button (press <ENTER> to finish recording)
Checking for toggle bit mask.
Please press an arbitrary button repeatedly as fast as possible.
Make sure you keep pressing the SAME button and that you DON'T HOLD
the button down!.
If you can't see any dots appear, wait a bit between button presses.
Press RETURN to continue.
...Cannot find any toggle mask.
Successfully written config file notworking.lircd.conf
Here is what the config file that's generated looks like
Now, if I setup another remote I have laying around I get a correct config file
Here is a picture of the two remotes sitting side by side, the remote on the left is the one that is not working
I've tried using this tutorial too to no avail
https://www.raspberrypi.org/forums/viewtopic.php?t=235256
does anyone know what's going on here?

Gnome shell two monitors full screen apps

I'm working on the Ubuntu 16.04 whit Gnome Shell version 3.18.5 and I'm using two monitors. Issue which I have regarding aplications opend in the full screen mode.
For expample if I open on the monitor number 1 my browser and on the monitor number 2 terminal in full screen mode plus some additional application such as a code editor(not full screen). Now when I'm focus on the code editor which is on the top of the terminal it's ok but when I click on my broser window(monitor 1) then the code editor gose behind the terminal automatically.
I've prepared some video to better show this problem:
In this video you can see correct behaviour when I'm using one monitor.
Here is video showing incorrect behaviour. Don't care about the elements which are above the terminal on the left screen. Terminal was set to full screen.
Dose anybody know how to change this behaviour? I was looking for solution in google but without success. Thank you.
That's the expected behavior when things are in focus/out of focus. Try resizing your windows so they don't block one another; thus, nothing will be "behind" anything else when you shift focus by clicking here or there.

Bring Matlab uigetfile window to front of all other programs?

I'm calling a script from another program (Vicon Nexus 2.3). This other program will launch Matlab, then run the script.
The first thing the script does is it calls uigetfile(). However since the Nexus program has the Windows focus, the uigetfile() window appears behind everything. Is there any way to bring it to the front without using the mouse?
I've tried:
shg
uistack()
But I think the issue here is windows focus, not uistack. Anyone out there know if this is possible?
What you need to do is bring Matlab to front before opening uigetfile dialogue. You can do that e.g. by calling commandwindow:
commandwindow();
uigetfile();
Tested by starting Matlab from command line and overlaying some other windows on top once it is open, but before the code after pause is executed:
matlab -r "pause(3); commandwindow(); uigetfile();"

How can I script GNU Screen to start with a program running inside of it so that it does not exit the session on program completion?

How can I script GNU Screen to start with a program running inside of it so that it does not exit the session when the program completes?
I want to run an interactive program as a daemon, if I manually start screen and then launch this program inside of it everything works just as I want. If the program exits or crashes the screen session remains and I can go look at it to see what just happened. However, if I start the program with a simple screen launch then it does run inside of screen but when the program exits the screen session ends and any output from the program is lost.
So screen –dmS serverName serverApplication does not work for my scenario. I did think about making a script which launches the program I want to run & then sleeps forever, I could then launch the script at the same time as screen and should get the effect I am after but it seems rather an untidy way to do things and I am sure there must be something more elegant.
I have read quite a few screen tutorials and trawled through the man page but nothing leaps out at me as the right way to do this. I did try –X but that is for screen commands, not for running commands inside the screen session... Any suggestions will be very much appreciated; I am even happy to use something other than GNU Screen if there is a better tool for use in scripting but please give me an example where possible.
(Side note: The two things I will be running with this are a minecraft_server and a mythtv_backend. My plan was to launch these from a chron job at boot via some ruby/bash script)
First, you'll want to start a daemon screen session just running your default shell:
$ screen -dmS "serverName"
Then, send your command to that shell using screen's stuff in combination with -X:
$ screen -S "serverName" -p 0 -X stuff "serverApplication$(printf \\r)"
The -p is important for telling screen into which window within that session to stuff the command. In this case, it's the only available window, 0, but if you don't specify that, for some odd reason your command will go nowhere. The $(printf \\r) sends a 'Return' keystroke. A regular \n might work in its place, but I've read that's shell-dependent. The newline character does not work in bash; I can vouch for that.
Here's another cool trick. If you want to then make another screen window within that session, you can:
$ screen -S "serverName" -X screen
Now you can send commands to that one using the same syntax as above, but with -p 1. Lots of fun.

What determines the monitor my app runs on?

I am using Windows, and I have two monitors.
Some applications will always start on my primary monitor, no matter where they were when I closed them.
Others will always start on the secondary monitor, no matter where they were when I closed them.
Is there a registry setting buried somewhere, which I can manipulate to control which monitor applications launch into by default?
#rp: I have Ultramon, and I agree that it is indispensable, to the point that Microsoft should buy it and incorporate it into their OS. But as you said, it doesn't let you control the default monitor a program launches into.
Here's what I've found. If you want an app to open on your secondary monitor by default do the following:
1. Open the application.
2. Re-size the window so that it is not maximized or minimized.
3. Move the window to the monitor you want it to open on by default.
4. Close the application. Do not re-size prior to closing.
5. Open the application.
It should open on the monitor you just moved it to and closed it on.
6. Maximize the window.
The application will now open on this monitor by default. If you want to change it to another monitor, just follow steps 1-6 again.
Correctly written Windows apps that want to save their location from run to run will save the results of GetWindowPlacement() before shutting down, then use SetWindowPlacement() on startup to restore their position.
Frequently, apps will store the results of GetWindowPlacement() in the registry as a REG_BINARY for easy use.
The WINDOWPLACEMENTroute has many advantages over other methods:
Handles the case where the screen resolution changed since the last run: SetWindowPlacement() will automatically ensure that the window is not entirely offscreen
Saves the state (minimized/maximized) but also saves the restored (normal) size and position
Handles desktop metrics correctly, compensating for the taskbar position, etc. (i.e. uses "workspace coordinates" instead of "screen coordinates" -- techniques that rely on saving screen coordinates may suffer from the "walking windows" problem where a window will always appear a little lower each time if the user has a toolbar at the top of the screen).
Finally, programs that handle window restoration properly will take into account the nCmdShow parameter passed in from the shell. This parameter is set in the shortcut that launches the application (Normal, Minimized, Maximize):
if(nCmdShow != SW_SHOWNORMAL)
placement.showCmd = nCmdShow; //allow shortcut to override
For non-Win32 applications, it's important to be sure that the method you're using to save/restore window position eventually uses the same underlying call, otherwise (like Java Swing's setBounds()/getBounds() problem) you'll end up writing a lot of extra code to re-implement functionality that's already there in the WINDOWPLACEMENT functions.
It's not exactly the answer to this question but I dealt with this problem with the Shift + Win + [left,right] arrow keys shortcut. You can move the currently active window to another monitor with it.
Get UltraMon. Quickly.
http://realtimesoft.com/ultramon/
It doesn't let you specify what monitor an app starts on, but it lets you move an app to the another monitor, and keep its aspect ratio intact, with one mouse click. It is a very handy utility.
Most programs will start where you last left them. So if you have two monitors at work, but only one at home, it's possible to start you laptop at home and not see the apps running on the other monitor (which now isn't there). UltrMon also lets you move those orphan apps back to the main screen quickly and easily.
I'm fairly sure the primary monitor is the default. If the app was coded decently, when it's closed, it'll remember where it was last at and will reopen there, but -- as you've noticed -- it isn't a default behavior.
EDIT: The way I usually do it is to have the location stored in the app's settings. On load, if there is no value for them, it defaults to the center of the screen. On closing of the form, it records its position. That way, whenever it opens, it's where it was last. I don't know of a simple way to tell it to launch onto the second monitor the first time automatically, however.
-- Kevin Fairchild
Important note: If you remember the position of your application and shutdown and then start up again at that position, keep in mind that the user's monitor configuration may have changed while your application was closed.
Laptop users, for example, frequently change their display configuration. When docked there may be a 2nd monitor that disappears when undocked. If the user closes an application that was running on the 2nd monitor and the re-opens the application when the monitor is disconnected, restoring the window to the previous coordinates will leave it completely off-screen.
To figure out how big the display really is, check out GetSystemMetrics.
So I had this issue with Adobe Reader 9.0. Somehow the program forgot to open on my right monitor and was consistently opening on my left monitor. Most programs allow you to drag it over, maximize the screen, and then close it out and it will remember. Well, with Adobe, I had to drag it over and then close it before maximizing it, in order for Windows to remember which screen to open it in next time. Once you set it to the correct monitor, then you can maximize it. I think this is stupid, since almost all windows programs remember it automatically without try to rig a way for XP to remember.
So I agree there are some apps that you can configured to open on one screen by maximizing or right clicking and moving/sizing screen, then close and reopen. However, there are others that will only open on the main screen.
What I've done to resolve: set the monitor you prefer stubborn apps to open on, as monitor 1 and the your other monitor as 2, then change your monitor 2 to be the primary - so your desktop settings and start bar remain. Hope this helps.
Do not hold me to this but I am pretty sure it depends on the application it self. I know many always open on the main monitor, some will reopen to the same monitor they were previously run in, and some you can set. I know for example I have shortcuts to open command windows to particular directories, and each has an option in their properties to the location to open the window in. While Outlook just remembers and opens in the last screen it was open in. Then other apps open in what ever window the current focus is in.
So I am not sure there is a way to tell every program where to open. Hope that helps some.
I've noticed that if I put a shortcut on my desktop on one screen the launched application may appear on that screen (if that app doesn't reposition itself).
This also applies to running things from Windows Explorer - if Explorer is on one screen the launched application will pick that monitor to use.
Again - I think this is when the launching application specifies the default (windows managed) position. Most applications seem to override this default behavior in some way.
A simple window created like so will do this:
hWnd = CreateWindow(windowClass, windowTitle, WS_VISIBLE | WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, SW_SHOW, CW_USEDEFAULT, 0, NULL, NULL, hInst, NULL);
Right click the shortcut and select properties.
Make sure you are on the "Shortcut" Tab.
Select the RUN drop down box and change it to Maximized.
This may assist in launching the program in full screen on the primary monitor.