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 11 forks source link

Batch setting/loading of file info for preloaded functions #531

Open dyavc opened 1 year ago

dyavc commented 1 year ago

Is your feature request related to a problem? Please describe. If you use link preloaded option to link in many files, file information of the functions is not known or used by Dyalog.

Describe the solution you'd like The customer would like the ability to batch set/load in file info for preload functions perhaps as a link option. The file info was obtained by 5177⌶.

Additional context Emails from customer. I have changed the name of the company to MyCompany: Essentially, when you use ⎕FIX to load a function from file, the interpreter stores some metadata in an internal space. One can query this data (or remove it) using I-beams (5176, 5177, 5178 and 5179).

Link uses []FIX to load files into a session, but at MyCompany we don’t want to do that as it is too slow with the number of files involved. What we do is attach a number of dwx files and then establish a link with a switch that essentially tells link to skip all syncing operations and assume that the session is synchronised with the file path specified. Effectively we only want it to activate the file system watcher to pick up on changes in the file system and write back changes in the session.

At the moment we do that by using the metadata we stored (as a map between function name and filename) and a Link hook (getFilename) which works well. If we were able to put the metadata back into the interpreter we wouldn’t need to do the lookup ourselves, it could be done by the interpreter. Also, the interpreter would show the filepath in the caption when opening a linked file, which it doesn’t at the moment because we never used ⎕FIX to load it in.

So, when we build a code file we do:

  1. ⎕FIX source code
  2. Extract metadata with 5177 I-beam and store in variable: filemeta ← 5177⌶⍬
  3. Clear internal metadata with 5178 I-beam
  4. Create dwx file

When we start a new development session we would like to:

  1. Attach dwx file
  2. Update file paths in filemeta (repository root on developer machine may differ to where it was built).
  3. Create link with -preloaded switch
  4. Load the metadata into the interpreter, perhaps using an I-beam, eg: 5180⌶filemeta or maybe as an optional parameter to link

Here is what the code looks like when establishing the link:

⎕←'Establish link' opts←⎕NS'' opts.flatten←1 opts.preloaded←1 opts.codeExtensions←,⊂'aplf' opts.getFilename←'⎕SE.MyCompany.LinkHandler' opts ⎕SE.Link.Create #(root,'src')

First email: we build shared code files (dwx files) from source files in a build step. We keep the metadata returned from “List Loaded File Objects R←5177⌶Y” in a variable called ∆FILEINFO in the dwx file.

Later we attach these in a new development session and re-establish a link with a “-preloaded” switch, to prevent Link scanning the file system. Now, it would be nice if we could also load the metadata we tucked away in ∆FILEINFO, so the counterpart of I-beam 5177. That way the interpreter would know that the functions in the workspace are linked to external files and be able to show the file path in the caption of the editor when opening a function.

Would this be possible to add?

dyavc commented 1 year ago

The customer may have a way of achieving what they want with relative paths, email 23 May 2023.