The same code from comment below, but in Python

And generated code for those parameters

ROUTINE User.Test.G1 [Type=INT,Generated]
	;User.Test.G1
	;(C)InterSystems, method generator for class User.Test.  Do NOT edit.
	Quit
	;
pCOMPILETIME(%class,%parameter) public { New %classname Set %classname=%class
 Quit $ZDateTime($ZTimeStamp,,,3)
}

ROUTINE User.Test.1 [Type=INT,Generated]
 ;User.Test.1
 ;Generated for class User.Test.  Do NOT edit. 10/03/2022 07:50:07AM
 ;;3043524C;User.Test
 ;
ztest() public {
  Write !,"RunTime: ", ..#RUNTIME
  Write !,"CompileTime: ", ..#COMPILETIME
  hang .5
  Write !,"RunTime: ", ..#RUNTIME
  Quit 1 }
zRUNTIMEP() public {
	Quit ($ZDateTime($ZTimeStamp,,,3)) }

By default the value of the parameter is static. But you can define parameters that way that the value can be evaluated at RunTime or CompileTime

So, technically, you can define the Get method for Parameters

Why would you need it?

##class(class.name).#PARAMETER 

..#PARAMETER 

$parameter(“class.name”, “PARAMETER”)

From my point of view, the main issue is ObjectScript. Any new developer, would not see it as something that may help him in the future. Developers should not work at the same company and with the same technology for a lifetime. Every developer, should check the potential to change the job, and get a promotion. In comparison to more popular programming languages, ObjectScript can offer nothing at all. Python developers for instance can change work and get a better salary, much easier.

Even though, InterSystems products are supported by other programming languages, such as Java, .Net, and NodeJS. It's real pain, to make that work, even with the last trending Python, quite tricky to start. 

I'm sure, that to gain more people on our IRIS side, we have to look at the popular tools, frameworks, and libraries used by developers, and make them work with IRIS as well. Many libraries support a huge amount of databases, including some proprietary, but no IRIS at all. So, developers who know well Java, have a lot of possibilities to start a project very quickly which would work with any database, but IRIS.

I'm personally, trying to help with these issues. Even for ObjectScript, I managed to upgrade the developer's experience with modern IDE VSCode (So, the young developers who know what a modern development process should look like, would not be so shocked by so outdated Studio). Help with using Docker in the development process, package managers, and continuous integration, all with ObjectScript, and even static syntax analyzer. But I want that all the new projects would not use ObjectScript at all, to help with it, I have built Django driver to IRIS. I want to see IRIS support in as many programming languages as possible, and as many libraries and frameworks as possible. So, the developers would not have any issues in switching jobs, they have to use their knowledge which could be applicable anywhere. Want to build an application that uses SQL, that's ok, here is the driver, connect it and use it, as you would do it with another relational database.  NoSQL, ORM, or something else, is not an issue as well. But it's still too far to this point. 

Protocol and its implementation

I've looked at the realization in IRIS, and it does not support any streams, So, any call of Write, is like a complete message and it accepts only string.

Did you try with --format docker? I have no podman, just see, that it said on the error

Why do not pass a stream to %ToJSON, and then Write the stream content?

Set stream = ##class(%Stream.TmpCharacter).%New()
Do message.Msg.%ToJSON(stream)

But, I'm sure that you will not be able to send the whole big stream as a whole message. You still have to split it and receive it knowing that it's not complete.

There are no settings that would limit it.

There are various reasons, which may cause the low reading speed. It may also depend on the kind of disk HDD or SSD. Multiple processes can read simultaneously. If you manage to split one read to multiple processes, you may achieve better speed. Copy file, not a right way to measure the speed, because with Cache your data can be spread among disk wider than you think, and it will take time to read it. Defragmentation can be the reason of slow speed.

You may ask InterSystems WRC to help you to investigate this. Or may contact me, directly I can help with it as well.

I'm sure that error should point to the particular class, where it found the issue with storage

btw, you may report your issue here.

So, probably you missed some of the classes, if you use VSCode, import all the code and compile manually and export with VSCode. So, all classes will get storage correctly.

Why did you remove storage from the classes?

It's an important part of the code. And ZPM mentioned this. All classes have to have storage defined in the code. It will not allow installing without storage.

it would be a huge waste of resources with higher complexity of the development process. I would not recommend it this way at all.

A much better way is to use named volumes, where you could munt data, which you would like to keep between restarts of containers, but not easy way as well requires a lot of attention to many staff in IRIS, or use with Durable %SYS

It's essential to keep in mind, that ObjectScript code has to be compiled. And actually, there are two ways of doing this.

• Build stage, mostly with using Dockerfile
• Runtime stage, start vanilla IRIS and build application there.

Yes, docker build can be slow, but the issue here is that IRIS starts in fully functional mode, and it takes too much time to start. While it would be enough if IRIS would be started with very minimal functionality (no spare wrtitedaemons, no hot jobs for Interoperability, and so on)

Building an application in runtime does make not so much sense. First of all, it's not so simple to make this happen. And second, the logging of this is quite complicated as well. So, it makes the debugging of the build process much more difficult. And in the case of a significantly big project, it still will take a lot of time to be built, but with less understanding of the progress.

The ability to fail fast is quite important, and it's a sign to a developer, that something is odd. Building images with BuildKit, have a different way of logging, and it may not show the real reason for failure, but you can turn on the full logging this way

docker-compose build --progress plain

If your project uses ZPM, so, most probably you would have lines like this

RUN --mount=type=bind,src=.,dst=. \
  iris start iris && \
  iris session iris "##class(%ZPM.PackageManager).Shell(\"load /home/irisowner/$MODULE -v\",1,1)" && \
  ([ $TESTS -eq 0 ] || iris session iris "##class(%ZPM.PackageManager).Shell(\"test $MODULE -v -only\",1,1)") && \
  iris stop iris quietly

ZPM's Shell accepts three parameters

• executed command itself
• Fail on error
• Halt on exit

So, you can just change the second parameter (the first 1) to 0, and the build will be successful in any case

And unfortunately some (almost all) of the images there are already outdated and replaced with new ones