search

the-carlisle-group / Acre-Desktop

A simple Dyalog APL IDE plugin that introduces "projects" and allows you to keep your source code in Unicode text files.
MIT License
11 stars 1 forks source link

acre with multiple installations of Dyalog #74

Closed aplteam closed 5 years ago

aplteam commented 6 years ago

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:

  1. 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.

  2. I write my own function doing the trick.

  3. 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.

??

PhilLast commented 6 years ago

On first thought it seems this would be easier to write if it were not actually an itegral part of acre.

aplteam commented 6 years ago

Agreed. I tend towards the installer.

e9gille commented 6 years ago

Are you considering all platforms for the installer?

aplteam commented 6 years ago

I did not. I am heading for Windows. I guess you ask because you want it to be platform independent?!

PaulMansour commented 6 years ago

Decided: Acre ws should not need to be re-opened to install over an existing install.

PhilLast commented 6 years ago

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. )LOADing 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 )LOADed the ws in the first place..

norberturkiewicz commented 6 years ago

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.

aplteam commented 6 years ago

From within a user command script one can at runtime address the full name of the script with

##.SourceFile
PhilLast commented 6 years ago

@aplteam So you can!