search

Dyalog / link

Source code for Link – the built-in component that enables the use of text files as the primary storage mechanism for APL source code
https://dyalog.github.io/link
MIT License
19 stars 10 forks source link

Installation #85

Closed PaulMansour closed 5 years ago

PaulMansour commented 5 years ago

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?

abrudz commented 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.

PaulMansour commented 5 years ago

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?

abrudz commented 5 years ago

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.

mkromberg commented 5 years ago

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.

PaulMansour commented 5 years ago

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.

PaulMansour commented 5 years ago

Do you really want the entire git repository for a tool, for every tool, in your Dyalog installation folder?

PaulMansour commented 5 years ago

Also a tool or app can have a significant number of small files, which is very good for development, but very bad for distribution.

abrudz commented 5 years ago

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.

abrudz commented 5 years ago

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.

abrudz commented 5 years ago

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.

PaulMansour commented 5 years ago

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.

PaulMansour commented 5 years ago

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?

PaulMansour commented 5 years ago

Oh my, the session font initialization and change events are run through the workspaceloaded callback. Nice.