Yes, this is very long story. :)

But in any case, there is [better spelled] system method, which returns endianness flag from kernel code:

As you might recognize the fact that JSON support is still work-in-progress, and any next version is getting better than prior. In this case 2016.3 will be better than 2016.2 because there iis added support for $toJSON in resultsets (though I ran this in "latest" so results might look different that in 2016.3FT).

Overseas it's still as bad as original 6seconds for Mark. At the moment total load time is 4 seconds, though "time-to-first-byte" (TTFB) for the 1st request is 0.9seconds (which is not instant, but good enough).

The page is still heavy (57 requests and 1.6MB payload), and Drupal devs should pay attention to this large number of files involved.

I'm curious what is the point to write longer ##class(%Object).$new() instead of simple {} ?

You have missed the extension of file "data.csv" used in the example. CSV stands for "Comma Separated Values", which is simplest way to exportt Excel like data to the textual file. And in this case it was apparently exported in the Russian-loale where "comma" is ";" actually.

Ok, Eduard, let me elaborate using some fictional, ideal picture.

• Let assume you are part of large team which is working on some pretty huge system, say multiple hundreds or even few thousands of classes in the single namespace. And whole your team are good citizens and have covered all classes with unit-tests pretty extensively.
• Let assume you are working on a changes to classes which are part of pretty-large "system" package (i.e. ocnsisting of few hundreds of unit-tests)
• And you have changed only 2 classes in the package, which is covered by dozen of unit-tests here and where.

And as a good citizen you always run all relevant unit-tests for changed classes before committing to VCS. So what would you choice before commit: to run unit-tests for whole package (which might take hours) or only for your project with relevant classes (which will take few minutes)?

Although I do foresee the need to run all unit-tests in current namespace or for the seelected package, but from developers prospective I will need to run only those unit-test which are connected to the current project I'm working on. And for that I use Studio project (or would use separate Atelier workspaces once and if I'd migrate to Atelier).

So it's a proper approach IMVHO to start from project items and then add wider collections (package(s) or namespace wide).

Ok, ok, good point about PPG that it will remove reference to the object. And that simple local variable will work better, because it will not serialize OREF to string.

And the only case when it was workng for me - then the parent call is still presented in the stack, and still has reference to the originally created object. Which is exactly the case when %-named singleton would work (i.e. you open object at the top of the stack, and it's still visible in the nested calls).

So yes, we better to get rid of PPG and use %-named variables in our CPM code (pull-requests welcome)

Here are assumptions:

- you could not implement singleton which will be working across jobs, only for this same process;

- to share instance to teh object you could emply %-named variable or process-private global.

Here is the sample using PPG, which is easy to convert to % with redefinition of CpmVar macro

https://github.com/cpmteam/CPM/blob/master/CPM/Main.cls.xml#L33

OMG! Looks a little bit over-designed

On the other hand: if we would deal with SAMPLES and ENSDEMO similarly, and %ALL mapping  would work in SAMPLES the same way as for others, then leaving DOCBOOK alone would not make much sense :)

I'd prefer %ALL to work everywhere, without exceptions, that would significantly simiplify global mapping creation in some package manager you may be aware of.

Or better yet to disable this mode (removal of extra line breaks) globally in the Outlook:

[This is in Russian, sorry, but location of this element in the English version is the same, so you'll find it easily]

Feel free, Wolf, to request these features via GitHub repo issues , and, if you are brave enough, pull requests are very welcomed! This is open-source model, things might be changed easier (if you are really wanting them to be changed).

My guess that this sounds like result of some source control  hook activity (Deltanji?)...

Though, returning to the original question, I tend to agree with the recommendation to use ^GLOBUFF, because  of dynaic nature of a data in the Ensemble configuration. There is no hard data, but consistent statistics.

Ok, here is the simpler route:

1. if you have performance problems then run pButtons, call WRC, they will get "performance team" involved and explain you what you see :);

2. if you have budget for new HW then see item #1 above and ask WRC for advice.