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.
Related
Following https://docs.hiro.so/smart-contracts/devnet I can't get the command clarinet integrate to work. I have installed Docker on my mac and am running version 0.28.0 of clarinet. Running command within 'my-react-app/clarinet' where all clarity related files live (contracts, settings, tests, and Clarinet.toml).
My guess is it could be an issue with Docker?
The issue was that I downloaded my Devnet.toml file from a repo that was configured incorrectly. The configuration I needed was:
[network]
name = "devnet"
I increased the CPU and Memory in Docker as well.
There is an issue when the command attempts to spin up the stacks explorer, but I was informed that there are several existing issues with the stacks explorer from clarinet integrate at the moment.
Depending on how the last devnet was terminated, you could have some containers running. This issue should be fixed in the next incoming release, meanwhile, you'd need to terminate this stale containers manually.
Apart from Ludo's suggestions, I'd also look into your Docker resources. The default CPU/memory allocation should allow you to get started with Clarinet, but just in case, you could alter it to see if that makes a difference. Here's my settings for your reference:
Alternatively, to tease things out, you could reuse one of the samples (eg: hirosystems/stacks-billboard) instead of running your project. See if the sample comes up as expected; if it does, there could be something missing in your project.
I'm using Logic-Apps for my project now. I think it's good and easy! However, It was difficult to debug during the coding of the logic. Because I couldn't to confirm the variables or status at a middle point of the code. Usually a developer can detect the variables during the execution of program on Visual Studio. How can I debug the code on Logic-Apps? Do you have an idea?
At the moment, Logic Apps can only run on Azure, thus while you are developing a workflow, in order to debug your code, you need to run it on Azure. Once you run it, you can see the inputs and outputs of each action for that instance, including setting variable actions.
You can see in the documentation how to monitor each instance and the inputs and outputs of each action.
HTH
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!
Is there an equivalent of the browser console in AIDE? It took me trial and error to find out that it doesn't seem to support local storage (or at least the library that I'm usings implementation of it)
Should I wrap everything in one big try Catch block? I've googled and searched, I suspect I should be doing better error handling.
Here's what I ended up doing. You can share the published web app from aide when you're running it. Open it in Firefox for Android after downloading the console add-on. It's not as fully featured as a desktop version but it's close
It feels like poor form to answer ones own question, I earnt the tumbleweed badge for this so perhaps I can be forgiven!
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.