Closed PaulMansour closed 5 years ago
The reason it is so complicated is that the dynamic loading of Link's code has to be worked into the session file without harming existing code that uses the involved event. Once it is installed, assuming we don't change these auto-loading procedures and formats, updating is simply a matter of placing text files in [DYALOG]/StartupSession/Link/ and for the user commands, in [DYALOG]/SALT/spice/
You can even set up your system to pick these things up from a location outside the Dyalog install folder. If you do this, all you need to do is a git pull and restart APL.
Why not just load the code within the user command framework? It seems the workspaceloaded is a very round about way to get the code in. Also, the link code is distributed as text files currently, which makes loading a little awkward. Any reason not in a .dws?
The user command framework works via the WorkspaceLoaded event, but additionally requires SALT (well, and user commands), and anyway cannot load utility functions. (The Link user commands are just an interface.)
The whole idea of Link is moving to text file based development instead of workspaces. It would be a bit ironic if it was done using a workspace ;-) Link is actually loaded using a pretty lightweight function which for 18.0 is planned to be the basis of a whole new system of auto-loading resources.
Further to that, several of the early adopters are actively using the GitHub repository to report issues and pick up changes. An important goal is to make it possible to install Link (and in the future, other tools) in such a way that all you need to get the latest / a specific / version of the tool is to issue the right Git command.
I was just going to ask if the use of the folder name 'StartupSession' and file name 'startup.dyalog' was an indication of some new feature for auto-loading, and so it is. That great, looking forward to that.
So the user commands also use the kluge of the workspaceloaded event, presumably because there was no way to auto-load resources? Will alll this be cleaned up in v18?
Regarding text files vs workspaces, don't throw the baby out with the bath water. The whole point of Link is text file based development not text file based distribution of runtime code. A user command can easily QuadCY in code.
Do you really want the entire git repository for a tool, for every tool, in your Dyalog installation folder?
Also a tool or app can have a significant number of small files, which is very good for development, but very bad for distribution.
So the user commands also use the kluge of the workspaceloaded event, presumably because there was no way to auto-load resources? Will alll this be cleaned up in v18?
There still is no other way, but we are considering making the startup procedure independent of the event. This may or may not go into 18.0. I doubt we'll have the resources to change the user command system in time for 18.0, though.
Do you really want the entire git repository for a tool, for every tool, in your Dyalog installation folder?
The startup procedure already allows auto-loading things from any location.
Also a tool or app can have a significant number of small files, which is very good for development, but very bad for distribution.
I only spoke of development. However, I know of plenty of (closed source) applications where non-core functionality is delivered in a host of text files. This makes it much easier for people to modify the behaviour of the application to suit their needs.
The startup procedure already allows auto-loading things from any location.
I mean do you really want to do a git pull of the repository when you are a consumer of a tool or app, rather than download some release artifact. Do you really want all the unit tests, the test files, and all of the stuff needed for development.
There still is no other way, but we are considering making the startup procedure independent of the event.
Do you know why the user commands (and link) rely on the WorkspaceLoaded event vs the Create event? It seems the latter would be much more appropriate. Is there some downside to using onCreate to initialize stuff in the session?
Oh my, the session font initialization and change events are run through the workspaceloaded callback. Nice.
The installation process is, shall we say, somewhat onerous. I realize that Link will come preinstalled with 17.1, but I assume an update to Link in 17.1 might not be the easiest thing either. No doubt there is much I don't understand about it.
But, is there any reason the installation of any user command requires more than the appropriate placement of a .dyalog file and possibly an associated folder full of stuff?