GSoC 2021: Coding Period – Report (2)

Hello there, this is my weekly report about my work. In this report, I will show what I did this past week. I will also show what I intend to do in the next week. All the code of the project can be found on this repository. let’s get started.


This is a companion discussion topic for the original entry at https://abdallahshamy.wordpress.com/2021/07/15/gsoc-2021-coding-period-report-2/
1 Like

The jsondecode function transforms the keys of JSON objects into valid octave variable names. This is not compatible with the notebook format, so we need to handle it.

For my version of jsonencode, I added two options (with default values matching Matlab);

ReplacementStyle: string to control how non-alphanumeric characters are replaced
{‘underscore’,‘hex’,‘delete’,‘nop’} [Default: ‘underscore’]
Prefix: string to prepend when first character of a field is not alphabetical [Default: ‘x’]

Would that solve the compatibility issue with the notebook format?

1 Like

the replacement style option is actually supported in jsondecode (thanks for the suggestion)

but it makes a call to matlab.lang.makeValidName which doesn’t support the nop option.

If this option is supported, it will solve this compatibility issue.

@siko1056, I wonder if we should keep the original solution (make a pre-processing step to handle this since it is only for MIME types keys) or should we try to support this option (whether in jsondecode or in matlab.lang.makeValidName)?

@Abdallah_Elshamy yes, I also agree to the great idea of @Guillaume.

Octave’s matlab.lang.makeValidName currently sticks very close to the original ReplacementStyle options, which is one of {‘underscore’,‘hex’,‘delete’}.

Introducing nop in matlab.lang.makeValidName might indeed be the easiest solution here and not too diverging from Matlab’s original specification. In some situations like with structs, Octave can cope with the original input.

Please go ahead with that solution. If you don’t want to work on a custom Octave build, those changes can be applied first to

@siko1056, We agreed in our meeting that adding the nop option is better at jsondecode but apparently that can’t be done without modifying the behaviour of matlab.lang.makeValidName .

The make_valid_name_options object is constructed at the beginning of the jsondecode function call and it checks for the valid options immediately. So, we can’t support the “nop” in jsondecode without supporting it in matlab.lang.makeValidName .

So I will add it to the makeValidName function :grinning:.

For completeness, should I support the nop option in Prefix? In case we don’t want any modifications at all.

Both approaches are fine with me. After our recent conversation, I changed my preference to do the changes in jsondecode.cc again :sweat_smile:

What would be necessary to realize nop in jsondecode.cc, was to preprocess the input before creating the octave::make_valid_name_options object.

However, having nop in matlab.lang.makeValidName option ReplacementStyle is okay, too. Enabling a nop for prefix, would be to permit an empty string '' as input. Thus the logic here

must be changed and puts the function a little bit ad absurdum :thinking:

Done :white_check_mark: check this commit.

As we agreed, I added a new option makeValidName. I also documented the new option and added some test cases to make sure that the changes are working fine.

If you have any comments, please let me know.

1 Like