subject:"\[R\] Bug"

Re: [R] Bug? plot.formula does need support plot.first / plot.last param in plot.default

2024-07-07 Thread Erez Shomron

Thank you Ivan,

Yes I meant `panel.first`.
I fumbled the title and the examples, but the end result is the same:

```
# Works
with(mtcars, plot(wt, mpg, panel.first = {
arrows(3, 15, 4, 30)
}))

# Doesn't work
plot(mpg ~ wt, data = mtcars, panel.first = {
arrows(3, 15, 4, 30)
})

```

I saw the bug reported 13 years ago after-the-fact, and the paragraph I missed 
for the manual entry.
Thanks for clarifying both.

I do think making these arguments lazy evaluate would be a welcome change. It's 
especially confusing for new R users trying to use base graphics to plot their 
linear model. But I also understand this would be low priority as user 
workaround is simple (don't use the formula method), and because of the testing 
effort that would be required.

Maybe a warning would be nice, telling users that `panel.first` and 
`panel.last` are evaluated before plotting. I think users would check `?plot` 
before `?plot.formula` and would not see any reason not to try and pass these 
arguments.

Kind Regards,
Erez

On Sat, Jul 6, 2024, at 5:24 PM, Ivan Krylov wrote:
> В Fri, 05 Jul 2024 14:35:40 +0300
> "Erez Shomron"  пишет:
> 
> > This works as expected:
> 
> > with(mtcars, plot(wt, mpg, plot.first = {
> > plot.window(range(wt), range(mpg))
> > arrows(3, 15, 4, 30)
> > }))
> 
> I think you meant panel.first, not plot.first. At least I cannot find
> any mention of plot.first in the R source code. In this example,
> plot.first ends up being an argument of an internal call from
> plot.default() to plot.window(), which evaluates its ellipsis
> arguments. If your plot.first expression returned a non-NULL value, you
> would also have received a warning:
> 
> plot.window(0:1, 0:1, plot.first = message('hello'))
> # hello
> plot.window(0:1, 0:1, plot.first = 123)
> # Warning message:
> # In plot.window(0:1, 0:1, plot.first = 123) :
> #   "plot.first" is not a graphical parameter
> 
> It is indeed documented that "passing [panel.first] from other ‘plot’
> methods may well not work since it may be evaluated too early". The
> plot.formula method deliberately evaluates the arguments in the
> ellipsis, and the workaround suggested in
> https://bugs.r-project.org/show_bug.cgi?id=14591 doesn't help because
> the expression is then evaluated in an undesired environment (parent
> frame, not data).
> 
> You are correct that plot.formula tries to evaluate all its remaining
> arguments in the context of the data passed to the method. In order for
> the lazy evaluation to work, plot.formula would have to (1) know and
> skip all such arguments by name on line 6, minding partial matching, (2)
> rewrite them into the form evalq(original_argument_expression,
> model_frame, parent_frame) so that they would be able to access both
> the data and the variables visible in the frame of the caller, and (3)
> give these expressions to do.call() in place of the original ones.
> 
> (1) sounds especially brittle since plot.formula() may dispatch to
> other plot.* methods. Additionally, great care will need to be taken
> not to break existing code that calls plot.formula, even if it's
> already full of workarounds for plot.formula's behaviour.
> 
> -- 
> Best regards,
> Ivan
> 

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Bug? plot.formula does need support plot.first / plot.last param in plot.default

2024-07-06 Thread Ivan Krylov via R-help

В Fri, 05 Jul 2024 14:35:40 +0300
"Erez Shomron"  пишет:

> This works as expected:

> with(mtcars, plot(wt, mpg, plot.first = {
> plot.window(range(wt), range(mpg))
> arrows(3, 15, 4, 30)
> }))

I think you meant panel.first, not plot.first. At least I cannot find
any mention of plot.first in the R source code. In this example,
plot.first ends up being an argument of an internal call from
plot.default() to plot.window(), which evaluates its ellipsis
arguments. If your plot.first expression returned a non-NULL value, you
would also have received a warning:

plot.window(0:1, 0:1, plot.first = message('hello'))
# hello
plot.window(0:1, 0:1, plot.first = 123)
# Warning message:
# In plot.window(0:1, 0:1, plot.first = 123) :
#   "plot.first" is not a graphical parameter

It is indeed documented that "passing [panel.first] from other ‘plot’
methods may well not work since it may be evaluated too early". The
plot.formula method deliberately evaluates the arguments in the
ellipsis, and the workaround suggested in
https://bugs.r-project.org/show_bug.cgi?id=14591 doesn't help because
the expression is then evaluated in an undesired environment (parent
frame, not data).

You are correct that plot.formula tries to evaluate all its remaining
arguments in the context of the data passed to the method. In order for
the lazy evaluation to work, plot.formula would have to (1) know and
skip all such arguments by name on line 6, minding partial matching, (2)
rewrite them into the form evalq(original_argument_expression,
model_frame, parent_frame) so that they would be able to access both
the data and the variables visible in the frame of the caller, and (3)
give these expressions to do.call() in place of the original ones.

(1) sounds especially brittle since plot.formula() may dispatch to
other plot.* methods. Additionally, great care will need to be taken
not to break existing code that calls plot.formula, even if it's
already full of workarounds for plot.formula's behaviour.

-- 
Best regards,
Ivan

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Bug? plot.formula does need support plot.first / plot.last param in plot.default

2024-07-06 Thread Erez Shomron

Thanks for your answer.

Should I report in Bugzilla at least so it's tracked?

I can point that the issue is with line 6 of the function body:
```
dots <- lapply(m$..., eval, md, eframe)
```

I assume the intention was to evaluate the arguments with the context of data 
passed to the function.
But the expression in panel.first / panel.last gets evaluated before plot.new 
is called (as the error indicates).

I believe the fix would be to somehow not evaluate line 6, or replace with 
`dots <- m$...`, and when `plot` is later called, to somehow evaluate it with 
the data passed to the function. I tried to add `envir` argument to `do.call` 
but it does not work as I expected.

I would've liked to contribute a patch but my R knowledge is limited and and 
this `plot.formula` code is a bit of my head frankly.

Kindly,
Erez


On Sat, Jul 6, 2024, at 1:05 AM, Duncan Murdoch wrote:
> That definitely looks like a bug, but not one that anyone will be eager 
> to fix.  It's very old code that tried to be clever, and that's the 
> hardest kind of code to fix.
> 
> Remember Kernighan's Law:  "Everyone knows that debugging is twice as 
> hard as writing a program in the first place. So if you’re as clever as 
> you can be when you write it, how will you ever debug it?"
> 
> Duncan Murdoch
> 
> On 2024-07-05 7:35 a.m., Erez Shomron wrote:
> > Is the following a bug in your opinion? I think so.
> > 
> > This works as expected:
> > 
> > ```
> > with(mtcars, plot(wt, mpg, plot.first = {
> >  plot.window(range(wt), range(mpg))
> >  arrows(3, 15, 4, 30)
> > }))
> > ```
> > 
> > This does not.
> > 
> > ```
> > plot(mpg ~ wt, data = mtcars, plot.first = {
> >  plot.window(range(wt), range(mpg))
> >  arrows(3, 15, 4, 30)
> > })
> > ```
> > 
> > With error:
> > ```
> > Error in arrows(3, 15, 4, 30) : plot.new has not been called yet
> > ```
> > 
> > The second example should work.
> > 
> >  From the docs:
> > 
> > ?plot.formula
> > " For the ‘plot’ method the formula can be of the form ‘~ z + y +
> >   z’: the variables specified on the right-hand side are collected
> >   into a data frame, subsetted if specified, and displayed by
> >   ‘plot.data.frame’.
> > "
> > 
> > ?plot.data.frame
> > " ...: further arguments to ‘stripchart’, ‘plot.default’ or ‘pairs’.
> > "
> > 
> > And plot.default has both plot.first and plot.last
> > 
> > It seems very arbitrary you can't use these parameters with the 
> > plot.formula method specifically.
> > 
> >> sessionInfo()
> > R version 4.4.1 (2024-06-14)
> > Platform: x86_64-suse-linux-gnu
> > Running under: openSUSE Tumbleweed
> > [...]
> > 
> > __
> > R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> > https://stat.ethz.ch/mailman/listinfo/r-help
> > PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> > and provide commented, minimal, self-contained, reproducible code.
> 
> 

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Bug? plot.formula does need support plot.first / plot.last param in plot.default

2024-07-05 Thread Duncan Murdoch

That definitely looks like a bug, but not one that anyone will be eager 
to fix.  It's very old code that tried to be clever, and that's the 
hardest kind of code to fix.


Remember Kernighan's Law:  "Everyone knows that debugging is twice as 
hard as writing a program in the first place. So if you’re as clever as 
you can be when you write it, how will you ever debug it?"


Duncan Murdoch

On 2024-07-05 7:35 a.m., Erez Shomron wrote:

Is the following a bug in your opinion? I think so.

This works as expected:

```
with(mtcars, plot(wt, mpg, plot.first = {
 plot.window(range(wt), range(mpg))
 arrows(3, 15, 4, 30)
}))
```

This does not.

```
plot(mpg ~ wt, data = mtcars, plot.first = {
 plot.window(range(wt), range(mpg))
 arrows(3, 15, 4, 30)
})
```

With error:
```
Error in arrows(3, 15, 4, 30) : plot.new has not been called yet
```

The second example should work.

 From the docs:

?plot.formula
" For the ‘plot’ method the formula can be of the form ‘~ z + y +
  z’: the variables specified on the right-hand side are collected
  into a data frame, subsetted if specified, and displayed by
  ‘plot.data.frame’.
"

?plot.data.frame
" ...: further arguments to ‘stripchart’, ‘plot.default’ or ‘pairs’.
"

And plot.default has both plot.first and plot.last

It seems very arbitrary you can't use these parameters with the plot.formula 
method specifically.


sessionInfo()

R version 4.4.1 (2024-06-14)
Platform: x86_64-suse-linux-gnu
Running under: openSUSE Tumbleweed
[...]

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.


__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

[R] Bug? plot.formula does need support plot.first / plot.last param in plot.default

2024-07-05 Thread Erez Shomron

Is the following a bug in your opinion? I think so.

This works as expected:

```
with(mtcars, plot(wt, mpg, plot.first = {
plot.window(range(wt), range(mpg))
arrows(3, 15, 4, 30)
}))
```

This does not.

```
plot(mpg ~ wt, data = mtcars, plot.first = {
plot.window(range(wt), range(mpg))
arrows(3, 15, 4, 30)
})
```

With error:
```
Error in arrows(3, 15, 4, 30) : plot.new has not been called yet
```

The second example should work.

>From the docs:

?plot.formula
" For the ‘plot’ method the formula can be of the form ‘~ z + y +
 z’: the variables specified on the right-hand side are collected
 into a data frame, subsetted if specified, and displayed by
 ‘plot.data.frame’.
"

?plot.data.frame
" ...: further arguments to ‘stripchart’, ‘plot.default’ or ‘pairs’.
"

And plot.default has both plot.first and plot.last

It seems very arbitrary you can't use these parameters with the plot.formula 
method specifically.

> sessionInfo()
R version 4.4.1 (2024-06-14)
Platform: x86_64-suse-linux-gnu
Running under: openSUSE Tumbleweed
[...]

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Bug with writeClipboard in {utils}

2024-06-21 Thread Ivan Krylov via R-help

В Thu, 20 Jun 2024 18:39:34 +0300
Ivan Krylov via R-help  пишет:

> > Is there a way to test this patch or will there soon be a published
> > patched R version available for download?  
> 
> Not directly.

Now that the bug is fixed in R-devel (thanks Tomas!), a Windows build
of the development version of R with the fix is available:
https://cran.r-project.org/bin/windows/base/rdevel.html

-- 
Best regards,
Ivan

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Bug with writeClipboard in {utils}

2024-06-21 Thread Barthelemy Tanguy via R-help

Hello,

Thank you for your research and your bug report.
At the end of your bug report 
(https://bugs.r-project.org/show_bug.cgi?id=18747) you mentioned that "the 
problem doesn't reappear with the attached patch".

Is there a way to test this patch or will there soon be a published patched R 
version available for download?

Thank you again

Tanguy BARTHELEMY




De : Ivan Krylov 
Envoyé : mercredi 19 juin 2024 16:07
À : r-help@r-project.org
Cc : Barthelemy Tanguy
Objet : Re: [R] Bug with writeClipboard in {utils}

« Ce courriel provient d’un expéditeur extérieur à l’Insee. Compte tenu du 
contexte de menace cyber actuel il convient d’être extrêmement vigilant sur 
l’émetteur et son contenu avant d’ouvrir une pièce jointe, de cliquer sur un 
lien internet présent dans ce message ou d'y répondre. »


В Tue, 18 Jun 2024 10:12:04 +
Barthelemy Tanguy via R-help  пишет:

> #> [1] "plot(AirPassengers)" "⤀攀"
> #> [1] "plot(AirPassengers)" "\u0a00"
> #> [1] "plot(AirPassengers)" "\xed\xb0\x80ư"

Thanks for showing an example!

I was able to reproduce it both with R-4.3.1 on Windows 7 and with a
fresh R-devel build on Windows 10. Bug reported at
<https://bugs.r-project.org/show_bug.cgi?id=18747>.

--
Best regards,
Ivan

[[alternative HTML version deleted]]

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Bug with writeClipboard in {utils}

2024-06-21 Thread Barthelemy Tanguy via R-help

Hello,

Thank you for your different tests.

You have that you didn't find any errors with Rscript or with R but I have the 
impression that your test with R (second test) showed additional and unwanted 
characters (second line of the output)?

Thank you again

Tanguy BARTHELEMY



De : Rui Barradas 
Envoyé : mercredi 19 juin 2024 19:26
À : Barthelemy Tanguy; r-help@r-project.org
Objet : Re: [R] Bug with writeClipboard in {utils}

« Ce courriel provient d’un expéditeur extérieur à l’Insee. Compte tenu du 
contexte de menace cyber actuel il convient d’être extrêmement vigilant sur 
l’émetteur et son contenu avant d’ouvrir une pièce jointe, de cliquer sur un 
lien internet présent dans ce message ou d'y répondre. »


Às 11:12 de 18/06/2024, Barthelemy Tanguy via R-help escreveu:
> Hello,
>
> I'm encountering what seems to be a bug when using the `writeClipboard()` 
> function in the R {utils} package.
> When I try to copy text to the clipboard, I notice that I get extra 
> characters when I try to paste it (by hand with CTRL+V or with the 
> `readClipboard()` function from R packages {utils}).
>
> Here's my example:
>
> ``` r
> utils::writeClipboard("plot(AirPassengers)")
> for (k in 1:10) {
>  print(utils::readClipboard())
> }
> #> [1] "plot(AirPassengers)" "⤀攀"
> #> [1] "plot(AirPassengers)" "\u0a00"
> #> [1] "plot(AirPassengers)" "\xed\xb0\x80ư"
> #> [1] "plot(AirPassengers)"
> #> [1] "plot(AirPassengers)"
> #> [1] "plot(AirPassengers)"
> #> [1] "plot(AirPassengers)"
> #> [1] "plot(AirPassengers)"
> #> [1] "plot(AirPassengers)" "⤀"
> #> [1] "plot(AirPassengers)"
> Message d'avis :
> Dans utils::readClipboard() : unpaired surrogate Unicode point dc00
> ```
>
> So I don't always get the same result.
> I opened a problem in the {clipr} GitHub repository before realizing it's a 
> {tools} problem: https://github.com/mdlincoln/clipr/issues/68
>
> Is this a bug or something I haven't configured properly?
>
>
> Thank you very much
>
>
> Tanguy BARTHELEMY
>
>
>   [[alternative HTML version deleted]]
>
> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
Hello,

I have reproduced part of the behavior in the OP but it will depend on
the GUI or command line used.

With Rscript or with R I haven't found any errors.
With Rgui or with RStudio, yes, the output was not the expected output.

All code run in R 4.4.0 on Windows 11.

The script rscript.R is


utils::capture.output({
utils::writeClipboard("plot(AirPassengers)")
for (k in 1:10) {
   print(utils::readClipboard())
}
sessionInfo()
}, file = "rhelp.txt")


---

Here are the results I got.

1) Command:

Rscript rscript.R

Output:

[1] "plot(AirPassengers)"
[1] "plot(AirPassengers)"
[1] "plot(AirPassengers)"
[1] "plot(AirPassengers)"
[1] "plot(AirPassengers)"
[1] "plot(AirPassengers)"
[1] "plot(AirPassengers)"
[1] "plot(AirPassengers)"
[1] "plot(AirPassengers)"
[1] "plot(AirPassengers)"
R version 4.4.0 (2024-04-24 ucrt)
Platform: x86_64-w64-mingw32/x64
Running under: Windows 11 x64 (build 22631)

Matrix products: default


locale:
[1] LC_COLLATE=Portuguese_Portugal.utf8
LC_CTYPE=Portuguese_Portugal.utf8
[3] LC_MONETARY=Portuguese_Portugal.utf8 LC_NUMERIC=C

[5] LC_TIME=Portuguese_Portugal.utf8

time zone: Europe/Lisbon
tzcode source: internal

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

loaded via a namespace (and not attached):
[1] compiler_4.4.0

---

2) Command:
R -q -f rscript.R

Output:

 > utils::writeClipboard("plot(AirPassengers)")
 > for (k in 1:10) {
+ print(utils::readClipboard())
+ }
[1] "plot(AirPassengers)"
[1] "plot(AirPassengers)" "㨀Ǐ\005"
[1] "plot(AirPassengers)"
[1] "plot(AirPassengers)"
[1] "plot(AirPassengers)"
[1] "plot(AirPassengers)"
[1] "plot(AirPassengers)"
[1] "plot(AirPassengers)"
[1] "plot(AirPassengers)"
[1] "plot(AirPassengers)"
 > sessionInfo()
R version 4.4.0 (2024-04-24 ucrt)
Platform: x86_64-w64-mingw32/x64
Running under: Windows 11 x64 (build 22631)

Matrix products: default


locale:
[1] LC_COLLATE=Portuguese_Portugal.utf8
LC_CTYPE=Portuguese_Portugal.utf8
[3] LC_MONETARY=Portuguese_Portugal.utf8 LC_NUMERIC=C

[5]

Re: [R] Bug with writeClipboard in {utils}

2024-06-20 Thread Ivan Krylov via R-help

В Thu, 20 Jun 2024 13:21:38 +
Barthelemy Tanguy пишет:

> Is there a way to test this patch or will there soon be a published
> patched R version available for download?

Not directly. If you're willing to follow the partially manual process
yourself, the instructions at [1] describe how to download R-devel and
compile the program. It's not spelled out anywhere how to apply patches
(some work is in progress at [2]), so feel free to ask additional
questions about `svn patch` if you would like to go this way.

Alternatively, taking a patch and submitting it as a pull request to
https://github.com/r-devel/r-svn will result in several checks being
run on it, one of which builds an R installer (e.g. see the artifacts
at [3]).

The remaining option is to wait for the bug to be fixed. Allocating
enough space for the terminator is probably necessary, but the R
developers may also decide to make readClipboard() more robust against
missing terminators.

Some fixes can be backported to R-patched; snapshots of R-patched
compiled for Windows are available from CRAN. R-patched may eventually
become R-4.4.2. If not backported, the fix will appear in the next
version of R.

--
Best regards,
Ivan

[1]
https://cran.r-project.org/bin/windows/base/howto-R-devel.html#building-r-from-source-using-rtools44

[2]
https://github.com/r-devel/rdevguide/issues/170

[3]
https://github.com/r-devel/r-svn/actions/runs/8749727418

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

1 2 3 4 5 >

1 - 100 of 499 matches

Mail list logo