Thanks @John Murray for arising this... I was getting crazy thinking I was doing something wrong with a simple webterminal installation. 🤯

Thanks @Theo Stolker It works for me also doing in the way you mention. I think you don't need to include %All role to /terminalsocket... as John mentioned at the end, one easier (but less secure) way would be just to set RW privilegies to %DB_USER or to a specific resource %DB_xxxxxx, associated to the database where WebTerminal was installed.

Hi,

this is an old question but perhaps still is worthy to give an updated answer.

This is now entirely possible in last versions of WSL2 for Windows 10 and Windows 11.

You just have to install Docker Desktop for Windows and enable that Docker is available in your WSL distro(s) (it's set by default to your default WSL distro, but you can include more). And it's all set. From then on you can use docker from Windows, using the icon menu or powershell or cmd,... and also, from the WSL(s) that you've enabled. It doesn't matter. You can decide where to launch your containers from... from Linux in WSL or from Windows... depending on your needs.

Hope it helps.

Did you try it in Windows? 

I've tried all the combinations I can imagine... it only works if I take out the blank space. I've created a method JTS.test:write() that just accepts an string an write it to the console... see the results... it works without space in the firts 2 executions escaping as @Iain MacDonald 
 suggested with triple quotes """ and also with \" ... but it fails when we introduce a blank space in the string:

I'm pretry sure it'll be something stupid... but I don't know what.

Thinking in how our intellisense works, we need classes generated... thinking on how FHIR work, we will need to use non-persistent objects but with features like the ones that inherite from %Dynamic*** or the ones that make use of %JSON.Adapter... so one (very general) idea would be to start from the JSON schema of a FHIR release or profile with which you need to work and have a tool that automatically generates the classes that map such schema... and those classes have to have the easiness to export/import JSON documents that %Dynamic* and %JSON.* packages give us.

We should have in mind that these are intermediary packages, no need to persist, we just need them to help us for having intellisense when manual programming FHIR resources, also to help in DTL definitions, etc... so we could have several packages, one for each FHIR release/profile we want to use: r4.*, r4uscore.*, r5il.*,... in the end the objects instanced will inherit for a common class of type %<SomeKindOfNew>DynamicObject.... that provide the helpful logic to use %ToJSON, %FromJSON, %BulkExport,... and to be used in DTL definitions from HL7 to r4.* resource... DTL from r4.* to r5.* resources,... and the capability to be easily serializable or work as virtual document if needed to be sent within our interoperability framework...

Just thinking aloud

Right. But we should have a quicker way to get the parameter in our Python code.

Replacing

set r = ..#MYPARAM

with

r = iris.cls('MyPackage.Subpackage.ClassName')._GetParameter('MYPARAM') 

doesn't seem too "developer friendly" to me wink

By the way, it varies if we're in a ClassMethod or in an instance Method. In instance we could do:

r = self._GetParameter('MYPARAM') 

which it's more acceptable...

But, in a classmethod it seems that our only chance would be the long version.

I wonder if we could translate them to Python as read-only special properties, adopting perhaps some convention in their name to avoid the conflicts in the (unusual) case that there is a parameter with same name that a property.

Interesting summary. Even as a Windows user I'll bockmark it to take a closer look... regarding the terminal... give it a try to Windows Terminal Preview...available in Microsoft Store... sure you'll like it.

Also for screen snapshots... if you want to have the chance to decide where to store it... use this option 

that you'll find in Windows Ink workspace... (the one you get rid of :-)  ) ... it'll capture the whole screen and open it to let you cut, modify and copy or save the image...

I think that that's not valid as "in theory" he doesn't know the name of variables. I would try this:

ClassMethod Indirection()

{
    set TABLES(0)="EVEN"
    set TABLES(1)="ODD"
    for i=1:1:100
    {
        set table = TABLES((i#2))
        set @table@(i)=
    }

    zw @table
    set evenTotal=0
    set i=""
    for
    {
        set i=$ORDER(@table@(i)) QUIT:i=""  
        set evenTotal evenTotal+@table@(i)
    }
    zwrite evenTotal
}

Hi again, I've just added to the article the slides that I used during the video tutorial. Feel free to use all of some of them. If you do, the only thing I would kindly ask you is to include a link as a reference to this article within our community.

For the ones that contacted me, you were right, the repository in GitHub was set as private. It's set to public now: GitHub Repository - Examples 

Well, it has been a long trip... but Chapter 6, "What's about SQL?" is finally published with reviewed English CC...

In this last chapter I'll show you what's about the Multi-Model architecture of InterSystems IRIS, and how ObjectScript is able to work also with SQL paradigm in a very easy way to also cover that feature of the platform.
We'll do hands-on exercises of embedded and dynamic SQL using the small class model we defined in the previous chapter... which now we'll see as an E/R model.

And... That's all folks!

Happy Coding!

Yep, I know. But I hoped something more "transparent"... if we deal with several instances and change with certain frecuency (as it's my case), having to define direct accesses when we have a link in the "cube" menu, doesn't seem too clean. For Linux/Mac users, the solution is clean. You just define your aliases file, and you just can install your IRIS instances... all of them would make use of them seamlessly... that's the functionality. Right now, for windows users, it's incomplete. A pity because it's a really very good feature to have, our terminal/shell needs these kind of tools, but it has to be much easier to reuse among instances.  IMHO. 

Perhaps it would be as easy as to change our installer so to include that argument out-of-the-box in the call to Terminal in the cube... and then let the developers build their own script in their own home directory.