I submitted OEx updates to the details of both my entries earlier today, merely adding an online demo link for each. Both updates are still showing as awaiting approval. Please add that bonus to DX Jetpack for VS Code and IPM in VS Code.
...and Jetpack now has a video plus a first DC article.
Please see my reply at https://github.com/gjsjohnmurray/iris-package-manager/issues/2#issuecom… to the GH issue you created.
do ^myRoutineName
A second article for IPM in VS Code, which now supports the use-case where a dev is using an IRIS container to import their local sources to.
Setting this up on a 2024.2 Windows instance hasn't been easy, and even now I'm only getting a blank page like @Jeffrey.Drummreported elsewhere on this thread. His IRIS was 2024.2 but not on Windows.
Hurdles were:
zpm:%SYS>config set UseStandalonePip 1 zpm:%SYS>config set PipCaller "C:\Program Files\Python312\Scripts\pip.exe"
So now I have it installed in %SYS (thanks to the tip from @Evgeny.Shvarovin this thread):
zpm:%SYS>list zpm 0.7.3 iterm 0.1.0 zpm:%SYS>
But still the blank page. And I'm wondering why the iterm contest entry mentions WSGI but the /iterm app set up by the installer is a REST one rather than a WSGI one.
So far, no gain in return for the pain, and I'll continue to get along with Lite Terminal that's built in to the VS Code ObjectScript extension. It requires zero config and works on 2023.2+
Pinging @Semion Makarov in case the extra point has been overlooked.
The missing `set` was because I had copied the wrong line from my shell session. I have edited the post to correct this.
I get the same as Jeff, so it seems the zpm install installed the requirements OK.
Thanks for adding the BYOP doc to the wiki.
Since the Cody people talk about "the repository" I'm guessing they mean a local Git repository. When you're using ISFS you're using the server-side editing paradigm, so no local Git repository is involved.
@Evgeny Shvarov re #1 aren't you already using the "objectscript.conn.docker-compose.service" and ""objectscript.conn.docker-compose.internalPort" settings? If you're finding a specific problem using these please open an issue at https://github.com/intersystems-community/vscode-objectscript/issues
@Evgeny.Shvarovre #3 when you write git-source-control are you referring to this package?
https://openexchange.intersystems.com/package/Git-for-Shared-Developmen…
Is using this with the client-side paradigm a supported mode? I haven't yet found any documentation to that effect.
It seems that sometimes the first command you issue after opening the tab doesn't run. Please try `version` twice. After you get the version response try using other commands.
Disappointed that you have picked such a US-centric time for this, so I won't be able to participate.
Thank you for rescheduling the meeting.
Has anyone here succeeded in making this work with 2024.1 or 2024.2 on Windows? I've tried two separate IRIS instances, and in both cases I only get a blank black page after IRIS authentication.
Browser devtools network trace shows this repeatedly:
oops: <PYTHON EXCEPTION> 246 <class 'ModuleNotFoundError'>: No module named 'termios'
Probably has no hope of working on Windows:
.png)
@Jeffrey.Drummdoes this also happen if you launch iterm from a private browser session?
Are you able to launch an IRIS Lite Terminal onto this server from inside VS Code? Testing this could rule out it being an issue with websockets.
@Jeffrey.DrummI think your issue is likely to be that the app apparently assumes this OS-level command will lead directly to an IRIS shell prompt without requiring credentials. On Linux this means the %Service_Terminal service is accepting Operating System authentication. There must also be an IRIS user definition that matches the OS username under which IRIS runs, and that user must have sufficient rights. Enabling login-related audit messages may help you diagnose failures in this area:
/path/to/iris/bin/irisdb -s/path/to/iris/mgr
What about if you are logged into Linux as the userid which your IRIS runs as? On a default install it's typically irisusr, and on the containerized IRIS instances @Dmitry.Maslennikovprobably uses it's typically irisowner.
Here's what I find when I successfully connect to a Docker container created from a DC registry image, authenticating as SuperUser/SYS
Node: d2ba2ec8dbce, Instance: IRIS USER>w $zv IRIS for UNIX (Ubuntu Server LTS for x86-64 Containers) 2024.1 (Build 262U) Thu Mar 7 2024 15:36:40 EST USER>w $username SuperUser USER>!whoami irisowner USER>
If the user I authenticate with doesn't have USE permission on %Service_Login you don't even try, which means I get a terminal session with the username and roles (typically %All) of the account IRIS runs as.
I have raised https://github.com/caretdev/iterm/issues/2 about this.
I hope you will do me the honour of reviewing my IPM VS Code extension, and of taking a look at the new extensions I added to the 2024 edition of the DX Jetpack extension pack that you reviewed last year.
Does it also happen if you use a private browser session?
Yes, maybe the Management Portal login on the server allows Unauthenticated.
With the release of VS Code 1.94.2 today this problem has been resolved unless you are using a multi-root workspace that has one or more file:// root folders in addition to your isfs:// one(s).
A side effect of the 1.94.2 fix is that people using our beta VSIX with proposed APIs enabled will no longer get the benefit of the new 1.94 Explorer Find functionality, despite the beta being capable of participating in this. We hope the VS Code team will resolve this in 1.95 next month.
See the Path Prefix element of the definition.
https://docs.intersystems.com/components/csp/docbook/DocBook.UI.Page.cl…
David, if you point your Edge to edge://policy/ does it report an AuthSchemes policy value?
Release note links aren't yet updated.
Maybe a browser add-on? For example https://addons.mozilla.org/en-US/firefox/addon/accept-language-per-site/ (not tested by me, so please don't treat this as an endorsement).