Closed LTLA closed 3 years ago
Thanks for the message, and in particular for the V8::engine_info
output indicating a failing version. I am just trying to sort out a reproducible environment with a sufficiently ancient libv8/libnode to trigger this, the likely fix is straightforward and will be updated shortly.
I hope the fix will be on github in the next couple of days, CRAN shortly after depending on how intransigent they feel like being as there's also an ireproducible error on a bespoke fedora system.
Hello
On my side, I've V8::engine_info()
== "3.14.5.10"
.
json_validate()
works fine in version 1.1.0 of {jsonvalidate} but not in version 1.3.1 (I could change the version of the package using devtools::install_version()
).
Thus I don't think the issue comes from V8.
I hope it helps
Thank you
To give you more context:
Here is what I get with version 1.3.1
library(jsonvalidate)
V8::engine_info()
#> $version
#> [1] "3.14.5.10"
example("json_validate")
#>
#> jsn_vl> # A simple schema example:
#> jsn_vl> schema <- '{
#> jsn_vl+ "$schema": "http://json-schema.org/draft-04/schema#",
#> jsn_vl+ "title": "Product",
#> jsn_vl+ "description": "A product from Acme\'s catalog",
#> jsn_vl+ "type": "object",
#> jsn_vl+ "properties": {
#> jsn_vl+ "id": {
#> jsn_vl+ "description": "The unique identifier for a product",
#> jsn_vl+ "type": "integer"
#> jsn_vl+ },
#> jsn_vl+ "name": {
#> jsn_vl+ "description": "Name of the product",
#> jsn_vl+ "type": "string"
#> jsn_vl+ },
#> jsn_vl+ "price": {
#> jsn_vl+ "type": "number",
#> jsn_vl+ "minimum": 0,
#> jsn_vl+ "exclusiveMinimum": true
#> jsn_vl+ },
#> jsn_vl+ "tags": {
#> jsn_vl+ "type": "array",
#> jsn_vl+ "items": {
#> jsn_vl+ "type": "string"
#> jsn_vl+ },
#> jsn_vl+ "minItems": 1,
#> jsn_vl+ "uniqueItems": true
#> jsn_vl+ }
#> jsn_vl+ },
#> jsn_vl+ "required": ["id", "name", "price"]
#> jsn_vl+ }'
#>
#> jsn_vl> # Test if some (invalid) json conforms to the schema
#> jsn_vl> jsonvalidate::json_validate("{}", schema, verbose = TRUE)
#> Error in context_eval(join(src), private$context, serialize): SyntaxError: Use of const in strict mode.
sessionInfo()
#> R version 4.1.1 (2021-08-10)
#> Platform: x86_64-pc-linux-gnu (64-bit)
#> Running under: Red Hat Enterprise Linux
#>
#> Matrix products: default
#> BLAS/LAPACK: /usr/lib64/libopenblasp-r0.3.3.so
#>
#> locale:
#> [1] LC_CTYPE=en_GB.UTF-8 LC_NUMERIC=C
#> [3] LC_TIME=en_GB.UTF-8 LC_COLLATE=en_GB.UTF-8
#> [5] LC_MONETARY=en_GB.UTF-8 LC_MESSAGES=en_GB.UTF-8
#> [7] LC_PAPER=en_GB.UTF-8 LC_NAME=C
#> [9] LC_ADDRESS=C LC_TELEPHONE=C
#> [11] LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=C
#>
#> attached base packages:
#> [1] stats graphics grDevices utils datasets methods base
#>
#> other attached packages:
#> [1] jsonvalidate_1.3.1
#>
#> loaded via a namespace (and not attached):
#> [1] Rcpp_1.0.7 V8_3.4.2 digest_0.6.28 withr_2.4.2
#> [5] jsonlite_1.7.2 magrittr_2.0.1 reprex_2.0.1 evaluate_0.14
#> [9] highr_0.9 stringi_1.7.5 rlang_0.4.12 cli_3.0.1
#> [13] curl_4.3.2 rstudioapi_0.13 fs_1.5.0 rmarkdown_2.11
#> [17] tools_4.1.1 stringr_1.4.0 glue_1.4.2 xfun_0.27
#> [21] yaml_2.2.1 fastmap_1.1.0 compiler_4.1.1 htmltools_0.5.2
#> [25] knitr_1.36
And here is what I get with version 1.1.0
library(jsonvalidate)
V8::engine_info()
#> $version
#> [1] "3.14.5.10"
example("json_validate")
#>
#> jsn_vl> # A simple schema example:
#> jsn_vl> schema <- '{
#> jsn_vl+ "$schema": "http://json-schema.org/draft-04/schema#",
#> jsn_vl+ "title": "Product",
#> jsn_vl+ "description": "A product from Acme\'s catalog",
#> jsn_vl+ "type": "object",
#> jsn_vl+ "properties": {
#> jsn_vl+ "id": {
#> jsn_vl+ "description": "The unique identifier for a product",
#> jsn_vl+ "type": "integer"
#> jsn_vl+ },
#> jsn_vl+ "name": {
#> jsn_vl+ "description": "Name of the product",
#> jsn_vl+ "type": "string"
#> jsn_vl+ },
#> jsn_vl+ "price": {
#> jsn_vl+ "type": "number",
#> jsn_vl+ "minimum": 0,
#> jsn_vl+ "exclusiveMinimum": true
#> jsn_vl+ },
#> jsn_vl+ "tags": {
#> jsn_vl+ "type": "array",
#> jsn_vl+ "items": {
#> jsn_vl+ "type": "string"
#> jsn_vl+ },
#> jsn_vl+ "minItems": 1,
#> jsn_vl+ "uniqueItems": true
#> jsn_vl+ }
#> jsn_vl+ },
#> jsn_vl+ "required": ["id", "name", "price"]
#> jsn_vl+ }'
#>
#> jsn_vl> # Test if some (invalid) json conforms to the schema
#> jsn_vl> jsonvalidate::json_validate("{}", schema, verbose = TRUE)
#> [1] FALSE
#> attr(,"errors")
#> field message
#> 1 data.id is required
#> 2 data.name is required
#> 3 data.price is required
#>
#> jsn_vl> # Test if some (valid) json conforms to the schema
#> jsn_vl> jsonvalidate::json_validate('{
#> jsn_vl+ "id": 1,
#> jsn_vl+ "name": "A green door",
#> jsn_vl+ "price": 12.50,
#> jsn_vl+ "tags": ["home", "green"]
#> jsn_vl+ }', schema)
#> [1] TRUE
sessionInfo()
#> R version 4.1.1 (2021-08-10)
#> Platform: x86_64-pc-linux-gnu (64-bit)
#> Running under: Red Hat Enterprise Linux
#>
#> Matrix products: default
#> BLAS/LAPACK: /usr/lib64/libopenblasp-r0.3.3.so
#>
#> locale:
#> [1] LC_CTYPE=en_GB.UTF-8 LC_NUMERIC=C
#> [3] LC_TIME=en_GB.UTF-8 LC_COLLATE=en_GB.UTF-8
#> [5] LC_MONETARY=en_GB.UTF-8 LC_MESSAGES=en_GB.UTF-8
#> [7] LC_PAPER=en_GB.UTF-8 LC_NAME=C
#> [9] LC_ADDRESS=C LC_TELEPHONE=C
#> [11] LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=C
#>
#> attached base packages:
#> [1] stats graphics grDevices utils datasets methods base
#>
#> other attached packages:
#> [1] jsonvalidate_1.1.0
#>
#> loaded via a namespace (and not attached):
#> [1] Rcpp_1.0.7 V8_3.4.2 digest_0.6.28 withr_2.4.2
#> [5] jsonlite_1.7.2 magrittr_2.0.1 reprex_2.0.1 evaluate_0.14
#> [9] highr_0.9 stringi_1.7.5 rlang_0.4.12 cli_3.0.1
#> [13] curl_4.3.2 rstudioapi_0.13 fs_1.5.0 rmarkdown_2.11
#> [17] tools_4.1.1 stringr_1.4.0 glue_1.4.2 xfun_0.27
#> [21] yaml_2.2.1 fastmap_1.1.0 compiler_4.1.1 htmltools_0.5.2
#> [25] knitr_1.36
The issue comes because jsonvalidate 1.3.1 uses ES6 code that is not compatible with the "legacy" version of v8 (3.14.x). Despite being really very old this is the version installed by default on ubuntu 18.04 so not that uncommon in the wild.
We're working on a fix, but as you've seen installing the previous version will make the issue disappear
Ah I see. That the same on RHEL7. Unfortunately, not that uncommon as you say... Thank you
Hi @LTLA and @patzaw, any chance you could check the version on branch i51-cran-update
(e.g., with remotes remotes::install_github("ropensci/jsonvalidate@i51-cran-update", upgrade = FALSE)
- this version (1.3.2) should fix the errors you are seeing.
Hi
It looks OK on my side with branch i51-cran-update
library(jsonvalidate)
V8::engine_info()
#> $version
#> [1] "3.14.5.10"
example("json_validate")
#>
#> jsn_vl> # A simple schema example:
#> jsn_vl> schema <- '{
#> jsn_vl+ "$schema": "http://json-schema.org/draft-04/schema#",
#> jsn_vl+ "title": "Product",
#> jsn_vl+ "description": "A product from Acme\'s catalog",
#> jsn_vl+ "type": "object",
#> jsn_vl+ "properties": {
#> jsn_vl+ "id": {
#> jsn_vl+ "description": "The unique identifier for a product",
#> jsn_vl+ "type": "integer"
#> jsn_vl+ },
#> jsn_vl+ "name": {
#> jsn_vl+ "description": "Name of the product",
#> jsn_vl+ "type": "string"
#> jsn_vl+ },
#> jsn_vl+ "price": {
#> jsn_vl+ "type": "number",
#> jsn_vl+ "minimum": 0,
#> jsn_vl+ "exclusiveMinimum": true
#> jsn_vl+ },
#> jsn_vl+ "tags": {
#> jsn_vl+ "type": "array",
#> jsn_vl+ "items": {
#> jsn_vl+ "type": "string"
#> jsn_vl+ },
#> jsn_vl+ "minItems": 1,
#> jsn_vl+ "uniqueItems": true
#> jsn_vl+ }
#> jsn_vl+ },
#> jsn_vl+ "required": ["id", "name", "price"]
#> jsn_vl+ }'
#>
#> jsn_vl> # Test if some (invalid) json conforms to the schema
#> jsn_vl> jsonvalidate::json_validate("{}", schema, verbose = TRUE)
#> [1] FALSE
#> attr(,"errors")
#> field message
#> 1 data.id is required
#> 2 data.name is required
#> 3 data.price is required
#>
#> jsn_vl> # Test if some (valid) json conforms to the schema
#> jsn_vl> json <- '{
#> jsn_vl+ "id": 1,
#> jsn_vl+ "name": "A green door",
#> jsn_vl+ "price": 12.50,
#> jsn_vl+ "tags": ["home", "green"]
#> jsn_vl+ }'
#>
#> jsn_vl> jsonvalidate::json_validate(json, schema)
#> [1] TRUE
#>
#> jsn_vl> # Test a fraction of a data against a reference into the schema:
#> jsn_vl> jsonvalidate::json_validate(json, schema,
#> jsn_vl+ query = "tags", reference = "#/properties/tags",
#> jsn_vl+ engine = "ajv", verbose = TRUE)
#> [1] TRUE
sessionInfo()
#> R version 4.1.1 (2021-08-10)
#> Platform: x86_64-pc-linux-gnu (64-bit)
#> Running under: Red Hat Enterprise Linux
#>
#> Matrix products: default
#> BLAS/LAPACK: /usr/lib64/libopenblasp-r0.3.3.so
#>
#> locale:
#> [1] LC_CTYPE=en_GB.UTF-8 LC_NUMERIC=C
#> [3] LC_TIME=en_GB.UTF-8 LC_COLLATE=en_GB.UTF-8
#> [5] LC_MONETARY=en_GB.UTF-8 LC_MESSAGES=en_GB.UTF-8
#> [7] LC_PAPER=en_GB.UTF-8 LC_NAME=C
#> [9] LC_ADDRESS=C LC_TELEPHONE=C
#> [11] LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=C
#>
#> attached base packages:
#> [1] stats graphics grDevices utils datasets methods base
#>
#> other attached packages:
#> [1] jsonvalidate_1.3.2
#>
#> loaded via a namespace (and not attached):
#> [1] Rcpp_1.0.7 V8_3.4.2 digest_0.6.28 withr_2.4.2
#> [5] jsonlite_1.7.2 magrittr_2.0.1 reprex_2.0.1 evaluate_0.14
#> [9] highr_0.9 stringi_1.7.5 rlang_0.4.12 cli_3.0.1
#> [13] curl_4.3.2 rstudioapi_0.13 fs_1.5.0 rmarkdown_2.11
#> [17] tools_4.1.1 stringr_1.4.0 glue_1.4.2 xfun_0.27
#> [21] yaml_2.2.1 fastmap_1.1.0 compiler_4.1.1 htmltools_0.5.2
#> [25] knitr_1.36
Looks good on my end as well.
Thanks both - still trying to track down a really weird error on one exotic platform (https://github.com/jeroen/V8/issues/128) but will get this updated on CRAN next week
FWIW, I ran into this for a few revdepcheck packages checked on an up-to-date CentOS 7.9.2009 system. I've got:
$ ls -l /lib64/ | grep -F libv8.
lrwxrwxrwx 1 root root 15 Oct 4 16:07 libv8.so -> libv8.so.3.14.5
lrwxrwxrwx 1 root root 15 Oct 4 16:06 libv8.so.3 -> libv8.so.3.14.5
lrwxrwxrwx 1 root root 15 Oct 4 16:06 libv8.so.3.14 -> libv8.so.3.14.5
-rwxr-xr-x 1 root root 5852272 Jul 26 2016 libv8.so.3.14.5
Thanks Henrik, the fix is good to go, just need to understand a crash on a machine that Brian has that I can't easily reproduce (possibly related to the above, though of course information from CRAN is not forthcoming). That will delay a fix, and/or result in the test suite being disabled on CRAN going forward which is not something I want to do lightly
Hi, Thanks for this useful package.
I am using jsonvalidate to validate a JSON file in the following package: RstoxFramework Checks have been failing run on Ubuntu, Mac and Windows over the last week, as seen here: 142 The checks first failed on Ubuntu and Mac, then on Windows with R 3.6 and the latest R, and then this morning on Windows with R 4.0.
On Ubuntu I get the same <
Is there a time frame on this being fixed on CRAN. Pressure is increasing on my side..
Can you please try the fix as in this comment and let me know if it works.
I aim to submit to CRAN tomorrow once Jeroen is back and we can look at the other CRAN complaint. After that, it's up to them as to whether they accept it
I tested installing the fix in the check-full.yaml (line 125), but problem is still there.
Thanks - that looks like it might be a different problem, your failed builds show:
Error: Error: package or namespace load failed for ‘RstoxFramework’:
.onLoad failed in loadNamespace() for 'RstoxFramework', details:
call: NULL
error: While reading '(string)' > '"'
Did not find schema file '"'
Error: Error: loading failed
Execution halted
ERROR: loading failed
* removing ‘/Users/runner/work/RstoxFramework/RstoxFramework/check/RstoxFramework.Rcheck/RstoxFramework’
The machines you have there overlap considerably with the ones that we're using on jsonvalidate's own tests
Ah, I see. The remaining error is something different. Brilliant, then I will fix that error and wait for the new jsonvalidate on CRAN. Thanks.
This is updated on CRAN now, with any luck it will stay there.
The recent jsonvalidate update (1.3.1) on CRAN introduces... something... that causes this error:
It occurs regardless of what the arguments are, because it's happening during the loading of jsonvalidate's
bundle.js
. I'd also guess that it depends on the version of the V8 library; this problem occurs on my HPC servers whereV8::engine_info
reports 3.14.5.9, while my laptop reports 9.1.269.36 and has no such problems.