Test suite issues in version 1.1.5

Hi,
I wanted to upgrade the repr package in Debian. Unfortunately there are some admittedly strange issues where diff creates some differences that do not really look like different strings. The test suite output starts with

══ Failed tests ════════════════════════════════════════════════════════════════
── Failure ('test_escaping.r:49'): LaTeX escaping in matrices works ────────────
repr_latex(matrix(c("[", "{", "%", "#"), 2, 2, TRUE)) (`actual`) not identical to "A matrix: 2 × 2 of type chr\n\\begin{tabular}{ll}\n\t {[} & \\{\\\\\n\t \\% &                     \\#\\\\\n\\end{tabular}\n" (`expected`).
    lines(actual)                 | lines(expected)
[1] "A matrix: 2 x 2 of type chr" - "A matrix: 2 × 2 of type chr" [1]
[2] "\\begin{tabular}{ll}"        | "\\begin{tabular}{ll}"        [2]
[3] "\t {[} & \\{\\\\"            | "\t {[} & \\{\\\\"            [3]
[4] "\t \\% & \\#\\\\"            | "\t \\% & \\#\\\\"            [4]
── Failure ('test_escaping.r:56'): LaTeX escaping in matrices works ────────────
repr_latex(...) (`actual`) not identical to "A matrix: 2 × 2 of type chr\n\\begin{tabular}{r|ll}\n  & \\% & \\textbar{}\\\\\n\\hline\n\t\\$ & {]} & \\}\\\\\n\t\\# & \\& &           \\_\\\\\n\\end{tabular}\n" (`expected`).
    lines(actual)                 | lines(expected)
[1] "A matrix: 2 x 2 of type chr" - "A matrix: 2 × 2 of type chr" [1]
[2] "\\begin{tabular}{r|ll}"      | "\\begin{tabular}{r|ll}"      [2]
[3] "  & \\% & \\textbar{}\\\\"   | "  & \\% & \\textbar{}\\\\"   [3]
[4] "\\hline"                     | "\\hline"                     [4]
── Failure ('test_escaping.r:68'): HTML escaping in matrices works ─────────────
repr_html(matrix(c("[", "{", "%", "#"), 2, 2, TRUE)) (`actual`) not identical to "<table class=\"dataframe\">\n<caption>A matrix: 2 × 2 of type chr</caption>\n<tbody>\n\t<tr><td>[</td><td>{</td></tr>\n\t<tr><td>%</td><td>#</td></tr>\n</tbody>\n</table>\n" (`expected`).
lines(actual)[1:5] vs lines(expected)[1:5]
  "<table class=\"dataframe\">"
- "<caption>A matrix: 2 x 2 of type chr</caption>"
+ "<caption>A matrix: 2 × 2 of type chr</caption>"
  "<tbody>"
  "\t<tr><td>[</td><td>{</td></tr>"
  "\t<tr><td>%</td><td>#</td></tr>"

Feel free to find the full build log in the Debian CI.
Kind regards, Andreas.

I don't have a solution, but the "expected" strings contain ×, U+00D7 MULTIPLICATION SIGN, while the "actual" strings contain x, U+0078 LATIN SMALL LETTER X.

Am Sun, Jan 22, 2023 at 02:49:30AM -0800 schrieb aitap:

I don't have a solution, but the "expected" strings contain `×`, U+00D7 MULTIPLICATION SIGN, while the "actual" strings contain `x`, U+0078 LATIN SMALL LETTER X.

Ahhh, good catch. Does the test work at your site so is it an issue that is specific for the Debian environment at my site? Kind regards, Andreas.

The tests pass on my machine but fail if I set LC_ALL=C with a similar set of error messages. (My system cannot represent \u00d7 when I set LC_ALL=C, so your environment must be using a Latin-1 locale.)

We explicitly set LC_ALL=C.UTF-8 for the test . If I set LC_ALL=en_US.UTF-8 the issue becomes at least obvious:

- "A data.frame: 2 x 6"
+ "A data.frame: 2 \u00d7 6"

I failed with setting LC_ALL=en_US.ISO-8859-1. How is your exact locale setting?
I'd recommend you'd adapt to UTF-8 which is somehow a widely accepted default.
Kind regards, Andreas.

Sorry I wasn't entirely clear. My locale is normally ru_RU.UTF-8, and the tests pass when I'm using that locale. The test also passes if I run it under C.UTF-8 on my Debian oldstable machine. The package uses nchar('\ud7') != nchar(capture.output(cat('\ud7'))) as a test to decide whether to use the fallback character, which shouldn't be failing under C.UTF-8: https://github.com/IRkernel/repr/blob/f51ce4abac9824041cc27fee698e644cd181e059/R/repr_matrix_df.r#L18-L30 What's also interesting is that I can't get the test to fail under LC_ALL=en_GB.iso885915. '×' seems to be at 0xD7 in both ISO-8859-1 and ISO-8859-15, at least according to Wikipedia. Just in case, does your test environment have all the relevant locales generated? Your example looks to me like it doesn't have en_US.UTF-8, which makes the C runtime fall back to "C".

I think what might be happening here is that the package level code here is executed at build time (R packages are compiled to bytecode when building them from source)

Therefore we might be able to improve things by caching the characters at package initialization instead of on package build time.

Please check if the debian CI can handle with the version of this package from #160

Please report here if the problem persists, although I don’t think there’s anything that can be done on the repr side

Am Sun, Jan 22, 2023 at 01:14:44PM -0800 schrieb Philipp A.:

Closed #159 as completed via #160.

It would help a lot if you would do a new point release on CRAN with this fix. Kind regards, Andreas.

I’ll do that once and publish v1.1.6. If you still run into problems there, we’ll have to collaborate in another way, without me pushing speculative fixes, since the CRAN maintainers don’t like frequent updates like that.

Navigation Menu

Repository navigation

Test suite issues in version 1.1.5 #159

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Test suite issues in version 1.1.5 #159

Description

Activity

aitap commented on Jan 22, 2023

tillea commented on Jan 22, 2023

aitap commented on Jan 22, 2023

tillea commented on Jan 22, 2023

aitap commented on Jan 22, 2023

flying-sheep commented on Jan 22, 2023

flying-sheep commented on Jan 22, 2023

tillea commented on Jan 26, 2023

flying-sheep commented on Jan 26, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions