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.
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?
"Ask and it shall be given unto you" - nice to see that page has now been updated.
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.
Maybe revise the message to read "Package name can contain dots but cannot start or end with a dot", or something similar.
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().
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.
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.
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.
In Atelier go to Window\Preferences and add a software site (I called my entry "Atelier") pointing to https://atelier.artifactoryonline.com/atelier/atelier-beta-1.0/
After saving that, use "Check for Updates" on Atelier's Help menu. You should be offered the update.
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.
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.
Nice article. One comment: I get nervous when I see code that swaps namespace without taking steps to swap back again afterwards.
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
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.
The port info is also available from the "About" link at the top of Portal:
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)
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?
$NAMESPACE arrived in 2010.1 (or at least, that's when it was first documented). Compare http://docs.intersystems.com/cache20101/csp/docbook/DocBook.UI.Page.cls… with http://docs.intersystems.com/cache20091/csp/docbook/DocBook.UI.Page.cls…
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.
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.
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.
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.
Thanks. Keep 'em coming!
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.
Given that John Willeke reports the "+" feature arrived in 2016.1, is that version of Ensemble also affected by this bug? I don't currently have a 2016.1 Ensemble to test.
On my Atelier (1.0.131 on Windows) I have a Server Explorer view on the Atelier perspective:
As well as offering + and x buttons with which to add and delete connections, it also gives me access to the properties of a connection for amendment.
If you don't have the Server Explorer tab visible, look for it as an option on Window\Show View
Francis, I think the idea of the "Developer Community Feedback" community/group is to discuss the behaviour of this community.intersystems.com website software.
I think your posting belongs better in the "Caché" community/group because that is the base product from InterSystems in which COS is implemented, and upon which Ensemble, HealthShare and DeepSee (which each have a separate community/group) are built.