mirage / ezjsonm Goto Github PK

AFAIK JSOO optimizes only self-tail-calls so Ezjsonm.value_from_string fails on biggish values with stack-overflow (at least at 20 KB json for me on chrome & firefox)

I have an imperative implementation here that fixes the problem for my case (one self-tail-call actually):
https://github.com/tqtezos/TZComet/pull/8/files

It's way longer & messier, and could have some subtle bug I haven't hit yet.
And fixes a problem only in the JSOO case.

Is a PR for this something that you'd be interested in?

#31 raises a valid question but doesn't go far enough. :)

Trying to parse Ezjsonm.from_string "1" should not throw any errors at all, it should return Float 1.0.

According to https://www.json.org/json-en.html , the start symbol of the grammar is "element" which is "whitespace? value whitespace?". This means bare primitive values like 1 or "hello world" are valid JSON.

That's also how most JSON libraries for other languages behave.

Another problem with the current approach is that if you are destructuring a JSON value, you cannot use to_string to to print a a value.

Sexplib expects very specific naming conventions to be able to further build up sexp-converters for other types. As such, it would be great if you could add aliases called sexp_of_t and t_of_sexp for the to_sexp and of_sexp functions, respectively.

ezjsonm appears to build with sexplib 113.24.00, but the upper bound on opam-repository is 113.01.00 . Is there a runtime problem? If not, can the upper bound on opam-repository be updated to 113.25.00 ?

Encoded arbitrary strings can fail to be parsed back:

# let teeshow s = Printf.printf "-> %S\n%!" s; s;;
val teeshow : string -> string = <fun>
# let x = Ezjsonm.(value_from_string (value_to_string (`String "\xbe") |> teeshow));;
-> "\"\190\""
Exception:
Ezjsonm.Parse_error (`Null,
 "JSON.of_buffer illegal bytes in character stream (BE)").

In value_to_src `String _ Ezjsonm.values are passed directly to Jsonm.encode e (`Lexeme l).

The Jsonm documentation says:

Only the UTF-8 encoding scheme is supported. The strings of encoded `Name and `String lexemes are assumed to be immutable and must be UTF-8 encoded, this is not checked by the module.

Should Ezjsonm fail earlier, at encoding time?

Testing with OCaml 4.04.2 and ezjsonm 0.5.0 from opam:

─utop # Ezjsonm.from_string "1";;
Exception: Assert_failure ("lib/ezjsonm.ml", 58, 59).

I know (ez)jsonm requires a wrapping array/object but an assertion failure seems worth reporting.

Wouldn't it make sense to have a variation on 'find' that returns an option instead of raising an error when no element is found?

• I like to have the possibility to read documentation without having to generate it.
• Github pages are perfect for this purpose.
• Ezjsonm does not provide any known online documentation.

So, I started to add a rule to Makefile to generate documention and push it to gh-pages, and ended with a script (https://github.com/sagotch/ghpup), because the Makefile rule was a mess...

You can see it "in action" on my fork, where I used it to generate github pages for Ezjsonm (https://github.com/sagotch/ezjsonm/blob/master/Makefile#L54).

If you want to merge the script into mirage/ezjsonm, it would be with great pleasure. If you do not, gh-pages branch still is a good idea. :)

The accessor functions raise exceptions when their preconditions are not met. What is your take on an additional interface, maybe in a submodule Opt or similar, which returns option values instead? I believe this would facilitate using Option.bind quite nicely and monadic error handling. Given the dynamic nature of JSON values, error handling somewhat cumbersome and this could help to make it smoother.

E.g.

# Ezjsonm.to_string (`Float 123.0) ;;
# Ezjsonm.to_string (`String "one two three");;
etc.

All raise Invalid_argument "invalid json text"

Is this a recent change?

I found this issue by using Cow in a Jsoo compiled program to read a json-list of data; and now found that the failure also appears when running the following with Firefox:

Array.(`A (to_list (make 1000 (`O [("bar", `String "baz")]))))
|> Ezjsonm.to_string 

The problem doesn't seem to appear with Chromium. Guess it might as well be an issue with Firefox not handling recursion properly...

Building with Lwt support fails with "Error: Unbound module Lwt.Infix"
To reproduce:

 > ./configure --enable-lwt
 > make

Output is:

ocaml setup.ml -build 
Finished, 1 target (0 cached) in 00:00:00.
File "_tags", line 28, characters 22-34:
Warning: the tag "pkg_alcotest" is not used in any flag or dependency declaration, so it will have no effect; it may be a typo. Otherwise you can use `mark_tag_used` in your myocamlbuild.ml to disable this warning.
File "_tags", line 37, characters 23-35:
Warning: the tag "pkg_alcotest" is not used in any flag or dependency declaration, so it will have no effect; it may be a typo. Otherwise you can use `mark_tag_used` in your myocamlbuild.ml to disable this warning.
+ /Users/juan.chanco/.opam/4.02.3/bin/ocamlfind ocamlc -c -g -annot -bin-annot -I lib -package hex -package jsonm -package lwt -package sexplib -package uutf -I lib -o lib/ezjsonm_lwt.cmo lib/ezjsonm_lwt.ml
File "lib/ezjsonm_lwt.ml", line 17, characters 5-14:
Error: Unbound module Lwt.Infix
Command exited with code 2.
Compilation unsuccessful after building 12 targets (0 cached) in 00:00:00.
E: Failure("Command ''/Users/juan.chanco/.opam/4.02.3/bin/ocamlbuild' lib/ezjsonm.cma lib/ezjsonm.cmxa lib/ezjsonm.a lib/ezjsonm.cmxs lib/ezjsonm-lwt.cma lib/ezjsonm-lwt.cmxa lib/ezjsonm-lwt.a lib/ezjsonm-lwt.cmxs -tag debug' terminated with error code 10")
make: *** [build] Error 1

Alternately, installing with opam fails similarly:

> opam install lwt ezjsonm

that includes the fixed for js_of_ocaml