Opening dependencies

[PhilLast]

'til now the syntax for Open in the config file has been one of:

open←'this/'                               ⍝ single
open←⊂'this/' '#.here'                     ⍝ ditto with target (enclosed)
open←'this/' 'that/'                       ⍝ multiple
open←('this/' '#.here')('that/' '#.there') ⍝ ditto with targets

We are now adding modifier -track and potentially -dependencies to each.

It would be easier to parse, and probably to compose, if we made the spec for each project a simple blank separated string:

open←'this/'                                   ⍝ single
open←'this/ #.here'                            ⍝ with target
open←'this/ -track=off'                        ⍝ with modifier
open←'this/ #.here -track=off'                 ⍝ with both
open←'this/ #.here' 'that/ #.there -track=off' ⍝ multiple

so that each were exactly as it would be passed to ⎕SE.UCMD after 'acre.OpenProject ',...

In case I'm not being clear the top four and the next five are alternatives. There should still be only a single definition for Open no matter how many dependencies. Folder paths containing blanks will need to be "quoted thus".

As questions don't always get answered any too promptly I'm assuming that's OK and will address objections while coding.

[PhilLast]

Further to this the protocol I'm following is:

• by default all projects are tracked and their dependants opened.
• a project with -dependencies=off is opened but its dependants are not.
• a project with -track=off is opened but not tracked.
• the dependants of a project that is not tracked are not tracked.
• in all cases "off" is case-agnostic and may be quoted.

There is never a need to include -track=on or -dependencies=on.

[PhilLast]

I appear to be using dependents and dependencies interchangeably and indeed they are more-or-less synonyms when used as nouns. The code currently expects -dependencies=... although -d=... is sufficient so long as we introduce no other modifier starting with 'd'. Do we care? Does anyone have a preference?

[aplteam]

dependents is certainly less likely to be understood by non-native speakers. The plural is not even recognized by the spell checker. For that reason I would favour dependencies.

[PhilLast]

Sorry. My error. One of the half a dozen or so words I frequently misspell: the word is "dependants". But I'll leave it as "-dependencies" anyway.

[PhilLast]

And there's another decision to be made. see OpenProject and LoadProject and particularly that the latter lifts

the restriction that it may not be opened underneath another project.

We will no longer have LoadProject. The distinction is to be made by the -track and -dependencies modifiers. I currently have it linked to -track but the above restriction does not seem necessarily to be related to either. Perhaps we should we have another modifier -embed [say] with a default of "off" xor "no" such that adding -embed=on xor -embed=yes would lift the restriction.

Actually I can imagine only a single situation where one would want to lift the restriction - in order permanently to embed the contents of one project in another - and this would probably be easier to achieve through copying source files.

[aplteam]

Sorry. My error. One of the half a dozen or so words I frequently misspell: the word is "dependants". But I'll leave it as "-dependencies" anyway.

Paul would probably say "No you didn't":

http://www.k12reader.com/term/dependent-vs-dependant/

Another good reason to stick to dependencies.

[PhilLast]

Fait accompli. Please reopen if anyone wants to question decisions.

[PhilLast]

With slight refinements, and hopefully complete this time, the protocol I'm following is:

• by default all projects are tracked and their dependants opened.
• if a project with -dependencies=off is opened its dependants are not.
• if a project with -track=off is opened it is not tracked.
• the dependants of a project that is not tracked are not tracked.
• a tracked project may not be opened into another tracked project.
• if for any reason a dependant of a project cannot be opened, the project is opened without it.
• a tracked project opened directly by OpenProject rather than as a dependant of another project has its Startup parameter executed in its ProjectSpace.
• in all cases "off" is case-agnostic and may be quoted.
• -track=on or -dependencies=on need never be specified.

Please react if you consider any of these points to be contentious.

[aplteam]

All agreed except

if for any reason a dependant of a project cannot be opened, the project is opened without it.

If it's a dependency then that should stop the whole operation dead, meaning signalling an error.

I would also like to change acre's behaviour when it cannot fix something. I think it should signal an error then as well. Not straight away when something does not open or fix but at the very end, to make it more obvious that something went wrong.

For example, I have automated all my "Make" operations (for applications like Fire and Meddy etc.). I did not realize the danger so far - because it always happened to work - but if something goes wrong I would not notice because it's all done under program control in a newly started instance of Dyalog, and the whole process takes almost no time, so you cannot really watch what's printed to the session.

But I don't want to catch and analyze the messages either; if something that basic goes wrong throwing an error seems to be the right thing to do, because such a problem needs immediate attention in any case. I cannot imagine any situation were one would say "Oh, this did not open (or did not fix) but that's okay, I want to carry on anyway!".

[PhilLast]

I disagree that acre should stop part way through. If a project has two dependants and the first has loaded without problem nothing is gained by leaving things as they are and we can hardly recover by erasing the first as it may well have overwritten something that was already there.

The remedy is likely to be a correction to the config file of one or other of the projects involved. A misspelling, missed quotes or a conflict in the target location.

But your suggestion regarding the '!!! Not fixed' messages could usefully be taken for the main point.

Acre could gather all warning messages whether failed dependencies or fix failures and repeat them en bloc at the end. But stopping part way through, especially with the paucity of the error display under the user command framework would be unlikely to make analysis easier.

⎕SIGNAL could be issued as a last step after the final rendering of warning and error messages if any.

[aplteam]

Sorry, the way I phrased it was just wrong.

I want acre to do exactly what it is doing right now (including printing messages to the session) except that instead of finally returning control to the user command framework I would like acre to throw an error, ideally self-defined ones as in

'Acre could not ⎕F(I)X object' ⎕signal 612
'Acre could not open dependency' ⎕signal 613

Just examples.

[PhilLast]

I believe my suggestion of three hours ago is largely compatible with what you are suggesting.

In terms of returning or not returning control to the command framework, unless the user has previously issued ]udebug on, we can't avoid it as any ⎕SIGNAL issued by acre will be caught and largely suppressed by UCMD.

But in case of an error acre could set an error flag, buffer warning and error msgs and, having done everything possible on the way, display the buffered msgs and signal instead of returning the final result.

[aplteam]

Sounds good.

[PhilLast]

I've just made some adjustments to acre to produce the above behaviour and experimented with tentative changes to a couple of the test cases to attempt to accommodate them.

My adjustment is to buffer error messages and, if there are any, reproduce them, catenated with CRs, as the left arg to ⎕SIGNAL as a final step before returning the result.

That left arg to ⎕SIGNAL becomes the first line of ⎕DM that ⎕SE.UCMD then catenates to its own "* Command Execution Failed:" and sets ⎕EN to 100.

I wonder if it is possible to test the working of an acre command called from the test case through ⎕SE.UCMD when that command is going to use ⎕SIGNAL to flag an error.

[PhilLast]

On 2018-05-08 05:25, Kai Jaeger wrote:>

Could you beam those changes up in a branch so that I can have a go?

I know I said I could do this and actually tried it out and got it working but I'm still not happy that this behaviour is right for a project in development.

A scenario:

I want to work on a project at the top of a hierarchy of dependency. If some problem arises opening or fixing an item in a dependant of a dependant I don't want it to stop my working on the main project.

I know I'll have to fix the problem sooner or later but for now it's not my main concern. Of the half dozen projects in the tree I'm unlikely to want to look at that one in this session. Next time I actually need it will be the time to fix it.

I can issue the ]openproject command with the -d=off modifier but that will prevent acre from opening any of the dependants.

The only recourse will be temporarily to change the config file of the project that specifies it to remove it from its open← entry.

If rather than signalling an error, acre were merely to repeat the error messages immediately prior to returning control having opened the main project, everything except the minor project with the error would be open and we could continue with the session.

[PhilLast]

@PaulMansour @norberturkiewicz @aplteam The latest upload includes my implementation of Kai's suggestion re. ⎕SIGNAL out of OpenProject in particular and presumably other commands in similar situations when something unexpected has occurred.

I don't like it myself as the result currently is that many subsidiary projects may have been opened but because of signalling, the main one is not open rather than just the one(s) that caused the problem.

I see acre as a development environment, my original hope was to call it acme for APL Code Management Environment (i) but this change seems to me to be working rather against the developer than helping.

Are there any other opinions or suggestions?

If you need help in triggering the behaviour, add a non existent project to the Open← setting in acreConfig.txt.

(i) I didn't want to be tarred with the same brush as Wile E. Coyote.

[aplteam]

Works perfectly well, in particular in version 16.0 were I can use ⎕SIGNAL 0 to reset both ⎕EN and ⎕DM(X).