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

Joel, I suggest you also add the Atelier tag to this posting. At the moment it's only tagged "Git" and I only found it by accident.

John Murray · Jun 23, 2016 go to post

Glad to hear that System Defaults are working for them. My main gripe with that mechanism is how cumbersome Portal's UI is for making the setting in the right place. Added to that, it's just too easy for someone to adjust a setting directly, filing the new setting into the production class where it (a) overrides the System Default and (b) propagates when the class gets transferred.

John Murray · Jun 22, 2016 go to post

Out of interest, are all other settings of the production's configuration items identical between DEV and PROD? Or are you using System Defaults successfully to ensure that, say, hostname/port of outbound target system is different in DEV versus in PROD?

Many Ensemble sites that use our Deltanji source control tool to propagate code from DEV to PROD choose to exclude the production class itself from that workflow. Some maintain multiple variants of the class, e.g. one for DEV and another for PROD, versioning each variant only within its own environment, and using a diff tool such as Beyond Compare (which Deltanji integrates with) to propagate applicable production changes from DEV to PROD.

John Murray · Jun 21, 2016 go to post

Their client app is a GUI built in MSM-Workstation, correct? And presumably this app is talking to Caché using the InterSystems VisM.ocx, right?

Assuming VisM.ocx dispatches a double-precision value using the correct datatype, maybe MSM-Workstation's COM handling code doesn't deal with that datatype correctly.

Can they test VisM.ocx in a different client to see if it works there when retrieving their double-precision property?

John Murray · Jun 21, 2016 go to post

Maybe modify the simplified rule you showed above, so it includes only the first of the 3 constraints. Then repeat with only the second. Then with only the third. Does this pinpoint only one constraint failing? Or do all three fail independently?

What Ensemble version are you using?

John Murray · Jun 14, 2016 go to post

As well as the suggestion of using a process-private global, Tim flags up an important point here. The $ORDER technique only enumerates public local variables.

John Murray · Jun 14, 2016 go to post

Here's a sneaky way to use a NEWable and SETtable system variable to cache your "safe" variable name in:

 new $etrap
 set $etrap=";"_..GetNewVarName() ; semicolon prefix makes the $ETRAP into a valid line of code (i.e. a comment)
 set @$extract($etrap,2,*)=""
 set @$extract($etrap,2,*)=$order(@@$extract($etrap,2,*))

You need more than one "safe" variable? Use subscripts of the one you've grabbed:

 set @$extract($etrap,2,*)@(1)="Some more info I need to store"
John Murray · Jun 14, 2016 go to post

I use Serenji. I can start interactive application debugging direct from the Terminal prompt. For a CSP or Zen based web app I can launch my pages in the browser and immediately start stepping through code, or running to soft breakpoints (no changes needed in my source). I can attach to background processes. I can set conditional breaks (e.g. break when variable ABC is set to value 123) or delayed breaks (e.g. stop the tenth time I get to this point). And with the Ensemble edition I can replay sessions command-by-command in a uniquely powerful way.

Disclosure: I created this tool in 1998 and continue to maintain and support it, so you should probably look to others for a more objective opinion of its value. Or try it free for 30 days.

John Murray · Jun 9, 2016 go to post

I think your code is vulnerable to a <MAXSTRING> error in the case of records with a large number of long values.

How about this instead, which might be a bit faster too?

set crc = 0
for i=1:1:in {
 set crc = $zcrc($char(i#256)_in(i), 7, crc)
}
return crc

Prefixing the input string to each $zcrc call with a character derived from the argument position number is intended to prevent us getting an unchanged CRC in the event that a substring has been removed from the beginning of one argument and appended to the previous argument (or removed from the end of one argument and prepended to the next argument)

The #256 is probably overkill because (a) you might be on a Unicode instance of Caché and (b) it might not even be possible to pass more than 255 arguments to the method (I haven't investigated).

John Murray · Jun 7, 2016 go to post

Maybe try "upgrading" you Cache instance to the same version as you already have?

John Murray · Jun 7, 2016 go to post

Compact view is nice, but I wish the UI would remember my preference for it. Instead, as soon as I reload the page it displays normal view.

John Murray · Jun 6, 2016 go to post

When you write "no process kill command affects it", are you referring to commands issued from within Ensemble Portal or perhaps command prompt?

Also, what is the $ZV string of your Ensemble?

John Murray · Jun 3, 2016 go to post

Now it becomes clear!

I had wondered if your requirement for "string" was that it contained only printable characters. In such a case one solution could be to base64-encode the result of $listbuild. On a Unicode instance of Caché you'd need to convert it to UTF8 first.

USER>s list=$lb($c(0),$c(1),"Hello",",","World")
 
USER>s printable=$system.Encryption.Base64Encode($zconvert(list,"O","UTF8"))
 
USER>w printable
AwEAAwEBBwFIZWxsbwMBLAcBV29ybGQ=
USER>s list2=$zconvert($system.Encryption.Base64Decode(printable),"I","UTF8")
 
USER>w list2=list
1
USER>w $a($li(list2,1))
0
USER>w $a($li(list2,2))
1
USER>w $li(list2,3)
Hello
USER>w $li(list2,4)
,
USER>w $li(list2,5)
World
USER>

Note that Base64Encode adds a CRLF after every 76 characters, so if you want to remove these from your "printable" you can either $TR(printable,$c(13,10)) or on 2015.2 or later you can pass a second argument to Base64Encode.

John Murray · Jun 3, 2016 go to post

I don't understand what you mean by "until the list values may contain any set of characters".

Nor do I understand the purpose of the second line of your terminal transcript above. None of your subsequent lines do anything with your local variable called list

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.