Odd string to F64 parsing bugs in Roc REPL (old_linux_x86_64)

[hristog]

Description

I've been experiencing some odd Str to F64 parsing bugs in the Roc REPL (old_linux_x86_64). The same functionality is working as expected if executed as part of a compiled Roc program.

Environment

I'm running Roc inside a container built from debian:buster-slim.

The Roc version I'm using is a release version from GitHub (i.e., not a locally built one), namely roc_nightly-old_linux_x86_64-2024-03-08-7d51d2b.

Examples

> uname -m
x86_64

> roc version
roc nightly pre-release, built from commit 7d51d2b on Fri Mar  8 09:08:29 UTC 2024

> roc repl

  The rockin' roc repl
────────────────────────

Enter an expression, or :help, or :q to quit.

# ------------------- Examples - Not Ok ------------------- #

» v32bit : F32
… v32bit = 2.5321321

2.5321321 : F32

» v64bit : F64
… v64bit = 2.5321321

2.5321321 : F64

» Num.toStr v64bit |> Str.toF64

Ok 0 : Result F64 [InvalidNumStr] # Not Ok

» Str.toF64 "3" 

Ok 0 : Result F64 [InvalidNumStr] # Not Ok

» str = "2.5321321"

"2.5321321" : Str

» Str.toF64 str

Ok 0 : Result F64 [InvalidNumStr]  # Not Ok

» Str.toF32 "3.39281732" |> Result.withDefault 0 |> Num.toF64

3.392817258834839 : F64 # Not Ok

# ------------------- Examples - Ok ------------------- #

» Num.toStr v32bit

"2.532132148742676" : Str # Ok

» Num.toStr v64bit

"2.5321321" : Str # Ok

» Str.toF32 str

Ok 2.5321321 : Result F32 [InvalidNumStr]  # Ok

» Str.toF32 "3" |> Result.withDefault 0 |> Num.toF64

3 : F64 # Ok