Closed PhilLast closed 5 years ago
The filetypes are still unchanged from their originals. The current Dyalog-preferred alternatives are:
Dyalog | acre |
---|---|
.aplf | .function |
.aplo | .operator |
.apln | .script |
.aplc | .class |
.apli | .interface |
.array, .charstring, .charmat & .charlist remaining the same.
Changing the bit in acre's nameClass function will cause all .function, .operator, .script, .class & .interface files to be renamed the next time each project is opened. This will take a few seconds for a large project such as CAS and will probably entail rather a lot of messages unless the ]openproject
command is issued with the -m=off
option.
When?
I'd like that in before the user meeting if possible.
I'll commit and push this change but please be aware that it will entail a change to almost every filename in this project and any others you open and a message to say so. My comment above re. the -messages=off
option would be better as -m=#.whatever
that will stash all messages from the command into global variable #.whatever
including the opening messages that you always get - one of which is "Please wait ...".
So please wait. It's doing twice as much as usual. You'll see the project-space as usual when it's finished.
commit "New filetypes" @ 2018-10-25 22.30 UTC as version 4.8.1.036
@e9gille would this follow protocol better as a pre-release?
Doesn't really matter now but I've just switched the headings in the table above to put them above the correct columns.
Ohh, thank you very much!
would this follow protocol better as a pre-release?
I don't know. Arguably you could bump the minor version as it technically isn't a bug fix, but at the same time it isn't a breaking change (is it?). As I understand it, if I use the new version on a project, some files change extensions. Going back to a previous version of Acre would rename them back again, right?
Yes indeed!
The latest development build of acre is now able to read and potentially to write the enhanced standard Dyalog filetypes in addition to its own native types.
It won't write them until we decide a method to indicate which set a project is using.
We could make a decision that following a particular release,
CreateProject
will set an internal flag to force the standard on any new project.We could make such a flag public as a new configuration setting.
We could create any new sourcefile in a project as standard if any standard type exists in the source-tree but continue with the native types if not.
I do not envision turning off the ability to read the native types until some time after the renaming of files in response to the guidelines set out in the wiki is complete. I'm working on it.