Re: [Rd] Rust bindings to nmath
Thanks for the feedback! > Any chance you could rename it to a more neutral r_mathlib or something? > As a free-standing C library it has long been wrapped by other languages, but > if it were my project I'd be more careful to not imply "all of stats" here. > FWIW in Debian we call it `r-mathlib`. I will rename it to `r-mathlib`. In addition to a more clear name, it will aid discoverability for users if it has the same name as the same thing somewhere else. Thanks for the tip. Rich __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] sys.call() 's srcref doesn't match the language
Dear R-devel,
I found this behavior disturbing, if `1 + f()` is called, `sys.call()`
called inside of `f` will return a quoted `f()` with a "srcref" that prints
"1 + f()".
I don't know which one is good but I don't think they can be correct at the
same time.
Here's a reproducible example:
f <- function(){
sc <- sys.call()
print(sc)
attr(sc, "srcref") <- NULL
print(sc)
1
}
f2 <- function() {
1 + f()
}
f()
#> f()
#> f()
#> [1] 1
f2()
#> 1 + f()
#> f()
#> [1] 2
Best,
Antoine
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sys.call() 's srcref doesn't match the language
Hello,
The source references are useful for debugging tools because they
allow linking to call sites in the source files.
I agree the output can be confusing. Perhaps this could be fixed by
tweaking the print method for calls. If the deparsed call doesn't
match the srcref, both could be displayed along with file:line:column.
```
#> f()
#>
#> 1 + f()
```
Best,
Lionel
On 9/2/20, Antoine Fabri wrote:
> Dear R-devel,
>
> I found this behavior disturbing, if `1 + f()` is called, `sys.call()`
> called inside of `f` will return a quoted `f()` with a "srcref" that prints
> "1 + f()".
>
> I don't know which one is good but I don't think they can be correct at the
> same time.
>
> Here's a reproducible example:
>
> f <- function(){
> sc <- sys.call()
> print(sc)
> attr(sc, "srcref") <- NULL
> print(sc)
> 1
> }
> f2 <- function() {
> 1 + f()
> }
> f()
> #> f()
> #> f()
> #> [1] 1
> f2()
> #> 1 + f()
> #> f()
> #> [1] 2
>
> Best,
>
> Antoine
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sys.call() 's srcref doesn't match the language
Thanks Lionel,
I now understand what's going on. I like your proposal and I can confirm I
wouldn't have been confused had it be printed this way.
In fact I wouldn't mind the file:line:column to be displayed every time.
Best,
Antoine
Le jeu. 3 sept. 2020 à 00:19, Lionel Henry a écrit :
> Hello,
>
> The source references are useful for debugging tools because they
> allow linking to call sites in the source files.
>
> I agree the output can be confusing. Perhaps this could be fixed by
> tweaking the print method for calls. If the deparsed call doesn't
> match the srcref, both could be displayed along with file:line:column.
>
> ```
> #> f()
> #>
> #> 1 + f()
> ```
>
> Best,
> Lionel
>
>
> On 9/2/20, Antoine Fabri wrote:
> > Dear R-devel,
> >
> > I found this behavior disturbing, if `1 + f()` is called, `sys.call()`
> > called inside of `f` will return a quoted `f()` with a "srcref" that
> prints
> > "1 + f()".
> >
> > I don't know which one is good but I don't think they can be correct at
> the
> > same time.
> >
> > Here's a reproducible example:
> >
> > f <- function(){
> > sc <- sys.call()
> > print(sc)
> > attr(sc, "srcref") <- NULL
> > print(sc)
> > 1
> > }
> > f2 <- function() {
> > 1 + f()
> > }
> > f()
> > #> f()
> > #> f()
> > #> [1] 1
> > f2()
> > #> 1 + f()
> > #> f()
> > #> [1] 2
> >
> > Best,
> >
> > Antoine
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sys.call() 's srcref doesn't match the language
>On Wednesday, September 2, 2020, 6:19:20 PM EDT, Lionel Henry > wrote: > >Hello, > >The source references are useful for debugging tools because they >allow linking to call sites in the source files. > >I agree the output can be confusing. Perhaps this could be fixed by >tweaking the print method for calls. If the deparsed call doesn't >match the srcref, both could be displayed along with file:line:column. > >``` >#> f() >#> >#> 1 + f() >``` > >Best, >Lionel Why print the mismatched srcref at all? I find that confusing. Just omit the srcref from display. Debugging tools can still retrieve it and use the information, presumably. Best, Brodie. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Rgui never processes ~/.Renviron
ISSUE:
It looks like Rgui.exe never processes ~/.Renviron - only ./.Renviron.
REPRODUCIBLE EXAMPLE:
On Windows, create the following ~/.Renviron and ~/.Rprofile files:
C:\Users\alice> Rscript -e "cat('FOO=123\n', file='~/.Renviron')"
C:\Users\alice> Rscript -e "cat('print(Sys.getenv(\'FOO\'))',
file='~/.Rprofile')"
and launch Rgui (from a folder other that ~):
C:\Users\alice> Rgui
and you'll see that FOO is reported as "" (empty), whereas with R or
Rscript, it is reported as "123".
TROUBLESHOOTING:
>From code inspection
():
#ifdef Win32
{
char buf[1024]; /* MAX_PATH is less than this */
/* R_USER is not necessarily set yet, so we have to work harder */
s = getenv("R_USER");
if(!s) s = getenv("HOME");
if(!s) return;
snprintf(buf, 1024, "%s/.Renviron", s);
s = buf;
}
#endif
I think it happens because neither R_USER nor HOME is set when the
Rgui startup process calls process_user_Renviron().
WORKAROUND:
Setting R_USER or HOME prior to calling Rgui will cause Rgui to
process ~/.Renviron, e.g.
C:\User\alice> set R_USER=%UserProfile%\Documents
C:\User\alice> Rgui
The background for finding this is R-help thread '[R] tempdir() does
not respect TMPDIR' on 2020-08-29
(https://stat.ethz.ch/pipermail/r-help/2020-August/468573.html).
/Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
