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

Add a file crawler in background as backup for FileSystemWatcher #88

Open mkromberg opened 5 years ago

mkromberg commented 5 years ago

FileSystemWatcher mechanisms are fundamentally unreliable on all platforms. A mechanism needs to be added to periodically scan the file system for events which have been lost.

nicolas-dyalog commented 4 years ago

related to #120

nicolas-dyalog commented 4 years ago

Requires fixes to :

bernecky commented 3 years ago

I assume that Morten's assertion of 2019-07-30 is correct. Given that, here is a possible workaround, based on (MY) user habits during development and debugging in a unix/linux environment. I assume that )ed and friends work correctly, and update any linked host system files when the editor exits. Hence, we need concern ourselves only with someone tinkering a file folder from outside APL.

I try to use one text editor (vi/vim) for all my work, as it facilitates my typing habits, muscle memory, etc. So, my workflow is, with APL being the APL session, and LINK being an xterm or other command prompt doodad:

  APL:  foo 42
domain error foo[2]

  LINK:  vi foo  
    [fix the error]

  APL: )reset maybe 
      foo 42
1 2 3

Morten's problem arises at the above LINK->APL window change, by me and my mouse.

This suggests that, if APL (RIDE?) can detect the arrival of the cursor in the APL window, or even a change in focus to the APL window, that is (for me) an adequate trigger for looking at file timestamps in LINK. Just once.

I think that is sufficient unto my day. Am I missing something? If so, let's look elsewhere:

I have no idea what ]link behavior is defined, or desired, when a host-side-edited function changes, but the function is on the execution stack. If I recall correctly, the function on the stack is decoupled from the one in the workspace, so nothing appears to change (for the APL session) until the stack is empty of that function. Hence, function exit could trigger the LINK timestamp search. Not a good idea from a performance standpoint.

However, return to immediate execution could trigger a LINK timestamp search, with much less overhead.

I am not enthused with an egg-timer approach, in which the interpreter would "periodically" do the LINK timestamp check. If done too frequently, then APL is bashing disk/network every second or so. If done infrequently, a function that I Know Has Changed does not appear in the APL namespace when I want.

I think I want a focus-change-detection-based approach.