Closed aplteam closed 5 years ago
On first thought it seems this would be easier to write if it were not actually an itegral part of acre.
Agreed. I tend towards the installer.
Are you considering all platforms for the installer?
I did not. I am heading for Windows. I guess you ask because you want it to be platform independent?!
Decided: Acre ws should not need to be re-opened to install over an existing install.
Not easy to read and comprehend code not addressed for several weeks while trying to attend to a four-or-five-way discussion. So I've looked further into this.
Normally when a new release becomes available it should be necessary only to overwrite the workspace acre.dws
but definitely not the user command file acre.dyalog
which contains the paths from the installation in which it was created, viz. mine. )LOAD
ing the ws runs the Install
function that recreates acre.dyalog
with its own path coded inside. For this reason from now on I shall attempt to ensure acre.dyalog
does not exist in the release folder. Merging the new folder into the old will then be incapable of overwriting the local version.
But each time any command is added or removed or any change made to the scope, syntax, description or help of any command or if the location or name of the installation folder is changed it will be necessary to re)LOAD
the ws.
I can ensure that the release notes tell whether the )LOAD
is necessary but my guess is that in most instances it'll be less arduous just to )LOAD
the ws by clicking on it than doing the same to the release notes and actually having to read them before deciding whether you should have just )LOAD
ed the ws in the first place..
Is there any reason why the .dyalog command script cannot determine its own location and use a relative path to the .dws. It would make the whole process of writing a custom .dyalog file, on each machine, irrelevant.
From within a user command script one can at runtime address the full name of the script with
##.SourceFile
@aplteam So you can!
Currently acre installs itself just for the version of Dyalog the acre workspace was loaded with.
For me this is a pain because I have 8 different versions of Dyalog installed. It's not funny to fire up 8 instances and load the acre WS in all of them. Well, not all of them because we actually use acre 4 "only" in 15.0 (32+64) and 16.0 (32+64) and 17.0 (64 only for the time being) but still.
I can see three solutions:
acre works out whether there are more than just one version of Dyalog installed and if so asks the user if she wants to install just for the current version or all versions and then acts accordingly.
I write my own function doing the trick.
I write an installer that defaults to C:\Users\All Users\Carlisle Group\acre as installation folder. The installer could also enforce the correct name for the folder holding the WS.
It's not a big deal to implement [3], and it would make it much easier.
??