See Robert's answers. The %File.Writeable(...) method's underlying implementation ($zutil(140,12,filename,2)=0) is apparently not able to determine whether or not a directory is writeable, despite the method doc stating "Return true if the file/directory is writable and false if it is not"

See this older doc for $zutil(140) information.

You could try raising the issue with InterSystems WRC, but my guess is they'll say it's a bug in the comment on the method.

Good point Jon. Here's a concrete example, taken from the CheckLinkAccess classmethod of %CSP.Portal.Utils (2017.2 version). I have done the macro expansion myself and highlighted the expansions:

  Set tHaveAllRole = 0
  Do 
  . New $roles
  . Set $roles=""
  . If ($extract($roles,1,$length("%All"))="%All") Set tHaveAllRole = 1
  If tHaveAllRole {

  ...

I just had this happen, but not on Mac. I'm using Eclipse Oxygen on Windows 10 (64bit), with Atelier 1.1.391.

Things were working fine, then I restarted Eclipse and found my connections to servers were failing. When I used "Edit Connection" and clicked the "Test Connection" button I got this:

Restarting Eclipse didn't resolve it, nor did "Check for updates" find anything out of date. So I used Help\Install New Software, chose the repository I'd previously installed Atelier from (https://atelier.artifactoryonline.com/atelier/updates/beta/latest/), cleared the "Hide items that are already installed", then selected both "Core" and "Optional" and clicked "Next". Eclipse reported that most pieces weren't needed, but it did install one, which I think was "TM Terminal via Remote API Connector Extensions".

When it had finished it told me to restart Eclipse, and now my connections worked.

Evgeny was too modest to mention that he excluded himself from the awards on the basis that it's sort of his job to make lots of contributions to DC. The raw data shows just how prolific he is in doing that.

A minor quirk in the table is that "DC Expert 2017 - 4th-10th places" only lists 6 names rather than the expected 7. But looking at the raw data I see that 2 authors tied for the position below Rubens Silva. So I guess either they both get the badge or neither does.

The superserver port is recorded in the cache.cpf file, and I think it can be changed there by simply editing the file and then restarting Cache.

I'm guessing that the Cache installer uses the registry to discover the locations of the CPF files it needs to check when picking a "free" port to offer as the superserver port for a new instance. So if one of your instances wasn't properly registered at the time you installed another instance then the installer may have defaulted to a port that was actually already taken.

There's some documentation here.

In your case it sounds like a Cache instance was moved onto the server but not added to the registry that Cache's ccontrol command uses. On Windows I think Cache uses the Windows Registry. On other platforms it uses a file, and offers commands ccontrol create, ccontrol update and  ccontrol delete to maintain entries in this registry.

Alex, if you code it as an instance method (private or public) then you won't be able to call it from a classmethod (private or public) unless the caller has (or creates) an instance of its class. In other words, the decision about whether to code an instance method or a classmethod is surely independent of the decision about whether to mark that method private or public, no?