I have written an app for OSX (Sierra) in Go (lang) with the GUI powered by the Golang QT binding therecipe/qt. When I build the app and run it from the command prompt with command open $(pwd)/myapp.app I get a terminal output while its running, and everything works fine.
When I double click on the app in finder to run it, I obviously don't have access to the console to see debugging, but in parts of the app that work fine in the GUI when I run from console (clicking on things, etc), it crashes the app when run by clicking on it.
I realise people don't know what the app is, and without seeing where in the app it crashes, they can't help me. What I am after is some ideas about debugging it, for instance:
Outputting logs to a text file and tailing the text file to watch as it is written to
Connecting a debugger to the application by the process, perhaps I can discover where it crashes. This doesn't sound straight forward
Is there a way to attach to a console of an application run like this to see what it is outputting?
Any ideas appreciated.
Thanks
Related
I'm developing a windows application and i cannot debug because i don't see any log when i launch the application from a terminal (cmd.exe).
So i started trying other apps like the browser or notepad and i cannot see any log as well.
It seems like the terminal detaches from the application output automatically on start.
It's the first time it happens, i remember some weeks ago i used to start apps from the terminal and they showed on the terminal..
Is there a way to force terminal output for a Windows application?
I try to run an windows 10 application inside a windows servercore container.
The app can run without user input via COM-Interface (and without visible GUI), but it seems that it needs to load a hidden window in the background. When I start it on docker, the application log file indicates that it's stuck on starting this window.
Is there a way to make the app assume it successfully loaded the window?
All information I found so far was about users who want to see the GUI or about Linux/Windows combinations. None of that helped me.
got a weird question which I haven't been able to find an answer to online so I'm trying my luck here.
I have a normal erlang application using wxWidgets, once I try to shut down my application I get the event that the wxServer has indeed entered the event which is connected to the window closing, I get a message that it is in the process of exiting, and my window does indeed close, but as shown in the picture below, the beam.smp on my toolbar doesn't close at all, I have to manually force the closing of the beam.smp file which sends a SIGTERM to the erlang terminal which also shuts down my erlang VM (which I have to reboot it later).
long story short, what am I missing on my close window event so that everything shuts down nicely without it crashing my erlang VM? I was able to read that wxWidgets behaves differently on macOS but I haven't been able to find how to correctly close the application.
handle_event(#wx{event = #wxClose{}},State = #state{frame = Frame,panel = Panel}) ->
io:format("Exiting~n"),
wxFrame:close(Frame),
wxFrame:destroy(Frame),
wx:destroy(),
{stop,normal,State};
You can close the emulator from code with init:stop/0,1
Also, if your application is started as permanent, it should suffice with terminating that application. Check the behaviour in erlang:application
I worked on a Console Application with a friend today. Is it possible to share the default console during a Live Share session? What I mean is that we had to compile and run our program manually through the default Windows Terminal to see output(which wasn't the best idea, there was a ton of empty lines displayed every time we would input anything), and debugging was impossible because we just couldn't see the console (only the host could).
According to the docs, it's possible to share the terminal in both VS Code and Visual Studio, but I don't think there's a way to share the console that comes up when you debug a console app. The solution I see is simply sharing a terminal, running your app in it manually and if you want debugging, you can try attaching the VS debugger to the console app's process after you start it manually by following this guide.
I have a Mac OS X project (a game using SDL), and for debugging purposes when not running in xcode, I'd like to open up a terminal window that I can send text to and get line input from the user.
Is there a quick way to do this that doesn't involve creating a custom window (which is slightly problematic since the game uses SDL and I don't directly create windows)?
Opening up the standard OS X terminal would be fine, or even connecting to a separate terminal process and then sending output and reading input would also be OK.
The one criteria is that it needs to work when the application is run outside of xcode, or even on machines that don't have xcode installed.
I've spent the last few hours trying to Google this, but my searches are all returning unhelpful results. I'm clearing not seaching on the right keywords.
Thanks.
Actually every app has ability to interact with console, your just need to run it in a proper way (from a terminal or console)
Locate folder with your application. For XCode you can do it in a "Project Navigator" folder "Products", then for your app in context menu press "Show in Finder". For installed application it probably will be in the folder /Applications/. Let it be, for example, /Applications/MyBigProgramm.app.
Open console or terminal make cd to your app folder /Applications/MyBigProgramm.app/Contents/MacOS
There will be an executable file of your app.
Run it from console. After it stdin and stdout will be linked to your app.
Work with stdin and stdout as you want.
UPD 1
A bit of automation.
Create applescript with the following content:
tell application "Terminal" set currentTab to do script
("/Applications/MyBigProgramm.app/Contents/MacOS/MyBigProgramm")
end tell
Save your applescript either as app or script.
Run your base application ("MyBigProgramm") by starting your applescript.
Work with stdin and stdout as you want within your base application.
Watch output in the terminal, type sth in the terminal as input to your base application.