there are some possible issues to have docker related files in a dedicated folder. 

When you would like to start an environment with docker-compose, you can do it with a command like this.

docker-compose up -d

but it will work only if the docker-compose.yml file name has not changed and it lays right in the current folder.

if you change its location or name, you will have to specify the new place

docker-compose -f ./docker/docker-compose.yml up -d

became not so simple, right?

Ok, next about Dockerfile.

when you build docker image, you have to specify context. So, the command below, just uses file Dockerfile in the current folder, and uses current folder as a context for build.

docker build .

To build docker image with Dockerfile placed somewhere else, you should specify it, suppose you still would like to have current folder as context.

docker build -f ./docker/Dockerfile .

any other files in the root, such as Installer.cls, irissession.sh or any other files which should be used during docker build have to be available from specified context folder. And you can't specify more than one context. So, any of those files should have some parent folder at least, and why not the root of a project.

with docker-compose.yml, we forget about docker build command, but we still have to care about docker-compose

you have two options, instead of cache.exe use irisdb.exe

or use command iris terminal <instancename>

6252 supports  DCPM, while 6152 does not

The first iris after exec is the service name from docker-compose.yml, then goes command which has to be executed.

 iris command is a replacement for ccontrol from Cache/Ensemble

session - subcommand for iris tool

And the latest iris as the instance name inside for IRIS inside the container

Sounds good. How about to run it on Raspberry PI, is it already a time, to order of some (even now, when it has been recently updated and got a lower price)?

So, today, I'm presenting a demo of VSCode-ObjectScript at CUG meetup here in Antwerp

Yep, it tries to open terminal automatically when docker-compose option used 

Hi Jose,

Interesting, I don't have windows, but as I can see, exit code 2, means 

The system cannot find the file specified.

That's strange when it successfully called docker-compose when looked for a port.

You can also try to open an ordinary terminal in VSCode (Menu, View->Terminal), and put full command there, to see how it works.

I've already published a beta version with support for CSP editing, It would be cool, if you could test it and give some feedback.

A FOR loop pushes a new level onto the stack. A WHILE loop does not change the stack level.  

Source

Working with stack takes time.

Something like this, you can have many serverN folders, with own settings.json there, configured for any server.

{
    "folders": [
        {
            "name": "root",
            "path": ".",
        },
        {
            "name": "server1",
            "path": "server1",
        },
        {
            "uri": "isfs://server1",
            "name": "server1",
        },
        {
            "uri": "isfs://server1?ns=%25SYS",
            "name": "server1 sys",
        },
        {
            "name": "server2",
            "path": "server2",
        },
        {
            "uri": "isfs://server2",
            "name": "server2",
        },
        {
            "uri": "isfs://server2?ns=%25SYS",
            "name": "server2 sys",
        },
        {
            "name": "server3",
            "path": "server3",
        },
        {
            "uri": "isfs://server3",
            "name": "server3",
        },
        {
            "uri": "isfs://server3?ns=%25SYS",
            "name": "server3 sys",
        }
    ],
    "settings": {
        "objectscript.serverSideEditing": true
    }
}

Fixed

Could you explain a bit, how would you like to see work with CSP files? For me, when you working with own local instance, you can just open csp folder in VSCode, and edit as a usual file, InterSystems will compile it automatically with the next request. I think it would be possible to add CSP editor only as part of Server-side editing feature.

Server-side search, not yet available, because, search engine not yet publicly released. I've already implemented server-side search when server-side editing enabled, and you can test it with the latest beta version of vscode-objectscript, and only with Code-Insiders version, and with flag --enable-proposed-api daimor.vscode-objectscript

Could you add your expectations from debugging feature, as an issue here?

Only one server connection.

At the moment it is possible to have multiple folders configured for each own server, and tied up with .code-workspace file. I see you already use server-side editing, so, you can just extend your file. And the link for the info, how to configure it.

Curiously, what do you expect from XData? Could you fill the issue, so, for any other ideas as well?

When your team uses Studio with source hooks, it's even easier to move to VSCode. VSCode supports source control class hooks, and even some types of actions from menu. You can the latest beta release, to get more features.

VSCode can also be used to edit files directly on a server, almost the same way as Studio. Just at the moment it does not check any changes on the server, and uses your opened files as a source of truth.

Scott, could you give some more details about your experience with VSCode, privately directly to me or publicly here? What do you expect, and what would help you decide to use VSCode instead of Studio?

His LinkedIn and Twitter, but I don't see any relations of him with InterSystems technologies. So, I think he just googled how to join our leaderboard.