Is it possible for launch.json to specify a namespace?

[bourette]

I was helping someone with a debugging question where they had code in %SYS and USER. They were trying to debug the code in USER, but the debugger was trying to execute the code in %SYS and therefore not finding the code (reported it as not compiled). I had them setup objectscript.conn { "ns" = "USER"} to resolve the issue, but it would seem better if this was handled in the launch.json, is that possible?

[daimor]

Yeah, it's a bit tricky.
At the moment it's using the current opened document to get connection settings. But in multi connection environment, it makes even harder for developer to catch where it will run. Having just a namespace in the launch.json, make no sense, due to this multi-connection feature.

I see the only way, how to solve it. Is to review the current way of getting current connection settings, and it should be tied with settings on the same level. E.g. workspace or folder. Isfs root should allow to store launch.json as well.

[gjsjohnmurray]

Isfs root should allow to store launch.json as well.

@daimor ever since 0.9.4 this is possible. All you need is a CSP-type web app named /_vscode that uses the %SYS namespace.

It is mentioned in the 0.9.4 CHANGELOG entry, and #425 is an open issue for getting proper documentation written.

@isc-rsingh can you assign that issue to your documentation resource?

[bourette]

@daimor, to me it seems this is exactly why namespace would make sense in a multinamespace environment, you tell it which namespace along with the code that you are trying to execute.

I look at the documentation https://intersystems-community.github.io/vscode-objectscript/rundebug/ that shows multiple configurations, but now how it's deciding which configuration it's going to run.

@gjsjohnmurray, I guess this should make sense, but I'm not sure I understand how this helps. How does the user then specify that the debugging namespace should be USER? It also seems like a lot of work for the user, now they need to setup a csp application, and another isfs.

[gjsjohnmurray]

@bourette they only need to set up a single extra csp application per server, and they don't need to add a csp-type isfs for any namespace unless they want to be able to find launch.json directly in the VS Code Explorer. They can simply update those files from the Configurations dropdown on the Debug view.

And when debugging an isfs-supplied routine or class there should be no need to specify the namespace anywhere. VS Code should get the debug config from the correct isfs-root, and thus know what namespace to debug in.

[bourette]

@gjsjohnmurray, Sorry, I'm still not understanding this. If there is only one isfs config, I don't understand "VS Code should get the debug config from the correct isfs-root, and thus know what namespace to debug in."

If I have namespaces USER, TEST, HOME, and I want to debug a class in each of these at different times, how would I go about doing indicating which namespace the class relates to?

Using a slightly modified version of the snippet from the docs, where I made the package name the namespace name just for clarity, first how would vscode know which item to run, and second, how would I tell it to run User.MyClass in USER and Home.MyClass in HOME?

"launch": {
"version": "0.2.0",
"configurations": [

	{
		"type": "objectscript",
		"request": "launch",
		"name": "ObjectScript Debug HelloWorld",
		"program": "##class(User.MyClass).HelloWorld()",
	},
	{
		"type": "objectscript",
		"request": "launch",
		"name": "ObjectScript Debug GoodbyWorld",
		"program": "##class(Home.MyOtherClass).GoodbyWorld()",
	},
]
}

[daimor]

It does not mean that it is a good scenario, you have multiple isfs-roots, but you want the same debugging settings.
Having ns setting in launch.json will cause to many other issues. It just increases the complexity of the configuration process. While we already have objectscript.conn and intersystems.servers.

[bourette]

@daimor, perhaps, I'm misunderstanding, are you suggesting that I would have a isfs csp root to store the .vscode for each namespace I have on a server? Is it only for debugging that I want this?

[daimor]

Just to clarify, are you using ISFS or not?

[bourette]

I am not, but the person I was helping is, so for the sake of this discussion yes.

[daimor]

My personal opinion is that isfs feature, by now available mostly for transition time. And I would not recommend using it.
So, my recommendation will be using local files based development environment. And in this case, all the files in any namespaces have to be in different local folders. So, each such root will have its own version of settings.json and launch.json.

[isc-bsaviano]

We added a paragraph at the bottom of our debug documentation page that says how the server connection is resolved.

@gjsjohnmurray Do you think there's any reason to allow a server and/or namespace to be specified in the launch config that would override the current behavior? The tradeoff is that in exchange for clarity on the user's end, the config can't be re-used with a different server without modification.