go to post Mathew Rimmington · Mar 18 Hi Brett, I'll give some further context to what we are doing at CDS. Our product's repository contains a lot more than just IRIS objects and it is entirely feasible that a developer can spend days working in C# without opening VSCode. Rather than insisting that developers open VSCode specially and Import and Compile all routines and classes every time the developer does a git checkout or git pull (anything that affects the repo files), we created hooks to automate the process. The reason we chose Git hooks were threefold. Firstly, we have approximately 15,000 IRIS routines and classes. It takes several minutes to import and compile ALL of these files. A Git hook is clever enough to know which specific files have changed, and can just import and compile them. Secondly, we have many routines and classes which, when saved, need to trigger something else to be built - like a mini install process. Say a developer is making changes to routine A, the developer will be happy enough to manually trigger the install process. But when routine A is committed to the repo and other developers start to pull the routine, it felt impractical to ask developers to remember to run the same install process. Thirdly, we need to import routines before classes. This is because some of our classes are dependant and won't compile until the mini install process I mentioned above have ran first. I'd love nothing more than to be able to just use the VSCode extension to keep our IRIS objects in sync with the file system, but as I've said, a lot of our developers won't even have VSCode open if they're developing new features solely in C#. And because we can't run our mini install processes as routines are changing, we are finding that classes won't compile. Hopefully this explains why having VSCode monitor the file system for changes won't work for us. As Michael has mentioned, I think we need the setting to control whether saving a file within VSCode automatically imports and compiles, and an independant setting to control whether file system changes outside of VSCode automatically import and compile. One other problem we found in testing was that the VSCode extension is opening files with exclusive locks. This causes the Git hooks to not be able to read the changed files. Even if we could just use VSCode to get around this problem, the dilema we have is that we can't turn off using our Git Hooks as VSCode won't always be running. Mat
go to post Mathew Rimmington · Jan 29, 2024 Hi Brett, thanks for getting back to me with an answer. As we have thousands of routines containing dot syntax I couldn't really leave this without a solution. For now we've built our own simple extension to implement OnTypeFormattingEditProvider. See https://vshaxe.github.io/vscode-extern/vscode/OnTypeFormattingEditProvider.html. In our case all the method implementation needs to do is look at the previous line, assess how many dots the line begins with and populate the same on the new line. I can appreciate the difficulty you'll have with making this work for all scenarios in Object Script though.
go to post Mathew Rimmington · Jan 18, 2024 Hi @John Murray, thanks so much for this. I can confirm that this fixes the issue.
go to post Mathew Rimmington · Jan 18, 2024 Removed - posted at the same time as John Murray's answer above.
go to post Mathew Rimmington · Jan 18, 2024 As an experiment, I did try switching the folder structure to appname/database/src. I also changed the objectscript.export.folder setting to match the new structure. This does resolve the issue. Is there some hardcoding of the "src" folder perhaps in the extension? The trouble is, I can't leave the folder structure like this.
go to post Mathew Rimmington · Jan 18, 2024 In the repository root there is a .vscode/settings.json file but it doesn't override any export settings. It looks like this: { "objectscript.conn": { "server": "iris", "ns": "{namespace}", "active": true } }
go to post Mathew Rimmington · Jan 17, 2024 Hi @Brett Saviano, just tried it but made no difference sadly. New routines are still created in package src.database.
go to post Mathew Rimmington · Jan 17, 2024 Hi @brett morgan, thanks for resolving this so quickly. The changes work perfectly thanks.
go to post Mathew Rimmington · Jan 17, 2024 Hi @Brett Saviano I didn't type in a username, I left it blank as per the instructions in the screen shot. i.e. "leave blank for unauthenticated access as UnknownUser"
go to post Mathew Rimmington · Nov 22, 2023 Whilst exploring how the company I work for could get source control up and running for our development environment I came across this announcement and am intrigued. However, I'm a bit confused about whether this is now out of support. The link to the page here: https://openexchange.intersystems.com/package/Git-for-Shared-Development-Environments has a line at the top stating "This application is not supported by InterSystems Corporation". The phrasing of this is ambiguous, I can't quite tell if it means that the product is out of support and that people shouldn't use it, or whether the product is just not maintained by InterSystems themselves. I thought I'd give it a go, but installing the package manager crashes on installation while using the instructions found here: https://openexchange.intersystems.com/package/Git-for-Shared-Development.... I did notice that there is an issue logged for it here: https://github.com/intersystems/ipm/issues/432. Does anyone know whether this avenue for source control is effectively closed?
