You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To figure out which messages are produced by base:
First, I edited R/test.data.table.R to force foreign=FALSE, then I commented out the setnames call between tests 1904.5 and 1904.6 (it relies on an object that doesn't get created due to test failure), then I ran:
# note: `es` is a language where R has translations but data.table does not,
# meaning DT messages are in English but base are in Spanish
LANGUAGE=es Rscript -e "library(data.table); test.data.table()" > test_failures.txt
There were two cases where the approach here wouldn't work:
test 1671 is testing an error that's generated in C, I don't see a way to generate that directly from R short of writing a short C function solely for this purpose which seems like a bit much. The gettext() approach here is robust to other languages, but not to R's own message changing.
@MichaelChirico Good idea to force foreign=FALSE. But LANGUAGE=zh_CN so our own messages are being translated. How about picking a language that data.table is not translated for (and so data.table will emit English and will pass our English tests) but base R is translated for. Then we will see the base R messages in non-English not matching our English tests which should be a much smaller list.
@mattdowle that worked excellently. I got about halfway done changing things to work across languages before realizing I'd lost the plot of what we're trying to do exactly. Going back over it now. The goal is to make ourselves immune to base message changes, but in the process we can make base errors work regardless of session language as well.
MichaelChirico
changed the title
test commit showing reliance on base error messages
testing is more robust to changes in base messages
May 11, 2021
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Related: #4770
To figure out which messages are produced by base:
First, I edited
R/test.data.table.Rto forceforeign=FALSE, then I commented out thesetnamescall between tests 1904.5 and 1904.6 (it relies on an object that doesn't get created due to test failure), then I ran:There were two cases where the approach here wouldn't work:
.checkTyposrelies on English messages, in non-English.checkTyposcan never return suggested fixes.gettext()approach here is robust to other languages, but not to R's own message changing.