Re: [Rd] Native characterset is wrong for unicode builds for Windows

2015-02-26 Thread maill...@tlink.de
Am 27.02.2015 um 03:13 schrieb Duncan Murdoch: On 26/02/2015 6:34 PM, maill...@tlink.de wrote: On 26/02/2015 3:09 PM, maill...@tlink.de wrote: When I send some outlandish characters through enc2native (or format) in R 3.1.2 on Ubuntu trusty it works quite well: > "®ØΔЊת" [1] "®ØΔЊת" > en

Re: [Rd] Native characterset is wrong for unicode builds for Windows

2015-02-26 Thread Duncan Murdoch
On 26/02/2015 6:34 PM, maill...@tlink.de wrote: >> On 26/02/2015 3:09 PM, maill...@tlink.de wrote: >>> When I send some outlandish characters through enc2native (or format) in >>> R 3.1.2 on Ubuntu trusty it works quite well: >>> >>> > "®ØΔЊת" >>> [1] "®ØΔЊת" >>> > enc2native("®ØΔЊת") >>> [1] "

Re: [Rd] The Environment variables settings in bin/R, why do they ignore environment variables of the same name?

2015-02-26 Thread Dirk Eddelbuettel
On 26 February 2015 at 16:20, Saptarshi Guha wrote: | In installation/R/bin/R i notice | | 1. R_HOME_DIR is hard coded e.g. | R_HOME_DIR=/usr/local/lib64/R | | 2. It ignores R_HOME_DIR | | echo "WARNING: ignoring environment value of R_HOME" | | 3. R_SHARE_DIR, R_INCLUDE_DIR and R_DOC_DIR are

[Rd] static pdf vignette

2015-02-26 Thread Wang, Zhu
Dear all, In my package I have a computational expensive Rnw file which can't pass R CMD check. Therefore I set eval=FALSE in the Rnw file. But I would like to have the pdf vignette generated by the Rnw file with eval=TRUE. It seems to me a static pdf vignette is an option. Any suggestions on

[Rd] The Environment variables settings in bin/R, why do they ignore environment variables of the same name?

2015-02-26 Thread Saptarshi Guha
Hello, In installation/R/bin/R i notice 1. R_HOME_DIR is hard coded e.g. R_HOME_DIR=/usr/local/lib64/R 2. It ignores R_HOME_DIR echo "WARNING: ignoring environment value of R_HOME" 3. R_SHARE_DIR, R_INCLUDE_DIR and R_DOC_DIR are also hard coded. Is there a reason why these settings do not re

Re: [Rd] Native characterset is wrong for unicode builds for Windows

2015-02-26 Thread maill...@tlink.de
Am 26.02.2015 um 23:44 schrieb Winston Chang: > On Thu, Feb 26, 2015 at 2:09 PM, maill...@tlink.de > > wrote: > > > When I send some outlandish characters through enc2native (or > format) in R 3.1.2 on Ubuntu trusty it works quite well:

Re: [Rd] Native characterset is wrong for unicode builds for Windows

2015-02-26 Thread maill...@tlink.de
On 26/02/2015 3:09 PM, maill...@tlink.de wrote: When I send some outlandish characters through enc2native (or format) in R 3.1.2 on Ubuntu trusty it works quite well: > "®ØΔЊת" [1] "®ØΔЊת" > enc2native("®ØΔЊת") [1] "®ØΔЊת" > Encoding(enc2native("®ØΔЊת")) [1] "UTF-8" In Windows the result

Re: [Rd] Native characterset is wrong for unicode builds for Windows

2015-02-26 Thread Winston Chang
On Thu, Feb 26, 2015 at 2:09 PM, maill...@tlink.de wrote: > > When I send some outlandish characters through enc2native (or format) in R > 3.1.2 on Ubuntu trusty it works quite well: > > > "®ØΔЊת" > [1] "®ØΔЊת" > > enc2native("®ØΔЊת") > [1] "®ØΔЊת" > > Encoding(enc2native("®ØΔЊת")) > [1] "UTF-8"

Re: [Rd] Native characterset is wrong for unicode builds for Windows

2015-02-26 Thread Duncan Murdoch
On 26/02/2015 3:09 PM, maill...@tlink.de wrote: > > When I send some outlandish characters through enc2native (or format) in > R 3.1.2 on Ubuntu trusty it works quite well: > > > "®ØΔЊת" > [1] "®ØΔЊת" > > enc2native("®ØΔЊת") > [1] "®ØΔЊת" > > Encoding(enc2native("®ØΔЊת")) > [1] "UTF-8" > > I

[Rd] Native characterset is wrong for unicode builds for Windows

2015-02-26 Thread maill...@tlink.de
When I send some outlandish characters through enc2native (or format) in R 3.1.2 on Ubuntu trusty it works quite well: > "®ØΔЊת" [1] "®ØΔЊת" > enc2native("®ØΔЊת") [1] "®ØΔЊת" > Encoding(enc2native("®ØΔЊת")) [1] "UTF-8" In Windows the result is different: > "®ØΔЊת" [1] "®ØΔЊת" > enc2native("®

Re: [Rd] iterated lapply

2015-02-26 Thread luke-tierney
Actually using local() might create some issues, though probably not many. For the C implementation of lapply I would probably create a new environment with a frame containing the binding for i and use that in an eval call. That wouldn't add another call frame, but it would change the environment

Re: [Rd] iterated lapply

2015-02-26 Thread William Dunlap
Would introducing the new frame, with the call to local(), cause problems when you use frame counting instead of <<- to modify variables outside the scope of lapply's FUN, I think the frame counts may have to change. E.g., here is code from actuar::simul() that might be affected: x <- unl

Re: [Rd] iterated lapply

2015-02-26 Thread Martin Maechler
> Michael Weylandt > on Wed, 25 Feb 2015 21:43:36 -0500 writes: >> On Feb 25, 2015, at 5:35 PM, Benjamin Tyner >> wrote: >> >> Actually, it depends on the number of cores: > Under current semantics, yes. Each 'stream' of function > calls is lazily capturing