@Mikko Taittonen
The vscode-objectscript extension does provide New File commands for Interoperability classes. You can read the documentation here. The SOAP wizard can be accessed from the Server Actions menu. BPL and DTL classes can be edited textually. Support for the graphical editors will be added when they are rewritten using Angular. For a preview of how that would work, you can try out the new Angular Rule Editor in VS Code.
@Alexey Maslov
That sounds like a bug to me. Can you file a GitHub issue with steps to reproduce? It would also help to know the versions of the extensions you have installed, the version of IRIS you're connected to, and the text of the file that you see the bug in.
@Menno Voerman
Unfortunately I don't think this is possible. That command is for opening files, and technically the name of the file is "HS/FHIRServer/Interop.HTTPOperation.cls", not "HS.FHIRServer.Interop.HTTPOperation.cls".
@David Hockenbroch
We just improved the UI for creating a new server-side editing workspace folder. If you have no workspace open, you can follow the steps here to create a new one. If you do, you can add a new folder to you workspace by right-clicking in the file explorer and selecting "Add Server Namespace to Workspace..". That command will follow steps 4 and on. To see CSP files, select "Web Application Files" in the menu from step 8. To see basic files, select "code files in <NS>", then select "Filter", then make sure your custom filter contains the "*.bas" pattern. It can include other file types as well.
@Martin Fukátko
I tried reproducing your issue but couldn't. I see your using client-side editing (editing a local file). Have you saved that class on the server? The Language Server extension checks for class existence against the list of classes on the server so if yours hasn't been saved, it technically doesn't exist.
@Norman W. Freeman
This query will return the names of all non-system and non-generated classes in the current namespace:
SELECTNameFROM %Library.RoutineMgr_StudioOpenDialog('*.cls',1,1,0,1,0,0)The documentation for this query and its parameters can be found here.
@Ben Spead
The existing docs here have been updated to reflect the new UI.
I expect that this will work fine. Our 'Open Error Location..." command just goes to the line+offset in the INT routine, it doesn't try to resolve the location in the CLS/MAC/CSP that generated the INT.
Here's a full list of all the MimeTypes that will be correctly colored in VS Code (requires InterSystems Langauge Server version 2.1.1):
An XData bock with no MimeType will still be colored as XML.
@Scott Roth
Please see our documentation page on server-side editing for directions for setting up your workspace.
I just released InterSystems Language Server version 2.2.0, which provides intellisense for variables created by %New(), %Open() or %OpenId(). VS Code should auto-update it for you.
Maybe try using 'ck' instead of 'cuk'. The 'u' flag is the one that tells the compiler to not recompile if it doesn't detect a code change.
@Zach McKinney
Thanks for log output. Have you compiled that class? The "Breakpoint Cannot Be Mapped" error means that the debugger couldn't map that location in that class to the generated INT routine.
@Zach McKinney
Please follow the steps listed here and send me the log output. Feel free to mask any sensitive information.
I opened a pull request to improve the documentation so other users don't have the same confusion
That's the problem. The folder setting is relative to your workspace root. Since you have repos open, you want it to be "PATS\Server\Namespaces\AXIS".
Which folder do you have open as the root of your workspace?
Did you export those files using the VS Code extension? The extension uses its export settings to determine where it will look for local copies. For example, if you have the AXIS folder open in VS Code you would need the following export settings to reflect the existing folder structure that you have: objectscript.export.folder setting equal to "", objectscript.export.atelier setting set to true, and objectscript.export.addCategory setting set to false.
@Michael Hampton
I need more info about your exact setup to answer your question. What were your export settings previously? What folder within your workspace are your InterSystems files in? Are you sure that the file that contains the definition has a local copy?
I believe this is the same problem described here. You need to add the --check-caps false command to the iris container in your docker-compose.yml file, like this:
...
iris:
command: --check-caps false
init: true
...
The SAM 1.1 distribution should have this done for you but that change must not have made it in. I think you can still enter the SAM 2.0 EAP if you'd like to start with the upcoming version.
The logs are stored in the containers themselves. Using docker you can read them using the docker logs command. According to the podman docs, this is what you would need to run:
podman logs sam_iris_1
@Scott Roth
I don't use podman so I'm not sure how to check this but it looks like the SAM Manager container (a modified IRIS) is not up or is not healthy. Can you check if it's up and if so, check the log contents? Nginx is probably reporting a bad gateway error because the SAM Manager isn't listening on the expected port
@Scott Roth
SAM or Prometheus alone can be installed on a separate server. They just need network access to the IRIS servers that you want to collect metrics from.
@Gertjan Klein
Unfortunately that's not supported and I'm not aware of any way to support that.
@Michael Davidovich
Refreshing the explorer only refreshes the nodes in the tree view. If you have a virtual file open that you opened from the explorer it won't auto-update. You can close it and reopen it and the extension should fetch the new copy. If you have your local copy open, you can export again to get the latest version.
@Michael Davidovich
If you have a local folder open there should be two tree views within the ObjectScript view container (the left pane that is shown after clicking the InterSystems logo in the activity bar on the far left). The bottom one is the Projects Explorer and it's only used to create/modify/export server-side project contents (also known as Studio Projects). The top tree (with the Explorer name) is the ObjectScript Explorer where you can Compile/Export/Delete packages and files. Since you don't use server-side source control and need files in your local file system, you can safely ignore the Projects Explorer since they won't be useful for your workflow. Here's a screenshot of what this looks like for me in a locla folder called "langauge-server":
EDIT: If the ObjectScript Explorer isn't showing, make sure you don't have the setting "objectscript.showExpolorer" set to false.
@Michael Davidovich
You can export individual packages or files from the ObjectScript Explorer. Simply right-click on the node(s) that you want to export and click the "Export" menu option. The command may be better in your use case though because once you have your settings configured properly, you don't need to do anything else besides run the command to update your local copies.
Unfortunately there isn't a way to automatically update your copy if changes are detected. If you make an edit and then try to save it to the server the extension will check if there's a conflict and help you resolve it. If you are working client-side then I wouldn't expect a server conflict though because your local copies (synced with source control of course) should be the "source of truth". You can always re-run the export command before you edit if you want to avoid conflicts.
As for the disappearing disp class, editing the impl class will not force the disp class to be regenerated so its state shouldn't change. That may be due to your Studio configuration being set to hide generated files.
As a first step I suggest you read through our online documentation to familiarize yourself with common workflows. The extension supports a client-side workflow where you export files to the currently open local folder and handle the source control yourself. To edit client-side, you can use the ObjectScript Explorer to export files. You can also use the Export Code From Server command, which uses the objectscript.exportconfiguration settings to determine what to export. Our extension does not support VS Code's "Download" menu option.
Since the disp class is generated from the spec class you probably don't want to store it in source control but if you still want to export it, you can have the Explorer show generated files before you export a package or if you're using the command you can set the objectscript.export.generatedto true.
@Henry Wojnicki
I'm glad you like the extensions! If you send me an example of the syntax coloring bugs via email (or post an issue on the Language Server GitHub) I will try to fix them for you.