Page 1 of 1

Tidy up 'Most Recently Used'

PostPosted: July 18th, 2015, 2:48 am
by Ajay Askoolum
When I save a workspace, it is inserted into the 'most recently' used list that appears under the file menu. This is quite handy, as it allows me to re-load the workspace when I want to resume working with it.

However, when I drop a workspace that I loaded via the 'most recently' used list under the file menu, the 'most recently' used list still contains that entry.

If any given workspace has an entry in the 'most recently' used list and it is dropped, could you remove it from that list?

In fact, on starting APL+Win, could you tidy up the 'most recently used' list such that it contains just workspaces, read 'files', that still exist? (I could have deleted the workspace from Windows Explorer).

Also, if I )Load a workspace that does not physically exist, I get WS NOT FOUND. This is fine but the existing content of the session stays put. In other words, )load acted just like )copy, with the )wsid also being preserved. I would prefer a )load operation to start by clearing the active workspace and setting its names to CLEAR WS.

Re: Tidy up 'Most Recently Used'

PostPosted: July 18th, 2015, 11:00 pm
by Davin Church
Ajay Askoolum wrote:Also, if I )Load a workspace that does not physically exist, I get WS NOT FOUND. This is fine but the existing content of the session stays put. In other words, )load acted just like )copy, with the )wsid also being preserved. I would prefer a )load operation to start by clearing the active workspace and setting its names to CLEAR WS.

I don't know if I like this idea or not. I think that if )LOAD fails it probably ought to not change my environment (as it is now). The only reason I can think this would be useful is when automating APL commands under program control (which I sometimes do) with an ActiveX APL server (for instance). But in such a case I simply send )CLEAR before )LOAD and that gives me the same effect.

Did you have some particular need for it to be the other way (that I haven't thought of)?

Re: Tidy up 'Most Recently Used'

PostPosted: July 19th, 2015, 1:27 am
by Ajay Askoolum
I think that the MRU does need to be tidied up. I mentioned the load behaviour in the same thread.

For incremental changes to the workspace, there is )copy.
)load is supposed to replace the current workspace. Since failing to )load does not clear the workspace, I imagine that it )clears AFTER )loading. If so, it must be doing the other chores (such as )symbols) after )loading also. Would )loading be much faster if followed a )clear?

This is not vital. I mentioned it purely because it catches me quite often. During the 'work in progress' phase, I often have like named functions in different workspaces which I move. If my current workspace has a function and I want to run a like named function in another workspace (to refresh my mind on the previous behaviour), and do not notice that the )load failed, and then get caught.

I suppose most people have different sessions for working on parallel changes. I get caught out in this scenario also.

In a source control environment, I would have different generations of a workspace. Without source control, I use different copies of the workspace.

If I )load a workspace programmatically (which starts with a latent expression) and )load fails, the old context still continues execution. This is difficult to avoid (especially when )load has no return to indicate success or failure) unless a failing )load clears the current workspace.

Am I making sense?

PS: For )load read []Load as appropriate.

Re: Tidy up 'Most Recently Used'

PostPosted: July 19th, 2015, 6:33 am
by Garth Hutchinson
For []LOAD, at least, would not the fact that you dropped into the following instruction indicate thatLOAD had failed; and if CLEAR was done automatically, then there would be no following instruction? Or are you speaking of code in a ]USER command?

Re: Tidy up 'Most Recently Used'

PostPosted: July 19th, 2015, 8:07 am
by Ajay Askoolum
If the []load instruction fails, there is no follow up instruction by default:
Code: Select all
      ∇ A
[1]   ⍝
[2]   ⎕load 'C:\AJAY\APL+WIN\CSE\STRINGFORMAT\STRINGFORMAT2'
[3]   ⍳10
    ∇

      A
WS NOT FOUND
A[2] ⎕load 'C:\AJAY\APL+WIN\CSE\STRINGFORMAT\STRINGFORMAT2'
     ^
A runtime session will simply disappear. If I coded to resume on failure, thus:
Code: Select all
    ∇ A;⎕elx
[1]   ⎕elx←'→⎕lc+1'
[2]   ⎕load 'C:\AJAY\APL+WIN\CSE\STRINGFORMAT\STRINGFORMAT2'
[3]   ⍳10
    ∇

      A
1 2 3 4 5 6 7 8 9 10
I have no way of knowing whether the []load succeeded (it does not return a result) - unless I check for an object that exists exclusively in the workspace on the following line. If the []load succeeded, the following line is simply not there!
Code: Select all
    ∇ A;⎕elx
[1]   ⎕elx←'→⎕lc+1'
[2]   ⎕load 'C:\AJAY\APL+WIN\CSE\STRINGFORMAT\STRINGFORMAT'
[3]   ⍳10
    ∇

      A
C:\AJAY\APL+WIN\CSE\STRINGFORMAT\STRINGFORMAT SAVED 19 July 2015 08:06:07
In normal circumstances, I would expect that a latent expression in the loaded workspace takes over.
As I've mentioned, this is not vital. There is one advantage in the current behaviour: it loaves the current workspace intact giving me another chance to review the []load argument ... in case I misspelt anything.

Re: Tidy up 'Most Recently Used'

PostPosted: July 20th, 2015, 8:59 am
by Garth Hutchinson
I have no way of knowing whether the []load succeeded (it does not return a result) - unless I check for an object that exists exclusively in the workspace on the following line. If the []load succeeded, the following line is simply not there!


I think that was my point -- you can have code (instead of i10) that runs if it is unsuccessful; it it is successful, your []LX code runs.

Re: Tidy up 'Most Recently Used'

PostPosted: July 23rd, 2015, 5:42 am
by brent hildebrand
[1] MRU list - )drop leaves the name in the list. )wsid WS_Name without saving the workspace creates an entry in the MRU list.

[2] You can not clean up the MRU from the APL Development Session. When you close your APL session, the MRU reverts back to the old list with the new additions. If you write an APL program to cleanup the MRU in the development system, it must either run on the runtime interpreter or a development interpreter in another location that does not use the APLW.INI file for your development system

[3] attached is a little program with runtime interpreter (v15.0.0.1) that cleans up the MRU. NOTE - the development interpreter must not be running for this to ultimately succeed. ADF file not needed, just the EXE and W3. Just double click the EXE.

[4] load fails - I like the current behavior.

CLEANMRU.zip
(1.31 MiB) Downloaded 751 times