[Feature] Remote Analysis

[Domiii]

Is your feature request related to a problem? Please describe.

Dbux's Runtime Server is currently hard-coded to live on port 3374 and @dbux/runtime connects to localhost:3374. Thus, remote applications cannot currently be debugged.

Describe the solution you'd like

This should be configurable in order to allow debugging remotely executed code as well as containers.

Is this covered by any of the Dbux known limitations or future-work items? If so, which?

Remote Analysis.

Important

Please let us know on discord and up-vote this feature, if this issue is blocking you from using Dbux.

[CherryDT]

I would think regular port forwarding (for example via SSH switch -L) should work for this, doesn't it? If it does, it would be nice to see this as solution in the docs.

[Domiii]

I'd love to amend the docs. Can you write it up?

The docs for that page are here. But maybe the solution deserves its own docs page, maybe at Guides → Remote Analysis?

(Also, I have not tried that before, and I'm not sure what the pre-reqs are for this.)

[CherryDT]

I see the port forwarding is in the other direction - but then it works fine. I used -R 3374:localhost:3374 on the SSH connection and manually started the runtime server in VSCode.

However, the easiest way is to simply run a remote SSH session in VSCode and install the extension there - then everything just works out of the box (just like in the WSL remote scenario)!

How do I correctly add a new guide page?

[CherryDT]

...OK I realized, the port forwarding "works" only to the extent that it successfully loads the trace into dbux in VSCode.

But then it obviously fails to do anything useful with it because the file doesn't exist locally.

So I guess the only working way (which luckily is also the most straight forward one) is to use the remote SSH extension for VSCode and simply use dbux in the remote VSCode session.

[Domiii]

That is a good point... remote analysis would require files mapped to where Dbux can find them... I guess, that was why I was hesitant to just implement it, since allowing custom address+port is easy. Mapping files on the other hand... hum... We theoretically have most of the important parts of the source code file in the data. Maybe this will be a bigger future work-type of feature, where we use the data that we have to reconstruct (mostly) complete original files from that data?

And until then, we might just want to amend the docs to point to the SSH sln, or otherwise recommend people to make things "virtually available locally"?

[Domiii]

@CherryDT

How do I correctly add a new guide page?

1. Follow setup guidelines from the Contributing page.
2. Curse me for, again, requiring in-Windows bash (since some of our package.json scripts are using it)
   • In my defense: at least it works (used to work) on Windows, even obscure Linux and Mac! :P
3. Find a work-around for your bash situation, by just ignoring it at first, and then fixing up the few scripts that do depend on bash manually (e.g. in package.json, it might only be build:clean, can't find anything else rn)
4. Once you have the workspace open, you can find all docs in the docs_site folder.
   • Guides are in docs_site/content/guides.
5. Run yarn docs to test it locally.
6. Once you are done: yarn docs:build which does a few more pre-deployment checks.
7. If it all works out, send out a PR.

(I will add this to Contributing now or later as well)

[CherryDT]

@2 I don't have a problem with that, requiring from a contributor to have bash available is fine I think. Plus, in this scenario one has more control over it. I'd run this in WSL anyway (I do all development work in WSL) and I'm sure it'll work out of the box. But even if I didn't, then it'd work fine in Git bash. (The problem in the other thread was not requiring someone to use bash but requiring the global bash command in Windows to resolve to a specific thing.)

EDIT: My bigger issue is that I don't use yarn normally 😉 (yeah, not really an issue.)

[Domiii]

Again, I recommend volta to deal with all those node, npm and yarn versioning issues... But you might know my stance on that by now :)

[CherryDT]

Will probably look into Volta indeed, because I'm currently using asdf and it annoys the heck out of me.

[Domiii]

Side note: be careful to fully get rid of the old node and npm installations, if possible. Conflicting global installs can cause pain when you depend on certain global packages (which Dbux should not do, but still just to be safe).

[CherryDT]

Hm... compared with the other "guides" - I'm not sure how much content I have, actually, now that port forwarding isn't included anymore. It would be a very short article. Is there some better place?

Because all it'd really say is:

dbux also works in remote VSCode sessions (using one of the VSCode remote extensions - WSL, Docker, SSH, ...)! If you want to debug code on a remote server via SSH, you need to follow the VSCode remote debugging guide and then go click "Install in Remote: SSH" for dbux after connecting. After that, everything should work the same way as it does locally.

[Domiii]

@CherryDT You can add it to the FAQ?

As a feedback on your proposed content:

1. Could you consider (i) re-writing it as a numbered list, and (ii) possibly provide a small screenshot for the most difficult of the steps in that list?
2. Also, the link you provided is not a "debugging guide", but it does contain a short section on debugging. At the same time, it might be confusing to refer the user to the "VSCode debugging guide", since Dbux is generally used very differently from the built-in debugger? Which steps of that guide do they have to follow exactly?

Either way, your enthusiasm is much appreciated. Hope, me giving you feedback like this does not piss you off. It is neither intended to be personal, nor a judgement of your work at all, just my opinion.

[CherryDT]

No of course not.

Also, calling it "debugging guide" was a lapse of mind, it was supposed to be "development guide" :)

I'm not sure what the "most difficult" step would be? Perhaps setting up the SSH configuration if needed, but that's not really in the scope of this FAQ entry and can differ wildly depending on your setup.

Essentially, it's this:

1. If not already done, set up remote development with VSCode on your server via the "Remote: SSH" extension, as described in this guide.
2. In a VSCode remote session, install the dbux extension, in the same way you would do locally (going to "Extensions" in the sidebar, searching for "dbux" and clicking "Install").
3. Use dbux normally!

(About "which steps to follow": It would make sense to read the whole guide to understand how this works and what using a remote session in VSCode actually means. What the bare minimum would be is also different depending on your setup. I, for example, already have some SSH connections configured in my ~/.ssh/config file that I use from the command line, and all I needed was installing the "Remote: SSH" extension, opening a new remote window and selecting the desired host from the list that was autopopulated based on my config file. But others may need to go a different route. Also, I guess it makes a difference whether you have Windows' native SSH client installed or something else - but all these things are things a developer who uses SSH should already know / have set up in some way.)

[Domiii]

@CherryDT sounds good to me. Maybe capitalize the D in Dbux (to be more consistent with how we write it everywhere else), and feel free to send out that PR :)