[Rd] Setting LC_CTYPE=en_US.UTF-8 failed

[Steven Penny]

Using this in my "~/.profile":

   export LC_ALL=en_US.UTF-8

Yields this:

   $ Rscript -e 'print(9)'
   During startup - Warning message:
   Setting LC_CTYPE=en_US.UTF-8 failed
   [1] 9

This is confusing as the exact same environment works fine with other
languages:

   $ python3 -c 'print(9)'
   9

   $ ruby -e 'puts 9'
   9

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

Re: [Rd] Offer zip builds

[Steven Penny]

On Tue, Jun 4, 2019 at 11:06 AM Iñaki Ucar wrote:
> FWIW, innoextract extracts the contents of the installer just fine.

That is great, thank you very much:

https://github.com/dscharrer/innoextract

Between this thread and others I have interacted with 14 people, and you are the
first person to post an actual solution rather than arguing.

I still think zip builds should be offered, but this is a good workaround until
then. Thanks again.

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

Re: [Rd] Setting LC_CTYPE=en_US.UTF-8 failed

[Tomas Kalibera]

On 6/5/19 3:49 AM, Steven Penny wrote:

Using this in my "~/.profile":

   export LC_ALL=en_US.UTF-8

Yields this:

   $ Rscript -e 'print(9)'
   During startup - Warning message:
   Setting LC_CTYPE=en_US.UTF-8 failed
   [1] 9

This is confusing as the exact same environment works fine with other
languages:

   $ python3 -c 'print(9)'
   9

   $ ruby -e 'puts 9'
   9


The locale is probably not available on your system, please 
install/generate it.


Tomas




__
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] Offer zip builds

[Jeroen Ooms]

On Tue, Jun 4, 2019 at 5:40 PM Steven Penny  wrote:
>
> Theres nothing nefarious here. It would allow people to use the R environment
> without running an installer. If someone is a new user they may want to try
> R out, and installers can be invasive as they commonly:
>
> - copy files to install dir
> - copy files to profile dir
> - set registry entries
> - set environment variables
> - set start menu entries
>
> and historically uninstallers have a bad record of reverting these changes.
> should not put this burden upon new users or even having them resort to 
> virtual
> machine to avoid items above. having a ZIP file allows new users to run the
> R environment, then if they like it perhaps they can run the installer going
> forward.

This is a valid suggestion, but probably impossible to do reliably.
Most installers (the R one is completely open source btw) perform
those steps for a reason. It is great if software can be installed
simply by extracting a zip file somewhere, but if this is what you
desire, you're using the wrong operating system.

We only offer official installation options that work 100% reliably
and I don't think this can be accomplished with a zip file. For
example a zip file won't be able to set the installation location in
the registry, and hence other software such as RStudio won't be able
to find the R installation. Also a zip installation might mix up
package libraries from different R versions (which is bad), or users
might expect they can upgrade R by overwriting their installation with
a new zip (also bad). Hence I'm afraid offering such alternative
installation options would open a new can of worms with bug reports
from Windows users with broken installations, or packages that don't
work as expected.

As for alternatives, 'rportable' and 'innoextract' have already been
mentioned if you really just want to dump the files from the
installer, if that works for you. Another popular option to install
(any) Windows software without manually running installers is using
chocolatey, for example:

  choco install miktex
  choco install r.project

This will still indirectly use official installers, but the installers
have been verified as "safe" by external folks and the installation is
completely automated. Perhaps that's another compromise you could live
with.

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

Re: [Rd] Setting LC_CTYPE=en_US.UTF-8 failed

[Duncan Murdoch]

On 06/06/2019 6:22 a.m., Tomas Kalibera wrote:

On 6/5/19 3:49 AM, Steven Penny wrote:

Using this in my "~/.profile":

    export LC_ALL=en_US.UTF-8

Yields this:

    $ Rscript -e 'print(9)'
    During startup - Warning message:
    Setting LC_CTYPE=en_US.UTF-8 failed
    [1] 9

This is confusing as the exact same environment works fine with other
languages:

    $ python3 -c 'print(9)'
    9

    $ ruby -e 'puts 9'
    9


The locale is probably not available on your system, please
install/generate it.


I think Steven is running the Windows build, not a POSIX build, so 
that's not a legal value.  He could try the Cygwin build, but I think it 
has other problems, and isn't supported by R Core.  As far as I know 
there is no Windows locale that fully supports UTF-8.


Duncan Murdoch

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

Re: [Rd] Setting LC_CTYPE=en_US.UTF-8 failed

[Duncan Murdoch]

On 06/06/2019 7:28 a.m., Duncan Murdoch wrote:

On 06/06/2019 6:22 a.m., Tomas Kalibera wrote:

On 6/5/19 3:49 AM, Steven Penny wrote:

Using this in my "~/.profile":

     export LC_ALL=en_US.UTF-8

Yields this:

     $ Rscript -e 'print(9)'
     During startup - Warning message:
     Setting LC_CTYPE=en_US.UTF-8 failed
     [1] 9

This is confusing as the exact same environment works fine with other
languages:

     $ python3 -c 'print(9)'
     9

     $ ruby -e 'puts 9'
     9


The locale is probably not available on your system, please
install/generate it.


I think Steven is running the Windows build, not a POSIX build, so
that's not a legal value.  He could try the Cygwin build, but I think it
has other problems, and isn't supported by R Core.  As far as I know
there is no Windows locale that fully supports UTF-8.



The Windows name for a UTF-8 locale is supposed to be en_US.65001 (see
 
if it hasn't disappeared by the time you read this).  However, when I 
tried that a few years ago, it didn't work.  Maybe it does now.


Duncan Murdoch

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

Re: [Rd] stopifnot

[Martin Maechler]

> Martin Maechler 
> on Mon, 3 Jun 2019 18:14:15 +0200 writes:

> Suharto Anggono Suharto Anggono 
> on Thu, 30 May 2019 14:45:22 + writes:
> Suharto Anggono Suharto Anggono 
> on Thu, 30 May 2019 14:45:22 + writes:

>> Here is a patch to function 'stopifnot' that adds 'evaluated' argument 
and makes 'exprs' argument in 'stopifnot' like 'exprs' argument in 
'withAutoprint'.

>> --- stop.R   2019-05-30 14:01:15.282197286 +
>> +++ stop_new.R   2019-05-30 14:01:51.372187466 +

> [..]

> Thank you, Suharto.

> I've looked at the patch and tested it a bit, and also (re)read
> your April 15 remarks (cited below).  I now agree that my hacks to
> enable dealing with "language objects" (typically class
> 'expression')  'exprs' has remained hackish and hence not
> working in all cases,  and that it may be a better idea to add
> a new logical argument (as in other functions) which has to be
> "switched" and then leads somewhat simpler and more robust code.

> OTOH, of course, this is an API change would typically not go into the R
> 3.6.x series ... and I have no idea if it would affect much more
> than R's own tests/reg-tests-* ...

> Even though the argument name 'evaluated' was chosen for
> withAutoprint(), I don't find it a very good name anymore, and -
> if the change should happen - would probably prefer something
> like 'is.language' or 'expr.is.language' or similar..

> Could we get any other readers' opinions ?

[none ..]

In the mean time, I've seen a nicer solution:  If have to add
yet another argument to stopifnot() to make this cleaner, I'm
now pretty sure we should rather use that new argument  to pass
an "expression-alike" object instead of unevaluated expressions.

I'm calling it `exprObject`  for now (and ditch the `evaluated=FALSE`).
With that the new code becomes even cleaner and easier to understand:

stopifnot <- function(..., exprs, exprObject, local = TRUE)
{
n <- ...length()
if((has.e <- !missing(exprs)) || !missing(exprObject)) {
if(n || (has.e && !missing(exprObject)))
stop("Only one of 'exprs', 'exprObject' or unnamed expressions, not 
more")
envir <- if (isTRUE(local)) parent.frame()
 else if(isFALSE(local)) .GlobalEnv
 else if (is.environment(local)) local
 else stop("'local' must be TRUE, FALSE or an environment")
E1 <- if(has.e && is.call(exprs <- substitute(exprs))) exprs[[1]]
cl <- if(is.symbol(E1) &&
 E1 == quote(`{`)) {
  exprs[[1]] <- quote(stopifnot) ## --> stopifnot(*, *, ..., *) 
:
  exprs
  }
  else
  as.call(c(quote(stopifnot),
if(!has.e) exprObject else as.expression(exprs)))
names(cl) <- NULL
return(eval(cl, envir=envir))
}
## else   use '...' (and not 'exprs') :

   [ code unchanged from here to the end .. ]
   [ code unchanged from here to the end .. ]
}

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

Re: [Rd] [R] Open a file which name contains a tilde

[Ivan Krylov]

On Wed, 5 Jun 2019 18:07:15 +0200
Frank Schwidom  wrote:

> +> path.expand("a ~ b")  
> [1] "a /home/user b"

> How can I switch off any file crippling activity?

It doesn't seem to be possible if readline is enabled and works
correctly.

Calls to path.expand [1] end up [2] in R_ExpandFileName [3], which
calls R_ExpandFileName_readline [4], which uses libreadline function
tilde_expand [5]. tilde_expand seems to be designed to expand '~'
anywhere in the string it is handed, i.e. operate on whole command
lines, not file paths.

I am taking the liberty of Cc-ing R-devel in case this can be
considered a bug.

-- 
Best regards,
Ivan

[1]
https://github.com/wch/r-source/blob/12d1d2d232d84aa355e48b81180a0e2c6f2f/src/main/names.c#L807

[2]
https://github.com/wch/r-source/blob/12d1d2d232d84aa355e48b81180a0e2c6f2f/src/main/platform.c#L1915

[3]
https://github.com/wch/r-source/blob/12d1d2d232d84aa355e48b81180a0e2c6f2f/src/unix/sys-unix.c#L147

[4]
https://github.com/wch/r-source/blob/12d1d2d232d84aa355e48b81180a0e2c6f2f/src/unix/sys-std.c#L494

[5]
https://git.savannah.gnu.org/cgit/readline.git/tree/tilde.c?h=devel#n187

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

Re: [Rd] Setting LC_CTYPE=en_US.UTF-8 failed

[Tomas Kalibera]

On 6/6/19 3:24 PM, Duncan Murdoch wrote:

On 06/06/2019 7:28 a.m., Duncan Murdoch wrote:

On 06/06/2019 6:22 a.m., Tomas Kalibera wrote:

On 6/5/19 3:49 AM, Steven Penny wrote:

Using this in my "~/.profile":

     export LC_ALL=en_US.UTF-8

Yields this:

     $ Rscript -e 'print(9)'
     During startup - Warning message:
     Setting LC_CTYPE=en_US.UTF-8 failed
     [1] 9

This is confusing as the exact same environment works fine with other
languages:

     $ python3 -c 'print(9)'
     9

     $ ruby -e 'puts 9'
     9


The locale is probably not available on your system, please
install/generate it.


I think Steven is running the Windows build, not a POSIX build, so
that's not a legal value.  He could try the Cygwin build, but I think it
has other problems, and isn't supported by R Core.  As far as I know
there is no Windows locale that fully supports UTF-8.



The Windows name for a UTF-8 locale is supposed to be en_US.65001 (see
 
if it hasn't disappeared by the time you read this).  However, when I 
tried that a few years ago, it didn't work.  Maybe it does now.


Yes, it is 65001 but it still cannot be used as setlocale() Windows 
locale (in LC_CTYPE), and hence R on Windows cannot use UTF-8 as native 
encoding.


Tomas



Duncan Murdoch


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

Re: [Rd] R pkg install should fail for unsuccessful DLL copy on windows?

[Toby Hocking]

If anybody else has this issue, please add a comment on
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17478 so we are more
likely to get R-core to address this.

Thanks
Toby

On Tue, Jun 4, 2019 at 2:58 PM Pages, Herve  wrote:

> On 5/31/19 08:41, Toby Hocking wrote:...
> > In my opinion install.packages should stop with an error (instead of a
> > warning) if this happens.
>
> Totally agree with that.
>
> Best,
> H.
>
> --
> Hervé Pagès
>
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024
>
> E-mail: hpa...@fredhutch.org
> Phone:  (206) 667-5791
> Fax:(206) 667-1319
>

[[alternative HTML version deleted]]

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

Re: [Rd] R pkg install should fail for unsuccessful DLL copy on windows?

[Duncan Murdoch]

On 06/06/2019 4:19 p.m., Toby Hocking wrote:

If anybody else has this issue, please add a comment on
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17478 so we are more
likely to get R-core to address this.


Please don't encourage spam there.  Add a comment if you have 
information to add, but "me too" messages just waste everybody's time.


Duncan Murdoch



Thanks
Toby

On Tue, Jun 4, 2019 at 2:58 PM Pages, Herve  wrote:


On 5/31/19 08:41, Toby Hocking wrote:...

In my opinion install.packages should stop with an error (instead of a
warning) if this happens.


Totally agree with that.

Best,
H.

--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319



[[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] [R] Open a file which name contains a tilde

[Duncan Murdoch]

On 06/06/2019 5:04 p.m., Richard O'Keefe wrote:

How can expanding tildes anywhere but the beginning of a file name NOT be
considered a bug?


It looks like a bug in R, but not necessarily a bug in libreadline:  we 
may just be using tilde_expand improperly.


Duncan Murdoch




On Thu, 6 Jun 2019 at 23:04, Ivan Krylov  wrote:


On Wed, 5 Jun 2019 18:07:15 +0200
Frank Schwidom  wrote:


+> path.expand("a ~ b")
[1] "a /home/user b"



How can I switch off any file crippling activity?


It doesn't seem to be possible if readline is enabled and works
correctly.

Calls to path.expand [1] end up [2] in R_ExpandFileName [3], which
calls R_ExpandFileName_readline [4], which uses libreadline function
tilde_expand [5]. tilde_expand seems to be designed to expand '~'
anywhere in the string it is handed, i.e. operate on whole command
lines, not file paths.

I am taking the liberty of Cc-ing R-devel in case this can be
considered a bug.

--
Best regards,
Ivan

[1]

https://github.com/wch/r-source/blob/12d1d2d232d84aa355e48b81180a0e2c6f2f/src/main/names.c#L807

[2]

https://github.com/wch/r-source/blob/12d1d2d232d84aa355e48b81180a0e2c6f2f/src/main/platform.c#L1915

[3]

https://github.com/wch/r-source/blob/12d1d2d232d84aa355e48b81180a0e2c6f2f/src/unix/sys-unix.c#L147

[4]

https://github.com/wch/r-source/blob/12d1d2d232d84aa355e48b81180a0e2c6f2f/src/unix/sys-std.c#L494

[5]
https://git.savannah.gnu.org/cgit/readline.git/tree/tilde.c?h=devel#n187

__
r-h...@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.



[[alternative HTML version deleted]]

__
r-h...@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-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel