dyalog / link Goto Github PK

I ran the QA tests which passed successfully. After that I tried XLOADing a ws and saw the folowing warnings in the session:

      )xload C:\devt\svq\SVQ_12_124.dws
C:\devt\svq\SVQ_12_124.dws saved Tue Apr 12 11:33:15 2016
c:/src/trunk/SALT\core/Import.dyalog cannot be found
c:/src/trunk/SALT\core/Fix.dyalog cannot be found
c:/src/trunk/SALT\core/FileSystemWatcher.dyalog cannot be found
c:/src/trunk/SALT\core/Export.dyalog cannot be found

Any idea what causes this?

]link #.mySpace /my/path.on/disk
results in content written to
/my/path/on/disk/

It appears that deleting a directory causes a flurry of callbacks to APL, some of which are lost, and lead to a hang when the FileSystemWatcher is finally deleted.

Some changes to the active workspace cannot be detected by the ]link mechanism. The user command should provide a way for a user to explicitly add or remove source code links, for example:

]link -define=dfn←{⍺+⍵}
]link -expunge=myns
]link -rename oldns=newns

The examples in the Link.Test class need to be updated to use the syntax documented on the wiki - and the calls to them need to be adjusted accordingly.

If an external editor is used to change the name of a function (or operator) defined in a file which is being watched, then both the old and new function will exist, and both will be linked to the same file.

Setting the onBeforeRead option causes many operations to fail.

APL functions are linked to individual files with "flatten" option. We invoke Link.EditorFix via an AfterFix event.

If we change a function name in the Editor we expect to get:

• 2 functions in the workspace
• each of these are linked to it own file
• both files are located in the same folder as the "source" function.
• Only the new function and the newly created file is modified.

The new file will be seen from Git as "untracked".

UCMD.Export (

]link #.MyApp C:\devt\MyApp
)ed MyApp.MyNS.foo

looks for link, finds MyApp, then checks NC of MyApp.foo instead of MyApp.MyNS.foo

It should create file structure with case code suffix, both on folders (namespaces) and files.

If you attempt to move a variable from one namespace to another by moving the source file from one folder to another (and you are watching the folders), the variable will appear in the new namespace, but it will not be deleted from the old one.

When a new function is created, we invoke Link.EditorFix via an AfterFix event.

We will like to have a file stored in root of the linked repository folder. The file shall be linked to the new APL function in workspace.

Seen from Git, this file will the be "untracked".

Note: We use "flatten" and save individual APL functions ( 3=⎕NC) in separate text files.

I )CLEARed and then attempted re-running the link cmd only to find that it was still active.

Expected to see an automatic reset of all links. Is that reasonable?

Editing a ]link'ed class and renaming it causes loss of the source code.

Unlike the IDE, it does not allow the user to choose not to be asked again.

Link should implement a prototype of the proposed "Array Notation Mk III", as described in Adams Belfast Presentation

    ⎕SE.Link.U.Serialise'test',⎕UCS 13
('test')',(⎕UCS 13))

See also #37.

It is confusing to have all these specifications. A single 2-column matrix based on the current typeExtensions is enough. All extensions listed in the right column will be considered as code extensions, and additional custom extensions (which still require custom handlers beforeRead and beforeWrite) can be listed with ¯1 as their type, while 0 indicates "everything else".

Link will scan down the first column to find a compatible entry. E.g. for tradfns (3.1=⎕NC), Link will use the first found of 0 (everything else) 3 (functions) 3.1 (tradfns).

The default extensions will be:

Some operations fail with VALUE ERROR Undefined name: customExtensions.

We often use a setup, where a large number of APL functions are stored in a shared code file.
All functions are in root namespace

When we link to files with "flatten" option is takes a very long time compared to when all functions are in stored directly in the work space.

Two workarounds can be used short term:

1. Call Assimilate Shared Code Files (8666⌶⎕NULL) before calling ]link
2. Use ⎕EX to delete the functions etc. before calling ]link

If a directory is renamed, the corresponding namespace is correctly renamed but the links of objects withing the namespace still point to the old files.

Fixed in 38157bb.

Fixed in 07eaf08

There is ⎕ML-1 dependent code in EditorFix, which fails if you set ⎕SE.Link.DEBUG to 2 and then edit a function:

RANK ERROR
EditorFix[70] (1+⊃⎕LC)⎕STOP⊃⎕SI
∧

After ]link -reset, 0≠⍴5176⌶⍬

Try the following:

Create a class and put anything you want in it:

      )ed ○class

Then execute the following:

      ]link # d:\trash\wrapper\source\
 # linked to d:/trash/wrapper/source/ 
      )ed class
      ]link -reset
 Link from # to d:/trash/wrapper/source/ removed (2 names affected) 

Now try:

     )ed class

again... Surprise! The script is gone!

Make it easier to perform common operations like creating a new source folder or loading an existing one into the workspace, without having to provide lots of switches. For example:

]link create myns c:\sources\myns

Would validate that the target folder is empty and suitable for use in a new project.

[]EX and []FX (and probably also []OR and others) breaks the linking to files.
The APL must give an (optional) warning when a link is broken

]link # C:\devt\myapp
)ed MyNS.foo

As MyNS is not linked, it searches up the tree until it hits root and then bails out before picking the link.

I note that the Readme mentions that having automatic updates to the workspace based upon filesystem changes and additions only works under windows.

Note that both xnu (the darwin/osx kernel) and the Linux kernel provide for userspace notifications upon changes to specific files/directories. So it should be possible to implement equivalent functionality on those platforms.

However, maybe this requires changes in the backend APL interpreter process, rather than in this codebase?

⎕EX of a linked object does not remove the file. This should probably not be changed, but we could add a ⎕SE.Link.Expunge or Delete function which would remove and object with its file.

The environment variables DYALOGSTARTUPSE and DYALOGSTARTUPWS should be lenient regarding trailing slashes.

If you ]Link.Create based on files with .dyalog suffixes, then ]Link.Break and ]Link.Create again, duplicate files with .aplf are created for all functions.

If a file containing a class or namespace was edited externally to rename the class, this could lead to Link reporting that it had "lost track" and that the link needed to be broken and re-created.

If you edit a function which is being traced in APL, using an external editor like VS Code, then Link reports that the name of the function has been changed and temporarily loses track of it.

We discussed this, I know. I think we said "error if both ns and dir non-empty"

1. When first "exporting" dws content to file, target dir would be empty and there is no risk.

2. When loading into # from disk, we only need to signal error if # not empty.

Dyalog have elected a set of file extensions for their objects - these must be recognized by GitHub (and GitHub enterprise) - otherwise can the syntax highlighting not be used.

Please: make ]link (and its test suite) work in the classic interpreter. At the moment there are assumptions in the code. For instance: Test.onWrite (https://github.com/Dyalog/link/blob/master/Test.dyalog#L216) neglects to test for 82...

If links exist, )clear will remove them but )load will not. Subsequent attempts to use ]link may fail unpredictably.

⎕SE.Link.Fix doesn't receive the oldname from the ⎕SE.SALTUtils.EditorFix:

[64]			      →(args[4 6] ⎕SE.Link.Fix ⍬)⍴0 ⍝ If linked, returns 1

should be

[64]			      →(args[4 6 5] ⎕SE.Link.Fix ⍬)⍴0 ⍝ If linked, returns 1

If a function name is changed in the editor, then Link loses track of the source file.

#.MySpace.MyClass
]link #.MySpace /my/path -source=ns

MyClass not written to file.

Looks like the command is expecting a simple string but is called with a nested array.

Also, if bypassing the issue, it seems the resulting name has an extra / injected for no good reason.

We need to support multiple extensions that ]link will recognise as code, for example .dyalog,.apl, etc.

Repro: in a clear WS create an empty class, like aaa.
)ed ○aaa

Escape immediately to leave the class empty (the content is not relevant).
Then try and export the root:
]link.export # d:\trash\wrapper\src1
Exported: # → d:\trash\wrapper\src1

This is the content of the generated folder:

There are two files, and not one, as expected. And the one that is supposed to be aaa.aplc is called aaadyalog (no "." between name and extension and wrong extension).