Re: [Rd] eval and Calling Frames

[Lionel Henry]

Hi Brodie,

I wouldn't use the rlang tests as a measure of backward compatibility.
Your patch changes the structure of the `parent.frame()` hierarchy,
which is likely to be disruptive with packages that do weird NSE stuff
(and so, not rlang ;-p). Currently things are set up so that the
parent frame of the evaluated call is the "target" `eval()` context,
which itself has for parent the "closure" `eval()` context.

For example, with:

```
foo <- function() eval(quote(bar()))
bar <- function() EXPR()
```

The current hierarchy (as defined by `parent.frame()`) is:

```
█
 1. └─global::foo()
 2.   └─base::eval(quote(bar()))
 3. └─base::eval(quote(bar()))   <- This is the same frame env as foo()
 4.   └─global::bar()
 5. └─global::EXPR()
```

With your patch, it becomes:

```
█
 1. └─global::foo()
 2.   ├─base::eval(quote(bar()))
 3.   │ └─base::eval(quote(bar()))
 4.   └─global::bar()
 5. └─global::EXPR()
```

I agree the second hierarchy is preferable. See also the documentation
of `filter.callframes` in `?Rprof` which patches up things so that the
`eval()` frames are filtered out from the trailing backtrace
branch. This wouldn't be necessary with the second hierarchy.

Best,
Lionel


On 6/1/20, brodie gaslam via R-devel  wrote:
>  I ran into an interesting issue with `evalq` (and also
> `eval(quote(...))`):
>
>  f <- function() {
>    list(
>  sys.parent(1),
>  evalq(sys.parent(1)),
>  evalq((function() sys.parent(2))()),  # add an anon fun layer
>  evalq((function() sys.parent(1))())
>    )
>  }
>  res <- f()
>  str(res)
>  ## List of 4
>  ##  $ : int 0 # sys.parent(1)
>  ##  $ : int 2 # evalq(sys.parent(1))
>  ##  $ : int 0 # evalq((function() sys.parent(2))())
>  ##  $ : int 1 # evalq((function() sys.parent(1))())
>
> In order of least to most surprising:
>
> 1. `sys.parent(1)` and `evalq(sys.parent(1))` are not the same
> 2. `evalq(sys.parent(1))` and `evalq((function() sys.parent(2))())`
>    are not the same
> 3. `evalq((function() sys.parent(1))())` returns a lower frame number
>    than `evalq(sys.parent(1))`
>
> The root cause of this is that the `evalq` **closure** sets a context,
> but then the C-level `do_eval` it invokes sets another one[1] with the
> new `evalq` context as the calling frame (`cptr->sysparent`)[2].  This
> then interacts with how `sys.parent` resolves parents when a target
> frame appears more than once in the context stack.  `sys.parent`
> returns the oldest context that matches[3], and in this case `f`'s
> frame appears twice because `evalq` adds it via `do_eval`.
>
> One option is to change what `sysparent` of the `evalq` `envir`.
> For example, if we set it to be the same as it would be for commands
> outside the `evalq` we get:
>
>  str(res)
>  ## List of 4
>  ##  $ : int 0 # sys.parent(1)
>  ##  $ : int 0 # evalq(sys.parent(1))
>  ##  $ : int 0 # evalq((function() sys.parent(2))())
>  ##  $ : int 1 # evalq((function() sys.parent(1))())
>
> There is precedent for doing this in S3 generics and their methods
> where method `sysparent` is set to be that of the generic.  Now
> `evalq` no longer interferes with the resolution of calling frames.
> It seems reasonable to set evaluation environments without affecting
> what the calling frame is. Indeed that happens when we do something like
> `environment(fun) <- blah` as the calling frame is unaffected when `fun` is
> invoked.
>
> I attach a patch that implements this change.  The patch is a
> hack-job intended solely for illustrative purposes, though it does
> pass `make check-all` on a current version of r-devel.  I also ran the
> `rlang` tests as those probably push the envelope in this area.  There
> only one failed with 2,613 passing.  The failed one is for a
> deprecated function that was specifically checking for the repeated
> `evalq` contexts[7].
>
> I also attach a document with additional examples and commentary for
> those interested.
>
> Best,
>
> Brodie.
>
> PS: for a loosely related issue see #15531[8].
>
> [1]:
> https://github.com/wch/r-source/blob/tags/R-4-0-0/src/main/eval.c#L3329
> [2]:
> https://github.com/wch/r-source/blob/tags/R-4-0-0/src/main/context.c#L260
> [3]:
> https://github.com/wch/r-source/blob/tags/R-4-0-0/src/main/context.c#L433
> [4]:
> https://github.com/wch/r-source/blob/tags/R-4-0-0/src/main/eval.c#L1815
> [5]: https://cran.r-project.org/doc/manuals/r-devel/R-ints.html#Contexts
> [6]: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=15531
> [7]:
> https://github.com/r-lib/rlang/blob/v0.4.6/tests/testthat/test-retired.R#L437
> [8]: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=15531
>
>
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Debugging packages with compiled C code on Windows

[Sue McDonald]

I have several related questions.

1.  Is it possible to use a GUI: Rstudio/Eclipse/Visual-studio to debug
compiled code on Windows? Things that work on Eclipse for Windows do not
work on Eclipse for Windows.
2.  R CMD INSTALL seems to override default attempts to provide
CFLAGS="-DDEBUG -g3 -O0"
3.  Is it necessary to compile R with debug turned on?   One of the FAQs
mentioned to compile R with make DEBUG=T.
4.  Using Rtools 4.0 and Jeroen's scripts for building R works great (many
thanks). But does not seem to have an impact on optimization, other than
including -gwarf-2.  It adds -DNDEBUG flag.  Is that sufficient for
debugging compiled code in a package?  Obviously, I just need to debug
package code, so does it matter?

I am happy to write-up a FAQ.

Thanks, SM

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Debugging packages with compiled C code on Windows

[Avraham Adler]

Hello, Sue.

1. I work exclusively on Windows have packages with compiled C, C++,
and Fortran (2003+)  and I use RStudio to debug and work with them
using Rtools40, so I guess it's possible. Have I misunderstood and are
you asking about debugging assembler?
2. If you're using Jeroen's scripts, have you tried uncommenting and
adding that to EOPTS in MkRules.local.in? Note that
./src/gnuwin32/fixed/Makefile has a nasty habit of overriding various
optimizations that affect packages.
3. I don't think so
4. The default is that EOPTS is commented out. I talk about it a nit
more at length here [1]. Perhaps that would be of use?

[1] 


Good Luck,

Avi


On Mon, Jun 1, 2020 at 9:36 PM Sue McDonald  wrote:
>
> I have several related questions.
>
> 1.  Is it possible to use a GUI: Rstudio/Eclipse/Visual-studio to debug
> compiled code on Windows? Things that work on Eclipse for Windows do not
> work on Eclipse for Windows.
> 2.  R CMD INSTALL seems to override default attempts to provide
> CFLAGS="-DDEBUG -g3 -O0"
> 3.  Is it necessary to compile R with debug turned on?   One of the FAQs
> mentioned to compile R with make DEBUG=T.
> 4.  Using Rtools 4.0 and Jeroen's scripts for building R works great (many
> thanks). But does not seem to have an impact on optimization, other than
> including -gwarf-2.  It adds -DNDEBUG flag.  Is that sufficient for
> debugging compiled code in a package?  Obviously, I just need to debug
> package code, so does it matter?
>
> I am happy to write-up a FAQ.
>
> Thanks, SM
>
> [[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] Debugging packages with compiled C code on Windows

[Jeroen Ooms]

On Mon, Jun 1, 2020 at 11:36 PM Sue McDonald  wrote:
>
> I have several related questions.
>
> 1.  Is it possible to use a GUI: Rstudio/Eclipse/Visual-studio to debug
> compiled code on Windows? Things that work on Eclipse for Windows do not
> work on Eclipse for Windows.
> 2.  R CMD INSTALL seems to override default attempts to provide
> CFLAGS="-DDEBUG -g3 -O0"
> 3.  Is it necessary to compile R with debug turned on?   One of the FAQs
> mentioned to compile R with make DEBUG=T.
> 4.  Using Rtools 4.0 and Jeroen's scripts for building R works great (many
> thanks). But does not seem to have an impact on optimization, other than
> including -gwarf-2.  It adds -DNDEBUG flag.  Is that sufficient for
> debugging compiled code in a package?  Obviously, I just need to debug
> package code, so does it matter?

If you use the official R-for-Windows installation, you should install
your R package with R CMD INSTALL --debug in order to keep debug
symbols. That is usually sufficient to get a backtrace with e.g
drmingw. See FAQ 8.4 of
https://cran.r-project.org/bin/windows/base/rw-FAQ.html

Coincidentally I am also working on a special debugging build of R,
which uses -g -O0 for all compiled code. It is not final yet, but it
should work. You can test it here:
https://github.com/r-windows/rtools-packages/pull/119

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel