[Rd] writing Unicode text to the Windows clipboard

[Jennifer Bryan]

Hello,

I'm interested in moving text from and to the clipboard that cannot
necessarily be represented in the native encoding. So, really, this is
about Windows.

I can successfully read from the clipboard by specifying the format that
corresponds to unicode text.

>From R >=2.7.0, it seems you should also be able to write unicode text
to the Windows clipboard.

https://github.com/wch/r-source/blob/5a156a0865362bb8381dcd69ac335f5174a4f60c/src/gnuwin32/CHANGES0#L535-L536

However, in my hands, this does not seem to be true. I can make it work
with this change:

diff --git a/src/library/utils/src/windows/util.c
b/src/library/utils/src/windows/util.c
index 373049495dd..fc3dc39e3a7 100644
--- a/src/library/utils/src/windows/util.c
+++ b/src/library/utils/src/windows/util.c
@@ -318,7 +318,7 @@ SEXP writeClipboard(SEXP text, SEXP sformat)
  warning(_("unable to open the clipboard"));
  GlobalFree(hglb);
  } else {
- success = SetClipboardData(CF_TEXT, hglb) != 0;
+ success = SetClipboardData(format, hglb) != 0;
  if(!success) {
  warning(_("unable to write to the clipboard"));
  GlobalFree(hglb);

Example:

"≧" is "GREATER-THAN OVER EQUAL TO", which is unicode , has
UTF-16LE bytes 67 22, and is not representable in latin1.

I copy ≧ to the Windows clipboard and attempt a round trip. I see:

x <- readClipboard(format = 13, raw = TRUE) # 13 <--> "Unicode text"
#> [1] 67 22 00 00
writeClipboard(x, format = 13L)
readClipboard(format = 13, raw = TRUE)
#> [1] 67 00 22 00 00 00 00 00

and, literally, pasting yields: g"

If I build r-devel with the patch, the same process yields

x <- readClipboard(format = 13, raw = TRUE)
#> [1] 67 22 00 00
writeClipboard(x, format = 13)
readClipboard(format = 13, raw = TRUE)
#> [1] 67 22 00 00

and pasting returns the original input: ≧

Passing the `format` to SetClipboardData() instead of hard-wiring
"CF_TEXT" brings behaviour in line with the docs.

-- Jenny

[[alternative HTML version deleted]]

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

[Rd] Typo/bug in R-3.6.0/src/scripts/config ?

[Paul Wikramaratna]

Hi there,


I think there is a typo in the src/scripts/config file for R 3.6.0


This is my R version:


platform   x86_64-suse-linux-gnu
arch   x86_64
os linux-gnu
system x86_64, linux-gnu
status
major  3
minor  6.0
year   2019
month  04
day26
svn rev76424
language   R
version.string R version 3.6.0 (2019-04-26)
nickname   Planting of a Tree


I think that on line 277 of src/scripts/config "CXX17PICFLAGSS" should read 
"CXX17PICFLAGS"


On my UNIX-alike, without this change I get:


R CMD config CXX17PICFLAGS
ERROR: no information for variable 'CXX17PICFLAGS'


but if I delete the second S, then I get:


R CMD config CXX17PICFLAGS
-fPIC


which is the same as on R 3.5.2


Have had a look and couldn't see an existing bug report, apologies if I missed 
it (am trying to follow the advice here: 
https://www.r-project.org/bugs.html).


Best, Paul



__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

This e-mail and any files transmitted with it are confid...{{dropped:11}}

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

[Rd] writing Unicode text to the Windows clipboard

[Jennifer Bryan]

Hello,

I'm interested in moving text from and to the clipboard that cannot
necessarily be represented in the native encoding. So, really, this is
about Windows.

I can successfully read from the clipboard by specifying the format that
corresponds to unicode text.

>From R >=2.7.0, it seems you should also be able to write unicode text
to the Windows clipboard.

https://github.com/wch/r-source/blob/5a156a0865362bb8381dcd69ac335f5174a4f60c/src/gnuwin32/CHANGES0#L535-L536

However, in my hands, this does not seem to be true. I can make it work
with this change:

diff --git a/src/library/utils/src/windows/util.c
b/src/library/utils/src/windows/util.c
index 373049495dd..fc3dc39e3a7 100644
--- a/src/library/utils/src/windows/util.c
+++ b/src/library/utils/src/windows/util.c
@@ -318,7 +318,7 @@ SEXP writeClipboard(SEXP text, SEXP sformat)
  warning(_("unable to open the clipboard"));
  GlobalFree(hglb);
  } else {
- success = SetClipboardData(CF_TEXT, hglb) != 0;
+ success = SetClipboardData(format, hglb) != 0;
  if(!success) {
  warning(_("unable to write to the clipboard"));
  GlobalFree(hglb);

Example:

"≧" is "GREATER-THAN OVER EQUAL TO", which is unicode , has
UTF-16LE bytes 67 22, and is not representable in latin1.

I copy ≧ to the Windows clipboard and attempt a round trip. I see:

x <- readClipboard(format = 13, raw = TRUE) # 13 <--> "Unicode text"
#> [1] 67 22 00 00
writeClipboard(x, format = 13L)
readClipboard(format = 13, raw = TRUE)
#> [1] 67 00 22 00 00 00 00 00

and, literally, pasting yields: g"

If I build r-devel with the patch, the same process yields

x <- readClipboard(format = 13, raw = TRUE)
#> [1] 67 22 00 00
writeClipboard(x, format = 13)
readClipboard(format = 13, raw = TRUE)
#> [1] 67 22 00 00

and pasting returns the original input: ≧

Passing the `format` to SetClipboardData() instead of hard-wiring
"CF_TEXT" brings behaviour in line with the docs.

-- Jenny

[[alternative HTML version deleted]]

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

[Rd] Possible bug when finding shared libraries during staged installation

[Kara Woo]

Hi all,

With the new staged installation, it seems that R CMD INSTALL sometimes
fails on macOS due to these lines [1] when sapply() returns a list. The
x13binary package has an example [2], reproducible with the following steps:

$ git clone g...@github.com:x13org/x13binary.git && cd x13binary
$ git checkout 663ad7122
$ R CMD INSTALL .

(We've also run into it in an internal package, but it's easier to
reproduce with x13binary)

In this case the file command returns multiple results for one of the
dynamic libraries, so are_shared looks like this:

> are_shared
$`/Users/Kara/projects/forks/x13binary/inst//lib/libgcc_s.1.dylib`
[1] TRUE TRUE TRUE

$`/Users/Kara/projects/forks/x13binary/inst//lib/libgfortran.3.dylib`
[1] TRUE

$`/Users/Kara/projects/forks/x13binary/inst//lib/libquadmath.0.dylib`
[1] TRUE

slibs[are_shared] then fails with invalid subscript type 'list'.

I believe this may be a bug and I have included a patch that uses any() and
vapply() to ensure that only one value is returned for each library and the
result is an atomic vector. This is my first time submitting a bug report
or patch here; I'm happy to make any changes if needed.

Thanks for considering,
Kara

[1]
https://github.com/wch/r-source/blob/3fe2bb01e9ec1b268803a437c308742775c2442d/src/library/tools/R/install.R#L594-L597
[2] https://github.com/x13org/x13binary/issues/46

R version 3.6.0 Patched (2019-05-22 r76579)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: macOS Mojave 10.14.4
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Typo/bug in R-3.6.0/src/scripts/config ?

[Martin Maechler]

> Paul Wikramaratna 
> on Thu, 23 May 2019 12:32:53 + writes:

> Hi there,
> I think there is a typo in the src/scripts/config file for R 3.6.0


> This is my R version:


> platform   x86_64-suse-linux-gnu
> arch   x86_64
> os linux-gnu
> system x86_64, linux-gnu
> status
> major  3
> minor  6.0
> year   2019
> month  04
> day26
> svn rev76424
> language   R
> version.string R version 3.6.0 (2019-04-26)
> nickname   Planting of a Tree


> I think that on line 277 of src/scripts/config "CXX17PICFLAGSS" should 
read "CXX17PICFLAGS"


> On my UNIX-alike, without this change I get:


> R CMD config CXX17PICFLAGS
> ERROR: no information for variable 'CXX17PICFLAGS'


> but if I delete the second S, then I get:


> R CMD config CXX17PICFLAGS
> -fPIC


> which is the same as on R 3.5.2


> Have had a look and couldn't see an existing bug report, apologies if I 
missed it (am trying to follow the advice here: 
https://www.r-project.org/bugs.html).


> Best, Paul

Thank you, Paul!

The typo is fixed in the sources of both "R-devel" and "R 3.6.0
patched" now.

With grateful regards,
Martin
--
Martin Maechler
ETH Zurich and R Core Team

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

Re: [Rd] HTTPS warning on developer.r-project.org

[Colin Gillespie]

On Wed, 22 May 2019 at 16:55, Simon Urbanek  wrote:
>
> More to the point: the custom search function is currently broken anyway - it 
> just gives me 404.
>
> Should we just get rid of it?

Does anyone actually use it? Are there logs available?

Colin


>If people want to use Google they can just say
>
> site:developer.r-project.org foo
>
>
>
>
>
> > On May 22, 2019, at 1:08 AM, Paul Menzel  wrote:
> >
> > [Please CC me on replies, as I am not subscribed.]
> >
> > Dear R folks,
> >
> >
> > Accessing the *R Developer Page* [1], the browser (Firefox) shows an HTTPS 
> > warning.
> >
> > The reason is the embedded Google logo.
> >
> >> Gemischte (unsichere) Anzeige-Inhalte von 
> >> "http://www.google.com/logos/Logo_40wht.gif"; werden auf einer sicheren 
> >> Seite geladen
> > Could you change that to an HTTPS link please?
> >
> > ```
> > $ curl -I https://www.google.com/logos/Logo_40wht.gif
> > HTTP/2 200
> > accept-ranges: bytes
> > content-type: image/gif
> > content-length: 3845
> > date: Wed, 22 May 2019 05:07:35 GMT
> > expires: Wed, 22 May 2019 05:07:35 GMT
> > cache-control: private, max-age=31536000
> > last-modified: Thu, 08 Dec 2016 01:00:57 GMT
> > x-content-type-options: nosniff
> > server: sffe
> > x-xss-protection: 0
> > alt-svc: quic=":443"; ma=2592000; v="46,44,43,39"
> >
> > ```
> >
> >
> > Kind regards,
> >
> > Paul
> >
> >
> > [1]: https://developer.r-project.org/
> >
> > __
> > 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

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

Re: [Rd] Possible bug when finding shared libraries during staged installation

[Martin Maechler]

> Kara Woo 
> on Thu, 23 May 2019 14:24:26 -0700 writes:

> Hi all,
> With the new staged installation, it seems that R CMD INSTALL sometimes
> fails on macOS due to these lines [1] when sapply() returns a list. The
> x13binary package has an example [2], reproducible with the following 
steps:

> $ git clone g...@github.com:x13org/x13binary.git && cd x13binary
> $ git checkout 663ad7122
> $ R CMD INSTALL .

> (We've also run into it in an internal package, but it's easier to
> reproduce with x13binary)

> In this case the file command returns multiple results for one of the
> dynamic libraries, so are_shared looks like this:

>> are_shared
> $`/Users/Kara/projects/forks/x13binary/inst//lib/libgcc_s.1.dylib`
> [1] TRUE TRUE TRUE

> $`/Users/Kara/projects/forks/x13binary/inst//lib/libgfortran.3.dylib`
> [1] TRUE

> $`/Users/Kara/projects/forks/x13binary/inst//lib/libquadmath.0.dylib`
> [1] TRUE

Thank you, Kara.

Just for curiosity, what does

 file /Users/Kara/projects/forks/x13binary/inst//lib/libgcc_s.1.dylib

produce on your Mac?

> slibs[are_shared] then fails with invalid subscript type 'list'.

yes, "of course".

> I believe this may be a bug and I have included a patch that uses any() 
and
> vapply() to ensure that only one value is returned for each library and 
the
> result is an atomic vector. This is my first time submitting a bug report
> or patch here; I'm happy to make any changes if needed.

Your patch was not attached with MIME type   text/plain  and so
was filtered out by the mailing list software.
OTOH, I could relatively easily guess how to fix the bug,
notably when seeing the above "file ...dylib" result.

What we *meant* to say in  https://www.r-project.org/bugs.html 
is that in such a situation
1) you send your finding / suspicion / diagnosis
   to the R-devel mailing list,  in order to get confirmation etc
   if what you see is a bug;
2) then ideally, you'd do a formal bug report at
   https://bugs.r-project.org/
(for which you need to get an "account" there to be created
 once only by a bugzilla admin, typically an R core member).

In this case, that (2) may not be necessary, but you may want
that anyway (and let some of us know).

> Thanks for considering,
> Kara

Thank *you* indeed for the report,
Martin

> [1]
> 
https://github.com/wch/r-source/blob/3fe2bb01e9ec1b268803a437c308742775c2442d/src/library/tools/R/install.R#L594-L597
> [2] https://github.com/x13org/x13binary/issues/46

> R version 3.6.0 Patched (2019-05-22 r76579)
> Platform: x86_64-apple-darwin15.6.0 (64-bit)
> Running under: macOS Mojave 10.14.4

--
Martin Maechler
ETH Zurich  and  R Core Team

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

Re: [Rd] Possible bug when finding shared libraries during staged installation

[Simon Urbanek]

I'll have a look at the code - I don't think I actually reviewed all those 
macOS modifications - I wasn't even aware that they were added to the code.


> On May 24, 2019, at 08:52, Martin Maechler  wrote:
> 
>> Kara Woo 
>>on Thu, 23 May 2019 14:24:26 -0700 writes:
> 
>> Hi all,
>> With the new staged installation, it seems that R CMD INSTALL sometimes
>> fails on macOS due to these lines [1] when sapply() returns a list. The
>> x13binary package has an example [2], reproducible with the following steps:
> 
>> $ git clone g...@github.com:x13org/x13binary.git && cd x13binary
>> $ git checkout 663ad7122
>> $ R CMD INSTALL .
> 
>> (We've also run into it in an internal package, but it's easier to
>> reproduce with x13binary)
> 
>> In this case the file command returns multiple results for one of the
>> dynamic libraries, so are_shared looks like this:
> 
>>> are_shared
>> $`/Users/Kara/projects/forks/x13binary/inst//lib/libgcc_s.1.dylib`
>> [1] TRUE TRUE TRUE
> 
>> $`/Users/Kara/projects/forks/x13binary/inst//lib/libgfortran.3.dylib`
>> [1] TRUE
> 
>> $`/Users/Kara/projects/forks/x13binary/inst//lib/libquadmath.0.dylib`
>> [1] TRUE
> 
> Thank you, Kara.
> 
> Just for curiosity, what does
> 
> file /Users/Kara/projects/forks/x13binary/inst//lib/libgcc_s.1.dylib
> 
> produce on your Mac?
> 
>> slibs[are_shared] then fails with invalid subscript type 'list'.
> 
> yes, "of course".
> 
>> I believe this may be a bug and I have included a patch that uses any() and
>> vapply() to ensure that only one value is returned for each library and the
>> result is an atomic vector. This is my first time submitting a bug report
>> or patch here; I'm happy to make any changes if needed.
> 
> Your patch was not attached with MIME type   text/plain  and so
> was filtered out by the mailing list software.
> OTOH, I could relatively easily guess how to fix the bug,
> notably when seeing the above "file ...dylib" result.
> 
> What we *meant* to say in  https://www.r-project.org/bugs.html 
> is that in such a situation
> 1) you send your finding / suspicion / diagnosis
>   to the R-devel mailing list,  in order to get confirmation etc
>   if what you see is a bug;
> 2) then ideally, you'd do a formal bug report at
>   https://bugs.r-project.org/
>   (for which you need to get an "account" there to be created
>once only by a bugzilla admin, typically an R core member).
> 
> In this case, that (2) may not be necessary, but you may want
> that anyway (and let some of us know).
> 
>> Thanks for considering,
>> Kara
> 
> Thank *you* indeed for the report,
> Martin
> 
>> [1]
>> https://github.com/wch/r-source/blob/3fe2bb01e9ec1b268803a437c308742775c2442d/src/library/tools/R/install.R#L594-L597
>> [2] https://github.com/x13org/x13binary/issues/46
> 
>> R version 3.6.0 Patched (2019-05-22 r76579)
>> Platform: x86_64-apple-darwin15.6.0 (64-bit)
>> Running under: macOS Mojave 10.14.4
> 
> --
> Martin Maechler
> ETH Zurich  and  R Core Team
> 
> __
> 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] Possible bug when finding shared libraries during staged installation

[Tomas Kalibera]

On 5/24/19 2:52 PM, Martin Maechler wrote:

Kara Woo
 on Thu, 23 May 2019 14:24:26 -0700 writes:

 > Hi all,
 > With the new staged installation, it seems that R CMD INSTALL sometimes
 > fails on macOS due to these lines [1] when sapply() returns a list. The
 > x13binary package has an example [2], reproducible with the following 
steps:

 > $ git clone g...@github.com:x13org/x13binary.git && cd x13binary
 > $ git checkout 663ad7122
 > $ R CMD INSTALL .

 > (We've also run into it in an internal package, but it's easier to
 > reproduce with x13binary)

 > In this case the file command returns multiple results for one of the
 > dynamic libraries, so are_shared looks like this:

 >> are_shared
 > $`/Users/Kara/projects/forks/x13binary/inst//lib/libgcc_s.1.dylib`
 > [1] TRUE TRUE TRUE

 > $`/Users/Kara/projects/forks/x13binary/inst//lib/libgfortran.3.dylib`
 > [1] TRUE

 > $`/Users/Kara/projects/forks/x13binary/inst//lib/libquadmath.0.dylib`
 > [1] TRUE

Thank you, Kara.

Just for curiosity, what does

  file /Users/Kara/projects/forks/x13binary/inst//lib/libgcc_s.1.dylib

produce on your Mac?


I can reproduce, it is something like

/usr/lib/libgcc_s.1.dylib: Mach-O universal binary with 2 architectures: 
[x86_64:Mach-O 64-bit dynamically linked shared library x86_64] 
[i386:Mach-O dynamically linked shared library i386]
/usr/lib/libgcc_s.1.dylib (for architecture x86_64):    Mach-O 64-bit 
dynamically linked shared library x86_64
/usr/lib/libgcc_s.1.dylib (for architecture i386):    Mach-O dynamically 
linked shared library i386


Thanks for the report, I will fix.

Tomas



 > slibs[are_shared] then fails with invalid subscript type 'list'.

yes, "of course".

 > I believe this may be a bug and I have included a patch that uses any() 
and
 > vapply() to ensure that only one value is returned for each library and 
the
 > result is an atomic vector. This is my first time submitting a bug report
 > or patch here; I'm happy to make any changes if needed.

Your patch was not attached with MIME type   text/plain  and so
was filtered out by the mailing list software.
OTOH, I could relatively easily guess how to fix the bug,
notably when seeing the above "file ...dylib" result.

What we *meant* to say in  https://www.r-project.org/bugs.html
is that in such a situation
1) you send your finding / suspicion / diagnosis
to the R-devel mailing list,  in order to get confirmation etc
if what you see is a bug;
2) then ideally, you'd do a formal bug report at
https://bugs.r-project.org/
(for which you need to get an "account" there to be created
 once only by a bugzilla admin, typically an R core member).

In this case, that (2) may not be necessary, but you may want
that anyway (and let some of us know).

 > Thanks for considering,
 > Kara

Thank *you* indeed for the report,
Martin

 > [1]
 > 
https://github.com/wch/r-source/blob/3fe2bb01e9ec1b268803a437c308742775c2442d/src/library/tools/R/install.R#L594-L597
 > [2] https://github.com/x13org/x13binary/issues/46

 > R version 3.6.0 Patched (2019-05-22 r76579)
 > Platform: x86_64-apple-darwin15.6.0 (64-bit)
 > Running under: macOS Mojave 10.14.4

--
Martin Maechler
ETH Zurich  and  R Core Team

__
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] Possible bug when finding shared libraries during staged installation

[Kara Woo]

Yes, that's the same result that I see as well.

If you still want the formal report I can create one if someone adds me to
bugzilla, but it sounds like that may not be necessary. Thanks for looking
into this!

On Fri, May 24, 2019 at 5:58 AM Tomas Kalibera 
wrote:

> On 5/24/19 2:52 PM, Martin Maechler wrote:
> >> Kara Woo
> >>  on Thu, 23 May 2019 14:24:26 -0700 writes:
> >  > Hi all,
> >  > With the new staged installation, it seems that R CMD INSTALL
> sometimes
> >  > fails on macOS due to these lines [1] when sapply() returns a
> list. The
> >  > x13binary package has an example [2], reproducible with the
> following steps:
> >
> >  > $ git clone g...@github.com:x13org/x13binary.git && cd x13binary
> >  > $ git checkout 663ad7122
> >  > $ R CMD INSTALL .
> >
> >  > (We've also run into it in an internal package, but it's easier to
> >  > reproduce with x13binary)
> >
> >  > In this case the file command returns multiple results for one of
> the
> >  > dynamic libraries, so are_shared looks like this:
> >
> >  >> are_shared
> >  > $`/Users/Kara/projects/forks/x13binary/inst//lib/libgcc_s.1.dylib`
> >  > [1] TRUE TRUE TRUE
> >
> >  >
> $`/Users/Kara/projects/forks/x13binary/inst//lib/libgfortran.3.dylib`
> >  > [1] TRUE
> >
> >  >
> $`/Users/Kara/projects/forks/x13binary/inst//lib/libquadmath.0.dylib`
> >  > [1] TRUE
> >
> > Thank you, Kara.
> >
> > Just for curiosity, what does
> >
> >   file /Users/Kara/projects/forks/x13binary/inst//lib/libgcc_s.1.dylib
> >
> > produce on your Mac?
>
> I can reproduce, it is something like
>
> /usr/lib/libgcc_s.1.dylib: Mach-O universal binary with 2 architectures:
> [x86_64:Mach-O 64-bit dynamically linked shared library x86_64]
> [i386:Mach-O dynamically linked shared library i386]
> /usr/lib/libgcc_s.1.dylib (for architecture x86_64):Mach-O 64-bit
> dynamically linked shared library x86_64
> /usr/lib/libgcc_s.1.dylib (for architecture i386):Mach-O dynamically
> linked shared library i386
>
> Thanks for the report, I will fix.
>
> Tomas
>
> >
> >  > slibs[are_shared] then fails with invalid subscript type 'list'.
> >
> > yes, "of course".
> >
> >  > I believe this may be a bug and I have included a patch that uses
> any() and
> >  > vapply() to ensure that only one value is returned for each
> library and the
> >  > result is an atomic vector. This is my first time submitting a
> bug report
> >  > or patch here; I'm happy to make any changes if needed.
> >
> > Your patch was not attached with MIME type   text/plain  and so
> > was filtered out by the mailing list software.
> > OTOH, I could relatively easily guess how to fix the bug,
> > notably when seeing the above "file ...dylib" result.
> >
> > What we *meant* to say in  https://www.r-project.org/bugs.html
> > is that in such a situation
> > 1) you send your finding / suspicion / diagnosis
> > to the R-devel mailing list,  in order to get confirmation etc
> > if what you see is a bug;
> > 2) then ideally, you'd do a formal bug report at
> > https://bugs.r-project.org/
> >   (for which you need to get an "account" there to be created
> >once only by a bugzilla admin, typically an R core member).
> >
> > In this case, that (2) may not be necessary, but you may want
> > that anyway (and let some of us know).
> >
> >  > Thanks for considering,
> >  > Kara
> >
> > Thank *you* indeed for the report,
> > Martin
> >
> >  > [1]
> >  >
> https://github.com/wch/r-source/blob/3fe2bb01e9ec1b268803a437c308742775c2442d/src/library/tools/R/install.R#L594-L597
> >  > [2] https://github.com/x13org/x13binary/issues/46
> >
> >  > R version 3.6.0 Patched (2019-05-22 r76579)
> >  > Platform: x86_64-apple-darwin15.6.0 (64-bit)
> >  > Running under: macOS Mojave 10.14.4
> >
> > --
> > Martin Maechler
> > ETH Zurich  and  R Core Team
> >
> > __
> > 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] Give update.formula() an option not to simplify or reorder the result -- request for comments

[Abby Spurdle]

> Martin Maechler has asked me to send this to R-devel for discussion
> after I submitted it as an enhancement request (
> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17563).

I think R needs to provide more support for CAS-style symbolic computation.
That is, support by either the R language itself or the standard packages,
or both.
(And certainly not by interfacing with another interpreted language).

Obviously, I don't speak for R Core.
However, this is how I would like to see R move in the future.
...improved symbolic and symbolic-numeric computation...

I think any changes to formula objects or their methods, should be
congruent with these symbolic improvements.

[[alternative HTML version deleted]]

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