AllAccepted answers
Alexey Maslov · Aug 10, 2021

if there will be an error this won't change the namespace back even with the "new $namespace" command

It would be still "%SYS" inside the `catch` block, so it's unsafe to call any code in its context. Even if you write something like this:

 ...
 try {
   new $namespace
   set $namespace="%SYS"
   ...
 } catch ex {   // process the error
   set sc=ex.AsStatus()
   do ..logErr(sc) // do some debug logging
 }
 return sc

and the ..logErr() call will be successful (generated .int code was not split into parts), the global where the log goes should be the same for all namespaces (e.g. mapped via %ALL pseudo-namespace). There are so many complications that it seems better to avoid any error processing inside the `catch` block above returning the error code. BTW, it sounds reasonable in any case, not only in this one associated with %SYS.

Alexey Maslov · Aug 9, 2021

The key feature here is `new $namespace` command rather than the method of its changing, while `set $namespace="%SYS"` seems to be the preferred one as it is well documented and good looking.

I'd still use try / catch outside namespace changing as there can be security errors on attempt to do it. I mean something like this:

classmethod DoSomethingInSYS() as %Status
{
 set sc=$$$OK
 try { 
   new $namespace
   set $namespace="%SYS" 
   // do something, e.g. config change
 } catch ex {
   // process the error
   set sc=ex.AsStatus()
 }
 return sc 
}
Alexey Maslov · Jul 24, 2021

Jack, your results are easy to explain.  When you use $list*, you must perform conversion to string which adds extra cost.

When you check some conditions inside the loop, you add some cost as well, how much - it depends on checkup method.

So, the best results should be achieved with Robert's and Alex's approaches. I'd prefer the Robert's one as it doesn't force special processing of the first element.

Alexey Maslov · Jul 23, 2021

Thanks for the good advices, guys.
Robert, you should be aware that $zu(12) (a.k.a. $$$FileMgrDir) is usually not the same as $zu(12,""): 

QMS>w $zu(12)
f:\intersystems\cuni\mgr\
QMS>w $zu(12,"")
d:\bases\qms\

My writing was just a result of quick prototyping using the terminal. Just for curiosity, I dived into %occFile.inc and there was no macro to get the current directory. It is possible through class method call (##class(%Library.File).NormalizeDirectory("")), while all this stuff looks like a great overkill for such a small sample.

Alexey Maslov · Jun 23, 2021

I should be more specific in formulating the question.
So, attempt #2:

  • We used server-side source control in Studio just for having additional menu items, not for source control itself;
  • Now, after switching to VSCode, we started using "normal" client-side source control based on GitLab;
  • What I want is to revive those additional menu items I was able to add using Studio.

...And I don't see how to achieve it as the server-side source control menu is only active on "server-side" WorkSpaces, while client-side source control is not available there. 

I'm not sticking to this way of adding menu items to VSCode, it just seemed that it will be the easiest one.

Now I see that how wrong I was. Any idea of how to add menu items (with associated server commands) would be appreciated.

Alexey Maslov · Jun 21, 2021

Thank you all for the quick responses, but: from all the server-side source control functionality I used only the possibility to extent Studio's menu by adding items to the source control menu. E.g.

XData Menu
{
<MenuBase>
<Menu Name="%SourceMenu" Type="0">
<MenuItem Name="My item 1" Save="100"/>
<MenuItem Name="My item 2" Save="100"/>
...
</Menu>
<Menu Name="%SourceContext" Type="1">
<MenuItem Name="My item 1" Save="100"/>
<MenuItem Name="My item 2" Save="100"/>
...
</Menu>
</MenuBase>
}

Can I implement something similar with VS Code?

Alexey Maslov · Jun 9, 2021

Methods how these macros are defined are quite different: $$$ISWINDOWS is calculated using system call and always 1 on Windows platform, in contrast $$$WindowsCacheClient is defined manually, so it and can be easily set to 0 if needed.

Many years ago I faced a problem with LDAP which was solved this way (I didn't change ISC code, it was my own "fork"). Don't remember other details, only the fact.