Wiki is missing information on how/when variables are tracked

[PhilLast]

Currently acre tracks all items in a tracked project having ⎕NC in 2.1 3.1 3.2 4.1 4.2 9.4 9.5 and scripted 9.1 and having been changed in the editor - including those changed by the ]EditArray command - or stored by ]SetChanged.

The document "Link-Acre gap analysis" produced for the hackathon mentioned the tracking of arrays as having been agreed to be on-demand only but this appears to be referring specifically to Link.

Since then at the hackathon itself and in the provisional "Link API" it is unclear whether this was adopted or not. Filetype .apla is mentioned but this is specifically exclusive of the .char- types and the .array type assigned to APLAN encoded arrays leaving them to be handled by a named "user exit" or "hook" to be coded by the user or the designer of a framework such as acre.

The very first versions of acre did not store arrays at all. After its being requested it was added along with a per project configuration option whether or not to store arrays.

After several more acre versions the option was removed and all projects now save any item in the above list when changed in the editor or stored with ]SetChanged.

The wiki does not mention the tracking of arrays specifically because in this respect they are treated identically to other types.

[aplteam]

The wiki does not mention the tracking of arrays specifically because in this respect they are treated identically to other types.

It should. As it should mention that something that is ⎕FIXed or ⎕FXed or assigned (Hello←{'word'}) is not tracked because for somebody new to APL this might well be a surprise. For that reason I suggest a page like "What's tracked".

And maybe it's an idea to ask Dyalog to actually include all ways to define a function, but certainly not assignments to variables.

[e9gille]

Maybe it was missed in the Link API, but to summarise the reasoning around arrays we said:

1. Acre currently creates a new file if you edit a character array variable while tracing, this is likely unwanted.
2. Link and Acre only trigger on editor fix events, so at the moment it is only a problem for the 3 char types supported by Acre.
3. Assuming that arrays stored in source are some sort of constants, it seems sensible to require that they get added explicitly rather than automatically. When migrating code into Acre for the first time it might be important to include arrays.

The suggested solution was to only track arrays if they originate from file. By calling ]SetChanged or ]EditArray you explicitly ask for something to be tracked.

[PhilLast]

@PhilLast The wiki does not mention the tracking of arrays specifically because in this respect they are treated identically to other types.

@aplteam It should. As it should mention that something that is ⎕FIXed or ⎕FXed or assigned (Hello←{'word'}) is not tracked.

So not mention the tracking of arrays specifically but all items changed or created elsewhere than in the editor.

[PhilLast]

@e9gille The suggested solution was to only track arrays if they originate from file. By calling ]SetChanged or ]EditArray you explicitly ask for something to be tracked.

I'm still wondering when, where and by whom these discussions, solutions and decisions were made already to be mentioned in the gap analysis prior to the hackathon. I think not by the acre/Carlisle team and not in this forum.

But I do see the sense in the not tracking newly created items in some respects because I often clone functions to make experimental changes and finally decide which version I want. If the new then I rename that to the original and otherwise not. But either way I have to ]erase the other because acre has automatically tracked it. Now here I'm referring to functions.

If the starting of the tracking of arrays is to be on-demand should it not apply to all items?

[e9gille]

I'm still wondering when, where and by whom these discussions, solutions and decisions were

Apologies, I realise I have to be careful not to use the word "we" and "decided" as generously as I have. Note that I have been in many conversations with individuals and organisations and sometimes lose track fo who said what.

I believe the issue first was raised during an internal demo/review in Optima. I then discussed it with Morten. It was put into the GAP analysis so it wouldn't get forgotten about and seeing as we were about to meet in person, I hoped to discuss it with you Phil in Bramley.

I don't mean to sound like I make the calls here. I should have been more specific and expressed myself better. I'll keep that in mind for the future.

If the starting of the tracking of arrays is to be on-demand should it not apply to all items?

No, I don't think so. Arrays may be constants or variables it is unclear, other items are typically source code. Ideally it should distinguish local names and ignore them, but if that is not an option I think it makes sense to treat at least arrays more carefully.

[PhilLast]

I should have no objection to this change if a Fix event's occurring on a previously unsaved object caused acre to put up a modal msgbox asking the question whether or not to save it.

I should hate to have spent spend time creating a text item and find at the next session that I'd thrown it away.