Help in JSON encode/decode project

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

Help in JSON encode/decode project

Abdallah Elshamy

Hello Mr. Kai Ohlhus,

My name is Abdallah Elshamy and I am looking forward to contribute in octave during GSoC.

I started by building octave and I submitted a batch [1] to show my enthusiasm and I started filling my public application [2] (it doesn't have the topic "your task").


I am interested in JSON encoding/decoding project. I need some help to verify my understanding of the project.


I will illustrate my understanding using the jsondecode function as an example.


From what I understood from the references provided in the wiki page [3] the data flow diagram is this:

Data flow diagram.png


what we need to do is to cherry-pick (from the previous attempts) or write the components in this diagram and integrate them to achieve the required functionality with good performance (to be written in c++ not in m-file)


The expected output of the project is the c++ files that contains the two functions and .mex file (to be able to call it from octave) and the tests and documentation of those function so we can add it to core octave.


Did I get it right? If yes, It will be nice to guide me on what to do next. If not please, correct me.


I also read in this conversation [4] what Mr. Andrew Janke wrote on february 2020:

“I'm still working on JSONStuff - https://github.com/apjanke/octave-jsonstuff - and I think it's about feature-complete”

Does this mean that he is about to finish the project so I should consider another one or the project will use some of his work ?

This my first time to apply in GSoC so I don’t have much experience. Any help would be appreciated.

Thanks for your time,

Abdallah


[1] https://savannah.gnu.org/bugs/?57041

[2] https://wiki.octave.org/User:Abdallah_Elshamy

[3] https://wiki.octave.org/Summer_of_Code_-_Getting_Started#JSON_encoding.2Fdecoding

[4] https://savannah.gnu.org/bugs/?53100


Reply | Threaded
Open this post in threaded view
|

Re: Help in JSON encode/decode project

Mike Miller-4
On Fri, Mar 06, 2020 at 21:52:03 +0200, Abdallah Elshamy wrote:
> Does this mean that he is about to finish the project so I should consider
> another one or the project will use some of his work ?

You might want to test and familiarize yourself with the jsonstuff
package. I've tested it, found some bugs, helped improve compatibility.
If you want to make a project out of it, spend some time with it and see
where you think you can help improve it.

--
mike

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Help in JSON encode/decode project

Abdallah Elshamy

> If you want to make a project out of it, spend some time with it and see
> where you think you can help improve it.

Thanks for your reply.


I followed your advice and started spending some time with it. Also the issues list [1] of the package provided some useful info. What I think I can help in improving are:

  • Using RapidJson instead of jsoncpp to enhance performance.

  • modifying jsondecode to be compatible with RapidJson.

  • Writing jsonencode in c++ to improve performance.

  • Verifying the “condensation” algorithm by writing more tests then moving it to c++.

  • Some modifications is needed in the documentation (for example the documentation of jsondecode function is just a repetition of the documentation of jsonencode.)

  • preparing the two functions to be integrated to the core of octave rather than a package.


I was thinking that writing tests [2] will help me more in understanding the project and the package. Do you think it’s a good idea to do so (in parallel with my preparation of the proposal with you and the maintainers of octave)?


Thanks for your time.

Abdallah


[1] https://github.com/apjanke/octave-jsonstuff/issues

[2] https://github.com/apjanke/octave-jsonstuff/issues/13

 
Reply | Threaded
Open this post in threaded view
|

Re: Help in JSON encode/decode project

Andrew Janke-2


On 3/8/20 3:53 PM, Abdallah Elshamy wrote:

>
>     > If you want to make a project out of it, spend some time with it
>     and see
>     > where you think you can help improve it.
>
> Thanks for your reply.
>
>
> I followed your advice and started spending some time with it. Also the
> issues list [1] of the package provided some useful info. What I think I
> can help in improving are:
>
>   *
>
>     Using RapidJson instead of jsoncpp to enhance performance.
>
>   *
>
>     modifying jsondecode to be compatible with RapidJson.
>
>   *
>
>     Writing jsonencode in c++ to improve performance.
>
>   *
>
>     Verifying the “condensation” algorithm by writing more tests then
>     moving it to c++.
>
>   *
>
>     Some modifications is needed in the documentation (for example the
>     documentation of jsondecode function is just a repetition of the
>     documentation of jsonencode.)
>
>   *
>
>     preparing the two functions to be integrated to the core of octave
>     rather than a package.
>
>
> I was thinking that writing tests [2] will help me more in understanding
> the project and the package. Do you think it’s a good idea to do so (in
> parallel with my preparation of the proposal with you and the
> maintainers of octave)?
>
>
> Thanks for your time.
>
> Abdallah
>
>
> [1] https://github.com/apjanke/octave-jsonstuff/issues
>
> [2] https://github.com/apjanke/octave-jsonstuff/issues/13


For what it's worth, I think writing more unit tests so we can get to a
comprehensive test suite is the top priority for jsondecode. That will
make everything else listed here easier and safer.

This list sounds right to me, except I'm not sure about switching to
RapidJson. Do you know of any benchmarks comparing the performance of
jsondecode and RapidJson? Or would we need to do that testing ourselves?

Oops. Sorry about the bad doco on jsondecode. That definitely needs
fixed. https://github.com/apjanke/octave-jsonstuff/issues/17

Cheers,
Andrew

Reply | Threaded
Open this post in threaded view
|

Re: Help in JSON encode/decode project

siko1056
On 3/9/20 5:04 AM, Andrew Janke wrote:

> On 3/8/20 3:53 PM, Abdallah Elshamy wrote:
>>
>>     > If you want to make a project out of it, spend some time with it
>>     and see
>>     > where you think you can help improve it.
>>
>> Thanks for your reply.
>>
>>
>> I followed your advice and started spending some time with it. Also the
>> issues list [1] of the package provided some useful info. What I think I
>> can help in improving are:
>>
>>   * Using RapidJson instead of jsoncpp to enhance performance.
>>
>>   * modifying jsondecode to be compatible with RapidJson.
>>
>>   * Writing jsonencode in c++ to improve performance.
>>
>>   * Verifying the “condensation” algorithm by writing more tests then
>>     moving it to c++.
>>
>>   * Some modifications is needed in the documentation (for example the
>>     documentation of jsondecode function is just a repetition of the
>>     documentation of jsonencode.)
>>
>>   * preparing the two functions to be integrated to the core of octave
>>     rather than a package.
>>
>>
>> I was thinking that writing tests [2] will help me more in understanding
>> the project and the package. Do you think it’s a good idea to do so (in
>> parallel with my preparation of the proposal with you and the
>> maintainers of octave)?
>>
>>
>> Thanks for your time.
>>
>> Abdallah
>>
>>
>> [1] https://github.com/apjanke/octave-jsonstuff/issues
>>
>> [2] https://github.com/apjanke/octave-jsonstuff/issues/13
>
>
> For what it's worth, I think writing more unit tests so we can get to a
> comprehensive test suite is the top priority for jsondecode. That will
> make everything else listed here easier and safer.
>
> This list sounds right to me, except I'm not sure about switching to
> RapidJson. Do you know of any benchmarks comparing the performance of
> jsondecode and RapidJson? Or would we need to do that testing ourselves?
>
> Oops. Sorry about the bad doco on jsondecode. That definitely needs
> fixed. https://github.com/apjanke/octave-jsonstuff/issues/17
>
> Cheers,
> Andrew
>


Dear Abdallah,

Thank you for you interest in this project.  To answer you first email

> Does this mean that he is about to finish the project so I should
> consider another one or the project will use some of his work ?

The great work of Andrew and the other three projects mentioned in the
wiki project description [1] should not scare you away.  Proper
Matlab-compatible JSON integration into Octave core is a pending issue
for at least two years.  As far as I overview the situation, there is no
approach that can make it into Octave core before GSoC is over.  They
all require some sort of adaption and nobody could spend the necessary
time to really care about this project yet.

At the moment you are focused on "octave-jsonstuff".  Please keep in
mind, that there are two (three) other libraries as well.
"octave-rapidjson" worked for me out-of-the-box too, contains test, but
lacks of a Matlab-compatible interface.  JSONio has a very lightweight
dependency, contains tests, but is based on the MEX-C-interface, which
may not be a good choice for Octave core (mostly C++).  This is what I
mean by cherry picking.

The schedule I roughly have in mind is similar to what Mike suggests:
test and familiarize yourself with all four approaches.  Focus on
getting them to run, get an idea how they work, what features are
available, what is missing.

Based on you impressions, you can then prepare your proposal.  Of course
you don't need to complete anything when applying for the project.  A
rough schedule I have in mind is:

1. Extract available tests from all four approaches into your own
test-suite for the whole project.  If possible asses the tests for
Matlab-compatibility (I can help out with this task).  Create larger
scale test cases that run in Matlab too for benchmarking.

2. Asses comprehensively all four libraries with your tests and
benchmarks.  Create reliable figures, graphics.

3. Decide for a back-end (jsmn, rapidjson, jsoncpp).  This will then
become an (optional) Octave dependency.

4. Convert your test-suite into Octave BIST (builtin self-tests) and
implement jsonencode/jsondecode with nice documentation.

This is of course all my happy fantasy and there is lots of space for
discussing the exact outline.

Best,
Kai


[1]
https://wiki.octave.org/Summer_of_Code_-_Getting_Started#JSON_encoding.2Fdecoding

Reply | Threaded
Open this post in threaded view
|

Re: Help in JSON encode/decode project

Andrew Janke-2
On 3/8/20 11:38 PM, Kai Torben Ohlhus wrote:

>
> Dear Abdallah,
>
> Thank you for you interest in this project.  To answer you first email
>
>> Does this mean that he is about to finish the project so I should
>> consider another one or the project will use some of his work ?
>
> The great work of Andrew and the other three projects mentioned in the
> wiki project description [1] should not scare you away.  Proper
> Matlab-compatible JSON integration into Octave core is a pending issue
> for at least two years.  As far as I overview the situation, there is no
> approach that can make it into Octave core before GSoC is over.  They
> all require some sort of adaption and nobody could spend the necessary
> time to really care about this project yet.
>
> At the moment you are focused on "octave-jsonstuff".  Please keep in
> mind, that there are two (three) other libraries as well.
> "octave-rapidjson" worked for me out-of-the-box too, contains test, but
> lacks of a Matlab-compatible interface.  JSONio has a very lightweight
> dependency, contains tests, but is based on the MEX-C-interface, which
> may not be a good choice for Octave core (mostly C++).  This is what I
> mean by cherry picking.
>
> The schedule I roughly have in mind is similar to what Mike suggests:
> test and familiarize yourself with all four approaches.  Focus on
> getting them to run, get an idea how they work, what features are
> available, what is missing.
>
> Based on you impressions, you can then prepare your proposal.  Of course
> you don't need to complete anything when applying for the project.  A
> rough schedule I have in mind is:
>
> 1. Extract available tests from all four approaches into your own
> test-suite for the whole project.  If possible asses the tests for
> Matlab-compatibility (I can help out with this task).  Create larger
> scale test cases that run in Matlab too for benchmarking.
>
> 2. Asses comprehensively all four libraries with your tests and
> benchmarks.  Create reliable figures, graphics.
>
> 3. Decide for a back-end (jsmn, rapidjson, jsoncpp).  This will then
> become an (optional) Octave dependency.
>
> 4. Convert your test-suite into Octave BIST (builtin self-tests) and
> implement jsonencode/jsondecode with nice documentation.
>
> This is of course all my happy fantasy and there is lots of space for
> discussing the exact outline.
>
> Best,
> Kai
>
>
> [1]
> https://wiki.octave.org/Summer_of_Code_-_Getting_Started#JSON_encoding.2Fdecoding


As JsonStuff's author, I agree with Kai's assessment and plan here.
JsonStuff is nowhere near getting merged in to Octave core, and I will
not have time to get it there for many months to come. And this project
should consider the state and approach of all the existing Octave JSON
libraries.

Cheers,
Andrew

Reply | Threaded
Open this post in threaded view
|

Re: Help in JSON encode/decode project

Andrew Janke-2
In reply to this post by Andrew Janke-2


On 3/8/20 4:04 PM, Andrew Janke wrote:

>
>
> On 3/8/20 3:53 PM, Abdallah Elshamy wrote:
>>
>>     > If you want to make a project out of it, spend some time with it
>>     and see
>>     > where you think you can help improve it.
>>
>> Thanks for your reply.
>>
>>
>> I followed your advice and started spending some time with it. Also the
>> issues list [1] of the package provided some useful info. What I think I
>> can help in improving are:
>>
>>   *
>>
>>     Using RapidJson instead of jsoncpp to enhance performance.
>>
>>   *
>>
>>     modifying jsondecode to be compatible with RapidJson.
>>
>>   *
>>
>>     Writing jsonencode in c++ to improve performance.
>>
>>   *
>>
>>     Verifying the “condensation” algorithm by writing more tests then
>>     moving it to c++.
>>
>>   *
>>
>>     Some modifications is needed in the documentation (for example the
>>     documentation of jsondecode function is just a repetition of the
>>     documentation of jsonencode.)
>>
>>   *
>>
>>     preparing the two functions to be integrated to the core of octave
>>     rather than a package.
>>
>>
>> I was thinking that writing tests [2] will help me more in understanding
>> the project and the package. Do you think it’s a good idea to do so (in
>> parallel with my preparation of the proposal with you and the
>> maintainers of octave)?
>>
>>
>> Thanks for your time.
>>
>> Abdallah
>>
>>
>> [1] https://github.com/apjanke/octave-jsonstuff/issues
>>
>> [2] https://github.com/apjanke/octave-jsonstuff/issues/13
>
>
> For what it's worth, I think writing more unit tests so we can get to a
> comprehensive test suite is the top priority for jsondecode. That will
> make everything else listed here easier and safer.
>
> This list sounds right to me, except I'm not sure about switching to
> RapidJson. Do you know of any benchmarks comparing the performance of
> jsondecode and RapidJson? Or would we need to do that testing ourselves?
>
> Oops. Sorry about the bad doco on jsondecode. That definitely needs
> fixed. https://github.com/apjanke/octave-jsonstuff/issues/17
>
> Cheers,
> Andrew
>

I took a look in to RapidJSON and agree that it looks like a better
library for this than jsoncpp, both for performance, and code quality &
documentation. I have migrated JsonStuff to use RapidJSON.
https://github.com/apjanke/octave-jsonstuff/issues/18

A new JsonStuff version 0.3.3 is out that now uses RapidJSON.

I also did a basic fix for the jsondecode documentation, but much more
documentation work is needed.

Cheers,
Andrew

Reply | Threaded
Open this post in threaded view
|

Re: Help in JSON encode/decode project

siko1056
On 3/9/20 2:56 PM, Andrew Janke wrote:
>
> I took a look in to RapidJSON and agree that it looks like a better
> library for this than jsoncpp, both for performance, and code quality &
> documentation.


Now I am curious how did you get convinced of this change?  Did you run
some large scale tests yourself?

Best,
Kai

Reply | Threaded
Open this post in threaded view
|

Re: Help in JSON encode/decode project

Andrew Janke-2


On 3/9/20 2:01 AM, Kai Torben Ohlhus wrote:

> On 3/9/20 2:56 PM, Andrew Janke wrote:
>>
>> I took a look in to RapidJSON and agree that it looks like a better
>> library for this than jsoncpp, both for performance, and code quality &
>> documentation.
>
>
> Now I am curious how did you get convinced of this change?  Did you run
> some large scale tests yourself?
>
> Best,
> Kai
>

No, I don't have time for that. :)

I took a look at this benchmark [1] (which happens to be by the author
of RapidJSON) and thought it was pretty convincing; the code is put
together well, and I see it referenced in a lot of places. It shows a
pretty stark performance difference between jsoncpp and RapidJSON. And
the fact that the library author actually made and ran benchmarks made
me think well of RapidJSON. I saw a couple other benchmarks floating
around in which RapidJSON also beat out jsoncpp.

Then I took a look at the RapidJSON library itself, reading through its
documentation and part of its codebase, and reviewing its GitHub
activity. This struck me as a high quality library. I like its API a bit
better than jsoncpp's, and it's much better documented. The author
clearly also *gets* Unicode encoding and the subtleties of the various
definitions and "standards" for JSON. So I decided I was more
comfortable using RapidJSON than jsoncpp, even if performance weren't a
factor.

Since RapidJSON is a header-only library, it was easy to vendor it into
the JsonStuff project and make the transition without introducing any
external dependencies, so I went ahead and did it.

Cheers,
Andrew

[1] https://github.com/miloyip/nativejson-benchmark

Reply | Threaded
Open this post in threaded view
|

Re: Help in JSON encode/decode project

siko1056
On 3/9/20 3:14 PM, Andrew Janke wrote

> On 3/9/20 2:01 AM, Kai Torben Ohlhus wrote:
>> On 3/9/20 2:56 PM, Andrew Janke wrote:
>>>
>>> I took a look in to RapidJSON and agree that it looks like a better
>>> library for this than jsoncpp, both for performance, and code quality &
>>> documentation.
>>
>>
>> Now I am curious how did you get convinced of this change?  Did you run
>> some large scale tests yourself?
>>
>> Best,
>> Kai
>>
>
> No, I don't have time for that. :)
>
> I took a look at this benchmark [1] (which happens to be by the author
> of RapidJSON) and thought it was pretty convincing; the code is put
> together well, and I see it referenced in a lot of places. It shows a
> pretty stark performance difference between jsoncpp and RapidJSON. And
> the fact that the library author actually made and ran benchmarks made
> me think well of RapidJSON. I saw a couple other benchmarks floating
> around in which RapidJSON also beat out jsoncpp.
>
> Then I took a look at the RapidJSON library itself, reading through its
> documentation and part of its codebase, and reviewing its GitHub
> activity. This struck me as a high quality library. I like its API a bit
> better than jsoncpp's, and it's much better documented. The author
> clearly also *gets* Unicode encoding and the subtleties of the various
> definitions and "standards" for JSON. So I decided I was more
> comfortable using RapidJSON than jsoncpp, even if performance weren't a
> factor.
>
> Since RapidJSON is a header-only library, it was easy to vendor it into
> the JsonStuff project and make the transition without introducing any
> external dependencies, so I went ahead and did it.
>
> Cheers,
> Andrew
>
> [1] https://github.com/miloyip/nativejson-benchmark
>

Thank you for sharing the link Andrew.  Indeed very comprehensive
benchmark.  This simplifies the back-end decision a lot.

Kai

Reply | Threaded
Open this post in threaded view
|

Re: Help in JSON encode/decode project

Abdallah Elshamy
> At the moment you are focused on "octave-jsonstuff".  Please keep in
> mind, that there are two (three) other libraries as well.
> "octave-rapidjson" worked for me out-of-the-box too, contains test, but
> lacks of a Matlab-compatible interface.  JSONio has a very lightweight
> dependency, contains tests, but is based on the MEX-C-interface, which
> may not be a good choice for Octave core (mostly C++).  This is what I
> mean by cherry picking.

I have quickly checked them to understand what you mean. The tests they provide are very useful (especially octave-rapidjson as it provides big test cases). I understand now what you mean by cherry picking (certainly not for tests only, but also for approaches to the problem, design ...etc)

> I took a look at this benchmark [1] (which happens to be by the author
> of RapidJSON) and thought it was pretty convincing; the code is put
> together well, and I see it referenced in a lot of places.

Thanks a lot for sharing this link. this indeed is very useful.

> Based on you impressions, you can then prepare your proposal.  Of course
> you don't need to complete anything when applying for the project.

The list seems great but I would like to add more details to clarify some points for me:

  1. for the present time, I should spend more time with the four libraries (I already started) to decide my approach to the project so I can provide a more detailed time line and prepare my proposal.

  2. During the community bonding period, I should (besides getting more familiar with the organization) put a fine detailed and complete plan for the functions and the test suite.

  3. The first output of my work will be a complete test suit extracted from the four approaches and my additions to it. It will be Matlab-compatible for benchmarking.

  4. Asses comprehensively all four libraries with your tests and benchmarks. Create reliable figures, graphics to decide back-end (I don’t think that this is necessary since the link that Mr.Andrew Janke shared [1] provides a strong evidence that Rapidjson is better is my assumption is correct?)

  5. Produce a c++ implementation for jsondecode/jsonencode.

  6. convert my test suite to Octave BIST.

  7. Provide a proper documentation for the functions.

  8. Integrate the functions into octave core.

  9. Use the community and mentors feedback after submissions to perfect the patch.

A milestone list I have in mind is :

  1. deliver test suite

  2. deliver jsondecode

  3. deliver jsonencode


Please, let me know what you think about this.


Thanks for your time,

Abdallah


[1] https://github.com/miloyip/nativejson-benchmark



Reply | Threaded
Open this post in threaded view
|

Re: Help in JSON encode/decode project

siko1056
On 3/12/20 5:15 AM, Abdallah Elshamy wrote:

>> Based on you impressions, you can then prepare your proposal.  Of course
>> you don't need to complete anything when applying for the project.
>
> The list seems great but I would like to add more details to clarify
> some points for me:
>
>  1. for the present time, I should spend more time with the four
>     libraries (I already started) to decide my approach to the project
>     so I can provide a more detailed time line and prepare my proposal.
>
>  2. During the community bonding period, I should (besides getting more
>     familiar with the organization) put a fine detailed and complete
>     plan for the functions and the test suite.
>
>  3. The first output of my work will be a complete test suit extracted
>     from the four approaches and my additions to it. It will be
>     Matlab-compatible for benchmarking.
>
>  4. Asses comprehensively all four libraries with your tests and
>     benchmarks. Create reliable figures, graphics to decide back-end (I
>     don’t think that this is necessary since the link that Mr.Andrew
>     Janke shared [1] provides a strong evidence that Rapidjson is better
>     is my assumption is correct?)
>
>  5. Produce a c++ implementation for jsondecode/jsonencode.
>
>  6. convert my test suite to Octave BIST.
>
>  7. Provide a proper documentation for the functions.
>
>  8. Integrate the functions into octave core.
>
>  9. Use the community and mentors feedback after submissions to perfect
>     the patch.
>
> A milestone list I have in mind is :
>
>  1. deliver test suite
>
>  2. deliver jsondecode
>
>  3. deliver jsonencode
>
>
> Please, let me know what you think about this.
>
>
> Thanks for your time,
>
> Abdallah
>
>
> [1] https://github.com/miloyip/nativejson-benchmark
>


Looks all good to me.  You are right, I think RapidJSON should be the
choice.  Makes the project easier, but still lots of work to do ;-)
Because two of the four JSON projects now use RapidJSON, the focus of
the benchmark should not only be speed, but also Matlab compatible data
processing (like octave-jsonstuff passes 100 of 100 Matlab compatible
tests...).  This might also help those projects to improve their code.
Their focus is not only 100% Matlab compatibility, they also provide
other useful extension.  But for Octave compatibility should be more the
focus.

Best,
Kai

Reply | Threaded
Open this post in threaded view
|

Re: Help in JSON encode/decode project

Andreas Weber-6
In reply to this post by Abdallah Elshamy
Am 11.03.20 um 21:15 schrieb Abdallah Elshamy:
> ... The tests they
> provide are very useful (especially octave-rapidjson as it provides big
> test cases).

I'm the author of octave-rapidjson, you can email me of course.
My main focus on octave-rapidjson was to be very fast and that datatypes
in Octave survive a save/load cycle as the core save/load does.

I never used Matlab so I don't know there interface. I'm a little bit
baffled that there is so much effort creating just another wrapper
around Rapidjson (for example octave-jsonstuff) instead of working
together on a project.

-- Andy

Reply | Threaded
Open this post in threaded view
|

Re: Help in JSON encode/decode project

Andrew Janke-2


On 3/12/20 3:07 AM, Andreas Weber wrote:

> Am 11.03.20 um 21:15 schrieb Abdallah Elshamy:
>> ... The tests they
>> provide are very useful (especially octave-rapidjson as it provides big
>> test cases).
>
> I'm the author of octave-rapidjson, you can email me of course.
> My main focus on octave-rapidjson was to be very fast and that datatypes
> in Octave survive a save/load cycle as the core save/load does.
>
> I never used Matlab so I don't know there interface. I'm a little bit
> baffled that there is so much effort creating just another wrapper
> around Rapidjson (for example octave-jsonstuff) instead of working
> together on a project.
>
> -- Andy

My reasoning for octave-jsonstuff was that JsonStuff's main goal was a
100% Matlab-compatible interface, and a JSON wrapper layer is a small
enough project that it was easier for me to just throw it together on my
own instead of going through the communication overhead of collaborating
with an existing project.

Cheers,
Andrew


Reply | Threaded
Open this post in threaded view
|

Re: Help in JSON encode/decode project

Abdallah Elshamy
> I'm the author of octave-rapidjson, you can email me of course.
 
Thank you for reaching out. Your work is surely very helpful to me.

>  I'm a little bit baffled that there is so much effort creating just another wrapper
> around Rapidjson (for example octave-jsonstuff) instead of working
> together on a project.
 
 Collaboration and picking from previous work is a core part of this project. I am getting familiar with the different approaches right now.
--------------------------------------------------------------------------------------------------------------------------------------------------------
Hello everyone,

I hope that you and your families are (and will be) fine and well during this time of a pandemic.


I started writing my elaborated proposal [1] (it have some missing sections) and I would like to know what you think about it.

Is my estimations for the time line are realistic?
Do the mentors prefer a specific contact method (like: slack, skype ..etc) so I can add it (besides the methods I supplied contacts for) ?
Is there is any missing sections that I should provide?

Thanks for you time,
Abdallah

Reply | Threaded
Open this post in threaded view
|

Re: Help in JSON encode/decode project

Abdallah Elshamy
Hello everyone,

I have finished the first draft of my proposal [1]. I also completed my public application [2] and wiki-linked my draft there.
also I gave edit access to my mentor Mr.Kai Ohlhus so he can leave comments there so our communication can be more easy.

I also submitted the draft via google summer of code site.

please let me know your feedback.

Thanks for your time,
Abdallah

Reply | Threaded
Open this post in threaded view
|

Re: Help in JSON encode/decode project

Abdallah Elshamy
Hello everyone,

I made a mistake in link sharing and copied the link with  “Anyone with the link can view” instead of “Anyone with the link can comment”.
I am very sorry for that.

This is the link with comment rights [1]. I also corrected it in my public application [2].

I also corrected the link in google summer of code site. (does it get updated?)

I added more details to the implementation approach.
Please, tell me what you think about them and about the timeline.

again sorry for that mistake.

Thanks for your time,
Abdallah

Reply | Threaded
Open this post in threaded view
|

Re: Help in JSON encode/decode project

siko1056
On 3/24/20 4:07 AM, Abdallah Elshamy wrote:

> Hello everyone,
>
> I made a mistake in link sharing and copied the link with  “Anyone with
> the link can view” instead of *“Anyone with the link can comment”.*
> I am very sorry for that.
>
> This is the link with comment rights [1]. I also corrected it in my
> public application [2].
>
> I also corrected the link in google summer of code site. (does it get
> updated?)
>
> I added more details to the implementation approach.
> Please, tell me what you think about them and about the timeline.
>
> again sorry for that mistake.
>
> Thanks for your time,
> Abdallah
>
> [1] https://docs.google.com/document/d/1wmQVZseVSDv6I33449r8hCDG1DmM1hei0zdkZspDpTQ/edit?usp=sharing
>
> [2] https://wiki.octave.org/User:Abdallah_Elshamy
> **


Dear Abdallah,

Sorry for the delay.  Your proposal [1] looks good to me.  I already had
a look before and now added some comments, in general cosmetics.  If you
revisit [2], there are some spelling errors (mostly upper/lower case).

Your proposal was already discussed here on the mailing-list, thus I am
still fine with it.  I received an email, that the GSoC timeline [3] was
modified (not dramatically).  Please make sure to meet the new dates.

Best wishes,

Kai


[3] https://summerofcode.withgoogle.com/how-it-works/#timeline

Reply | Threaded
Open this post in threaded view
|

Re: Help in JSON encode/decode project

Abdallah Elshamy
> I already had a look before and now added some comments, in general cosmetics. 
 I modified the parts that you commented on. Did I miss something in the modifications?

> If you revisit [2], there are some spelling errors (mostly upper/lower case).
 I revisited it and fixed the spelling errors that I could notice.

I received an email, that the GSoC timeline [3] was
modified (not dramatically).  Please make sure to meet the new dates.
I have already updated it. 

Please, let me know if you have any more comments before I submit the proposal.

Thanks for your help and your time,
Abdallah


Reply | Threaded
Open this post in threaded view
|

Re: Help in JSON encode/decode project

siko1056
On 3/28/20 4:42 AM, Abdallah Elshamy wrote:
>
> Please, let me know if you have any more comments before I submit the
> proposal.
>
> Thanks for your help and your time,
> Abdallah
>

Thank you for updating your proposal.  Nothing more from my side.  Feel
free to submit.

Kai