search for: r_visibl

Hello list I have problems with little (see Debian package, r. instead R), I get an error message relate with the symbol R_Visible, it say that it is unknown. The same error I got from the Front-off or IDE for KDE (see debian packages, I really don't remember the name., it is rk... and else) How to solve this problem??? What is this symbol (R_Visible) is an internal variable??? I was trying with .Internal(...

...and haven't worked with r, yet, so please pardon any things I do not know... I tried installing r on my computer, and didn't manage to get the program running. After having installed littler, typing r into the bash results in following message: r: symbol lookup error: r: undefined symbol: R_Visible I found a bugreport here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=418686 I'm not sure, if this has anything to do with it, as it concerns rkward... Anyway, this information might come handy: my system: ubuntu 7.10 Kernel 2.6.22-14-generic GNOME 2.20.1 installed packages: r-base 2.7...

...but can > be reliably repaired [3]) and doesn't work for sub-classes of > data.table [4]. > > Is it feasible for R to consider allowing methods for `[` to set their > own visibility flag at this point? The change is deceptively small: set > 'eval' to 200 in names.c and R_Visible = TRUE before returning from the > non-method-dispatch branch in do_subset(). This results in one change > in the saved output of R's own tests/reg-S4.R [5]. Or is the potential > breakage for existing code too prohibitive? > > -- > Best regards, > Ivan > > [1] >...

...broke after a knitr update (but can be reliably repaired [3]) and doesn't work for sub-classes of data.table [4]. Is it feasible for R to consider allowing methods for `[` to set their own visibility flag at this point? The change is deceptively small: set 'eval' to 200 in names.c and R_Visible = TRUE before returning from the non-method-dispatch branch in do_subset(). This results in one change in the saved output of R's own tests/reg-S4.R [5]. Or is the potential breakage for existing code too prohibitive? -- Best regards, Ivan [1] https://github.com/Rdatatable/data.table/blob/e...

On Thu, 24 Oct 2024 13:23:56 -0400 Toby Hocking <tdhock5 at gmail.com> wrote: > The patch you are proposing to base R is > https://github.com/Rdatatable/data.table/issues/6566#issuecomment-2428912338 > right? Yes, it's this one, thank you for providing the link. Surprisingly, a very cursory check of 100 packages most downloaded from cloud.r-project.org in the last month

My message below sounds a little aggressive, I apologize in advance for that. But I can't think of better wording. This is a small change, which will have a small benefit, mainly for the data.table authors, who really brought it on themselves by choosing to (ab)use R extraction syntax to have side effects. Surely you or they should be the ones to run the test across all of CRAN? Duncan

? Fri, 25 Oct 2024 08:39:39 -0400 Duncan Murdoch <murdoch.duncan at gmail.com> ?????: > Surely you or they should be the ones to run the test across all of > CRAN? That's fair. The question is, is there a fundamental reason I overlooked to deny such a change? Except for positioning and whitespace, the line has been in names.c since SVN revision 2. The one regression test touched

On Fri, 25 Oct 2024, Ivan Krylov via R-devel wrote: > ? Fri, 25 Oct 2024 08:39:39 -0400 > Duncan Murdoch <murdoch.duncan at gmail.com> ?????: > >> Surely you or they should be the ones to run the test across all of >> CRAN? > > That's fair. The question is, is there a fundamental reason I > overlooked to deny such a change? Except for positioning and >

...9;d probably agree that such a function could be a nice asset in R, notably if it was possible to do this on the fast C level of R's main REPL. Have any of you looked into how this could be provided in R ? If you know the source a little, you will remember that there's the global variable R_Visible which is crucial here. The problem with that is that it *is* global, and only available as that; that the auto-printing "concept" is so linked to "toplevel context" and that is not easy, and AFAIK not so much centralized in one place in the source. Consequently, all kind of (v...

...al(). Print stage: - Frontends may want to always print the result of evaluation for some statements, they may want to suppress printing entirely for some (internal) statement, but most importantly, they will probably want to auto-print values for most statements (i.e. print them if and only if R_Visible is TRUE). - There does not seem to be a good way (from the C-API) to do auto-printing of values outside of R_ReplDLLdo1(): R_Visible is not exported any longer, and PrintValueEnv() is neither. Rf_PrintValue() should yield the same results as PrintValueEnv() in most, but probably not all cases....

...ce asset in R, >> notably if it was possible to do this on the fast C level of R's main >> REPL. >> >> Have any of you looked into how this could be provided in R ? >> If you know the source a little, you will remember that there's >> the global variable R_Visible which is crucial here. >> The problem with that is that it *is* global, and only available >> as that; that the auto-printing "concept" is so linked to "toplevel >> context" >> and that is not easy, and AFAIK not so much centralized in one place >&...

...t; notably if it was possible to do this on the fast C level of R's main >> REPL. >> >> Have any of you looked into how this could be provided in R ? >> If you know the source a little, you will remember that there's >> the global variable R_Visible which is crucial here. >> The problem with that is that it *is* global, and only available >> as that; that the auto-printing "concept" is so linked to "toplevel >> context" >> and that is not easy, and AFAIK not so much centralized in o...

...ction > could be a nice asset in R, > notably if it was possible to do this on the fast C level of R's main > REPL. > > Have any of you looked into how this could be provided in R ? > If you know the source a little, you will remember that there's > the global variable R_Visible which is crucial here. > The problem with that is that it *is* global, and only available > as that; that the auto-printing "concept" is so linked to "toplevel context" > and that is not easy, and AFAIK not so much centralized in one place in the > source. Conseque...

...the fast C level of R's main >> >> REPL. >> >> >> >> Have any of you looked into how this could be provided in R ? >> >> If you know the source a little, you will remember that there's >> >> the global variable R_Visible which is crucial here. >> >> The problem with that is that it *is* global, and only available >> >> as that; that the auto-printing "concept" is so linked to "toplevel >> >> context" >> >> and that is not easy, an...

...ction > could be a nice asset in R, > notably if it was possible to do this on the fast C level of R's main > REPL. > > Have any of you looked into how this could be provided in R ? > If you know the source a little, you will remember that there's > the global variable R_Visible which is crucial here. > The problem with that is that it *is* global, and only available > as that; that the auto-printing "concept" is so linked to "toplevel > context" > and that is not easy, and AFAIK not so much centralized in one place in the > source. Con...

...sible to do this on the fast C level of R's main > >> REPL. > >> > >> Have any of you looked into how this could be provided in R ? > >> If you know the source a little, you will remember that there's > >> the global variable R_Visible which is crucial here. > >> The problem with that is that it *is* global, and only available > >> as that; that the auto-printing "concept" is so linked to "toplevel > >> context" > >> and that is not easy, and AFAIK not so m...

On 06-Nov-97 maechler@stat.math.ethz.ch wrote: >I investigated some more: > R_VISIBLE is set to 0 ``R_Visible = 0;'' > also in other places in eval.c : > > line C function > > 344: do_if > 436: do_for > 480: do_while > 515: do_repeat > 720: \ > 727: > do_set > 738: / > ^^^ >(line num...

...a[[t<-'b']] > > Nothing gets printed! > > I need to use parenthesis to see the expected result: > > > a[[(t<-'b')]] > [1] 5 Yes, I agree it looks like a bug, and it's still there in R-devel. The problem is that the assignment sets the R_Visible flag to false, and the indexing never sets it to true. The same problem happens with a[t <- 'b'], whether a is a list or not: > a <- c(b=5, c=6, d=7) > a[t <- 'b'] > .Last.value b 5 Duncan Murdoch

1. File is (was) saved. 2. The added code is t(tradeStats("macross")) with 2 )'s. I'd appreciate if someone with QuantStrat installed, to try this and see if they get a different result. My R and RStudio and QuantStrat libraries are all current. I get the chart and this much output. > source('~/CodingData/RCode/Quantstrat1/maCross.R') [1] "2001-06-27

1. File is (was) saved. 2. The added code is t(tradeStats("macross")) with 2 )'s. I'd appreciate if someone with QuantStrat installed, to try this and see if they get a different result. My R and RStudio and QuantStrat libraries are all current. I get the chart and this much output. > source('~/CodingData/RCode/Quantstrat1/maCross.R') [1] "2001-06-27