Open nojnhuh opened 8 years ago
I can't see how Proto REPL might impact this but I might be missing something. What are some values you pass in for n?
It looks like it might be an issue casting to long, biginteger, and bigint type numbers.
user=> (long 8888888888888888888N) 8888888888888889000
user=> (bigint 8888888888888888888N) 8888888888888889000
user=> (biginteger 8888888888888888888N) 8888888888888889000
On Sat, Mar 12, 2016 at 9:17 PM, Jason Gilman notifications@github.com wrote:
I can't see how Proto REPL might impact this but I might be missing something. What are some values you pass in for n?
— Reply to this email directly or view it on GitHub https://github.com/jasongilman/proto-repl/issues/77#issuecomment-195861548 .
You're right. The problem here is with the use of ClojureScript for some helper code. Proto REPL uses ClojureScript to parse the EDN and then Fipp for pretty printing. Pretty printing is turned on by default but you can disable it in the Proto REPL settings. It's the first item listed.
The fix in Proto REPL will probably be to move the pretty print code for Clojure JVM REPLs to the JVM. Fipp can be added as a dependency of the proto-repl Clojure lib that projects should include. That will avoid some of the differences between ClojureScript and Clojure.
I wonder if there is an easy way to add a notice on the results that are different? Is there a way to undo the pretty print and compare it to the original string? Perhaps then alerting the user it might be incorrect, or skipping the pretty print?
After I updated from 0.16 to 1.0.2, the REPL rounds large random values generated by the following method.
(defn rand-bigint [n] (bigint (bigdec (rand n))))
Sample outputs are 22330278046951186000 9009988616622167000 20226490109620277000
It doesn't look like any random number with more than 17 significant figures can be generated.