So how do I debug the project

[zoulux]

So how do I debug the project?

[felipebueno]

I'd love to have an example of a launch.json for Visual Studio Code 😁

[matthewmueller]

(Moved into a discussion)

[Panakotta00]

Can you elaborate on what you mean by debugging a project @zoulux? Do you mean being able to run a debugger and step through a running server?

If so, I'm not too familiar with using a Go debugger, but I have a feeling it might be difficult to setup with Bud. Bud has a multi-process architecture. I have looked into starting a local tracing server to collect traces across processes. Maybe the same can be done for a debugging environment?

I'd love to work with someone on creating a better debugging environment for Bud! I'm still using the ole' fmt.Println debugging techniques 😅

@matthewmueller
What is reason behind going with multi-process architecture, espcially as one of Go's main goals is heavy thread based concurrency?
I could imagine the problem beeing loading the generated project from the "bud cli" f.e., I could imagine an alternative way using Go Plugins.

[matthewmueller]

See #18 for details. The TL;DR is that it's for flexibility. I tried Go plugins, but no luck so far.

I'm working on whittling it down to one optional, short-lived generator subprocess, and one long-running app subprocess. That may simplify setting up debugging, but I'd imagine the general requirements will remain the same.

If you have more details on how to setup debugging in a project, please share, or if you want to give it a try in Bud, I'm here to help!

[Panakotta00]

Sorry but i do not have such a deep insight on debugging.
But how it seems to be, a debugger has to be attached to a process and since you create new processes, the debugger wont be attached to them, so i can imagine that you could somehow hook the debug to the new process, or you dont use processes.
In C++ its not that problematic to use dynamically linked libraries to load additional program code "on demand", but since go is linked statically mostly, this approach would not work. But the plugin system from go seems to be exactly ment for such use case.
The newely loaded symbols will probably get discovered by the debugger and debugging should work.
This is just a assumption, I'm dont know much about the Go back-end, these are just assumptions based on observations.

I think it would be great if you could work on a general source documentation, because it is rather hard to navigate how your code works without propper debugging capabilities. (its just my opinion and my struggeling)
I would be glad to help, as the whole project seems to fit what i searched for very well (getting rid of Node.JS in backend, but still have the beauty of svelte).

[matthewmueller]

I think it would be great if you could work on a general source documentation, because it is rather hard to navigate how your code works without propper debugging capabilities.

Ah, this is a deeper problem and something I'm working on! The next release has much better errors and I'm currently trying to simplify the build process as much as possible while still achieving the desired flexibility.

This is a complex codebase (over 50k loc), so at some point, you'll just need to dive in, but I'm trying to make diving in as painless as possible! Adding more comments, documentation and tests is something I'm actively working on.

Re-iterating that if anyone wants to take a stab at trying to setup debugging, please give it a try and report back!

[runrc]

Re-iterating that if anyone wants to take a stab at trying to setup debugging, please give it a try and report back!

I think the best way to allow users to debug their programs is for bud to expose a callable function which runs bud in a similar way as main.go Using this allows users to effectively bootstrap bud from within their own go main program (not using the installed bud binary) and thus they can control debugging, and more importantly can pass go run time parameters like -race (the go race condition detector) etc. Hope this makes sense?