Docker is cool way to deploy and use versioned application, but, IMVHO, it's only applicable for the case when you have single executable or single script, which sets up environment and invoke you for some particular functionality. Like run particular version of compiler for build scenario. Or run continious integration scenario. Or run web front-end environment.

1 function - 1 container with 1 interactive executable is easy to convert to Docker. But not Cache, which is inherently multi-process. Luca has done a great thing in his Docker container where he has wrappee whole environment (including control daemon, write daemon, journal daemon, etc) in 1 handy Docker container whith single entry point implemnted in Go as ccontainrmain but this is , hmm, ... not very effecient way to use Docker.

Containers is all about density of CPU/disk resources, and all the beauty of Docker is based upon the simplicity to run multiple user at the single host. Given this way of packing Cache' configuration to the single container (each user run whole set of Cache' control processes) you will get the worst scalability.

It would be much, much bettrer, if there would be 2 kinds of Cache' docker containers (ran via Swarm for example) where ther would be single control container, and multiple users containers (each connecting to their separate port and separate namespace). But, today, with current security implementation, there would be big, big problem - each user would be seeing whole configuration, which is kind of unexpected in the case of docker container hosting. 

Once, these security issues could be resolved there would be effeciet way to host Cache' under docker, but not before.

Good question. There, on, is set of documentations acompanying each version of Caché released so far. And for each version yu could find "Release Notes" which contains teh list of changes introduced to the language, among the other changes (see Release Notes for 2015.2 as an example)

I would need to go and collect all changes for all releases... if documentation team would not do it for you already :)

The recentmost release notes has all the changes since Caché 5.1. The only you need to do now is to go thru the newest list (from 2016.2FT) and to find those relevant changes for ObjectScript compiler or depretaion warnings.

Very nice tools, but I disagreed with majority of fatal problems (especially in my projects :)). And who said that I could not write $$$MACRO as a single statement? Where did you get one?

So... it would require a lot of fine tuning to work properly accroding to the experienced Cache' ObjectScript programmer tastes. Java idioms ported as-is to ObjectScript just doesn't work.

I'd expect it supported via this set of share tools

but apparently it just sends the link to the given address. Ok, you need page scraper then - and the easiest tool for this I know is uKeeper by Umputun (very famous in Russian IT podcaster, one of voices of "Radio-T" podcast).


It's quite normal for all "share-buttons" to just send a link with title and not sending full content, they are all intending to be used in social networks where text length limitation is the major factor.

If you need article content to get delivered to your email "inbox" - use RSS subscriptions and RSS-enabled mailer. Like Microsoft Outlook :)

Good question, it would be nice to know the list of supported (i.e. properly syntax highlighted) mimetypes.

I know that application/json is [almost] properly handled (with the exception of open brace). But what else? Even text/plain is marked invalid.

Class CPM.Sample.PackageDefinition Extends CPM.Utils.PackageDefinition

XData Package [ MimeType = application/json ]
        "name": "cpm-embedded-package-sample",
        "description": "CPM package sample with the embedded paсkage definition",
        "author": "tsafin",
        "version": "0.5.0",
        "license": "MIT",
        "dependencies": {
            "async": ">= 0.2.10",
            "fsplus": ">= 0.1.0",
            "language-cos": ""


Rich, think about it from this prospective: Caché is inherently multiple processes system, if you need concurrency - you invoke new concurrent JOB (or submit order to the worker queue).

But there is shared memory used by whole system - this is called global buffers. If one of the processes will load some block of referenced global to the memory then it's already in shared memory, and another process will find it handily.

So, despite the percepted heavy weight of this advice but using globals as a mean for sharing data is not that bad and is pretty straightforward. Yes, for usual globals there will be extra transactions/journals mechanism involved, and if you really want to avoid them, making globals as much "in-memory" as possible then you could use ^CacheTemp* or ^mtemp globals, which will be mapped to CACHETEMP database, thus not be journalled, e.g. using ^CacheTemp.ApplicationName("pipe") for storing application data will use shared memory, will keep data in memory as long as it's used, and will not be journalled, reducing overhead to the minimum. (But please not forget to use the proper locking discipline, if you will modify this common data from several processes)


There is close approximation for this almost in-memory mechanism which is called "process-private variables", which do use CACHETEMP mechanisms for reduced overhead, but which provides extra services with automatic cleanup of used globals once process terminated. 

But the problem is - you could not use PP variables for exchanging data with your children because they are invisible outside of this process. Unfortunately, there is no inheritance mechanism for created process-private storage when children created...