Trying to add new helpers to docpad.coffee I'd like to debug these.
Having setup node inspector as outlined in http://docpad.org/docs/debug I expected the console to show logs when used with e.g.
getOutDir: (inPath) ->
console.log('inPath')
How to set breakpoints to helper methods in docpad.coffee?
How to log from docpad.coffee?
The instructions on docpad.org for node-inspector are incorrect (they are being worked on). You can't just run docpad-debug because that runs the globally installed version of docpad which confuses the debugger. Instead run the local copy of docpad-debug from your node-modules folder:
./node_modules/.bin/docpad-debug run
How to log from docpad.coffee?
docpad.log("info", "... your log info here ...")
Other log levels are "warn" and "error".
Related
Ubuntu. vscode 1.62.1. go1.17.3. vscode go extension v0.29.0. delve v1.7.1.
I'm new to vscode and Go. I have many years of experience debugging Java apps in Eclipse.
I've constructed a small multi-module Go app. I can set a breakpoint in main and other functions in other modules. Inside main.go, I select "Start Debugging".
It starts the application, and I can tell it's working from the console, and that the REST endpoint responds with my dummy response.
However, it will NOT stop at breakpoints. As soon as I start the session, the red breakpoint markers suddenly become hollow, and hovering on one of them shows a message "Could not find file ...", which prints the full path to the source file in question.
When I start it, it shows the following in the console:
Starting: /home/.../go/bin/dlv-dap dap --check-go-version=false --listen=127.0.0.1:43347 --log-dest=3 from /home/.../...
DAP server listening at: 127.0.0.1:43347
I haven't modified the launch.json (I hope someday a friendlier interface to editing launch configurations is provided).
What else could I be doing wrong?
Update:
This is a screenshot showing main.go just before I press F5 (Start Debugging):
Notice that I have a breakpoint on the print statement, on the first line of main.
This is what I see after I press F5:
Notice that it printed "At start of main" in the console. It didn't stop at the breakpoint. Also notice message in tooltip when hovering over the breakpoint.
Update:
This is a view of my directory structure:
First, just make sure you have initiated your project with go mod init voltagems: that would explain the import "voltagems/xxx", but also helps delve to find your main.go file at debug time.
You should have go.mod and go.sum files beside main.go.
Second, check your go env output, making sure GOPATH and GOROOT are set to default paths.
The OP David M. Karr adds in the comments:
I did run "go mod init" when I first created the project, but I realized that I didn't like the root module name, so I changed it to "voltagems"
I believe you can edit directly go.mod first line, and make sure it says:
module voltagems
Then go mod verify + go mod tidy
Finally, go build .. Restart your VSCode (or the command Reload Window), and see if the issue persists.
The OP David M. Karr points out to a root cause:
There are symbolic links in my project path.
There is a "substitutePath" configuration in VSCode-Go that is used to map to absolute paths.
You can see this parameter mentioned in Debugging with Legacy Debug Adapter
substitutePath
Path mappings to apply to get from a path in the editor to a path in the compiled program (default: []).
That comes from issue 622 "debug: breakpoints don't work when working with symlink".
And commit 93f32bb
src/debugAdapter: add substitutePath config for debugging
This change adds a new configuration option to both launch and
attach requests.
substituePath takes an array that maps from string to string that is used to translate paths passed to the debugger and then
back to the client.
This allows users to translate their symlinked directories to the
files that were actually used to build the binary.
In addition this can also be used for remote debugging, and when the location of the files has moved since the program was built.
Example: you need a from and to key:
"substitutePath": [
{
"from": "/symlink/path/dir/on/local/machine",
"to": "/absolute/path/dir/on/local/machine",
},
I'm having problems with the output of my log messages. I'm using logrus.
I'm developing with VS Code and when I debug my code the log output is:
time="2021-05-04T11:52:11+01:00" level=info msg=message
But when I'm running the app executable or use go run main.go the output is:
INFO[0007] message
I want the first output.
What is happening?
EDIT:
We need to set the formatter as stated in the logrus github.
We need to set the formatter as stated in the logrus github
I am a newbie in go and go-swagger. I am following steps in Simple Server tutorial in goswagger.io.
I am using Ubuntu 18.04, swagger v0.25.0 and go 1.15.6.
Following the same steps, there are a few differences of the files generated. For instance, goswagger.io's has find_todos_okbody.go and get_okbody.go in models but mine does not. Why is that so?
Link to screenshot of my generated files vs
Link to screenshot of generated files by swagger.io
Starting the server as written in the tutorial go install ./cmd/todo-list-server/ gives me the following error. Can anyone please help with this?
# my_folder/swagger-todo-list/restapi
restapi/configure_todo_list.go:41:8: api.TodosGetHandler undefined (type *operations.TodoListAPI has no field or method TodosGetHandler)
restapi/configure_todo_list.go:42:6: api.TodosGetHandler undefined (type *operations.TodoListAPI has no field or method TodosGetHandler)
The first step in goswagger.io todo-list is swagger init spec .... Which directory should I run this command in? I ran it in a newly created folder in my home directory. However, from the page, it shows the path to be ~/go/src/github.com/go-swagger/go-swagger/examples/tutorials/todo-list. I am not sure whether I should use go get ..., git clone ... or create those folders. Can someone advise me?
Thanks.
This is likely the documentation lagging behind the version of the code that you are running. As long as it compiles, the specific files the tool generates isn't so crucial.
This is a compilation error. When you do go install foo it will try to build the foo package as an executable and then move that to your GOPATH/bin directory. It seems that the generated code in restapi/configure_todo_list.go isn't correct for the operations code generated.
All you need to run this tutorial yourself is an empty directory and the swagger tool (not its source code). You run the commands from the root of this empty project. In order not to run into GOPATH problems I would initialise a module with go mod init todo-list-example before doing anything else.
Note that while the todo-list example code exists inside the go-swagger source, it's there just for documenting example usage and output.
What I would advice for #2 is to make sure you're using a properly released version of go-swagger, rather than installing from the latest commit (which happens when you just do a go get), as I have found that to be occasionally unstable.
Next, re-generate the entire server, but make sure you also regenerate restapi/configure_todo_list.go by passing --regenerate-configureapi to your swagger generate call. This file isn't always refreshed because you're meant to modify it to configure your app, and if you changed versions of the tool it may be different and incompatible.
If after that you still get the compilation error, it may be worth submitting a bug report at https://github.com/go-swagger/go-swagger/issues.
Thanks #EzequielMuns. The errors in #2 went away after I ran go get - u -f ./... as stated in
...
For this generation to compile you need to have some packages in your GOPATH:
* github.com/go-openapi/runtime
* github.com/jessevdk/go-flags
You can get these now with: go get -u -f ./...
I think it's an error of swagger code generation. You can do as folloing to fix this:
delete file configure_todo_list.go;
regenerate code.
# swagger generate server -A todo-list -f ./swagger.yml
Then, you can run command go install ./cmd/todo-list-server/, it will succeed.
The Julia docs are pretty clear on how to enable debugging messages from #debug macros, i.e. run export JULIA_DEBUG=mymodule or export JULIA_DEBUG=all on the command line before starting Julia. However, is there an easy way to enable debugging from within the Juno, or, more generally, while Julia is running?
I tried fiddling with Base.CoreLogging.disable_logging , Base.CoreLogging.BelowMinLevel and Base.CoreLogging._min_enabled_level without success.
I know I can set env variables for Julia in the Juno settings. But that's kind of annoying to work with as it requires restarting Julia. I really want to have the following workflow while working interactively:
Enter a line in the REPL
Stumble upon a bug from your own code that you didn't see coming.
Enable debugging.
Run that line again.
See the debug logs.
Fix your code.
Disable debug logging again.
Which I think is nicer than the common practice of commenting and un-commenting printf everywhere.
Enable #debug everywhere (this will only affect code loaded after running the following expression):
julia>ENV["JULIA_DEBUG"] = "all"
Enable #debug in file foo.jl (according to docs, haven't tested this):
julia>ENV["JULIA_DEBUG"] = "foo"
Disable #debug:
ENV["JULIA_DEBUG"] = ""
important note: macros are evaluated when code is loaded. So the tricks above will only have effect on code that is loaded after changing the value of JULIA_DEBUG. So after setting it to e.g. all, nothing will have changed. Reload the modules you want to #debug.
To enable #debug messages logging in your julia script:
# ... script ...
ENV["JULIA_DEBUG"]="all"
# debug messages are now enabled.
# ... Rest of the script...
The addition of ENV["JULIA_DEBUG"]="all" will enable #debug messages when running the script in Juno or running it with Julia from your terminal.
I am trying to debug my js code the runs on firebase functions.
My steps were:
install from functions
npm install --save #google-cloud/debug-agent
added index.js:
require('#google/cloud-debug').start();
when I tryed to run
firebase deploy --only functions
got an error :
Error: Error parsing triggers: Cannot find module '#google/cloud-debu
g'
Try running "npm install" in your functions directory before deployin
try: ndb firebase serve
debugger breakpoints are hit with stack traces visible, note it's a little slow so give the debugger time to instrument the child processes
Additionally I was able to debug cloud functions in isolation using (caps for removed values):
GCLOUD_PROJECT=THE-FIREBASE-PROJECT node --inspect-brk /path/to/functions-framework --target FUNCTION-NAME --port=5000
where functions-framework simply expands to the full path for the installed functions-framework (global in my case) and the working directory contains the target index.js for functions.
Alternately when or where the FIREBASE_CONFIG is needed try this format adjusted to fit:
FIREBASE_CONFIG="{\"databaseURL\":\"https://YOUR-FIREBASE-PROJECT.firebaseio.com\",\"storageBucket\":\"YOUR-FIREBASE-PROJECT.appspot.com\",\"projectId\":\"YOUR-FIREBASE-PROJECT\"}
https://github.com/GoogleChromeLabs/ndb
https://cloud.google.com/functions/docs/functions-framework
https://github.com/GoogleCloudPlatform/functions-framework-nodejs/issues/15
The addition to index.js should be:
require('#google-cloud/debug-agent').start();
or better:
require('#google-cloud/debug-agent').start({ allowExpressions: true });
We recently renamed the module, and it is possible that the instructions you are following are partially out of date. Can you point us to the instructions you have been following?
Also note that support for debugging cloud functions is experimental at this point. There are certain cases (dependent on the traffic to the function) where you function may finish before the debug-agent has a chance to initialize/register. We're currently looking into how to address this.