GSoC 2020: jsondecode status

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

GSoC 2020: jsondecode status

Abdallah Elshamy
Hello everyone,

I have finished the first draft for jsondecode [1] function on my github repo [2]. I have also added a few test cases [3] (I verified that they work on MATLAB online). The function now passes all the test cases.

Right now, the function is treated as an external *.oct file. The integration of the code into Octave's build system will be done at the end of the project. I transformed the test suite into Octave-compatible test files that can be found in "test/json" directory [4].

If you have any ideas for improvements, please let me know. I am waiting for your feedback and suggestions.

A good idea that was suggested by the author of JSONio [5] was to add a "ReplacementStyle" option [6] when creating a structure's field name. What do you think about this?

Thanks for your time,
Abdallah


Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2020: jsondecode status

Andreas Weber-6
Am 08.07.20 um 20:05 schrieb Abdallah Elshamy:
> Right now, the function is treated as an external *.oct file. The
> integration of the code into Octave's build system will be done at the
> end of the project.

Do you plan to create a "standalone" git repo with your code which
creates a .oct, perhaps forge compatible? I my eyes this would be great
to debug/send patches etc.

How do you build your .oct at the moment?

-- Andy

Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2020: jsondecode status

siko1056
On 7/9/20 3:45 PM, Andreas Weber wrote:

> Am 08.07.20 um 20:05 schrieb Abdallah Elshamy:
>> Right now, the function is treated as an external *.oct file. The
>> integration of the code into Octave's build system will be done at the
>> end of the project.
>
> Do you plan to create a "standalone" git repo with your code which
> creates a .oct, perhaps forge compatible? I my eyes this would be great
> to debug/send patches etc.
>
> How do you build your .oct at the moment?
>
> -- Andy
>

Sorry Andy for the late reply.  Making a "standalone" repo might
facilitate some things at the moment.

If Abdallah hadn't answered yet, he updated his blog post [1] with the
current instructions.

Kai

[1] https://abdallahshamy.wordpress.com/2020/07/10/coding-period-report-6/


Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2020: jsondecode status

Abdallah Elshamy

Sorry Andy for the late reply.  Making a "standalone" repo might
facilitate some things at the moment.

I thought what Andy meant is a forge-compatible package which is not necessary. I made a "standalone" repo [1] that contains only the files I am working on.
I moved the files with the commits (I thought it is a good idea to keep the history of the commits I made in Octave's repo) to this new repo. I also moved all the issues from Octave's repo to the new repo. I mentioned that also in my new weekly report [2].

Regarding using cell2struct [3], I think that in order to use it to convert our cell of objects into a struct array, We will need a considerable overhead in creating the "right" cell for conversion. Thus, I think we should go with the current custom code. What do you think ?

Best Regards,
Abdallah

Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2020: jsondecode status

siko1056
On 7/19/20 4:06 AM, Abdallah Elshamy wrote:
> [...] I made a "standalone" repo [1] that contains only the files I
> am working on.
> I moved the files with the commits (I thought it is a good idea to keep
> the history of the commits I made in Octave's repo) to this new repo. I
> also moved all the issues from Octave's repo to the new repo. I
> mentioned that also in my new weekly report [2].
>

Looks good to me.

> Regarding using cell2struct [3], I think that in order to use it to
> convert our cell of objects into a struct array, We will need a
> considerable overhead in creating the "right" cell for conversion. Thus,
> I think we should go with the current custom code. What do you think ?
>

Yes, last Friday, I did not regard, that "cell2struct" has to know about
the correct field names.  Maybe your custom code with detection is
better suited for this purpose.


> Best Regards,
> Abdallah
>
> [1] https://github.com/Abdallah-Elshamy/Octave-GSoC-JSON
> [2] https://abdallahshamy.wordpress.com/2020/07/18/coding-period-report-7/
> [3] https://octave.sourceforge.io/octave/function/cell2struct.html

Kai