Working on a console app to check power status for Macs and I’m not able to remotely debug. I can set up the remote debugger and Xojo seems to be able to transfer the build and start it, but nothing happens.
My console app should create a log file in /tmp and start writing to it. I even tried adding a ‘print “hi”’ as the very first line, but I get nothing when running remotely.
If I build and copy the project, or if I try to run locally, then it works as expected. I see the “Hi” and my log file is created and written to.
I’m running the remote debugger as root, so I don’t think there are permissions issues. The log file is being written in /tmp/, so I don’t think permissions are involved there either.
Really new to Xojo and this is adding to my confusion. Thanks for any suggestions.
Are you using the Remote Debugger Console version? And are you using the latest one?
I just ran a quick test and was able to break into the debugger and print “hi”.
Answering my own question!
I assumed that I could SSH into my test mac and run the RemoteDebuggerConsole, without needing to log in via the GUI. It seems that the RemoteDebuggerConsole copies the build and libs, but can’t open a new Terminal window to run the build.
If I log into the GUI on the remote Mac and start the RemoteDebuggerConsole in the Terminal.app with sudo, then my remote run testing works as expected. The RemoteDebuggerConsole opens a new terminal window and runs the build after copying the build.
I’m programming an app that is designed to only run while no one is logged in, so the RemoteDebuggerConsole won’t work for my purposes. I’ll have to manually copy the test builds, or script it myself, to test while no users are logged in.
Kem, Thanks for the reply. I’m using 2014r1, and the RemoteDebuggerConsole from that download. After I logged in, I’m able to print Hi and the break points are working.
( Rusty and I work together here at Penn State. )
Sounds like we need to file a bug/feature request to enable remote debugging of console applications when the remote OS X client is at the login window.
I’m not sure there is a solution to this without a redesign. The way it seems to work now, the binary is transferred to the remote host, then launched in Terminal, not on the shell directly. Since Terminal is required, the GUI is required too.
A redesign would allow you to specify that you are debugging an app that has no input or output, and any output would be redirect to /dev/null, I guess. That way it could be launched in a faceless shell.
I’m speculating, of course.
I need to test remote debugging of a console app on a Linux remote client - I wonder if it also requires that the user is logged in?
I would think that especially for Linux servers that remote debugging of console apps would be needed, which are rarely logged in a the server’s GUI / console window?
My guess is, yes it does.
Another thought is to be able to specify an app as having no input, and any output (like a
print statement) would be redirected back to the IDE’s log during debugging, and the system log during execution.
[quote=71471:@Justin Elliott]I need to test remote debugging of a console app on a Linux remote client - I wonder if it also requires that the user is logged in?
I would think that especially for Linux servers that remote debugging of console apps would be needed, which are rarely logged in a the server’s GUI / console window?[/quote]
It’s unlikely that this will work right now. The remote debuggers attempt to open a second connection back to the IDE and without opening firewalls on your network to allow this second connection, it’s not going to work.
Even for our own Linux servers that we have full control over, OS and networking?