octave-patch-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-patch-tracker] [patch #9980] JSON encoder and decoder, alternati


From: anonymous
Subject: [Octave-patch-tracker] [patch #9980] JSON encoder and decoder, alternative to object2json
Date: Mon, 20 Dec 2021 16:17:58 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:95.0) Gecko/20100101 Firefox/95.0

Follow-up Comment #53, patch #9980 (project octave):

Per your goal, on testing 'fromJSON' on random JSON files, I collected all the
JSON files on my linux sys with something akin:


mkdir(td="/tmp/test");
system(['find ~ -name "*.json" -exec cp {} "' td '" \;']);

lastwarn('');

for f=dir([td "/*.json"])';
  if( f.bytes < 1e6 );
    printf("\r%8d  %40s",f.bytes, f.name);
    fid=fopen([td '/' f.name]);
    fromJSON( fread(fid,'*char')' );
    lastwarn && printf("\n") && lastwarn('');
    fclose(fid);
  end
end;


This can detect 'fromJSON' parsing errors (via warnings), not necessarily
mangled outputs.   Nor is this strictly valid, in that I came across some
files that were not strictly valid JSON; e.g. some files had c-style comment
(with an explicit warning to remove all non-JSON c-style comments 😂). 

On that note, I did find another bug (where firefox uses an URL for a object
key, UGH!), which is now fixed (to be uploaded later).

Testing for accuracy in 'toJSON' or 'fromJSON' is tough, for two reasons:
whitespace and floating-point numbers precision.

With random JSON files, I tried doing something on the order of: 

  strcmp(json, toJSON(fromJSON(json)))


but 
* some JSON string will be beautified with whitespace: extraneous spaces and
newline for human use only (not for parsing).    'toJSON' doesn't beautify,
nor can it replicated the limitless permutation that may been used in the
original JSON string.  (and uglifying random JSON files is non-trivial).

* some JSON have floating point number strings that push the limit of 64-bit
FP precision.  Converting back and forth doesn't guarantee the EXACT same FP
number string.

Let me look into how to do comparison using NodeJS. If I figure out something,
I will upload a NodeJS script, along with the aforementioned bug fix.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/patch/?9980>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]