-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
abbreviated output for data.frame is wrong #28
Comments
It's possible I broke this when I was fixing things in the array abbreviating function. Can you tell me more about how this output is wrong? In particular, I'm not sure I understand the phrase "the index is not showing the right numbers but the numbers in the current data frame". |
I would expect that the index shows the row number in the old dataframe or none. So 1 |
I think this was fixed along with #31. @JanSchulz, can you confirm? |
Nope, still the same behavior, I think I tracked it down to the use of the readr package: ensure.package("dplyr")
ensure.package("readr")
df = data.frame(a=c(1:1000, 1111111111111), b=1:1001)
write_csv(df, "test_delete.csv")
df2 = read_csv("test_delete.csv")
#df2 %>% select(a) %>% glimpse()
df %>% select(a) # ok
df2 %>% select(a) # no ok... |
Interesting, thanks. I think it's something with the way repr shortens dplyr's library(dplyr)
df <- data.frame(a=c(1:1000, 111111), b=1:1001)
df2 <- tbl_df(df)
df # ok
df2 # not ok |
The problem is that dplyr automatically reassigns row names, which makes a ton of sense, but causes a bit of hassle here. The problem should be fixed whenever my current set of commits is merged in. (#32) |
Confirmed as fixed in a dataframe and with dplyr. Closing. @karldw Thanks! |
Ok, I take that back: library("dplyr")
options(jupyter.log_level = 3)
options(jupyter.rich_display = FALSE)
data.frame(a=1:200, b=201:400) %>% select(a)
[... shortend...]
27 27
28 28
29 29
30 30
<U+22EE> <U+22EE>
171 171
172 172
173 173
174 174
[...shortend...] In the html output it's fine... |
Is this #21? |
OK, looks like it. thanks! |
Oups, yes... should go home... |
Ok, it doesn't look like #21 will be fixed soon, so we should change the char: r-lib/evaluate#66 (comment) |
nooooooooooooooooooooooooooooooooooooooooooooooooooo |
no |
no fucking windows preventing us from having pretty things. if you want you can create code that detects if the character is supported and replaces it if it isn’t. with your strlen checking, there’s a good avenue for this. like: ellip.h <- if (strlen('\u22EF') == 1) '\u22EF' else '...'
ellip.v <- if (strlen('\u22EE') == 1) '\u22EE' else ellip.h
ellip.d <- if (strlen('\u22F1') == 1) '\u22F1' else '' |
This check doesn't work, you would have to print it in a capture.output... Is it such a problem to just use three dots? |
yes! we can encapsulate the correct check in a function: char_fallback <- function(char, default) {
real_len <- nchar(char)
r_len <- nchar(capture.output(cat(char))
if (real_len == r_len) char else default
}
ellip.h <- char_fallback('\u22EF', '...')
ellip.v <- char_fallback('\u22EE', ellip.h)
ellip.d <- char_fallback('\u22F1', '') would that be correct? |
This works on my windows box: char_fallback <- function(char, default) {
real_len <- nchar(char)
r_len <- nchar(capture.output(cat(char)))
if (real_len == r_len) char else default
}
ellip.h <- char_fallback('\u22EF', '...')
ellip.v <- char_fallback('\u22EE', ellip.h)
ellip.d <- char_fallback('\u22F1', '') If you go that way, you could also do something like this in the executer: if(.Platform$OS.type == "windows") {
issue_warning_if_bad_unicode <- function(code){
real_len <- nchar(code)
r_len <- nchar(capture.output(cat(code)))
if (real_len != r_len){
# Whatever is the right method here...
display_error("Your code contains a unicode char which is not displayable in your current locale. This can lead to subtile errors if you use such chars to do comparisons. Please see ...")
}
}
} else {
# Nothing on other systems
issue_warning_if_bad_unicode <- function(code) NULL
}
issue_warning_if_bad_unicode(code) |
and your idea is to call that function every time something is executed? |
I'm not sure if the warning would end up in the right place in the frontend... -> Similar to handle_display_error: if (!silent) {
send_response('stream', request, 'iopub', list(
name = 'stderr',
text = msg))
}
Yes, only on windows and maybe configurable. I'm a big fan of "explicit error messages": better do a check too many (or a fallback) than getting obscure error messages (or even silent errors, like here) in places where it's not obvious what went wrong... |
ah, good. we should create a |
more |
If you want, just go ahead, I won't work on this until wednesday evening... |
Ok, on it... |
👍 sorry, wasn’t in the mood |
On windows, ellipses are usually outside the chars which can be displayed in our way to display plain text /with `capture.output(print(...))` in the current locale. The leads to strangely escaped chars and we would have such a escaped chars each time we display a dataframe. This problem is probably not going away soon: IRkernel#28 (comment) Work around this by simple using three dots.
On windows, ellipses are usually outside the chars which can be displayed in our way to display plain text /with `capture.output(print(...))` in the current locale. The leads to strangely escaped chars and we would have such a escaped chars each time we display a dataframe. This problem is probably not going away soon: IRkernel#28 (comment) Work around this by simple using three dots.
On windows, ellipses are usually outside the chars which can be displayed in our way to display plain text /with `capture.output(print(...))` in the current locale. The leads to strangely escaped chars and we would have such a escaped chars each time we display a dataframe. This problem is probably not going away soon: IRkernel#28 (comment) Work around this by simple using three dots.
On windows, ellipses are usually outside the chars which can be displayed in our way to display plain text /with `capture.output(print(...))` in the current locale. The leads to strangely escaped chars and we would have such a escaped chars each time we display a dataframe. This problem is probably not going away soon: IRkernel#28 (comment) Work around this by simple using three dots.
I've a data frame (> 100 rows) which is abbreviated when I print it with
full_df %>% select(raw_lname, raw_fname)
. But the index is not showing the right numbers but the numbers in the current data frame:-> It doesn't show the real row number but the one from the printed frame :-(
The text was updated successfully, but these errors were encountered: