Re: [Bioc-devel] Bioconductor 3.1 release schedule now available
- Original Message - From: Dan Tenenbaum dtene...@fredhutch.org To: bioc-devel bioc-devel@r-project.org Sent: Friday, February 27, 2015 10:12:44 AM Subject: [Bioc-devel] Bioconductor 3.1 release schedule now available Hi all, The next version of Bioconductor will be 3.0 and its release schedule is now up on our website: 3.1 of course! Sorry for the typo. Dan ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Rd] Native characterset is wrong for unicode builds for Windows
Am 27.02.2015 um 11:49 schrieb Duncan Murdoch: On 27/02/2015 2:31 AM, maill...@tlink.de wrote: 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] ®ØΔЊת enc2native(®ØΔЊת) [1] ®ØΔЊת Encoding(enc2native(®ØΔЊת)) [1] UTF-8 In Windows the result is different: ®ØΔЊת [1] ®ØΔЊת enc2native(®ØΔЊת) [1] ®ØU+0394U+040AU+05EA Encoding(enc2native(®ØΔЊת)) [1] latin1 And this is wrong. The native character set of a unicode application under Windows is *Unicode*. enc2native should do the same under Windows as it does on Ubuntu. Also the unknown encoding should be changed to mean the same as UTF-8 exactly as it is on Linux. What is a unicode application, and what makes you think R is one? R is being told by Windows that your native encoding is latin1. Perhaps Windows 8 supports UTF-8 as a native encoding (I've never used it), but previous versions of Windows didn't. Duncan Murdoch A unicode application is a program that uses the unicode API of Windows R uses those functions, so I guess it is a unicode application. But internally it uses an 8 bit encoding (normally the native one for the platform it is running on, which in your case is apparently latin1). - the functions with the ending W. For such a application the system code page (native encoding) is completely irrelevant. The system code page is just a compatibility feature that enables Windows NT/Vista/7/8 to run applications that were developed for Windows 95 which didn't have unicode support. Windows 95 had UCS-2 support, which was pretty close to UTF-16. But this line of operating systems is dead for 10 years now. R obviously is a unicode application because it can print - or read from the clipboard - characters like ΔЊת that are not in my system code page which is not possible over the legacy API. So unicode application is something you just made up. If you use Windows development tools, they have macros to convert generic functions to either A or W versions. R doesn't use those. It calls the W functions when it has UTF-16 characters, and A functions when it has native characters. I would love it if R was a UTF-8 application, because it would make life so much simpler, but Windows doesn't support that. So R needs to do tons of conversions. If you don't like that, you probably need to stick with Ubuntu. Duncan Murdoch I am not complaining about those conversions. They work just fine already. I am complaining about enc2native breaking things in the windows builds. An assignment like s - format(®ØΔЊת) has no interaction with windows at all yet s contains garbage like ®ØU+0394U+040AU+05EA after that. And if a native encoding of UTF-8 - as defined by enc2native - works in Ubuntu why shouldn't it work in Windows? Because in Ubuntu, UTF-8 is the native encoding, and in your Windows system, latin1 is the native encoding. But I do agree that the format() issue is a problem. I haven't traced through the code, but I think the string ®ØΔЊת is read using Windows API functions that return a UTF-16 result, then converted by R to UTF-8. So format() should see that it is a UTF-8 string and not convert it to the native encoding. There is nothing wrong with enc2native(), it's doing what you asked for. The problem is that format() is using it. Duncan Murdoch I would expect that every function that is using enc2native is broken in this respect because it invariably will scramble most unicode characters in the process and I can't think of a case where this could be wanted actually. Functions that really need something other than UTF-8 are probably using iconv and getOption(encoding) anyway as this allows to specify the desired encoding much more flexible. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] The Environment variables settings in bin/R, why do they ignore environment variables of the same name?
On 27 Feb 2015, at 01:20 , Saptarshi Guha saptarshi.g...@gmail.com wrote: 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 read the values from the environment variables of the same name (assuming they exist) and defaulting to these hard coded values in case they dont? Yes. The R installation knows what the values should be and you do not. Especially if you have multiple version of R installed, you'd get yourself into a rotten mess otherwise. As I recall it, this logic was introduced years ago after instances of people building (say) r-devel from source and finding that it wouldn't run, the reason being that it was looking for system files in the wrong place (and as the relevant contents of the $R_HOME subdirectories only changed rarely, people had been getting away with it for a long time until we suddenly broke r-devel). -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] static pdf vignette
On Fri, Feb 27, 2015 at 4:05 AM, Kirill Müller
kirill.muel...@ivt.baug.ethz.ch wrote:
Perhaps the R.rsp package by Henrik Bengtsson [1,2] is an option.
Cheers
Kirill
[1] http://cran.r-project.org/web/packages/R.rsp/index.html
[2] https://github.com/HenrikBengtsson/R.rsp
Yes, this use case is one of the rationale for providing the
R.rsp::asis vignette engine (and the R.rsp::tex one). Just make sure
you try your best to provide the source in the *.tar.gz distribution,
which shouldn't be hard in this case since you're generating the PDF
from a (Sweave/knitr) vignette. For instructions, see the R.rsp 'R
packages: Static PDF and HTML vignettes'.
Also, if it's not already clear, users who install your package do
*not* have to install vignette engine packages (here R.rsp), i.e.
you're not adding any overhead for them; it's only when you as a
package developer run 'R CMD build' that the vignette engine machinery
is needed.
/Henrik
(author of R.rsp)
On 27.02.2015 02:44, Wang, Zhu wrote:
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 this?
Thanks,
Zhu Wang
**Connecticut Children's Confidentiality Notice**
This e-mail message, including any attachments, is for...{{dropped:6}}
__
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] Native characterset is wrong for unicode builds for Windows
On 27/02/2015 2:31 AM, maill...@tlink.de wrote: 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] ®ØΔЊת enc2native(®ØΔЊת) [1] ®ØΔЊת Encoding(enc2native(®ØΔЊת)) [1] UTF-8 In Windows the result is different: ®ØΔЊת [1] ®ØΔЊת enc2native(®ØΔЊת) [1] ®ØU+0394U+040AU+05EA Encoding(enc2native(®ØΔЊת)) [1] latin1 And this is wrong. The native character set of a unicode application under Windows is *Unicode*. enc2native should do the same under Windows as it does on Ubuntu. Also the unknown encoding should be changed to mean the same as UTF-8 exactly as it is on Linux. What is a unicode application, and what makes you think R is one? R is being told by Windows that your native encoding is latin1. Perhaps Windows 8 supports UTF-8 as a native encoding (I've never used it), but previous versions of Windows didn't. Duncan Murdoch A unicode application is a program that uses the unicode API of Windows R uses those functions, so I guess it is a unicode application. But internally it uses an 8 bit encoding (normally the native one for the platform it is running on, which in your case is apparently latin1). - the functions with the ending W. For such a application the system code page (native encoding) is completely irrelevant. The system code page is just a compatibility feature that enables Windows NT/Vista/7/8 to run applications that were developed for Windows 95 which didn't have unicode support. Windows 95 had UCS-2 support, which was pretty close to UTF-16. But this line of operating systems is dead for 10 years now. R obviously is a unicode application because it can print - or read from the clipboard - characters like ΔЊת that are not in my system code page which is not possible over the legacy API. So unicode application is something you just made up. If you use Windows development tools, they have macros to convert generic functions to either A or W versions. R doesn't use those. It calls the W functions when it has UTF-16 characters, and A functions when it has native characters. I would love it if R was a UTF-8 application, because it would make life so much simpler, but Windows doesn't support that. So R needs to do tons of conversions. If you don't like that, you probably need to stick with Ubuntu. Duncan Murdoch I am not complaining about those conversions. They work just fine already. I am complaining about enc2native breaking things in the windows builds. An assignment like s - format(®ØΔЊת) has no interaction with windows at all yet s contains garbage like ®ØU+0394U+040AU+05EA after that. And if a native encoding of UTF-8 - as defined by enc2native - works in Ubuntu why shouldn't it work in Windows? Because in Ubuntu, UTF-8 is the native encoding, and in your Windows system, latin1 is the native encoding. But I do agree that the format() issue is a problem. I haven't traced through the code, but I think the string ®ØΔЊת is read using Windows API functions that return a UTF-16 result, then converted by R to UTF-8. So format() should see that it is a UTF-8 string and not convert it to the native encoding. There is nothing wrong with enc2native(), it's doing what you asked for. The problem is that format() is using it. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Bioc-devel] 100k SVN commits...
On 02/27/2015 03:28 PM, Martin Morgan wrote: I noticed that we're at r99955 in svn; who will be the lucky person making the 100,000th commit? depends how many zeroes after the one you're gonna put on the check... 5? ;-) H. Martin -- 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 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Feature Request--add host and port to makeTxDbPackageFromBiomart
Hi Sean, This seems like a solid suggestion. I have put it into my queue. Marc On 02/27/2015 04:41 AM, Sean Davis wrote: Hi, Marc. Since Ensembl has switched to GRCh38 for their most recent builds, to get access to GRCh37 data now requires a different host and port for biomaRt. These are exposed in the makeTxDbFromBiomart, but not the accompanying functionality to directly make a package. Would it make sense to add host and port as arguments for the latter? Thanks, Sean [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Rd] static pdf vignette
Perhaps the R.rsp package by Henrik Bengtsson [1,2] is an option.
Cheers
Kirill
[1] http://cran.r-project.org/web/packages/R.rsp/index.html
[2] https://github.com/HenrikBengtsson/R.rsp
On 27.02.2015 02:44, Wang, Zhu wrote:
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 this?
Thanks,
Zhu Wang
**Connecticut Children's Confidentiality Notice**
This e-mail message, including any attachments, is for...{{dropped:6}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
