All
Accepted answers
John Murray · Jun 2, 2016 go to post

Looks like we now have HTML formatted digest emails. Was that new in the May 30 update?

John Murray · May 31, 2016 go to post

Did someone forget to sign the Windows kits? When I use the 64-bit Ensemble one on my Windows 8.1 machine I was warned that the EXE came from an unknown publisher.

Examining the Properties dialog for the EXE I see this:

By comparison the one for build 645 has a "Digital Signatures" tab with an ISC entry:

John Murray · May 27, 2016 go to post

Amit, you have tagged this as "Developer Community". Perhaps you originally posted it to the group, which as I understand things is primarily intended for feedback about this online forum, https://community.intersystems.com

I think that posts to that group are intentionally not shown on the homepage feed of new postings.

It looks like it's now in the HealthShare group, but maybe changing its tag will help other people find it and respond.

John Murray · May 27, 2016 go to post

Murray, the documentation section you link to recommends excluding certain directories as well as specific files. This makes me nervous, as having a scanning exclusion on an entire directory surely offers a safe haven for malware to write a payload that it subsequently executes. Can you explain the reasons for excluding entire directories?

John Murray · May 26, 2016 go to post

"Ask and it shall be given unto you" - nice to see that page has now been updated.

John Murray · May 23, 2016 go to post

Here's one change I'm particularly pleased to see:

Ability to Create Namespaces that are not Enabled for Ensemble
In certain circumstances, it is useful to create namespaces that are not enabled for Ensemble. In this release you can do this by clearing the Make this an Ensemble namespace checkbox when creating a new namespace. 

John Murray · May 13, 2016 go to post

Maybe revise the message to read "Package name can contain dots but cannot start or end with a dot", or something similar.

John Murray · May 12, 2016 go to post

Thanks for your explanation Mark.

Interesting to know that the ZZW command was removed, leaving only the full-form ZZWRITE one. Our Command Line Extensions implemented ZZW and ZZWRITE as synonymous. Your ZZWRITE implementation takes precedence over our ZZWRITE but at least our implementation remains accessible via ZZW.

Ideally you guys would establish a policy one way or another, document it, then stick to it going forward, applying the rule consistently to commands, functions and system variables. In the past you've typically added Z* things but not ZZ* things, for example $ZCLASSMETHOD().

John Murray · May 12, 2016 go to post

Thanks for posting this. I shall try and remember to use the link routinely for my exploration of the docs, as a way of testing the beta.

John Murray · May 12, 2016 go to post

Yes, a useful command but I think it's inconsiderate of InterSystems to be annexing the ZZ* command-space. The facility for sites to extend the language with their own commands by writing a %ZLANGC00 routine (see here) has been useful and we at George James Software have for many years offered a free download called Caché Command Line Extensions. We deliberately made all our commands begin with ZZ in an effort not to clash with future InterSystems extensions, but our ZZW extension was subsequently overridden by the ZZW command InterSystems added in 2013.1. It seems it's only a matter of time before you sequester other commands from us.

John Murray · May 11, 2016 go to post

For the information of anyone watching this thread, 1.0.158 appeared on the update site within the past 24 hours. It resolves the huge icon issue, and probably contains some other goodies too.

John Murray · May 11, 2016 go to post

For those of us outside InterSystems, 1.0.145 and 2016.2.0.645 are the latest versions currently available.

EDIT: I typed too soon. It turns out 1.0.158 was published on the update site overnight. Maybe Mike's problem will be resolved by him updating to that.

John Murray · May 10, 2016 go to post

Any idea when we can expect the next update? I don't mind the oversize menu icon, but it's more than two weeks since "Check for updates" in Atelier gave me anything new.

John Murray · May 10, 2016 go to post

Nice article. One comment: I get nervous when I see code that swaps namespace without taking steps to swap back again afterwards.

John Murray · May 3, 2016 go to post

Travis, are you aware of our well-established native Caché/Ensemble/HealthShare source code management and deployment tool? Previously known as VC/m, it's now called Deltanji.

As well as dealing with code versioning Deltanji also handles deployment. It integrates with Atelier, Studio and Portal.

Some members of this Developer Community may be willing to share their experiences of using our tool.

Perhaps you have specific reasons for wanting to go with Git, but it might be worthwhile considering Deltanji as an alternative route.

John Murray
George James Software

John Murray · May 3, 2016 go to post

Maybe your code at someLabel^someRoutine in OTHERNAMESPACE calls another routine that exists only in OTHERNAMESPACE. In that case, the <NOROUTINE> error will occur when the call is made. That's because when you d someLabel^|”OTHERNAMESPACE”|someRoutine(inputVar,.resultByReference) you are fetching the routine someRoutine from the database of the OTHERNAMESPACE namespace, but you are executing that code in your current namespace.

This is not the same as swapping to OTHERNAMESPACE, running the code, and then swapping back. For example, if someRoutine accesses globals it will do that from whichever namespace is current.

To see an example of this, try the following:

SAMPLES>w $zv
Cache for Windows (x86-64) 2016.2 (Build 636U) Wed Apr 13 2016 20:58:35 EDT
SAMPLES>d main^lookup
 
Lookup: 1-jan-2016...finding birthday...no matches
Lookup:
SAMPLES>zn "user"
 
USER>d main^|"SAMPLES"|lookup
 
Lookup: 1-jan-2016
<NOROUTINE>main+27^lookup *datent
USER 4d1>
 
USER 4d1>q
 
USER>

The code in main^lookup in the SAMPLES namespace calls $$validDOB^datent. When this is attempted from the USER namespace we get a <NOROUTINE> error. Notice that the extended information in the error tells us that the routine it can't find is datent.

John Murray · Apr 29, 2016 go to post

The port info is also available from the "About" link at the top of Portal:

John Murray · Apr 25, 2016 go to post

I suggest you use the %IsA classmethod that every class inherits from %Library.SystemBase.

With this I think your method becomes very simple:

 quit $classmethod(className,"%IsA",..#UTCLASS)

John Murray · Apr 21, 2016 go to post

That doesn't look right. Here's what I get from "Add to Project" off inspector.csp in the /csp/samples app in my SAMPLES namespace:

 

On that first dialog I choose the project to import to (GS2016). The next page looks like this:

 

I'm using Atelier 1.0.141. What build is yours?

John Murray · Apr 21, 2016 go to post

How about using the Server Explorer view in Atelier to locate the CSP file, then right-clicking and choosing "Copy to Project" ?

Incidentally on my Atelier (1.0.141 on x64 Windows) there's a noticeable lag (about 5 seconds) between the right-click on the CSP file and the appearance of the context menu.

John Murray · Apr 21, 2016 go to post

I agree about the value of Studio projects. Our Deltanji source code management product (hint - Solo edition is 100% free) is able to generate Studio projects automatically that match the Deltanji Change Requests which represent the enhancements/fixes you're working on and propagating through your dev/test/deploy cycle.

John Murray · Apr 21, 2016 go to post

Somewhat related to this, I think there's still a useful role for %Studio.Project projects as ad-hoc server-side collections of classes etc that can be assembled independently of your package hierarchy, which typically has to remain far more static. But it's not yet clear to me how these projects (which after all are more correctly called "Studio projects") will evolve/mutate/expire in the brave new world of Atelier.

John Murray · Apr 12, 2016 go to post

Thanks to James for a prompt and detailed reply to my breakfast table question. Here I'm going to add this link to a previous posting of mine about %ALL, in part to highlight that %ALL mappings don't apply to 100% of the namespaces you have. The DOCBOOK and SAMPLES namespaces are apparently exempt. I can rationalize the DOCBOOK extension to myself, but the SAMPLES one puzzles me, especially given that the ENSDEMO namespace of an Ensemble or HealthShare instance is not exempt even though it's effectively another "samples" namespace.

John Murray · Apr 8, 2016 go to post

I found the same, i.e. clearing cache was necessary but after having done that my FF no longer stops responding when I go into the tags field of a new post.