Closed aplteam closed 5 years ago
I get this:
]?acre.Createproject
───────────────────────────────────────────────────────────
]ACRE.CreateProject
Create a new project
Syntax: ]acre.CreateProject folder space
https://github.com/the-carlisle-group/Acre-Desktop/wiki/Command-Reference#createproject
Ah, two "??" do the trick:
]??ACRE.CreateProject
─────────────────────────────────────────────────────────────
]ACRE.CreateProject
Source: C:\T\Projects\acre\acre.dyalog
Version: Syntax:
Accepts modifiers -casecode= -help -keephistory= -messages[=]
The default value of modifier 'casecode' is "off"
The default value of modifier 'keephistory' is "off"
Create a new project
Syntax: ]acre.CreateProject folder space
https://github.com/the-carlisle-group/Acre-Desktop/wiki/Command-Reference#createproject
But why is that?
Presumably Dyalog v17.0 changes. What about
]command -?
]command -??
and should I do anything about it? I'm guessing that the help
function in the command script gets the same argument whether ]?command
or ]command -?
is entered?
Acre's -help
flag has not been deprecated and merely returns the same as your ]?command
above without the additions tacked on by Dyalog.
It depends indeed on the version: 15.0 shows the flags and options with a single ?
while 16.0 and 17.0 require two. 17.1 on the other hand does not show anything regarding slags and options no matter how many ?
are specified...
There is indeed no difference in 17.0 between ]?foo
and ]foo -?
.
v16.0 certainly shows the flags and options with a single ?
. v17.0 may require more. But I should have thought that v17.1's omitting them entirely (apart from the slags) should be reported to Dyalog as a bug.
v16.0 certainly shows the flags and options with a single ?.
Not for me.
... should be reported to Dyalog as a bug.
Will do.
I'm still on
Version: 16.0.34994.0 64 Unicode
Created: Dec 13 2018 at 19:31:36
Build ID: 7edb0685
Serial Number: xxxxxx
and will await developments
I traced through the code and discovered that acre does not provide any help at all: it's all left to the user command framework.
What is displayed depends on ]udebug on
: in that case additional information is shown. That's why I saw different pieces of information in different sessions. Those sessions came from different versions of Dyalog, but that was just a coincidence. What matters is just the setting of ]udebug
.
I think you need to provide the information yourself.
acre does not provide any help at all
It certainly does. Look back at my first comment above.
The first block is provided by Dyalog in all circumstances up to and including Dyalog v16.0.34994.0. Its length is determined solely by the number of defined switches and modifiers.
The next two lines are assigned by the help
function within the command script while the URL is only available after the first acre command in a session because prior to that the help
function doesn't have that information at its disposal running without the presence of acre.
None of this depends in any way on any other setting.
I suggest you run one of your own user commands in Dyalog v15.0 and compare what you see on the screen with what your help function actually provides.
Misunderstanding: what I meant was the information regarding flags and options - that's provided by SALT rather than you, and SALT stopped doing it in 17.0 and 17.1 in case debug is off.
It's obviously not a bug because in the past it always reported those pieces of information but now the is a condition around that block, so it looks like a deliberate decision.
However, I have reported this as a problem to Dyalog (<01605>) for two reasons:
Providing additional syntax information when debug is ON does not make sense. Debugging and wondering over the syntax of a user command are totally unrelated things.
When I want to debug a user command then I certainly do not want it to behave differently in any respect other than a) stopping at the right place and b) switching off any error trpapping.
In view of the absence of a second response to our questions to Dyalog regarding the change to the display of help for user commands in the removal of the option syntax; where previously we had:
]?createproject
Command "ACRE.CreateProject". Syntax:
Accepts modifiers -casecode= -help -keephistory= -messages[=]
The default value of modifier 'casecode' is "off"
The default value of modifier 'keephistory' is "off"
Create a new project
Syntax: ]acre.CreateProject folder space
https://github.com/the-carlisle-group/Acre-Desktop/wiki/Command-Reference#createproject
Script location: "C:\Users\Phil\AppData\Local\acre\acre14.0\acre.dyalog"
but we are now to expect only the central block defined by acre; I've added the options with their defaults to the tailored output for each command:
Create a new project
Syntax: ]acre.CreateProject folder space -help -messages[=] -casecode=off -keephistory=off
https://github.com/the-carlisle-group/Acre-Desktop/wiki/Command-Reference#createproject
It would be useful at this stage to be able to remove the long-time redundant and deprecated modifier -messages[=]
to reduce the clutter.
Does anyone have any leftover calls to it that are being ignored other than in the acre tests? If so they'll cause an error when I remove it.
I don’t use it anywhere.
Neither do I.
Thank you. @PaulMansour ? @e9gille ?
I don't use it, happy for you to remove
Kai. Will this still be a breaking issue? Seems a shame to up the major vesion for such a triviality.
I wouldn't sweat it
Given the user base, and that it has been marked as deprecated for some months, I think it's okay not to. I am not using it anywhere, or if I do then the only way to be reminded is by breaking acre.
Also, the question is whether acre will ever become a package that is installed and updated automatically, or rather be something that is downloaded and installed like an application. I am not sure but if the answer is "appllication" rather than "package" then it does not make sense to enforce semantic versioning on it. (I sometimes wonder whether we should have a "real" installer for acre)
However, when it comes to real packages then thinking of major numbers as being related to small or large changes does not fit into the concept of semantic versioning. In semantic versioning a change of the major number has a clear definition, and whether the criteria is met by a small change or a big one really does not matter.
I know and understand why you feel that way, I felt the same more than once since we switched, but we need to educate ourselfes to get rid of this feeling when it comes to packages.
Thanks for the answer. Very clear.
Also, the question is whether acre will ever become a package that is installed and updated automatically, or rather be something that is downloaded and installed like an application.
I almost made the same comment but changed my mind when I considered that acre now has an API. The API in itself suggests semantic versioning should be enforced. Although, given the current user base I felt it wasn't worth it.
In theory, before an API exists you may as well use major version 0. Once established the major version should increase for a breaking change. I think in general you deprecate methods and collect the removal of them into "next major release" branches, to avoid bumping it too often.
Agreed: I forgot about the API.
]?createproject
cites both but the createproject section in the wiki doesn't mention-keephistory.
Is that what you meant? I'll ensure it does.