Refactor acre.config to use a standard Boolean instead of On/Off, 1/0, or any other custom implementation.

[norberturkiewicz]

May I suggest that we enhance the config file to use standard JSON Boolean convention if there are any major updates?

[PhilLast]

Eye off ball.

As the config file is JSON by default then those values should work for both import and export for any conforming JSON processor. But what ⎕JSON does is import them as enclosed strings (⊂'true') and (⊂'false') and export those paticular values as JSON true and false. Not as the expected APL boolean scalars 1 and 0.

In fact acre doesn't currently use either as all switches expect strings 'oN' or 'oFf' in any case combination and return them as 'On' and 'Off'.

The parsing would be quite simple as acre's use of them is fairly restricted.

The question is would this necessarily replace 'On' and 'Off' or be an alternative?

Fortunately acre never rewrites the config file. It's created by CreateProject and only ever read thenceforward. But should it then write '"CaseCode": false' &c. rather than '"CaseCode": "Off"'?

[PhilLast]

Not pushed yet but under test.

In an acre.config file any of:

⍝     JSON                              APLAN                          APLScript     
 {                                  [                              :Namespace        
    "param0": true,                    param0←⊂'true'                 param0←⊂'true' 
    "param1": false,                   param1←⊂'false'                param1←⊂'false'
    "param2": "True",                  param2←'True'                  param2←'True'  
    "param3": "False",                 param3←'False'                 param3←'False' 
    "param4": ["True"],                param4←⊂'True'                 param4←⊂'True' 
    "param5": ["False"],               param5←⊂'False'                param5←⊂'False'
    "param6": "On",                    param6←'On'                    param6←'On'    
    "param7": "Off",                   param7←'Off'                   param7←'Off'   
    "param8": ["On"],                  param8←⊂'On'                   param8←⊂'On'   
    "param9": ["Off"]                  param9←⊂'Off'                  param9←⊂'Off'  
 }                                  ]                              :EndNamespace     

will now turn the requisite parameter on or off. In the ws project.AcreConfig.CaseCode [say] it will have been converted to 'On' or 'Off' but the file is never rewritten.

The JSON booleans (true/false) must be lower case. In APLScript or APLAN they must be quoted but may be coded in any case combination.

Any of these values may be used also in options that previously took only "On" or "Off". e.g. -track=false.

The allowing the words as strings and lists is to make the validation simpler within acre because Dyalog imports the JSON booleans as enclosed strings: ⊂'false' and ⊂true and exports those enclosed strings as JSON booleans. But I assume the requirement is to add consistency to a JSON config file that requires boolean values for other purposes. This I think is fulfilled.

Defaults for CreateProject are now "CaseCode": false, "KeepHistory": false and "Variables": false.

[PhilLast]

Committed and pushed

[PhilLast]

I don't know how many of you use ]AfterSave but I've just realised that this issue might bear on that because the left argument to your callback is a clone of the namespace represented by the projectfolder/acre.config file. It's presently stored internally as an APLAN string and instantiated when needed. Identically to the projectspace.AcreConfig space in the open project, it uses acre's original values of the booleans "On/Off" rather than whatever is contained in the file.

If the file is JSON and JSON booleans true/false are used then this may cause a problem to you. The trouble is the direct importation of true or false from a JSON file by ⎕JSON gives (⊂'true') or (⊂'false') in the APL session.

Please let me know if you would prefer this. This could be done by storing the actual text of the file itself, decoding with the requisite protocol: ⎕JSON, APLAN or ⎕FIX; and injecting ProjectFolder immediately before use. There would be no normalisation of names.

[PhilLast]

Another thing I've just noticed is that the dot net serialiser "JavaScriptSerializer" that's being used for reading the config file in Dyalog 14.0 translates true and false into 1 and 0 that doesn't satisfy either acre's original "On", "Off" or Dyalog's (⊂'true'), (⊂'false'). This means that using native JSON to write either true or false in the file sets the requisite parameter off in Dyalog v14.0 only.

The simplest thing for me to do is to change the 1, 0 after the fact into Dyalog's version and cut out the tidying up at the end that's then being re-done in any case by the readConfig function that calls it.

[norberturkiewicz]

Another thing I've just noticed is that the dot net serialiser "JavaScriptSerializer" that's being used for reading the config file in Dyalog 14.0 translates true and false into 1 and 0 that doesn't satisfy either acre's original "On", "Off" or Dyalog's (⊂'true'), (⊂'false'). This means that using native JSON to write either true or false in the file sets the requisite parameter off in Dyalog v14.0 only.

The simplest thing for me to do is to change the 1, 0 after the fact into Dyalog's version and cut out the tidying up at the end that's then being re-done in any case by the readConfig function that calls it.

I would not worry about 14.0. I'm the only user and do not check any values of the AcreConfig. It can be easily worked around if needed.