When an app is run via Xcode the result of fputs("Hello World", stdout) appears in the Xcode console. Where does it go when Xcode is not attached? Does the answer change for Debug vs. Release builds? You would think that information such as this would be easy to obtain; surprisingly not.
Update: Hmmm, no answer. The reason that I used fputs as an example is that it explicitly references stdout. But swift's print() function also outputs to stdout. An alternate question might be: What reasons, beyond performance, are there for eliminating print() statements from release builds:
When a GUI app is running under MacOS anything written to the "standard output" is sent to the console, which in turn is written to the console log. The easiest way to view the log is to use the Console app found in Utilities.
As to your alternative question reducing what your app writes to the console avoids cluttering up the console log with useless stuff - just take a look and see the amount of non-useful stuff some apps dump out. As a possible metric, if you as app developer will never ask a user to report something your app has written to the console then your app should not write it there, i.e. don't litter!
Related
Is there a way, in Linux, to make the electron executable copy or redirect output sent to its console to the shell console, i.e. when I run it from a terminal?
For instance, if I run, in a shell, electron foo.js, where foo.js contains simply console.log("foo"), I get the foo message echoed back to my terminal.
However, when I run a React app, the output of console.log is directed to the browser's console (as explained here).
Is there a way to copy/redirect the outputs sent to the browser Console, so that they will also be sent to the shell console? This can be very useful for some kinds of debugging (e.g. using grep and regexes).
Alternatively, if there are other methods than console.log that allow writing to the shell which created the browser process, that would also be helpful.
Edit: #0stone0 mentioned the difference between server code and client code; from the point of view of debugging, since I am running a local process, the browser could very well decide to copy its console output to stdout/stderr. I fail to see why technically Chromium could not do it; requiring an API or websockets for this use case seems excessive, but if that is indeed necessary (e.g. for security reasons), that is a valid answer for me.
I just found a way, thanks to this question:
Q: Does anyone know of a way to save the console.log output in Chrome to a file? Or how to copy the text out of the console?
A: Enable logging from the command line using the flags:
--enable-logging --v=1
I then combined it with the answer to this question to set the Chromium flag in my Electron app:
app.commandLine.appendSwitch('enable-logging');
And that is enough for me to get messages in my console, such as:
[1234:0328/3923.5981:INFO:CONSOLE(2)] "logging", source: file:///home/user/app/main.js
I am using AppEngine, NodeJS (Standard), I have accepted the license agreements, and I am initializing the Debug Agent this way:
require('#google-cloud/debug-agent').start({ allowExpressions: true });
I can see all the logs for my application in the Logs Viewer, all the requests are here.
When opening the Stackdriver Debugger, it recognizes what is the current source code running, and displays it. I try adding a few snapshots and logpoints, as basic as this:
if (true) logpoint("Hello World!")
It is waiting for hits, but obviously missing them. There are also no logs related to my logpoints. However, I can see the standard logs outputted by my app. Everything seems to work except the Stackdriver Debugger, even though it doesn't seem to complain either.
I have looked at everything and made sure everything was set up properly but I am not sure how to "debug the debugger" further.
Is it actually even working, and people are using it with NodeJS in Standard mode?
What can I check? Any way I can see errors related to the Debugger itself?
Prior to the „request” statement, how did you set up your project in Stackdriver Debugger for node.js? You may check Setting Up Stackdriver Debugger for Node.js as reference.
To reproduce this issue, one needs confidential information, such as details of your project and sample code. It is much easier to protect your information in the Public Issue Tracker. You are encouraged to open a similar issue there.
After the first few months of learning programming at my university I have always been including scanf_s("%d"); at the end of the file or at certain strategic places in my code, in order for the console not to disappear once the program has loaded.
I cannot seem to find a concise answer or an explanation as to:
Why does my console disappear if I do not write scanf_s("%d");
I am using Visual Studio 2015 and have noticed that earlier versions do not require this to be written at the end of the code. Why is this?
Is this considered bad practice` ?
Windows automatically closes the console programs when they finish execution. scanf_s, as well as scanf, getchar (though be aware there might have been some remaining unprocessed input, often consuming this call) or system("pause") (note - Windows-specific, not recommended) prevent this from happening, forcing the window to stay open expecting input.
Visual Studio might have prevented console from closing in some other way or used some internal console in earlier versions, making this workaround unnecessary. CLion, for example, uses its own console which doesn't suffer from this issue. Also if you launch your program manually from cmd you won't need anything to prevent console from closing - it will just return to the earlier state after your program finished executing.
Why does my console disappear if I do not write scanf_s("%d");
As #Luke already answered, Windows closes the console window when the program running within terminates. The program will not terminate if it is waiting for user input, as scanf_s() and many other I/O functions can make it do.
I am using Visual Studio 2015 and have noticed that earlier versions do not require this to be written at the end of the code. Why is this?
It's news to me that earlier versions of VS behaved differently. This is not a VS-specific behavior, but rather a general Windows behavior. If earlier version behaved differently then that's because those versions of VS made some kind of special provision for running console programs.
Is there any other way of preventing my console from disappearing without the use of scanf_s("%d"); ?
Yes. Open a console window manually and run your program inside, from the command line.
Is it possible to redirect the output of GWT.log() from the development console to a file? I need to debug a compiled GWT app and any logging or exception traces would be really nice.
GWT.log is compiled out, there is no way to get access to it when compiled to production.
On the other hand, GWT now has support for java.util.Logging, which can, when compiled in, send errors to the server for use however you want. It also can print these logging statements to a in-browser console, such as a popup or Firebug/Chrome Inspector. See http://code.google.com/webtoolkit/doc/latest/DevGuideLogging.html#Remote_Logging (and other sections on that page) for more details.
Keep in mind that unless you compile in full stack trace info, the exceptions will be very hard to read. See http://code.google.com/p/google-web-toolkit/wiki/WebModeExceptions#Emulated_Stack_Data for more info.
There is no way for a browser (without dev mode running) to write to a local file, for logging or other reasons. This is done for security reasons. Html5 might have support for some of these things, but they won't be supported in older browsers.
While "deploying" the solution from this question on a number of machines, I noticed some single core machines have terrible results (for example, the solution fails spectacularly on an intel atom).
What is happening here is the following. I call SetWinEventHook(...) to get callbacks for console changes. Due to the out-of-contex notification there is no synchronisation between the processing of the events and further changes on the console, so while multi core machines do well (not perfect btw), single core machines make a mess of this.
So I proceeded to turn on the In-Context notification since this should be synchronous according to the msdn. In c#, this is like asking for the Infinite Improbability Drive, so I created a simple dll in C that can do the dirty work, and talk to the dll from c#. So far so good.
As it turns out the callbacks happen in conhost.exe as opposed to the process owning the console. Now this presents a problem since in the callback I can't find a way to access the console output buffer in the context of conhost.exe. Or more precisely, I can't seem to find a way to obtain a handle to it. Here is what is avaliable: Handle to the console window, process id's of both the console application and conhost.exe and a pipe to the console application.
And here is what I tried sofar:
using GetStdHandle(...), results in invalid handles (makes sense in the context of conhost.exe)
using CreateFile("CONOUT$"...), dito
using the pipe to have the console application read from the output buffer, results in deadlock. I suspect a locking mechanism for preventing reads while writing, that would make sense.
duplicating the output buffer handle and passing it via the pipe. No joy because console handles cannot be duplicated to an external process.
attaching the conhost.exe process to the console of the console process it is serving and then do the CreateFile thing. Ok this was my favorite one, but it also doesn't work since AttachConsole(...) blocks, similar to 3.
Someone have any ideas on what to try next? My c/c++/winapi skills are intermediate at best, so it is very possible I overlooked something. Ok an obvious one would be to throw the whole thing overboard and just poll the output buffer for changes, but I would consider that a last resort option. I'm assuming that MS was smart enough to make sure either In Context or Out of Context events would actually be usable and as such I must be missing something.