Re: [Rd] Speed-up/Cache loadNamespace()
- Original Message - > From: "Dirk Eddelbuettel" > To: "Mario Annau" > Cc: "r-devel@r-project.org" > Sent: Sunday, July 19, 2020 10:09:24 PM > Subject: Re: [Rd] Speed-up/Cache loadNamespace() > On 19 July 2020 at 20:47, Mario Annau wrote: >| Am So., 19. Juli 2020 um 20:11 Uhr schrieb Hugh Parsonage < >| hugh.parson...@gmail.com>: >| > 3. Keep an R session running in perpetuity and source the scripts within >| > that everlasting session >| However, 3. sounds interesting - how would this work in a Linux environment? > > You had Rserve by Simon for close to 20 years. There isn't much in terms of > fancy docs but it has been widely used. In essence, R runs "headless" and > connect to it (think "telnet" or "ssh", but programmatically), fire off > request and get results with zero startup latency. But more work to build > the access layer. > > And Rserve is also underneath RestRserve which allows you to query a running > server vai REST / modern web stack tech. (Think "plumber", but in C++ and > faster / more scaleable). > > Lastly, there is Jeroen's OpenCPU. Or... lastly, the R Service Bus which has been used in production since 2010 and got a maintenance release (6.4.0) last week: https://rservicebus.io/ For REST (both asynchronous and synchronous APIs are available), you can start here: https://rservicebus.io/api/introduction/ Best, Tobias __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Underscores in package names
> Creeping code complexity ... > > I like to think that the cuteR names will have a Darwinian > disadvantage in the long run. FWIW Hadley Wickham argues (rightly, I > think) against mixed-case names: > http://r-pkgs.had.co.nz/package.html#naming. Good development environments will offer content assist (or tab completion or similar) which will not be hindered by naming conventions (whether camel case, dromedary case or other forms that snaked into the R world). Talking about Darwinian advantages, Wikipedia[1] just taught me about the existence of 'darwin case' ?! Best, Tobias [1] https://en.wikipedia.org/wiki/Camel_case > On 2019-08-09 2:00 p.m., neonira Arinoem wrote: >> Won't it be better to have a convention that allows lowercase, dash, >> underscore and dot as only valid characters for new package names and keep >> the ancient format validation scheme for older package names? >> >> This could be implemented by a single function, taking a strictNaming_b_1 >> parameter which defaults to true. Easy to use, and compliance results will >> vary according to the parameter value, allowing strict compliance for new >> package names and lazy compliance for older ones. >> >> Doing so allows to enforce a new package name convention while also >> insuring continuity of compliance for already existing package names. >> >> Fabien GELINEAU alias Neonira >> >> Le ven. 9 août 2019 à 18:40, Kevin Wright a écrit : >> >>> Please, no. I'd also like to disallow uppercase letters in package names. >>> For instance, the cuteness of using a capital "R" in package names is >>> outweighed by the annoyance of trying to remember which packages use an >>> upper-case letter. >>> >>> On Thu, Aug 8, 2019 at 9:32 AM Jim Hester >>> wrote: >>> Are there technical reasons that package names cannot be snake case? This seems to be enforced by `.standard_regexps()$valid_package_name` which currently returns "[[:alpha:]][[:alnum:].]*[[:alnum:]]" Is there any technical reason this couldn't be altered to accept `_` as well, e.g. "[[:alpha:]][[:alnum:]._]*[[:alnum:]]" I realize that historically `_` has not always been valid in variable names, but this has now been acceptable for 15+ years (since R 1.9.0 I believe). Might we also allow underscores for package names? Jim __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel >>> >>> >>> -- >>> Kevin Wright >>> >>> [[alternative HTML version deleted]] >>> >>> __ >>> 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 >> > > __ > 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] Example input data with example output using relative pathway in vignette of R package?
Hi Luck,
If your package is installed,
system.file("extdata", "InputFiles", package = "myPackage")
will give you the full path of the InputFiles directory.
See ?system.file for more details.
HTH,
Tobias
- Original Message -
> From: "Luck Buttered"
> To: "r-devel@r-project.org"
> Sent: Saturday, October 31, 2015 9:14:06 PM
> Subject: [Rd] Example input data with example output using relative pathway
> in vignette of R package?
> I'm putting together an R package. I would like to show example code in the
> vignette, where example data files (included in the package) are used to
> generate an (example) output file.
>
> I read about using example data in Hadley Wickham's post (
> http://r-pkgs.had.co.nz/data.html), and believe I should keep my example
> data as raw data, as it must be parsed to generate the output.
>
> So, I created a directory in my package structure
>
> /Users/userName/myPackage/inst/extdata/
>
> with subdirectories InputFiles and OutputFiles.
>
> And I put the example file (exampleData.csv) inside of the InputFiles
> subdirectory (/Users/userName/myPackage/inst/extdata/InputFiles).
>
> My vignette is located in:
>
> /Users/userName/myPackage/vignettes/myPackage.Rnw
>
> It contains the following syntax:
>
>
[Rd] [OT] new R logo in vector graphics format
L.S. Since some time there is a new r-project.org site as announced here: https://stat.ethz.ch/pipermail/r-announce/2015/000581.html The logo has changed on the site, but I fail to find a vector graphics file. For the previous logo I used to go to https://svn.r-project.org/R-dev-web/trunk/Logo/ Is there anything similar for the new logo? Many thanks in advance. Kind regards, Tobias -- Tobias Verbeke Managing Director Open Analytics NV Jupiterstraat 20 2600 Antwerp Belgium E tobias.verb...@openanalytics.eu M +32 499 36 33 15 http://www.openanalytics.eu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [OT] new R logo in vector graphics format
Thank you, Tobias - Original Message - From: hadley wickham h.wick...@gmail.com To: Tobias Verbeke tobias.verb...@openanalytics.eu Cc: r-devel@r-project.org r-devel@r-project.org Sent: Sunday, August 30, 2015 10:47:16 PM Subject: Re: [Rd] [OT] new R logo in vector graphics format It exists but is not currently available. We'll make it available once we have a trademark use policy in place. Hadley On Sun, Aug 30, 2015 at 2:58 PM, Tobias Verbeke tobias.verb...@openanalytics.eu wrote: L.S. Since some time there is a new r-project.org site as announced here: https://stat.ethz.ch/pipermail/r-announce/2015/000581.html The logo has changed on the site, but I fail to find a vector graphics file. For the previous logo I used to go to https://svn.r-project.org/R-dev-web/trunk/Logo/ Is there anything similar for the new logo? Many thanks in advance. Kind regards, Tobias -- Tobias Verbeke Managing Director Open Analytics NV Jupiterstraat 20 2600 Antwerp Belgium E tobias.verb...@openanalytics.eu M +32 499 36 33 15 http://www.openanalytics.eu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] NEWS file inconsistency
L.S. I noticed the NEWS file as made available at http://cran.r-project.org/src/base/NEWS became inconsistent in describing CHANGES for a new R version: $ wget http://cran.r-project.org/src/base/NEWS $ cat NEWS | grep 'CHANGES IN ' CHANGES IN 3.2.0: CHANGES IN R 3.1.3: CHANGES IN R 3.1.2: CHANGES IN R 3.1.1: CHANGES IN R 3.1.0: CHANGES IN R 3.0.3: CHANGES IN R 3.0.2: CHANGES IN R 3.0.1: CHANGES IN R 3.0.0: Not a big issue, obviously, but we were parsing the file as part of a build procedure. Best, Tobias __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NEWS file inconsistency
Many thanks, Duncan. We will check the prerelease versions of R 3.2.1. Best regards, Tobias - Original Message - From: Duncan Murdoch murdoch.dun...@gmail.com To: Tobias Verbeke tobias.verb...@openanalytics.eu, r-devel@r-project.org r-devel@r-project.org Sent: Saturday, June 6, 2015 2:37:04 PM Subject: Re: [Rd] NEWS file inconsistency On 06/06/2015 8:18 AM, Tobias Verbeke wrote: L.S. I noticed the NEWS file as made available at http://cran.r-project.org/src/base/NEWS became inconsistent in describing CHANGES for a new R version: $ wget http://cran.r-project.org/src/base/NEWS $ cat NEWS | grep 'CHANGES IN ' CHANGES IN 3.2.0: CHANGES IN R 3.1.3: CHANGES IN R 3.1.2: CHANGES IN R 3.1.1: CHANGES IN R 3.1.0: CHANGES IN R 3.0.3: CHANGES IN R 3.0.2: CHANGES IN R 3.0.1: CHANGES IN R 3.0.0: Not a big issue, obviously, but we were parsing the file as part of a build procedure. That's already been fixed, and hopefully it won't happen again in 3.2.1, due in a couple of weeks. I thought it had been fixed before release, but apparently not. Please do check the 3.2.1 pre-release versions (starting Monday) and make sure they work with your tools. Duncan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] parallel::detectCores(TRUE) gives: Error in system(cmd, TRUE) : error in running command
- Original Message - From: Marius Hofert marius.hof...@uwaterloo.ca To: R-devel r-devel@r-project.org Sent: Friday, August 22, 2014 10:03:13 PM Subject: [Rd] parallel::detectCores(TRUE) gives: Error in system(cmd, TRUE) : error in running command Hi, Both under the current R-devel (r66456) and a version from about 3 months ago, I experience the following behavior: parallel::detectCores(TRUE) Error in system(cmd, TRUE) : error in running command traceback() 3: system(cmd, TRUE) 2: gsub(^ +, , system(cmd, TRUE)[1]) 1: parallel::detectCores(TRUE) This is on Ubuntu 14.04. Does anybody else see this? [I currently have quite a heavy workload, otherwise I would have installed and tested it also under 3.1.1] Same under R 3.1.1 parallel::detectCores(TRUE) Error in system(cmd, TRUE) : error in running command Best, Tobias __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Question: Publishing R/S objects with WebServices (SOAP/WSDL)
Hi Kurt, The R Service Bus was made to do this. http://rsb.doc.openanalytics.eu/dev/ http://rsb.doc.openanalytics.eu/dev/wsdocs/index.html Running in production at multiple big pharma companies since 2010. Open source and freely available. Best, Tobias - Original Message - From: Kurt Schallitz schallitz.k...@gene.com To: r-devel@r-project.org Sent: Tuesday, July 22, 2014 4:21:09 PM Subject: [Rd] Question: Publishing R/S objects with WebServices (SOAP/WSDL) Hello, Can anyone tell me if there is a package which will allow me to write a package in R, then publish the package using WebServices? The idea is that I want to be able to pass a data set into R, have R perform the calculations, then send the result back to either a .Net application or a LIMS BASIC application. So far I see many packages that allow R to consume WebServices, but I haven't seen anything that allows you to publish a package as a WebService. One company advertised a product for WebServices, but they are not using the term in an industry standardized way - they are using it to mean, I can publish my R results on the web and access them from the web. This is NOT what we are looking for. We want to use true Web Services using SOAP and WSDL. Any help would be much appreciated. -- Kurt Schallitz Sr. Software Developer [LIMS] FPPQI Genentech (650)-467-7304 [[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] request of information about creating DLL from R to be used in other languages/programs
- Original Message - From: Duncan Murdoch murdoch.dun...@gmail.com To: Ludovic.Brossard ludovic.bross...@rennes.inra.fr Cc: r-devel@r-project.org Sent: Friday, July 18, 2014 9:17:12 PM Subject: Re: [Rd] request of information about creating DLL from R to be used in other languages/programs On 18/07/2014, 1:26 PM, Ludovic.Brossard wrote: Thanks for this answer. If I have well understood, there is no way to create dll and call it without having R installed on the computer ? R is open source so you could probably work out something, but there is no built-in support for doing that. As a (potential) alternative solution to the problem, you may want to address R functionality over RESTful web services, using e.g. the R Service Bus. Then your Delphi clients can all make use of a single central installation of R. See http://rsb.doc.openanalytics.eu/dev/ for the technical documentation and http://rsb.doc.openanalytics.eu/dev/wsdocs/index.html for the API overview. Best, Tobias Duncan Murdoch Sorry if I am wrong i am not a specialist. thanks Ludovic Brossard On 18/07/2014, 10:29 AM, Ludovic Brossard wrote: Hello My question is the following. I have tried to find a similar subject in archives but not found (perhaps bad search!) and I tried R-help and I was advised that R-devel would perhaps better for my question So I wonder if it is possible to create a dll from a R code to use it in another language/program. Indeed, one of my colleague wrote a R code combining some R functions to create a method of calculation. I would want to use this method in a program coded in Delphi. Is there possibilities to create a DLL from R code to be called in the Delphi program ? It would allow us to avoid rewriting code and searching correspondence between R functions and Delphi program (or other types of tools as TPMath). Is it possible to call a dll form R whereas R is not installed on the computer? I hope to be clear in my demand an I hope you will be able to give me some indications or where to find it. Most of this is possible, but not easy. See chapter 8 of the Writing R Extensions manual. You are essentially writing a new front-end to R, and it will require R to be installed for it to work. Many years ago I wrote instructions for using Delphi to create a DLL for R to use, which is another approach you could try. I've no idea how obsolete those instructions are nowadays, but they might give you some starting points: http://www.stats.uwo.ca/faculty/murdoch/software/compilingDLLs/pascal.html Duncan Murdoch Best regards Ludovic Brossard Ludovic BROSSARD UMR PEGASE (Physiologie, Environnement et Génétique pour l’Animal et les Systèmes d’Elevage) INRA – Agrocampus Ouest Domaine de la Prise, 35590 Saint-Gilles, France Tél : 33 (0)2 23 48 70 57 . Fax : 33(0)2 23 48 50 80 http://www.rennes.inra.fr/pegase www.rennes.inra.fr/pegase http://www.rennes.inra.fr/pegase. [[alternative HTML version deleted]] __ R-devel@r-project.org mailto:R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel Ludovic Brossard INRA - UMR PEGASE Domaine de la Prise 35590 SAINT GILLES tel : 02 23 48 70 57 fax : 02 23 48 50 80 __ 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 crash using Sys.which on Windows
Dear Prof. Ripley, Many thanks for the change in R 3.1.1 to be as well as for the description of the workaround for R 3.1.0. Best regards, Tobias Verbeke - Original Message - From: Prof Brian Ripley rip...@stats.ox.ac.uk To: r-devel@r-project.org Sent: Monday, May 12, 2014 12:40:17 PM Subject: Re: [Rd] R crash using Sys.which on Windows This is a change in behaviour of the Windows API function since the code was written (years ago). It will be changed in R 3.1.1: meanwhile you can always use the shortPathName to abbreviate the name. On 06/05/2014 19:28, Tobias Verbeke wrote: Dear list, When installing the latest version of Rtools (3.1.0.1942) into a path that contains more than 96 characters on Windows 7 64-bit, e.g. into C:\TheLatestRtoolsInAPathWithMoreThanNinetySixCharactersWillCrashTheRSessionUponCallingTheSysWhichFunctionInRToGetTheGccPath and assuming that the Rtools bin paths have been appropriately added to the PATH environment variable as in c:\TheLatestRtoolsInAPathWithMoreThanNinetySixCharactersWillCrashTheRSessionUponCallingTheSysWhichFunctionInRToGetTheGccPath\bin;c:\TheLatestRtoolsInAPathWithMoreThanNinetySixCharactersWillCrashTheRSessionUponCallingTheSysWhichFunctionInRToGetTheGccPath\gcc-4.6.3\bin the following call from RGui 64-bit (version 3.1.0) reproducibly causes R to crash: Sys.which(ls) Sys.which seems to use an internal function on Windows. Is this a known issue? Please let me know if I can provide any more relevant information. Best, Tobias __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ 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 crash using Sys.which on Windows
Some clarifications and additional data on this bug: - this has nothing to do with Rtools as such, but applies to finding any executable with 'Sys.which' that happens to live in a path with more than 96 characters; - the issue also occurs when using the 32-bit version of RGui on Windows 7 64-bit (and also with R.exe at the command line); - the issue also occurs when using the 32-bit version of RGui on Windows 7 32-bit (and also with R.exe at the command line). By means of example, the 'problem details' as given by Windows when R crashes is pasted below: Problem signature: Problem Event Name: APPCRASH Application Name: Rterm.exe Application Version: 3.10.65387.0 Application Timestamp:5347f09a Fault Module Name:ntdll.dll Fault Module Version: 6.1.7601.17514 Fault Module Timestamp: 4ce7b96e Exception Code: c005 Exception Offset: 000558d4 OS Version: 6.1.7601.2.1.0.256.48 Locale ID:1033 Additional Information 1: 0a9e Additional Information 2: 0a9e372d3b4ad19135b953a78882e789 Additional Information 3: 0a9e Additional Information 4: 0a9e372d3b4ad19135b953a78882e789 Best, Tobias - Original Message - From: Tobias Verbeke tobias.verb...@openanalytics.eu To: r-devel@r-project.org Sent: Tuesday, May 6, 2014 8:28:54 PM Subject: [Rd] R crash using Sys.which on Windows Dear list, When installing the latest version of Rtools (3.1.0.1942) into a path that contains more than 96 characters on Windows 7 64-bit, e.g. into C:\TheLatestRtoolsInAPathWithMoreThanNinetySixCharactersWillCrashTheRSessionUponCallingTheSysWhichFunctionInRToGetTheGccPath and assuming that the Rtools bin paths have been appropriately added to the PATH environment variable as in c:\TheLatestRtoolsInAPathWithMoreThanNinetySixCharactersWillCrashTheRSessionUponCallingTheSysWhichFunctionInRToGetTheGccPath\bin;c:\TheLatestRtoolsInAPathWithMoreThanNinetySixCharactersWillCrashTheRSessionUponCallingTheSysWhichFunctionInRToGetTheGccPath\gcc-4.6.3\bin the following call from RGui 64-bit (version 3.1.0) reproducibly causes R to crash: Sys.which(ls) Sys.which seems to use an internal function on Windows. Is this a known issue? Please let me know if I can provide any more relevant information. Best, Tobias __ 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] checking dependencies in R code ... WARNING
Hi Knut, The code will contain library or require statements, which do not belong there, but need to replaced by specifying the dependencies on these packages in the DESCRIPTION file (Depends / Imports field). For imports you also need to make sure the NAMESPACE file contains the intended statements. See http://cran.r-project.org/doc/manuals/R-exts.html#Package-Dependencies Best, Tobias - Original Message - From: Knut Krueger r...@knut-krueger.de To: R Devel List r-devel@r-project.org Sent: Thursday, May 8, 2014 8:15:03 AM Subject: [Rd] checking dependencies in R code ... WARNING I am trying to update an unsupported package and got the warning: * checking dependencies in R code ... WARNING 'library' or 'require' calls not declared from: 'Hmisc' 'R2HTML' 'tcltk' Missing or unexported object: 'utils::.win32consoleCompletion' See the information on DESCRIPTION files in the chapter 'Creating R packages' of the 'Writing R Extensions' manual. Is it only an error in the description file or in the code? Regards Knut __ 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] checking dependencies in R code ... WARNING
Hi Knut, I was primarily referring to the issues reported on the line 'library' or 'require' calls not declared from: 'Hmisc' 'R2HTML' 'tcltk' but what you say for .win32consoleCompletion does not seem wrong, esp. that it is not recommended to make use of ::: operators inside a package. Best, Tobias - Original Message - From: Knut Krueger r...@knut-krueger.de To: r-devel@r-project.org Sent: Thursday, May 8, 2014 8:59:43 AM Subject: Re: [Rd] checking dependencies in R code ... WARNING Am 08.05.2014 08:35, schrieb Tobias Verbeke: Hi Knut, The code will contain library or require statements, which do not belong there, but need to replaced by specifying the dependencies on these packages in the DESCRIPTION file (Depends / Imports field). For imports you also need to make sure the NAMESPACE file contains the intended statements. See http://cran.r-project.org/doc/manuals/R-exts.html#Package-Dependencies Best, Tobias Hi Tobias, if I am right it should be a code from the utils package # Use the internal win32consoleCompletion function in utils package res - utils:::.win32consoleCompletion(code, nchar(code)) IMPORT field ... Namespaces accessed by the ‘::’ and ‘:::’ operators must be listed here, DESCRIPTION Imports: utils, foo, ... it is included NAMESAPCE: import(utils, foo, ) could it be another problem? I found: Using foo:::f instead of foo::f allows access to unexported objects. This is generally not recommended, as the semantics of unexported objects may be changed by the package author in routine maintenance. Best Knut __ 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
[Rd] trivial patch solve.Rd (typo)
L.S.
Please find below a trivial patch which corrects a typo in solve.Rd from base.
Best,
Tobias
Index: solve.Rd
===
--- .architect/workspace/R_svn/src/library/base/man/solve.Rd(revision 65545)
+++ .architect/workspace/R_svn/src/library/base/man/solve.Rd(working copy)
@@ -44,7 +44,7 @@
\code{\link{qr.solve}} can handle non-square systems.
}
\source{
- The defult method is an interface to the LAPACK routines \code{DGESV}
+ The default method is an interface to the LAPACK routines \code{DGESV}
and \code{ZGESV}.
LAPACK is from \url{http://www.netlib.org/lapack}.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R crash using Sys.which on Windows
Dear list, When installing the latest version of Rtools (3.1.0.1942) into a path that contains more than 96 characters on Windows 7 64-bit, e.g. into C:\TheLatestRtoolsInAPathWithMoreThanNinetySixCharactersWillCrashTheRSessionUponCallingTheSysWhichFunctionInRToGetTheGccPath and assuming that the Rtools bin paths have been appropriately added to the PATH environment variable as in c:\TheLatestRtoolsInAPathWithMoreThanNinetySixCharactersWillCrashTheRSessionUponCallingTheSysWhichFunctionInRToGetTheGccPath\bin;c:\TheLatestRtoolsInAPathWithMoreThanNinetySixCharactersWillCrashTheRSessionUponCallingTheSysWhichFunctionInRToGetTheGccPath\gcc-4.6.3\bin the following call from RGui 64-bit (version 3.1.0) reproducibly causes R to crash: Sys.which(ls) Sys.which seems to use an internal function on Windows. Is this a known issue? Please let me know if I can provide any more relevant information. Best, Tobias __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] regenerate Rscript after moving R installation
Dear Simon, Many thanks for all additional detail and insight into your practice using rhome and symlinks. Much appreciated! Best, Tobias - Original Message - From: Simon Urbanek simon.urba...@r-project.org To: Tobias Verbeke tobias.verb...@openanalytics.eu Cc: r-devel@r-project.org Sent: Sunday, September 22, 2013 3:45:41 AM Subject: Re: [Rd] regenerate Rscript after moving R installation I forgot to mention that some packages bake-in paths as well, so even if you fix both R and Rscript, it will still not work in general. On Sep 22, 2013, at 3:42 AM, Simon Urbanek simon.urba...@r-project.org wrote: On Sep 21, 2013, at 8:43 PM, Tobias Verbeke tobias.verb...@openanalytics.eu wrote: L.S. In this bug report https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14493#c1 it is mentioned that after moving an R installation one should regenerate the Rscript executable. Is there an easy way to do so (after an R installation has been moved)? You cannot move installed R. Once you run make install, there are several places in which paths get baked in - mainly Rscript and the R start script. What I typically do for deployment on the Labs machines is to use make install rhome=xxx where xxx is some path that I can always create a symlink in (I also use DESTDIR so that path doesn't actually need to exist on the build machine and it avoid polluting --prefix which is not needed). That way you can move R wherever you want as long so you keep that one symlink up to date. Cheers, Simon I have not found any information in the R installation and administration manual. Many thanks in advance for any pointer. Best wishes, Tobias P.S. The background to this question is the usage of Rscript calls in the Makevars files of some R packages on CRAN, so the 'broken' Rscript prevents installation of certain R packages. -- Tobias Verbeke Manager OpenAnalytics BVBA Jupiterstraat 20 2600 Antwerp Belgium E tobias.verb...@openanalytics.eu M +32 499 36 33 15 http://www.openanalytics.eu __ 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
[Rd] regenerate Rscript after moving R installation
L.S. In this bug report https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14493#c1 it is mentioned that after moving an R installation one should regenerate the Rscript executable. Is there an easy way to do so (after an R installation has been moved)? I have not found any information in the R installation and administration manual. Many thanks in advance for any pointer. Best wishes, Tobias P.S. The background to this question is the usage of Rscript calls in the Makevars files of some R packages on CRAN, so the 'broken' Rscript prevents installation of certain R packages. -- Tobias Verbeke Manager OpenAnalytics BVBA Jupiterstraat 20 2600 Antwerp Belgium E tobias.verb...@openanalytics.eu M +32 499 36 33 15 http://www.openanalytics.eu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] regenerate Rscript after moving R installation
Hi Dirk,
Many thanks for your reaction.
- Original Message -
From: Dirk Eddelbuettel e...@debian.org
To: Tobias Verbeke tobias.verb...@openanalytics.eu
Cc: r-devel@r-project.org
Sent: Saturday, September 21, 2013 9:00:12 PM
Subject: Re: [Rd] regenerate Rscript after moving R installation
On 21 September 2013 at 20:43, Tobias Verbeke wrote:
| P.S. The background to this question is the usage of Rscript
| calls in the Makevars files of some R packages on CRAN, so
| the 'broken' Rscript prevents installation of certain R packages.
More details, please.
AFAICT there is no 'broken' Rscript per se. Eg for Rcpp, and per hints from
Kurt el al over the years, we have been doing this for a few years
PKG_CXXFLAGS=-I../inst/include
PKG_LIBS=`$(R_HOME)/bin/Rscript -e Rcpp:::LdFlags()` $(LAPACK_LIBS)
$(BLAS_LIBS) $(FLIBS)
The package that made me discover this was RcppEigen which has indeed
PKG_LIBS=`$(R_HOME)/bin/Rscript -e Rcpp:::LdFlags()` $(LAPACK_LIBS)
$(BLAS_LIBS) $(FLIBS)
where a key part is the `$(R_HOME)/bin` which permits you to transparently
switch between R-release, R-devel, R-beforeMove, R-afterMove, R-whatevr, ...
simply by adjusting your shell's $PATH variable, or the R wrapper you for R
CMD, or ...
It. Just. Works.
It is neat and certainly works, unless R is built on another location (on a
build machine)
prior to being put on its final location.
If I read the strace output below correctly, the origin of the problem is the
hardcoded
location of the R binary.
tobias@oa-laptop:/opt/architect/architect-stable/plugins/eu.openanalytics.architect.r.server.gtk.linux_stable/R/bin$
strace ./Rscript -e '2+2'
execve(./Rscript, [./Rscript, -e, 2+2], [/* 51 vars */]) = 0
brk(0) = 0x1eb6000
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fc7563e1000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=161604, ...}) = 0
mmap(NULL, 161604, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fc7563b9000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/x86_64-linux-gnu/libc.so.6, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\200\30\2\0\0\0\0\0...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1811128, ...}) = 0
mmap(NULL, 3925208, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7fc755e02000
mprotect(0x7fc755fb7000, 2093056, PROT_NONE) = 0
mmap(0x7fc7561b6000, 24576, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b4000) = 0x7fc7561b6000
mmap(0x7fc7561bc000, 17624, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fc7561bc000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fc7563b8000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fc7563b7000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fc7563b6000
arch_prctl(ARCH_SET_FS, 0x7fc7563b7700) = 0
mprotect(0x7fc7561b6000, 16384, PROT_READ) = 0
mprotect(0x601000, 4096, PROT_READ) = 0
mprotect(0x7fc7563e3000, 4096, PROT_READ) = 0
munmap(0x7fc7563b9000, 161604) = 0
brk(0) = 0x1eb6000
brk(0x1ed7000) = 0x1ed7000
execve(/home/builduser/architect/stable/R-build/sources/R-3.0.1/bin/R,
[/home/builduser/architect/stable/..., --slave, --no-restore, -e,
2+2, --args], [/* 52 vars */]) = -1 ENOENT (No such file or directory)
dup(2) = 3
fcntl(3, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE)
fstat(3, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 3), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fc7563e
lseek(3, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
write(3, Rscript execution error: No such..., 51Rscript execution error: No
such file or directory
) = 51
close(3)= 0
munmap(0x7fc7563e, 4096)= 0
exit_group(-1) = ?
So if you borked your Rscript somewhere, just use another and quickly rebuild
R for the new location. It is after all a cheap build (and cheaper still if
you use tricks like ccache which I am a huge fan of, or 'make -j8', or ...)
There is no way to build again since R itself is shipped (in a Debian/Ubuntu
package
and as part of Architect) prior to being installed and used on another computer.
The buildstamp that is part of the final installation path of the application
is
generated after the R build (since R is only one component), so changing the
--prefix
on the build machine would not work (currently).
I hope
Re: [Rd] regenerate Rscript after moving R installation
Hi Dirk, - Original Message - From: Dirk Eddelbuettel e...@debian.org To: Tobias Verbeke tobias.verb...@openanalytics.eu Cc: Dirk Eddelbuettel e...@debian.org, r-devel@r-project.org Sent: Saturday, September 21, 2013 11:03:37 PM Subject: Re: [Rd] regenerate Rscript after moving R installation Tobias, On 21 September 2013 at 21:39, Tobias Verbeke wrote: | The package that made me discover this was RcppEigen which has indeed Never heard of it :) | PKG_LIBS=`$(R_HOME)/bin/Rscript -e Rcpp:::LdFlags()` $(LAPACK_LIBS) | $(BLAS_LIBS) $(FLIBS) | | where a key part is the `$(R_HOME)/bin` which permits you to | transparently | switch between R-release, R-devel, R-beforeMove, R-afterMove, R-whatevr, | ... | simply by adjusting your shell's $PATH variable, or the R wrapper you for | R | CMD, or ... | | It. Just. Works. | | It is neat and certainly works, unless R is built on another location (on a | build machine) | prior to being put on its final location. | | If I read the strace output below correctly, the origin of the problem is | the hardcoded | location of the R binary. [...] | There is no way to build again since R itself is shipped (in a | Debian/Ubuntu package | and as part of Architect) prior to being installed and used on another | computer. ^^ I do not know what 'Architekt' is -- but maybe you just mistakenly assume Architect is a cross-platform Eclipse based R IDE with a.o. out-of-the-box Rcpp support ;-) that you can mv(1) installations at will? And maybe you can't? Consider the configure --prefix=/some/location/ ... make make install where /some/location gets set at compile-time. You seem to wish it didn't. But wishing alone may not make it so. In all seriousness, these binaries may not be relocatable at will. That is fair enough. I do not expect R-devel to be populated with Djinns, but was puzzled (and probably lead down the wrong path) by the fact that Rscript was the only stubborn piece in our build procedures. | The buildstamp that is part of the final installation path of the | application is | generated after the R build (since R is only one component), so changing | the --prefix | on the build machine would not work (currently). | | I hope this gives more background to the question and would be curious if | there are alternatives | to rapidly regenerate the Rscript executable only. | | (My other alternative of messing with the path in a hex editor has not been | successful :-) I'd go back to rebuilding for the target location. Thank you! I will report back if I find out more. Best, Tobias Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] scientific notation and comparison with character variable
L.S. Is the following expected and/or documented? 1e-2 0.05 [1] TRUE 1e-4 0.05 [1] FALSE Many thanks in advance for any pointer. Best, Tobias sessionInfo() R Under development (unstable) (2013-01-01 r61512) Platform: i386-w64-mingw32/i386 (32-bit) locale: [1] LC_COLLATE=English_United States.1252 [2] LC_CTYPE=English_United States.1252 [3] LC_MONETARY=English_United States.1252 [4] LC_NUMERIC=C [5] LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] scientific notation and comparison with character variable
Thanks and apologies for the noise. Best wishes, Tobias On 01/02/2013 07:43 PM, Joshua Ulrich wrote: It's expected. From ?: If the two arguments are atomic vectors of different types, one is coerced to the type of the other, the (decreasing) order of precedence being character, complex, numeric, integer, logical and raw. as.character(1e-2) 0.05 [1] TRUE as.character(1e-4) 0.05 [1] FALSE Best, -- Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com On Wed, Jan 2, 2013 at 12:38 PM, Tobias Verbeke tobias.verb...@openanalytics.eu wrote: L.S. Is the following expected and/or documented? 1e-2 0.05 [1] TRUE 1e-4 0.05 [1] FALSE Many thanks in advance for any pointer. Best, Tobias sessionInfo() R Under development (unstable) (2013-01-01 r61512) Platform: i386-w64-mingw32/i386 (32-bit) locale: [1] LC_COLLATE=English_United States.1252 [2] LC_CTYPE=English_United States.1252 [3] LC_MONETARY=English_United States.1252 [4] LC_NUMERIC=C [5] LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base __ 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] installing spam package is failing (spam_0.29-1)
Hi Chuckles, On 07/16/2012 09:05 PM, chuckles the clone wrote: No, it is R version 2.13.1 This is the latest version apt-get is getting. Is there some advanced technique for obtaining version 2.15.1 ? Have a look here: http://cran.r-project.org/bin/linux/ubuntu/ HTH, Tobias root:~# cat /etc/motd Welcome to Ubuntu 11.10 (GNU/Linux 3.0.0-16-virtual x86_64) root:~# apt-get upgrade R Reading package lists... Done Building dependency tree Reading state information... Done The following packages have been kept back: landscape-client libgeos-c1 linux-image-virtual linux-virtual 0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded. root:~# R --version R version 2.13.1 (2011-07-08) Copyright (C) 2011 The R Foundation for Statistical Computing ISBN 3-900051-07-0 Platform: x86_64-pc-linux-gnu (64-bit) R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under the terms of the GNU General Public License version 2. For more information about these matters see http://www.gnu.org/licenses/. -- View this message in context: http://r.789695.n4.nabble.com/installing-spam-package-is-failing-spam-0-29-1-tp4636628p4636676.html Sent from the R devel mailing list archive at Nabble.com. __ 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] Tesla GPUs
On 08/05/2011 08:36 PM, Simon Urbanek wrote: On Jul 19, 2011, at 12:56 PM, Simon Urbanek wrote: On Jul 19, 2011, at 2:26 AM, Prof Brian Ripley wrote: On Mon, 18 Jul 2011, Alireza Mahani wrote: Simon, Thank you for elaborating on the limitations of R in handling float types. I think I'm pretty much there with you. As for the insufficiency of single-precision math (and hence limitations of GPU), my personal take so far has been that double-precision becomes crucial when some sort of error accumulation occurs. For example, in differential equations where boundary values are integrated to arrive at interior values, etc. On the other hand, in my personal line of work (Hierarchical Bayesian models for quantitative marketing), we have so much inherent uncertainty and noise at so many levels in the problem (and no significant error accumulation sources) that single vs double precision issue is often inconsequential for us. So I think it really depends on the field as well as the nature of the problem. The main reason to use only double precision in R was that on modern CPUs double precision calculations are as fast as single-precision ones, and with 64-bit CPUs they are a single access. So the extra precision comes more-or-less for free. You also under-estimate the extent to which stability of commonly used algorithms relies on double precision. (There are stable single-precision versions, but they are no longer commonly used. And as Simon said, in some cases stability is ensured by using extra precision where available.) I disagree slightly with Simon on GPUs: I am told by local experts that the double-precision on the latest GPUs (those from the last year or so) is perfectly usable. See the performance claims on http://en.wikipedia.org/wiki/Nvidia_Tesla of about 50% of the SP performance in DP. That would be good news. Unfortunately those seem to be still targeted at a specialized market and are not really graphics cards in traditional sense. Although this is sort of required for the purpose it removes the benefit of ubiquity. So, yes, I agree with you that it may be an interesting way forward, but I fear it's too much of a niche to be widely supported. I may want to ask our GPU specialists here to see if they have any around so I could re-visit our OpenCL R benchmarks. Last time we abandoned our OpenCL R plans exactly due to the lack of speed in double precision. A quick update - it turns out we have a few Tesla/Fermi machines here, so I ran some very quick benchmarks on them. The test case was the same as for the original OpenCL comparisons posted here a while ago when Apple introduced it: dnorm on long vectors: 64M, single: -- GPU -- total: 4894.1 ms, compute: 234.5 ms, compile: 4565.7 ms, real: 328.3 ms -- CPU -- total: 2290.8 ms 64M, double: -- GPU -- total: 5448.4 ms, compute: 634.1 ms, compile: 4636.4 ms, real: 812.0 ms -- CPU -- total: 2415.8 ms 128M, single: -- GPU -- total: 5843.7 ms, compute: 469.2 ms, compile: 5040.5 ms, real: 803.1 ms -- CPU -- total: 4568.9 ms 128M, double: -- GPU -- total: 6042.8 ms, compute: 1093.9 ms, compile: 4583.3 ms, real: 1459.5 ms -- CPU -- total: 4946.8 ms The CPU times are based on a dual Xeon X5690 machine (12 cores @ 3.47GHz) using OpenMP, but are very approximate, because there were two other jobs running on machine -- still, it should be a good ballpark figure. The GPU times are run on Tesla S2050 using OpenCL, addressed as one device so presumably comparable to the performance of one Tesla M2050. The figures to compare are GPU.real (which is computation + host memory I/O) and CPU.total, because we can assume that we can compile the kernel in advance, but you can't save on the memory transfer (unless you find a good way to chain calls which is not realistic in R). So the good news is that the new GPUs fulfill their promise : double precision is only twice as slow as single precision. Also they scale approximately linearly - see the real time of 64M double is almost the same as 128M single. They also outperform the CPUs as well, although not by an order of magnitude. The double precision support is very good news, and even though we are still using GPUs in a suboptimal manner, they are faster than the CPUs. The only practical drawback is that using OpenCL requires serious work, it's not as easy as slapping omp pragmas on existing code. Also the HPC Teslas are quite expensive so I don't expect to see them in desktops anytime soon. However, for people that are thinking about big computation, it may be an interesting way to go. Given that it's not mainstream I don't expect core R to have OCL support just yet, but it may be worth keeping in mind for the future as we are designing the parallelization framework in R. +1. Chip vendors nowadays also offer a CPU runtime for execution of OpenCL code on common x86 multi-core CPUs (e.g. of the Opteron series or Core i7 family) so it may be more
Re: [Rd] Recent and upcoming changes to R-devel
L.S. On 07/05/2011 02:16 AM, mark.braving...@csiro.au wrote: I may have misunderstood, but: Please could we have an optional installation that does not*not* byte-compile base and recommended? Reason: it's not possible to debug byte-compiled code-- at least not with the 'debug' package, which is quite widely used. I quite often end up using 'mtrace' on functions in base/recommended packages to figure out what they are doing. And sometimes I (and others) experiment with changing functions in base/recommended to improve functionality. That seems to be harder with BC versions, and might even be impossible, as best I can tell from hints in the documentation of 'compile'). Personally, if I had to choose only one, I'd rather live with the speed penalty from not byte-compiling. But of course, if both are available, I could install both. I completely second this request. All speed improvements and the byte compiler in particular are leaps forward and I am very grateful and admiring towards the people that make this happen. That being said, 'moving away' from the sources (with the lazy loading files and byte-compilation) may be a step back for R package developers that (during development and maybe on separate development installations [as opposed to production installations of R]) require the sources of all packages to be efficient in their work. As many of you know there is an open source Eclipse/StatET visual debugger ready and for that application as well (similar to Mark's request) presence of non-compiled code is highly desirable. For the particular purpose of debugging R packages, I would even plead to go beyond the current options and support the addition of an R package install option that allows to include the sources (e.g. in a standard folder Rsrc/) in installed packages. I am fully aware that one can always fetch the source tarballs from CRAN for that purpose, but it would be much more easy if a simple installation option could put the R sources of a package in a separate folder [or archive inside an existing folder] such that R development tools (such as the Eclipse/StatET IDE) can offer inspection of sources or display them (e.g. during debugging) out of the box. If one has the srcref, one can always load the absolutely correct source code this way, even if one doesn't know the parent function with the source attribute. Any comments? Best, Tobias P.S. One could even consider a post-install option e.g. to add 'real' R sources (and source references) to Windows packages (which are by definition already 'installed' and for which such information is not by default included in the CRAN binaries of these packages). Prof Brian Ripley wrote: There was an R-core meeting the week before last, and various planned changes will appear in R-devel over the next few weeks. These are changes planned for R 2.14.0 scheduled for Oct 31. As we are sick of people referring to R-devel as '2.14' or '2.14.0', that version number will not be used until we reach 2.14.0 alpha. You will be able to have a package depend on an svn version number when referring to R-devel rather than using R (= 2.14.0). All packages are installed with lazy-loading (there were 72 CRAN packages and 8 BioC packages which opted out). This means that the code is always parsed at install time which inter alia simplifies the descriptions. R 2.13.1 RC warns on installation about packages which ask not to be lazy-loaded, and R-devel ignores such requests (with a warning). In the near future all packages will have a name space. If the sources do not contain one, a default NAMESPACE file will be added. This again will simplify the descriptions and also a lot of internal code. Maintainers of packages without name spaces (currently 42% of CRAN) are encouraged to add one themselves. R-devel is installed with the base and recommended packages byte-compiled (the equivalent of 'make bytecode' in R 2.13.x, but done less inefficiently). There is a new option R CMD INSTALL --byte-compile to byte-compile contributed packages, but that remains optional. Byte-compilation is quite expensive (so you definitely want to do it at install time, which requires lazy-loading), and relatively few packages benefit appreciably from byte-compilation. A larger number of packages benefit from byte-compilation of R itself: for example AER runs its checks 10% faster. The byte-compiler technology is thanks to Luke Tierney. There is support for figures in Rd files: currently with a first-pass implementation (thanks to Duncan Murdoch). __ 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] Recent and upcoming changes to R-devel
Dear Duncan, On 07/05/2011 03:25 PM, Duncan Murdoch wrote: On 05/07/2011 6:52 AM, Tobias Verbeke wrote: L.S. On 07/05/2011 02:16 AM, mark.braving...@csiro.au wrote: I may have misunderstood, but: Please could we have an optional installation that does not*not* byte-compile base and recommended? Reason: it's not possible to debug byte-compiled code-- at least not with the 'debug' package, which is quite widely used. I quite often end up using 'mtrace' on functions in base/recommended packages to figure out what they are doing. And sometimes I (and others) experiment with changing functions in base/recommended to improve functionality. That seems to be harder with BC versions, and might even be impossible, as best I can tell from hints in the documentation of 'compile'). Personally, if I had to choose only one, I'd rather live with the speed penalty from not byte-compiling. But of course, if both are available, I could install both. I completely second this request. All speed improvements and the byte compiler in particular are leaps forward and I am very grateful and admiring towards the people that make this happen. That being said, 'moving away' from the sources (with the lazy loading files and byte-compilation) may be a step back for R package developers that (during development and maybe on separate development installations [as opposed to production installations of R]) require the sources of all packages to be efficient in their work. As many of you know there is an open source Eclipse/StatET visual debugger ready and for that application as well (similar to Mark's request) presence of non-compiled code is highly desirable. For the particular purpose of debugging R packages, I would even plead to go beyond the current options and support the addition of an R package install option that allows to include the sources (e.g. in a standard folder Rsrc/) in installed packages. I am fully aware that one can always fetch the source tarballs from CRAN for that purpose, but it would be much more easy if a simple installation option could put the R sources of a package in a separate folder [or archive inside an existing folder] such that R development tools (such as the Eclipse/StatET IDE) can offer inspection of sources or display them (e.g. during debugging) out of the box. If one has the srcref, one can always load the absolutely correct source code this way, even if one doesn't know the parent function with the source attribute. Any comments? I think these requests have already been met. If you modify the body of a closure (as trace() does), then the byte compiled version is discarded, and you go back to the regular interpreted code. If you install packages with the R_KEEP_PKG_SOURCE=yes environment variable set, the you keep all source for all functions. (It's attached to the function itself, not as a file that may be out of date.) It's possible that byte compiling turns off R_KEEP_PKG_SOURCE, but that is something that is either easily fixed, or avoided by re-installing without byte compiling. Many thanks for your reaction. Is the R_KEEP_PKG_SOURCE=yes environment variable also supported during R installation ? I hope I'm not overlooking anything, but when compiling ftp://ftp.stat.math.ethz.ch/Software/R/R-devel.tar.gz a few minutes ago I encountered the following issue: [...] building package 'tools' mkdir -p -- ../../../library/tools make[4]: Entering directory `/home/tobias/rAdmin/R-devel/src/library/tools' mkdir -p -- ../../../library/tools/R mkdir -p -- ../../../library/tools/po make[4]: Leaving directory `/home/tobias/rAdmin/R-devel/src/library/tools' make[4]: Entering directory `/home/tobias/rAdmin/R-devel/src/library/tools' make[5]: Entering directory `/home/tobias/rAdmin/R-devel/src/library/tools/src' making text.d from text.c making init.d from init.c making Rmd5.d from Rmd5.c making md5.d from md5.c gcc -std=gnu99 -I../../../../include -I/usr/local/include -fvisibility=hidden -fpic -g -O2 -c text.c -o text.o gcc -std=gnu99 -I../../../../include -I/usr/local/include -fvisibility=hidden -fpic -g -O2 -c init.c -o init.o gcc -std=gnu99 -I../../../../include -I/usr/local/include -fvisibility=hidden -fpic -g -O2 -c Rmd5.c -o Rmd5.o gcc -std=gnu99 -I../../../../include -I/usr/local/include -fvisibility=hidden -fpic -g -O2 -c md5.c -o md5.o gcc -std=gnu99 -shared -L/usr/local/lib64 -o tools.so text.o init.o Rmd5.o md5.o -L../../../../lib -lR make[6]: Entering directory `/home/tobias/rAdmin/R-devel/src/library/tools/src' make[6]: `Makedeps' is up to date. make[6]: Leaving directory `/home/tobias/rAdmin/R-devel/src/library/tools/src' make[6]: Entering directory `/home/tobias/rAdmin/R-devel/src/library/tools/src' mkdir -p -- ../../../../library/tools/libs make[6]: Leaving directory `/home/tobias/rAdmin/R-devel/src/library/tools/src' make[5]: Leaving directory `/home/tobias/rAdmin/R-devel/src/library/tools/src' make[4]: Leaving directory `/home/tobias
Re: [Rd] Recent and upcoming changes to R-devel
On 07/05/2011 04:21 PM, Duncan Murdoch wrote: On 05/07/2011 10:17 AM, Tobias Verbeke wrote: Dear Duncan, On 07/05/2011 03:25 PM, Duncan Murdoch wrote: On 05/07/2011 6:52 AM, Tobias Verbeke wrote: L.S. On 07/05/2011 02:16 AM, mark.braving...@csiro.au wrote: I may have misunderstood, but: Please could we have an optional installation that does not*not* byte-compile base and recommended? Reason: it's not possible to debug byte-compiled code-- at least not with the 'debug' package, which is quite widely used. I quite often end up using 'mtrace' on functions in base/recommended packages to figure out what they are doing. And sometimes I (and others) experiment with changing functions in base/recommended to improve functionality. That seems to be harder with BC versions, and might even be impossible, as best I can tell from hints in the documentation of 'compile'). Personally, if I had to choose only one, I'd rather live with the speed penalty from not byte-compiling. But of course, if both are available, I could install both. I completely second this request. All speed improvements and the byte compiler in particular are leaps forward and I am very grateful and admiring towards the people that make this happen. That being said, 'moving away' from the sources (with the lazy loading files and byte-compilation) may be a step back for R package developers that (during development and maybe on separate development installations [as opposed to production installations of R]) require the sources of all packages to be efficient in their work. As many of you know there is an open source Eclipse/StatET visual debugger ready and for that application as well (similar to Mark's request) presence of non-compiled code is highly desirable. For the particular purpose of debugging R packages, I would even plead to go beyond the current options and support the addition of an R package install option that allows to include the sources (e.g. in a standard folder Rsrc/) in installed packages. I am fully aware that one can always fetch the source tarballs from CRAN for that purpose, but it would be much more easy if a simple installation option could put the R sources of a package in a separate folder [or archive inside an existing folder] such that R development tools (such as the Eclipse/StatET IDE) can offer inspection of sources or display them (e.g. during debugging) out of the box. If one has the srcref, one can always load the absolutely correct source code this way, even if one doesn't know the parent function with the source attribute. Any comments? I think these requests have already been met. If you modify the body of a closure (as trace() does), then the byte compiled version is discarded, and you go back to the regular interpreted code. If you install packages with the R_KEEP_PKG_SOURCE=yes environment variable set, the you keep all source for all functions. (It's attached to the function itself, not as a file that may be out of date.) It's possible Can you expand on when files put inside a package at install time will be out of date compared to the source information attached to a function ? I (naively) thought the source information was created and attached at install time as well and that it did not change afterwards either. I guess the arguments for files is that they have precise locations and allow for easy indexing by development tools external to R (but may be corrected here as well). that byte compiling turns off R_KEEP_PKG_SOURCE, but that is something that is either easily fixed, or avoided by re-installing without byte compiling. Many thanks for your reaction. Is the R_KEEP_PKG_SOURCE=yes environment variable also supported during R installation ? Yes, other than the error you saw below, which is a temporary problem. Not sure which function exceeded the length limit, but the length limit is going away before 2.14.0 is released. Thanks again, Duncan, for the clarification. Is it useful (or just whimsical) to have an R function that would allow for a given stock CRAN Windows R installation with stock Windows CRAN binary add-on packages to add the source information that would be useful e.g. for a debugger post factum? I can imagine something like update.packages(., checkSourcesKept = TRUE) as I don't think this can currently be solved with a combination of INSTALL_opts=--with-keep.source and type=source given that there will not be a check for the presence of source information to determine which packages require being updated (or in this case 'completed' with source information). The alternative scenario would be to expect users that want this functionality to compile R and all add-on packages from source (also on Windows or Mac). Best, Tobias I hope I'm not overlooking anything, but when compiling ftp://ftp.stat.math.ethz.ch/Software/R/R-devel.tar.gz a few minutes ago I encountered the following issue
Re: [Rd] R-devel Digest, Vol 100, Issue 28
On 06/29/2011 08:08 PM, Duncan Murdoch wrote: On 29/06/2011 1:44 PM, Duncan Murdoch wrote: On 29/06/2011 1:09 PM, Uwe Ligges wrote: On 29.06.2011 13:41, John Maindonald wrote: I get the same style of path as Hadley. This is on Windows 7 Home Premium with SP1. I start R by clicking on the R-2.31.0 icon. I'd assumed that it was a change that came with R-2.13.0! (On 32-bit Windows XP, which I have just checked, I do indeed get the 8.3 paths.) R.home() [1] C:/Programs/R/R-2.13.0 No, you got the same as Duncan: This is 8.3 compatible. Yes, that's right. The documentation is pretty inaccurate. What actually is supposed to happen is that you get the actual path, with forward slashes in it, unless it contains spaces: then you get the 8.3 version. So John's path has no spaces, and doesn't get converted to 8.3. True 8.3 would also have uppercase PROGRAMS, and only one dot in R-2.13.0 (I forget how that is converted). I've now clarified the help page. R.home() just looks up the environment variable R_HOME, and then possibly adds some subdir to it. If your front end (e.g. Hadley's rj/Eclipse setup) doesn't initialize R_HOME properly, then you'll get whatever it put there. You can also For the record, Eclipse/StatET makes use of an R_HOME variable as set by the user (not as initialized by the front-end) in a so called 'R Environment' under Window Preferences StatET Run/Debug R Environments Best, Tobias mess with it using Sys.setenv(R_HOME=junk). Duncan Murdoch __ 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] system.file() to read a text file from a vignette
Hi Michael, On 03/23/2011 03:03 PM, Michael Friendly wrote: [Env: R 2.12.2, WinXp] In a vignette for the vcdExtra package, I had a text file, tv.dat under data/, that I used in the vignette as tv1,results=verbatim= tv.data-read.table(system.file(data,tv.dat,package=vcdExtra)) head(tv.data,5) @ I was told that this now generates a warning for non-Rdata files in R CMD check. But I'm now confused about where to put this and how to use system.file() in the vignette to read it. The R-exts.pdf says The R working directory for all vignette tests in R CMD check is the installed version of the ‘doc’ subdirectory. Make sure all files needed by the vignette (data sets, . . . ) are accessible by either placing them in the ‘inst/doc’ hierarchy of the source package, or using calls to system.file(). So, I moved this file to inst/doc/extdata/tv.dat, and changed the vignette to tv1,results=verbatim= tv.data-read.table(system.file(inst,doc,extdata,tv.dat,package=vcdExtra)) head(tv.data,5) @ But I get the error: Error: processing vignette 'vcd-tutorial.Rnw' failed with diagnostics: chunk 23 (label=tv1) Error in read.table(system.file(inst, doc, extdata, tv.dat, package = vcdExtra)) : no lines available in input How can I fix this? The inst/ will be removed once the package is installed, so you would need system.file(doc, extdata, tv.dat, package = vcdExtra) The warning on non Rdata files is probably due to the fact that .dat is not supported, see Section 1.1.5 of Writing R Extensions and ?data Best, Tobias __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] texi2dvi / egrep issue shows (a.o.) up in R-alpha
On 03/22/2011 08:41 AM, Martin Maechler wrote: Tobias Verbeketobias.verb...@openanalytics.eu on Mon, 21 Mar 2011 23:45:33 +0100 writes: L.S. I noticed weird tools::texi2dvi behaviour on R-alpha when specifying an absolute path to the .tex file. The same phenomenon also appears to occur on R-2.12.2, so maybe the issue is independent of R. Yes. I think it's independent of R. In any case, there's been a bug in the (Unix/Linux/teTeX/) texi2dvi sh script, a bug which I think typically only bites if you work in non-ASCII locales -- as you and I, eg. Here's the patch that I have had in place for quite a while : MM@lynne$ diff -ubBw /usr/bin/texi2dvi /usr/local/bin/scripts/texi2dvi --- /usr/bin/texi2dvi 2011-01-11 15:33:52.0 +0100 +++ /usr/local/bin/scripts/texi2dvi 2010-07-09 08:32:36.25000 +0200 @@ -33,7 +33,7 @@ set -e # This string is expanded by rcs automatically when this file is checked out. -rcs_revision='$Revision: 1.135 $' +rcs_revision='$Revision: 1.135__mod.SfS_ETHZ $' rcs_version=`set - $rcs_revision; echo $2` program=`echo $0 | sed -e 's!.*/!!'` @@ -1683,7 +1683,7 @@ # If the COMMAND_LINE_FILENAME is not absolute (e.g., --debug.tex), # prepend `./' in order to avoid that the tools take it as an option. - echo $command_line_filename | $EGREP '^(/|[A-Za-z]:/)'6 \ + echo $command_line_filename | $EGREP '^(/|[[:alpha:]]:/)'6 \ || command_line_filename=./$command_line_filename # See if the file exists. If it doesn't we're in trouble since, even MM@lynne$ Many thanks, Martin. That was indeed the issue and the patch works perfectly fine. Kind regards, Tobias __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] texi2dvi / egrep issue shows (a.o.) up in R-alpha
L.S.
I noticed weird tools::texi2dvi behaviour on R-alpha
when specifying an absolute path to the .tex
file.
The same phenomenon also appears to occur on
R-2.12.2, so maybe the issue is independent
of R.
I hope I did not overlook any important information.
Best,
Tobias
require(tools)
Loading required package: tools
getwd()
[1] /home/tobias
texi2dvi(test.tex) # works OK
texi2dvi(/home/tobias/test.tex)
Error in texi2dvi(/home/tobias/test.tex) :
Running 'texi2dvi' on '/home/tobias/test.tex' failed.
Messages:
egrep: Invalid range end
/usr/bin/texi2dvi: cannot read .//home/tobias/test.tex, skipping.
sessionInfo()
R version 2.13.0 alpha (2011-03-19 r54880)
Platform: x86_64-unknown-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=en_US.utf8 LC_NUMERIC=C
[3] LC_TIME=en_US.utf8LC_COLLATE=en_US.utf8
[5] LC_MONETARY=C LC_MESSAGES=en_US.utf8
[7] LC_PAPER=en_US.utf8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.utf8 LC_IDENTIFICATION=C
attached base packages:
[1] tools stats graphics grDevices utils datasets methods
[8] base
This is Ubuntu 10.10 with GNU grep 2.6.3 and
texi2dvi (GNU Texinfo 4.13) 1.135.
The test file is most simple:
\documentclass{article}
\begin{document}
Test document.
\end{document}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Clipping (was Re: patch dendrogram.R from stats [was: Re: dendrogram plot does not draw long labels ?])
On 01/29/2011 11:59 PM, Prof Brian Ripley wrote: On Sat, 29 Jan 2011, Martin Maechler wrote: Tobias Verbeke tobias.verb...@openanalytics.eu on Tue, 25 Jan 2011 21:27:41 +0100 writes: L.S. Please find below a patch for dendrogram.R (stats package) against revision r54107 which allows one to pass the xpd parameter as a component of the nodePar list (to be passed to plot.dendrogram). I hope I did not overlook anything. Thank you, Tobias. Note BTW, that on Linux I don't have your problems that the label is not drawn when it does not fit. For me, it just is clipped (to the figure region as you note), so chopped off but the part inside the figure box is well visible. I was searching a bit and did not find mentioned on ?par or ?clip that clipping happens device dependently, but I vaguely recall to have seen it stated.. Yes, it is device-dependent (but then most low-level things about graphics are, in particular everything about fonts). The designers of the graphics internals never documented their principles, but I retrospectively tried to do so in the R-ints manual. So whereas clipping of lines is done in the graphics engine, for text the manual says: If possible, the graphics device should handle clipping of text. It indicates this by the structure element 'canClip' which if true will result in calls to the callback 'clip' to set the clipping region. If this is not done, the engine will clip very crudely (by omitting any text that does not appear to be wholly inside the clipping region). I'll add a note to ?clip, but perhaps this can serve as a reminder that the R-ints manual is the place to look for low-level graphics details. Many thanks, Prof Ripley and Martin, for your work integrating the patch, documentation updates as well as for the additional explanation putting the observed behaviour in perspective. Kind regards, Tobias Verbeke __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dendrogram plot does not draw long labels ?
Hi Karl, On 01/25/2011 11:27 AM, Karl Forner wrote: It seems that the plot function for dendrograms does not draw labels when they are too long. hc- hclust(dist(USArrests), ave) dend1- as.dendrogram(hc) dend2- cut(dend1, h=70) dd- dend2$lower[[1]] plot(dd) # first label is drawn attr(dd[[1]], label)- aa plot(dd) # first label is NOT drawn Is this expected ? Reading the code of stats:::plotNode, yes. Clipping to the figure region is hard-coded. You can see it is clipping to the figure region as follows: hc - hclust(dist(USArrests), ave) dend1 - as.dendrogram(hc) dend2 - cut(dend1, h=70) dd - dend2$lower[[1]] op - par(oma = c(8,4,4,2)+0.1, xpd = NA) plot(dd) # first label is drawn attr(dd[[1]], label) - abcdefghijklmnopqrstuvwxyz plot(dd) # first label is NOT drawn box(which = figure) par(op) Is it possible to force the drawing ? These are (from very quick reading -- not verified) the culprit lines in plotNode, I think: text(xBot, yBot + vln, nodeText, xpd = TRUE, # - clipping hard-coded cex = lab.cex, col = lab.col, font = lab.font) Best, Tobias __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] patch dendrogram.R from stats [was: Re: dendrogram plot does not draw long labels ?]
L.S. Please find below a patch for dendrogram.R (stats package) against revision r54107 which allows one to pass the xpd parameter as a component of the nodePar list (to be passed to plot.dendrogram). I hope I did not overlook anything. Best, Tobias 378a379 lab.xpd - Xtract(xpd, nPar, default = c(TRUE, TRUE), i) 391c392 text(X, Y, nodeText, xpd = TRUE, srt = srt, adj = adj, --- text(X, Y, nodeText, xpd = lab.xpd, srt = srt, adj = adj, 436c437 text(xBot, yBot + vln, nodeText, xpd = TRUE, --- text(xBot, yBot + vln, nodeText, xpd = lab.xpd, On 01/25/2011 04:34 PM, Karl Forner wrote: Hi Tobias and thank you for your reply, Using your insight I managed to work-around the issue (with some help) by increasing the mai option of par(). For example a mai with first coordinate (bottom) set to 5 allows to display ~ 42 letters. We tried to change the xpd value in the text() call that you mentioned, but it did not seem to fix the problem. But I think this is very annoying: the dendrogram plot is meant to be the common unique plotting for all clustering stuff and suddenly if your labels are just too long, nothing get displayed, without even a warning. I suppose that the margins should be dynamically set based on the max label text drawn length... The hclust plot seemed to handle very nicely these long labels, but I need to display colored labels and the only way I found is to use the plot.dendrogram for this. Best, Karl On Tue, Jan 25, 2011 at 12:17 PM, Tobias Verbeke tobias.verb...@openanalytics.eu mailto:tobias.verb...@openanalytics.eu wrote: Hi Karl, On 01/25/2011 11:27 AM, Karl Forner wrote: It seems that the plot function for dendrograms does not draw labels when they are too long. hc- hclust(dist(USArrests), ave) dend1- as.dendrogram(hc) dend2- cut(dend1, h=70) dd- dend2$lower[[1]] plot(dd) # first label is drawn attr(dd[[1]], label)- aa plot(dd) # first label is NOT drawn Is this expected ? Reading the code of stats:::plotNode, yes. Clipping to the figure region is hard-coded. You can see it is clipping to the figure region as follows: hc - hclust(dist(USArrests), ave) dend1 - as.dendrogram(hc) dend2 - cut(dend1, h=70) dd - dend2$lower[[1]] op - par(oma = c(8,4,4,2)+0.1, xpd = NA) plot(dd) # first label is drawn attr(dd[[1]], label) - abcdefghijklmnopqrstuvwxyz plot(dd) # first label is NOT drawn box(which = figure) par(op) Is it possible to force the drawing ? These are (from very quick reading -- not verified) the culprit lines in plotNode, I think: text(xBot, yBot + vln, nodeText, xpd = TRUE, # - clipping hard-coded cex = lab.cex, col = lab.col, font = lab.font) Best, Tobias __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Tips for debugging: R CMD check examples
On 06/29/2010 11:56 PM, Hadley Wickham wrote: Does anyone have any suggestions for debugging the execution of examples by R CMD check? The examples work fine when I run them from a live R prompt, but I get errors when they are run by R CMD check. Not a real tip, but when it occurs I immediately check for namespace issues (which often turn out to be the origin). Things I do are - verify all packages involved have namespaces; - load all packages (i.e. put explicitly on the search path) to detect masking issues; - check all imports and exports and if relevant turn package imports into individual function imports to have a more fine-grained view. Agreed this is a very indirect way, but at times faster than trying to interpret the error message. Best, Tobias __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Using SVN + SSH on windows
Paul Gilbert wrote: ... I try several things: if I do 'svn://christo...@svn.r-forge.r-project.org/svnroot/kml3d', I do manage to download the project. But then, I do not manage to upload some modification. All looks ok, but I think you are using the wrong protocol. It should be 'svn+ssh' for *commits*, i.e. svn+ssh://christo...@svn.r-forge.r-project.org/svnroot/kml3d ... (If this was already mentioned I missed it.) If you first check out with svn:// I find it relatively difficult to commit using a different protocol. It may be possible, but, if you intend to commit, I think it is much easier if you check out using svn+ssh:// so you can then commit without specifying the protocol. As others mention, to simplify you can get the checkout and commit working without a key and pageant first. It is pretty solid once it is working. An alternative not yet mentioned in this thread would be to use an IDE which offers strong svn support (such as Eclipse + Subclipse). If one remembers to configure it to use the pure Java (SVNKit) interface, it works well with R-Forge on many platforms (including Windows). Best, Tobias __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] p.adjust.Rd sugggestion
L.S.
In the current version of ?p.adjust.Rd, one needs
to scroll down to the examples section to find
confirmation of one's guess that fdr is an
alias of BH.
Please find a patch in attachment which mentions
this explicitly.
Best,
Tobias
32c32
Hochberg (1995) (\code{BH}), and Benjamini Yekutieli (2001)
---
Hochberg (1995) (\code{BH} or its alias \code{fdr}), and Benjamini Yekutieli (2001)
50,52c50,52
The \code{BH} and \code{BY} method of Benjamini, Hochberg, and
Yekutieli control the false discovery rate, the expected proportion of
false discoveries amongst the rejected hypotheses. The false
---
The \code{BH} (aka \code{fdr}) and \code{BY} method of Benjamini,
Hochberg, and Yekutieli control the false discovery rate, the expected
proportion of false discoveries amongst the rejected hypotheses. The false
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to organized code in the R/ directory of a package?
Peng Yu wrote: I'm making a package, Current, I put all R files in the R/ directory in the package (without using subdirectory). This will become a problem when there are many files in the directory. I'm wondering how to use subdirectories in R/? The standard solution is (I would think) to organize the code such that functions belonging together are grouped in one file. Best, Tobias Does 'R CMD INSTALL' install the files in the subdirectories automatically? __ 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 Updates or Changes in corporate version of R
Hi, What is the place to search for *corporate version of R *including 1) GUI 2) Documentation 3) Cloud Computing or HPC R is used *as such* in corporate environments all over the world and 1) it comes with a GUI (on Windows and Mac), 2) comes with extensive documentation and 3) has facilities for HPC using add-on packages most of which are listed here: http://cran.r-project.org/web/views/HighPerformanceComputing.html That being said there is a diversity of companies providing commercial services related to R and innumerous initiatives focusing on particular aspects which might be useful to corporate contexts as well. Best, Tobias P.S. This is IMO not a subject to be discussed on R-devel. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: Ability to suppress 'locale' from sessionInfo
Friedrich Leisch wrote: On Tue, 21 Apr 2009 21:16:59 -0500, Kevin W (KW) wrote: The printing of the locale information from sessionInfo is not very tidy. Using toLatex(sessionInfo) pretty much guarantees badness from breaking the margin boundary (though my version of TeX no longer reports such errors). A random example is here: http://cran.r-project.org/web/packages/Matrix/vignettes/Design-issues.pdf I find the locale information unnecessary and right now I hack this with si = sessionInfo() si$locale = US toLatex(si) I would like to be able to do something a bit cleaner, for example sessionInfo(locale=FALSE) For what it's worth, I don't think that early versions of sessionInfo printed information about the locale. It went in on 2006-05-26, so it's bben there for some time now. Discussion welcome. I agree that it doesn't look nice in latex documents, but it is very handy in bug reports. Are there any objections if we add a locale argument to the toLatex() method and let that default to FALSE? No objection although I would not be against letting it default to TRUE to preserve current behaviour. One improvement in the locale information that would make the LaTeX look much nicer would be to add a space after the separator, i.e. item1; item2; item3 instead of item1;item2;item3 That is for me more important than having the option to include locale info or not as without such a change I found no way to prevent the locale information to run into the margin (and off the page) of the resulting LaTeX document and that is esthetically much more displeasing than the mere presence of the locale information. Best, Tobias __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] suggestion for R = 3.0: computer-readable CHANGELOG
Dirk Eddelbuettel wrote: On 17 April 2009 at 10:36, Duncan Murdoch wrote: | I think it would have to do more than that to be useful. It would need | to warn about a lack of an entry for the current version. Otherwise | package.skeleton would create a blank one, and that would satisfy the | check from then on. | | To recognize an entry for the current version, it would need a standard | format. But then, unless whoever put together the format was willing to | do updates to the hundreds of existing files out there, there would be a I'd say use it on a go-forward basis. I agree. For the ChangeLog, the GNU ChangeLog format could be used. The advantage is that there are already converters available for some commonly used source control management systems, such that users can stick with their favorite systems and comply: For git: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=build-aux/gitlog-to-changelog;hb=HEAD For Subversion: http://ch.tudelft.nl/~arthur/svn2cl/ For CVS: http://www.red-bean.com/cvs2cl/ Always willing to participate (also in converting existing files). Best, Tobias | Could you take a look at CRAN and Bioconductor, and count how many | packages already have a news/changelog file, and how hard it would be to | convert them to a standard format? I can do the count for CRAN using the account we use for cran2deb work. I'll be travelling this weekend (yay, Boston Marathon!) so please ping me next week if I forget to aggregate this. Dirk __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] suggestion for R = 3.0: computer-readable CHANGELOG
Philippe Grosjean wrote: Tobias Verbeke wrote: Dirk Eddelbuettel wrote: On 17 April 2009 at 10:36, Duncan Murdoch wrote: | I think it would have to do more than that to be useful. It would need | to warn about a lack of an entry for the current version. Otherwise | package.skeleton would create a blank one, and that would satisfy the | check from then on. | | To recognize an entry for the current version, it would need a standard | format. But then, unless whoever put together the format was willing to | do updates to the hundreds of existing files out there, there would be a I'd say use it on a go-forward basis. I agree. For the ChangeLog, the GNU ChangeLog format could be used. The advantage is that there are already converters available for some commonly used source control management systems, such that users can stick with their favorite systems and comply: For git: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=build-aux/gitlog-to-changelog;hb=HEAD For Subversion: http://ch.tudelft.nl/~arthur/svn2cl/ For CVS: http://www.red-bean.com/cvs2cl/ Always willing to participate (also in converting existing files). Best, Tobias But that gives the information at the file level. Since there is no constraint in R package to place the function in a given file (even several R functions or objects can be defined in the same file), it gives no useful information to track changes at the level of the functions! I understand your point, but either (1) you rely on the succinct descriptions of developers in commit messages (and derive code changes to look for) or (2) (as proposed in your original post) you generate an overview of changes in code and need to rely on your own interpretation of what these changes are about at a higher level. Having a structured, computer readable ChangeLog format (that might just come out of an SCM or not) is IMO as interesting an objective as (2). If an argument is added in a new version, (2) is great, but the mere detection of change in code will not tell you it is a bug fix, for example, whereas a commit message might do so. Just my 2 eurocents. Best, Tobias | Could you take a look at CRAN and Bioconductor, and count how many | packages already have a news/changelog file, and how hard it would be to | convert them to a standard format? I can do the count for CRAN using the account we use for cran2deb work. I'll be travelling this weekend (yay, Boston Marathon!) so please ping me next week if I forget to aggregate this. Dirk __ 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
[Rd] master vignette
Dear list,
Is there a recommended way of building a package
vignette that consists of one master file that
\SweaveInput{}'s several other files ?
Many thanks in advance for any pointer.
Best,
Tobias
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Using R from Java
Hi Marzio, I am interesting in using R from a web application, for basic statistics and plots. The server is Java-based (tomcat). The simplest solution is a system call that generates the text or the image, then the servlet forwards the output. This can be done from any language, but it is quite inelegant and slow for the initialization time. Is there any package or approach for accessing R from a Java servlet you can suggest? The biocep project might be a good match, see http://biocep-distrib.r-forge.r-project.org/doc.html HTH, Tobias __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Autoconf / Windows package building problem for device package
Dear list, Tadashi Kadowaki has developed a pdf device package that allows to add hyperlinks and popups to (currently) text, mtext and rect calls. The package passes R CMD check (minor warnings) and compiles on MacOS X and GNU/Linux, but we do not succeed in building the package for Windows. The current version of the package can be checked out as svn checkout svn://svn.r-forge.r-project.org/svnroot/pdf2/trunk Please find the 00install.out below. Could anyone tell why config.h is not found? My practical experience with the GNU build tools is very limited but I would have hoped config.h.in would be processed into config.h. Any pointer or hint will be appreciated. Many thanks in advance, Tobias P.S. 00install.out (using R 2.7.1 and a current Rtools28.exe): installing R.css in C:/DOCUME~1/tverbeke/WORKSP~2/pdf2/TRUNK~1.RCH -- Making package trunk ** WARNING: this package has a configure script It probably needs manual configuration ** adding build stamp to DESCRIPTION installing NAMESPACE file and metadata making DLL ... gcc -std=gnu99 -Ic:/R/R-2.7.0/include -Iinclude -DHAVE_CONFIG_H -O3 -Wall -c devPS.c -o devPS.o devPS.c:26:20: error: config.h: No such file or directory In file included from devPS.c:29: include/Defn.h:1022: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Rf_onsigusr1' include/Defn.h:1023: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Rf_onsigusr2' In file included from c:\rtools\mingw\bin\../lib/gcc/mingw32/4.2.1-sjlj/../../../../include/wchar.h:352, from include/Defn.h:1126, from devPS.c:29: c:\rtools\mingw\bin\../lib/gcc/mingw32/4.2.1-sjlj/../../../../include/stdint.h:66: error: conflicting types for 'intptr_t' include/Defn.h:204: error: previous declaration of 'intptr_t' was here c:\rtools\mingw\bin\../lib/gcc/mingw32/4.2.1-sjlj/../../../../include/stdint.h:75: error: conflicting types for 'uintptr_t' include/Defn.h:207: error: previous declaration of 'uintptr_t' was here devPS.c: In function 'pathcmp': devPS.c:449: error: 'FILESEP' undeclared (first use in this function) devPS.c:449: error: (Each undeclared identifier is reported only once devPS.c:449: error: for each function it appears in.) devPS.c: In function 'LoadEncoding': devPS.c:515: error: 'FILESEP' undeclared (first use in this function) devPS.c: In function 'PostScriptLoadFontMetrics': devPS.c:560: error: 'FILESEP' undeclared (first use in this function) devPS.c: In function 'PostScriptMetricInfo': devPS.c:862: warning: implicit declaration of function 'Riconv_open' devPS.c:862: warning: assignment makes pointer from integer without a cast devPS.c:872: warning: implicit declaration of function 'Riconv' devPS.c:874: warning: implicit declaration of function 'Riconv_close' devPS.c: In function 'mbcsToSbcs': devPS.c:4020: warning: assignment makes pointer from integer without a cast devPS.c:4029: error: 'EILSEQ' undeclared (first use in this function) devPS.c: In function 'PDF_NewPage': devPS.c:6406: warning: unused variable 'i' devPS.c: In function 'PDF_StrSize': devPS.c:7129: warning: unused variable 'face' devPS.c:7128: warning: unused variable 'pd' devPS.c: In function 'PDFAnnotBox': devPS.c:7469: warning: passing argument 5 of 'Rf_GConvert' from incompatible pointer type devPS.c:7470: warning: passing argument 5 of 'Rf_GConvert' from incompatible pointer type make[3]: *** [devPS.o] Error 1 make[2]: *** [srcDynlib] Error 2 make[1]: *** [all] Error 2 make: *** [pkg-trunk] Error 2 *** Installation of trunk failed *** Removing 'C:/DOCUME~1/tverbeke/WORKSP~2/pdf2/TRUNK~1.RCH/trunk' __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] trivial typo ?title
There is a trivial typo in ?title.
Please find a patch below.
Kind regards,
Tobias
Index:
/home/tobias/Documents/workspace/Rdevel_svn/src/library/graphics/man/title.Rd
===
---
/home/tobias/Documents/workspace/Rdevel_svn/src/library/graphics/man/title.Rd
(revision 45972)
+++
/home/tobias/Documents/workspace/Rdevel_svn/src/library/graphics/man/title.Rd
(working copy)
@@ -41,7 +41,7 @@
greek letters, fractions, etc: see \link{plotmath}
}
\details{
- The labels passed to \code{title} can be a character strings or
+ The labels passed to \code{title} can be character strings or
language objects (names, calls or expressions), or a list
containing the string to be plotted, and a selection of the optional
modifying graphical parameters \code{cex=}, \code{col=} and
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] ** operator
Dear list, I did not find any mentioning of the fact that the ** operator can be used as a synonym for the ^ operator. 5 ** 2 [1] 25 Searching of ** in the R Reference Index only leads to some examples in the mgcv documentation. Equally ?** does not open the arithmetic operators help page, but produces ?** No documentation for '**' in specified packages and libraries: you could try 'help.search(**)' Is there any reason to this or am I overlooking something ? Many thanks in advance, Tobias sessionInfo() R version 2.7.0 (2008-04-22) i486-pc-linux-gnu locale: LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] A patch for extending pdf device to embed popup text and web links
Dear Tadashi, Thank you very much for sharing your work. I am sending a patch for R-2.7.0 for extending pdf device to embed pop up text and web links. The patch is available at http://www.okada.jp.org/RWiki/?plugin=attachpcmd=openfile=R-2.7.0.patchrefer=pdf%20device%20patch You can see what the patch can do through a sample output, which is available at http://www.okada.jp.org/RWiki/?plugin=attachpcmd=openfile=sample2.pdfrefer=pdf%20device%20patch An script is at http://www.okada.jp.org/RWiki/?plugin=attachpcmd=openfile=sample2.rrefer=pdf%20device%20patch Ei-ji Nakama kindly build Windows binary, which can be obtained from http://prs.ism.ac.jp/~nakama/tadakadosan/cran/ An installer, R-2.7.0pat-win32.exe, will install programs in C:\Program Files\R\R-2.7.0pat so that you can use both of original and patched version simultaneously. I think it would be most useful if you could bundle your patched version of the pdf device in a separate device package, similar to the RSVGTipsDevice. What do you think ? Kind regards, Tobias __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] option(expressions) and --max-ppsize
Dear list, Is there an exact formula / safe rule of thumb that allows one to express the value of --max-ppsize as a function of the value of getOption(expressions) ? ?options tells If you increase it [the expressions option], you may also want to start R with a larger protection stack. Motivation is to determine stack size of a Java vm used to launch R with a given --max-ppsize option. Many thanks in advance, Tobias -- Tobias Verbeke - Consultant Business Decision Benelux Rue de la révolution 8 1000 Brussels - BELGIUM +32 499 36 33 15 [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] tests Rin and Rout
Peter Dalgaard wrote: Christophe Genolini wrote: hmm, I see 219 out 1378 CRAN packages having a 'tests' subdirectory, so it seems you have been a bit unlucky. ;-) Luck has probably nothing related with my failure. I just try to look in packages recommanded by Pr Brian Ripley (like codetools, foreign, lattice) and I did not find any tests directories. So either I am not looking in the right place, or tests are not including in the package for windows. Any idea? Aha... That would explain it, yes. It is only in the _source_ package and not installed. [EMAIL PROTECTED] ISWR]$ ls ISwR/ CVS data DESCRIPTION inst man R tests TITLE [EMAIL PROTECTED] ISWR]$ ls ~/Rlibrary/ISwR/ CONTENTS DESCRIPTION html latex Meta rawdata scripts data help INDEX manR R-ex [EMAIL PROTECTED] ISWR]$ grep -i version ISwR/DESCRIPTION Version: 2.0-0 [EMAIL PROTECTED] ISWR]$ grep -i version ~/Rlibrary/ISwR/DESCRIPTION Version: 2.0-0 For the record (and similarly to what Martin Maechler mentioned previously in this thread) it is perfectly possible to include a $R_PKG_ROOT/inst/unitTests directory (or similar) with tests. This will make sure the directory is included in binary (and installed) packages as well. Open the Windows binary package zip file for RSQLite, for example. Kind regards, Tobias __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] tests Rin and Rout
Christophe Genolini wrote: Prof Brian Ripley a écrit : Recommended packages cluster codetools foreign lattice nlme and rpart have tests, for example. (As do standard packages grDevices, grid and stats.) Thanks for your help. Concerning .Rin, I check all the package you point, but none of them use it. Does someone know a package using .Rin ? https://svn.r-project.org/R/trunk/tests/ has isas-tests.Rin and no-segfault.Rin HTH, Tobias __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] by infelicity
Dear list, Please find below an example of odd behaviour of the by function. It occurs both under GNU/Linux R 2.6.2 and Windows R 2.7.0alpha. Respective sessionInfo()'s are given below. I hope I do not overlook anything. testFactor - factor(sample(LETTERS[1:6], size = 42, replace = TRUE)) testMatrix - matrix(rnorm(42 * 6), nrow = 42) testDf - as.data.frame(testMatrix) by(data = testDf, INDICES = testFactor, FUN = mean) # OK by(data = testDf, INDICES = testFactor, FUN = median) # error # Error in median.default(data[x, ], ...) : need numeric data Kind regards, Tobias ### GNU/Linux ### sessionInfo() R version 2.6.2 (2008-02-08) i486-pc-linux-gnu locale: LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=en_US.UTF-8;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C attached base packages: [1] tools stats graphics grDevices utils datasets methods [8] base other attached packages: [1] Biobase_1.16.3 ### Windows ### sessionInfo() R version 2.7.0 alpha (2008-03-29 r44988) i386-pc-mingw32 locale: LC_COLLATE=English_United Kingdom.1252;LC_CTYPE=English_United Kingdom.1252;LC_MONETARY=English_United Kingdom.1252;LC_NUMERIC=C;LC_TIME=English_United Kingdom.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] by
- Oorspronkelijk bericht - Van: Peter Dalgaard [mailto:[EMAIL PROTECTED] Verzonden: donderdag, april 3, 2008 02:16 PM Aan: 'Tobias Verbeke' CC: r-devel@r-project.org Onderwerp: Re: [Rd] by infelicity Tobias Verbeke wrote: Dear list, Please find below an example of odd behaviour of the by function. It occurs both under GNU/Linux R 2.6.2 and Windows R 2.7.0alpha. Respective sessionInfo()'s are given below. I hope I do not overlook anything. testFactor - factor(sample(LETTERS[1:6], size = 42, replace = TRUE)) testMatrix - matrix(rnorm(42 * 6), nrow = 42) testDf - as.data.frame(testMatrix) by(data = testDf, INDICES = testFactor, FUN = mean) # OK by(data = testDf, INDICES = testFactor, FUN = median) # error # Error in median.default(data[x, ], ...) : need numeric data The infelicity (if any) is not in by(). Try mean(airquality) median(airquality) The FUN in by() is applied to the subsetted data frame, and there is no median.data.frame method. Apologies. Thanks for the clarification. Kind regards, Tobias __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] segfault isoreg with NAs
I was able to reproduce the problem under Windows (R 2.6.1).
When running ir4 - isoreg(1:10, y4 - c(5, 9, 1:2, 5:8, NA, 8)),
the following message appears:
R for Windows GUI front-end has encountered a problem and
needs to close. We are sorry for the inconvenience
after which R closes.
HTH,
Tobias
sessionInfo()
R version 2.6.1 (2007-11-26)
i386-pc-mingw32
locale:
LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
States.1252;LC_MONETARY=English_United
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
As can be seen below, adding a NA to the y values
in a call to isoreg results in a segfault.
ir4 - isoreg(1:10, y4 - c(5, 9, 1:2, 5:8, NA, 8))
Adding missing values to the x values, on the contrary,
gives an error, but maybe the error message could be
tailored to this particular situation.
y - c(5, 9, 1:2, 5:8, 3, 8)
x - c(1:9, NA)
isoreg(x, y)
## error message: Error in if (!isOrd) { : missing value where
TRUE/FALSE needed
Please find below a (temporary) patch (against Revision 43692)
for both the R source and the help file.
Kind regards,
Tobias
### patch isoreg.R ###
--- isoreg.R 2007-12-14 19:07:47.0 +0100
+++ isoreg2.R 2007-12-14 19:11:20.0 +0100
@@ -18,6 +18,9 @@
##
isoreg - function(x, y=NULL)
{
+if (any(is.na(x))) stop(x may not contain NA values)
+if (any(is.na(y))) stop(y may not contain NA values)
+
xy - xy.coords(x,y)
x - xy$x
isOrd - (!is.null(xy$xlab) xy$xlab == Index) || !is.unsorted(x)
### patch isoreg.Rd ###
--- isoreg.Rd 2007-12-14 19:08:12.0 +0100
+++ isoreg2.Rd2007-12-14 19:15:00.0 +0100
@@ -20,6 +20,7 @@
\item{x, y}{%in \code{isoreg},
coordinate vectors of the regression points. Alternatively a single
plotting structure can be specified: see \code{\link{xy.coords}}.
+The coordinate vectors may not contain missing values.
}
}
\details{
### sessionInfo() information segfault ###
sessionInfo()
R version 2.6.0 (2007-10-03)
i486-pc-linux-gnu
locale:
LC_CTYPE=en_US.ISO-8859-15;LC_NUMERIC=C;LC_TIME=en_US.ISO-8859-15;LC_COLLATE=en_US.ISO-8859-15;LC_MONETARY=en_US.ISO-8859-15\
;LC_MESSAGES=en_US.ISO-8859-15;LC_PAPER=en_US.ISO-8859-15;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.ISO-885\
9-15;LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
ir4 - isoreg(1:10, y4 - c(5, 9, 1:2, 5:8, NA, 8))
*** caught segfault ***
address 0x24, cause 'memory not mapped'
Process R segmentation fault (core dumped) at Fri Dec 14 17:48:22 2007
__
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
[Rd] segfault isoreg with NAs
Dear list,
As can be seen below, adding a NA to the y values
in a call to isoreg results in a segfault.
ir4 - isoreg(1:10, y4 - c(5, 9, 1:2, 5:8, NA, 8))
Adding missing values to the x values, on the contrary,
gives an error, but maybe the error message could be
tailored to this particular situation.
y - c(5, 9, 1:2, 5:8, 3, 8)
x - c(1:9, NA)
isoreg(x, y)
## error message: Error in if (!isOrd) { : missing value where
TRUE/FALSE needed
Please find below a (temporary) patch (against Revision 43692)
for both the R source and the help file.
Kind regards,
Tobias
### patch isoreg.R ###
--- isoreg.R2007-12-14 19:07:47.0 +0100
+++ isoreg2.R 2007-12-14 19:11:20.0 +0100
@@ -18,6 +18,9 @@
##
isoreg - function(x, y=NULL)
{
+if (any(is.na(x))) stop(x may not contain NA values)
+if (any(is.na(y))) stop(y may not contain NA values)
+
xy - xy.coords(x,y)
x - xy$x
isOrd - (!is.null(xy$xlab) xy$xlab == Index) || !is.unsorted(x)
### patch isoreg.Rd ###
--- isoreg.Rd 2007-12-14 19:08:12.0 +0100
+++ isoreg2.Rd 2007-12-14 19:15:00.0 +0100
@@ -20,6 +20,7 @@
\item{x, y}{%in \code{isoreg},
coordinate vectors of the regression points. Alternatively a single
plotting structure can be specified: see \code{\link{xy.coords}}.
+The coordinate vectors may not contain missing values.
}
}
\details{
### sessionInfo() information segfault ###
sessionInfo()
R version 2.6.0 (2007-10-03)
i486-pc-linux-gnu
locale:
LC_CTYPE=en_US.ISO-8859-15;LC_NUMERIC=C;LC_TIME=en_US.ISO-8859-15;LC_COLLATE=en_US.ISO-8859-15;LC_MONETARY=en_US.ISO-8859-15\
;LC_MESSAGES=en_US.ISO-8859-15;LC_PAPER=en_US.ISO-8859-15;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.ISO-885\
9-15;LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
ir4 - isoreg(1:10, y4 - c(5, 9, 1:2, 5:8, NA, 8))
*** caught segfault ***
address 0x24, cause 'memory not mapped'
Process R segmentation fault (core dumped) at Fri Dec 14 17:48:22 2007
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] format text help pages Windows
Dear list, Could someone enlighten me a bit on the exact format used for text help pages as I see them on Windows in the help/ folders of (compiled) package roots. When opening an example of these files in a text editor (?Bessel in GNU emacs), the file is displayed as follows: _^HB_^He_^Hs_^Hs_^He_^Hl_^H _^HF_^Hu_^Hn_^Hc_^Ht_^Hi_^Ho_^Hn_^Hs Bessel package:base R Documentation _^HB_^He_^Hs_^Hs_^He_^Hl_^H _^HF_^Hu_^Hn_^Hc_^Ht_^Hi_^Ho_^Hn_^Hs _^HD_^He_^Hs_^Hc_^Hr_^Hi_^Hp_^Ht_^Hi_^Ho_^Hn: Bessel Functions of integer and fractional order, of first and second kind, J(nu) and Y(nu), and Modified Bessel functions (of first and third kind), I(nu) and K(nu). [] How should other applications handle these files ? Running Rterm as a console within eclipse, e.g., now displays ^H as small rectangles and leaves the underscores while R itself (Rgui to be precise) and ESS nicely display help pages with some formatting (color code for Rgui and underlining in an ESS help buffer). Many thanks in advance, Tobias -- Tobias Verbeke - Consultant Business Decision Benelux Rue de la révolution 8 1000 Brussels - BELGIUM +32 499 36 33 15 [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] trivial typo R-exts.texi
Dear list,
Please find below a trivial patch to
R-exts.texi
Kind regards,
Tobias
Index: R-exts.texi
===
--- R-exts.texi (revision 42789)
+++ R-exts.texi (working copy)
@@ -8874,7 +8874,7 @@
reasons it calls @code{predict.lm} directly, but in principle (and in S
originally and currently) it could use @code{NextMethod}.
(@code{NextMethod} seems under-used in the @R{} sources. Do be aware
-that there as S/R differences in this area, and the example above works
+that there are S/R differences in this area, and the example above works
because there is a @emph{next} method, the default method, not that a
new method is selected when the class is changed.)
--
Tobias Verbeke - Consultant
Business Decision Benelux
Rue de la révolution 8
1000 Brussels - BELGIUM
+32 499 36 33 15
[EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] trivial typo Foreign.Rd (base)
Dear list,
Please find below a patch for a trivial
typo in Foreign.Rd (base package)
Kind regards,
Tobias
Index: Foreign.Rd
===
--- Foreign.Rd (revision 42784)
+++ Foreign.Rd (working copy)
@@ -68,7 +68,7 @@
compiled code that uses \R objects in the same way as internal
\R functions.
- \code{.Call} and \code{.Call.graphics} can be used call compiled code
+ \code{.Call} and \code{.Call.graphics} can be used to call compiled code
which makes use of internal \R objects. The arguments are passed to
the C code as a sequence of \R objects. It is included to provide
compatibility with S version 4.
--
Tobias Verbeke - Consultant
Business Decision Benelux
Rue de la révolution 8
1000 Brussels - BELGIUM
+32 499 36 33 15
[EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] serialized plot object (for a certain device)
Dear list, Using serialize it is possible to save the binary string representing an R object to a raw R vector. ## adapted from ?serialize x - serialize(list(1,2,3), NULL) x I am looking for a way to capture the binary string that in normal use of graphics devices will be written to (most commonly) a file connection. jpeg(file = test.jpg) plot(1:10) dev.off() In other words, is there a way of capturing the binary `jpeg string' representing the plot(1:10) graph, e.g. into a raw vector ? Many thanks in advance, Tobias -- Tobias Verbeke - Consultant Business Decision Benelux Rue de la révolution 8 1000 Brussels - BELGIUM +32 499 36 33 15 [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sligthly OT Re: Makefile for embedding OpenBUGS in R package
Hin-Tak Leung wrote:
Tobias Verbeke wrote:
snipped
Actually, I think Hin-Tak is right about the absolute path. Even when
the R code will call the executable that resides in that directory, R
will call it from any directory and that (current) directory will be
resolved (at least that is what I observe experimentally).
When such an absolute path is coded in, everything runs fine -- we now
can run a BUGS script from within R under GNU/Linux !
It would however be nice to solve the remaining problem of the
absolute path in the dlopen() call, i.e. being able to fill in
`dynamically' the library path to which the package is actually
installed.
Is there a way to have the library path to which a package is
installed available during package installation and then to do some
text-processing to fill in this path dynamically into the C file i.e.
as argument of dlopen() before compiling it?
snipped
I don't know if there is a neater way of doing this, but one somewhat
clunky way is to process the result of .libPath() , append each of its
elements by package/inst/OpenBUGS/bugs.so and test if the file exists,
(.libPath() should be quite a small character vector so it should be too
slow to test every one), then pass the result as an explicit
argument to the main bugs binary before everything else it takes.
I think there is a more clever way of telling where the current package
is installed/located but it escapes me at the moment. Perhaps the source
code of data() (just typying 'data' without the () at the comment prompt
will display the source), can shed some lights on this, since data()
does something quite similiar.
Thank you, Hin-Tak, for pointing me in the right direction.
Please find below the final C code I use to get OpenBUGS
running.
#include stdlib.h
#include stdio.h
#include dlfcn.h
int main (int argc, char *argv[])
{
void * handle;
void (*cli)(void);
char * error;
char * sopath;
sopath = argv[1]; /* path of brugs.so */
handle = dlopen(sopath, RTLD_LAZY);
if (!handle) {
fprintf (stderr, %s\n, dlerror());
exit(1);
}
* (void **) (cli) = dlsym(handle, CLI);
if ((error = dlerror()) != NULL) {
fprintf (stderr, %s\n, error);
exit(1);
}
(*cli)();
dlclose(handle);
return 0;
}
At the R level, the use of system.file seemed to me to be
the most generally applicable. The relevant lines from the
calling R code are:
## construct system command
exe - if (iswin) bugs.exe else linbugs
sofile - brugs.so
OpenBUGSpath - system.file(OpenBUGS, package = CGHmix)
pathexe - file.path(OpenBUGSpath, exe)
pathso - file.path(OpenBUGSpath, sofile)
cmd - if (iswin){
paste(pathexe, , scriptfile, , resultsfile, sep = )
} else {
paste(pathexe, pathso, , scriptfile, , resultsfile,
sep = )
}
system(cmd)
The resulting package now allows for using an embedded OpenBUGS
on GNU/Linux without relying on WINE. Thanks to all for their helpful
comments.
Kind regards,
Tobias
--
Tobias Verbeke - Consultant
Business Decision Benelux
Rue de la révolution 8
1000 Brussels - BELGIUM
+32 499 36 33 15
[EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sligthly OT Re: Makefile for embedding OpenBUGS in R package
Hi Ben, Tobias Verbeke tobias.verbeke at businessdecision.com writes: The resulting package now allows for using an embedded OpenBUGS on GNU/Linux without relying on WINE. Thanks to all for their helpful comments. woo-hoo! this is great! Any chance that this will propagate to the R2WinBUGS package at some point ... ??? A quick look at R2WinBUGS reveals that this package does not embed the OpenBUGS distribution within the package. This is not needed per se, but will then imply that the user has to compile the C file that accesses the brugs.so shared library (or a variant as the path to the bugs executable is an argument to the bugs function in R2WinBUGS). When I worked on this (for a specific application a client had in mind), I deliberately chose to avoid any administration in addition to ordinary R package installation. The BRugs package, on the contrary, embeds a (previous) version of OpenBUGS and could use what we found out in this thread, but then the interface of BRugs is more designed for interactive use of BUGS which currently still is possible only on Windows. It might be an idea to modify the BRugsFit function (BRugs' meta function) to run a script file in one go when it runs on GNU/Linux. This modification is needed as the current BRugsfit uses the interactive commands modelCheck(), modelCompile() etc. in separate steps. If the maintainer (in cc) would think this is a good idea, the following things should then be assured within the BRugs package in addition of changing BRugsFit function for it to work under Linux: (1) all of the BUGS files (data, model, inits and script files) should have CR LF line endings (2) the script file produced should end on modelQuit() without any additional character (no newline) Alternatively, it could be put into (yet another) R - BUGS package, but this would duplicate a lot of the BRugs code. Kind regards, Tobias -- Tobias Verbeke - Consultant Business Decision Benelux Rue de la révolution 8 1000 Brussels - BELGIUM +32 499 36 33 15 [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sligthly OT Re: Makefile for embedding OpenBUGS in R package
Thank you very much for your input. In the meantime I was -- thanks to the pointer to the Rserve Makefile by Professor Ripley -- able to have a Makefile that built the package correctly: SFILE = ../inst/OpenBUGS/linbugs.c XFILE = ../inst/OpenBUGS/linbugs SOFILE = ../src/linbugs.so all: $(XFILE) copyop $(XFILE): $(SFILE) gcc -m32 -o $(XFILE) $(SFILE) -ldl copyop: $(XFILE) # Only *.so get copied. Therefore we need to fake the bin files as .sos to get # copied. Not a nice hack, but it works... (Comment from Rserve) cp $(XFILE) $(SOFILE) clean: rm -f *.so *~ $(XFILE) .PHONY: copyop clean (Note that I changed the naming of the C source and compiled file following a complaint by the package checker that observed that the OpenBUGS distribution has a directory Bugs which on case-insensitive systems could be confused with bugs, the previous name of the executable) Uwe Ligges wrote: Hin-Tak Leung wrote: Prof Brian Ripley wrote: OpenBUGS is distributed under GPL2, so this seems not to apply. It is distributed as source and as binaries: the difficulty is that it is written in Object Pascal for which a compiler is not readily available. Argh, I just thought of a proper technical reason, and I think I have spotted a possible bug in the original poster's code! Some choose to do dlopen() when the DLL/so is in a non-standard/non-system location, as an alternative to setting LD_LIBRARY_PATH explicitly or other link-loader magics. The line: handle = dlopen(./brugs.so, RTLD_LAZY); Seems to suggest this, However, the problem with this code, is that the current directory (./) may not be where the user thinks it is. I think the user meant to prepend $R_HOME/library/package/inst/ somehow to brugs.so, and dlopen'ing $R_HOME/library/package/inst/brugs.so instead. This should be $R_HOME/library/package/OpenBUGS/brugs.so (without the inst level that is taken out when installing the package) No, it's fine if the executable is started in the same directory, and that can be assured by the calling R code. Otherwise it will only work if you have the package in the main library of R. Anyway, it is still highly preferable to just load the Bugs lib into R, if we only could compile the stuff... Actually, I think Hin-Tak is right about the absolute path. Even when the R code will call the executable that resides in that directory, R will call it from any directory and that (current) directory will be resolved (at least that is what I observe experimentally). When such an absolute path is coded in, everything runs fine -- we now can run a BUGS script from within R under GNU/Linux ! It would however be nice to solve the remaining problem of the absolute path in the dlopen() call, i.e. being able to fill in `dynamically' the library path to which the package is actually installed. Is there a way to have the library path to which a package is installed available during package installation and then to do some text-processing to fill in this path dynamically into the C file i.e. as argument of dlopen() before compiling it? Thanks again, Tobias -- Tobias Verbeke - Consultant Business Decision Benelux Rue de la révolution 8 1000 Brussels - BELGIUM +32 499 36 33 15 [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Makefile for embedding OpenBUGS in R package
Dear list, I'm trying to embed OpenBUGS in an R package for use of it on 64-bit Linux. In order to get the CLI working one has to compile C code contained in $OpenBUGS/Manuals/CBugs.html (copied to say CBugs.c) using gcc -m32 -o bugs CBugs.c -ldl I put the OpenBUGS distribution in the ./inst subdirectory of the package root. Where should I now put the CBugs.c and how should the Makefile look like in order to be able to call $PKG_ROOT/OpenBUGS/bugs afterwards ? Naively putting the following Makefile in ./src does not work -% bugs: ../inst/OpenBUGS/CBugs.c gcc -m32 -o bugs ../inst/OpenBUGS/CBugs.c -ldl -%--- The objective is to use something along the following execfile - system.file(OpenBUGS, bugs, package = mypkg) system(paste(execfile, somescript.script somefile.out)) This system call to the CLI is currently the only (non-WINE) way of using OpenBUGS on Linux in batch mode. Many thanks in advance, Tobias -- Tobias Verbeke - Consultant Business Decision Benelux Rue de la révolution 8 1000 Brussels - BELGIUM +32 499 36 33 15 [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Makefile for embedding OpenBUGS in R package
- Oorspronkelijk bericht -
Van: Prof Brian Ripley [mailto:[EMAIL PROTECTED]
Verzonden: maandag, augustus 6, 2007 03:46 PM
Aan: 'Tobias Verbeke'
CC: r-devel@r-project.org
Onderwerp: Re: [Rd] Makefile for embedding OpenBUGS in R package
On Mon, 6 Aug 2007, Tobias Verbeke wrote:
Dear list,
I'm trying to embed OpenBUGS in an R package for use of it
on 64-bit Linux. In order to get the CLI working one has to
compile C code contained in $OpenBUGS/Manuals/CBugs.html
same as
http://mathstat.helsinki.fi/openbugs/data/Docu/CBugs.html
I presume.
Actually, these files appear to differ. The file I referred to
was the file ./Manuals/CBugs.html contained in the current OpenBUGS
release:
http://mathstat.helsinki.fi/openbugs/OpenBUGS.zip
(copied to say CBugs.c) using
gcc -m32 -o bugs CBugs.c -ldl
I put the OpenBUGS distribution in the ./inst subdirectory of
the package root. Where should I now put the CBugs.c and how
Why do you want to install CBugs.c?
The CBugs.c file itself is indeed not needed in the built package.
should the Makefile look like in order to be able to call
$PKG_ROOT/OpenBUGS/bugs afterwards ?
Naively putting the following Makefile in ./src does not work
What does 'does not work' mean? It's hard to know whether this is just
not doing what you wanted, or something else is wrong.
Apologies. This is the error message when putting the Makefile
in ./src and launching the package checker:
$ R.250 CMD check CGHmix
DISPLAY=localhost:10.0
* checking for working latex ... OK
* using log directory '/home/tverbek1/pkg/CGHmix.Rcheck'
* using R version 2.5.0 (2007-04-23)
* checking for file 'CGHmix/DESCRIPTION' ... OK
* checking extension type ... Package
* this is package 'CGHmix' version '0.1-2'
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking whether package 'CGHmix' can be installed ... ERROR
Installation failed.
See '/home/tverbek1/pkg/CGHmix.Rcheck/00install.out' for details.
The file 00install.out contains:
* Installing *source* package 'CGHmix' ...
** libs
** arch -
gcc -m32 -o ../inst/OpenBUGS/bugs ../inst/OpenBUGS/CBugs.c -ldl
cp: cannot stat `*.so': No such file or directory
ERROR: compilation failed for package 'CGHmix'
** Removing '/home/tverbek1/pkg/CGHmix.Rcheck/CGHmix'
-%
bugs: ../inst/OpenBUGS/CBugs.c
gcc -m32 -o bugs ../inst/OpenBUGS/CBugs.c -ldl
-%---
The objective is to use something along the following
execfile - system.file(OpenBUGS, bugs, package = mypkg)
system(paste(execfile, somescript.script somefile.out))
This system call to the CLI is currently the only (non-WINE)
way of using OpenBUGS on Linux in batch mode.
I think you need to make ../inst/OpenBUGS/bugs, not src/bugs. So
something like
all: ../inst/OpenBUGS/bugs
../inst/OpenBUGS/bugs: ../inst/OpenBUGS/CBugs.c
gcc -m32 -o ../inst/OpenBUGS/bugs ../inst/OpenBUGS/CBugs.c -ldl
Thank you.
However, -m32 builds a 32-bit executable on 64-bit linux. Is that what you
wanted?
Yes. The shared object (brugs.so) comes with the OpenBUGS distribution
and currently can only be cross-compiled by the main OpenBUGS developer
(Andrew Thomas) who knows all secrets of the Windows only BlackBox
(nomen omen) Component Pascal compiler.
$ file brugs.so
brugs.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped
Many thanks for your ever instructive answer.
Tobias
P.S. Contents of CBugs.c from OpenBUGS distribution (3.0.1)
/* GNU General Public Licence
This small C program loads the brugs.so ELF shared library and calls the CLI
function.
Save it as a .c file and then compile it on Linux using gcc -o bugs CBugs.c
-ldl
*/
#include dlfcn.h
#include stdio.h
#include string.h
int main (int argc, char **argv)
{
void * handle;
void (*cli)(void);
handle = dlopen(./brugs.so, RTLD_LAZY);
if (!handle)
return 1;
* (void **) (cli) = dlsym(handle, CLI);
(*cli)();
dlclose(handle);
return 0;
}
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Makefile for embedding OpenBUGS in R package
Hi Uwe,
As the BRugs maintainer, as far as I can tell, the most recent OpenBUGS
brugs.so is not compatible with (at least) my system and I do not have
the compilers to try it myself. Hence we still only ship BRugs for
Windows, but if anybody else has ideas how to get the BRugs.so compiled
(or just running without traps, I'd be happy to hear about it.
My strategy is to produce the data, model and inits file in
a BRugs manner and then produce a script along the lines of
modelCheck('Ratsmodel.txt')
modelData('Ratsdata.txt')
modelCompile()
modelInits('Ratsinits.txt')
modelUpdate(1000)
statsSet('alpha')
statsSet('beta')
modelUpdate(2000)
samplesStats('*')
modelQuit()
which is fed to bugs (compiled as described below) like
./bugs rats.script rats.out
Afterwards I use some simple R utilities to
clean up rats.out and read it in as
as dataframe for further processing.
There are however two (painfully learned and
undocumented) things to keep in mind when
producing these files:
(1) such a script (as well as all other BUGS files)
should use CR LF line endings
(2) There may be absolutely no character (no newline!)
after the final modelQuit() [otherwise you can end
up (like me) with 47 GB of error messages being joyfully
output to rats.out... which is when I had a phone call
from a local sysasmin]
The only missing piece to embed current OpenBUGS in an
R package for automating analyses on Linux is being able
to compile CBugs.c (see below) when building the R package.
I hope this is useful to someone.
Kind regards,
Tobias
Tobias Verbeke wrote:
- Oorspronkelijk bericht -
Van: Prof Brian Ripley [mailto:[EMAIL PROTECTED]
Verzonden: maandag, augustus 6, 2007 03:46 PM
Aan: 'Tobias Verbeke'
CC: r-devel@r-project.org
Onderwerp: Re: [Rd] Makefile for embedding OpenBUGS in R package
On Mon, 6 Aug 2007, Tobias Verbeke wrote:
Dear list,
I'm trying to embed OpenBUGS in an R package for use of it
on 64-bit Linux. In order to get the CLI working one has to
compile C code contained in $OpenBUGS/Manuals/CBugs.html
same as
http://mathstat.helsinki.fi/openbugs/data/Docu/CBugs.html
I presume.
Actually, these files appear to differ. The file I referred to
was the file ./Manuals/CBugs.html contained in the current OpenBUGS
release:
http://mathstat.helsinki.fi/openbugs/OpenBUGS.zip
(copied to say CBugs.c) using
gcc -m32 -o bugs CBugs.c -ldl
I put the OpenBUGS distribution in the ./inst subdirectory of
the package root. Where should I now put the CBugs.c and how
Why do you want to install CBugs.c?
The CBugs.c file itself is indeed not needed in the built package.
should the Makefile look like in order to be able to call
$PKG_ROOT/OpenBUGS/bugs afterwards ?
Naively putting the following Makefile in ./src does not work
What does 'does not work' mean? It's hard to know whether this is
just not doing what you wanted, or something else is wrong.
Apologies. This is the error message when putting the Makefile
in ./src and launching the package checker:
$ R.250 CMD check CGHmix
DISPLAY=localhost:10.0
* checking for working latex ... OK
* using log directory '/home/tverbek1/pkg/CGHmix.Rcheck'
* using R version 2.5.0 (2007-04-23)
* checking for file 'CGHmix/DESCRIPTION' ... OK
* checking extension type ... Package
* this is package 'CGHmix' version '0.1-2'
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking whether package 'CGHmix' can be installed ... ERROR
Installation failed.
See '/home/tverbek1/pkg/CGHmix.Rcheck/00install.out' for details.
The file 00install.out contains:
* Installing *source* package 'CGHmix' ...
** libs
** arch -
gcc -m32 -o ../inst/OpenBUGS/bugs ../inst/OpenBUGS/CBugs.c -ldl
cp: cannot stat `*.so': No such file or directory
ERROR: compilation failed for package 'CGHmix'
** Removing '/home/tverbek1/pkg/CGHmix.Rcheck/CGHmix'
-%
bugs: ../inst/OpenBUGS/CBugs.c
gcc -m32 -o bugs ../inst/OpenBUGS/CBugs.c -ldl
-%---
The objective is to use something along the following
execfile - system.file(OpenBUGS, bugs, package = mypkg)
system(paste(execfile, somescript.script somefile.out))
This system call to the CLI is currently the only (non-WINE)
way of using OpenBUGS on Linux in batch mode.
I think you need to make ../inst/OpenBUGS/bugs, not src/bugs. So
something like
all: ../inst/OpenBUGS/bugs
../inst/OpenBUGS/bugs: ../inst/OpenBUGS/CBugs.c
gcc -m32 -o ../inst/OpenBUGS/bugs ../inst/OpenBUGS/CBugs.c -ldl
Thank you.
However, -m32 builds a 32-bit executable on 64-bit linux. Is that
what you wanted?
Yes. The shared object (brugs.so) comes with the OpenBUGS distribution
and currently can only be cross-compiled by the main OpenBUGS
developer (Andrew Thomas) who knows all secrets of the Windows only
BlackBox (nomen omen) Component Pascal compiler.
$ file brugs.so
brugs.so: ELF 32-bit LSB shared object
[Rd] trivial typos R-admin
Please find below a patch against
https://svn.r-project.org/R/trunk/doc/manual/R-admin.texi
for two trivial typos.
1337c1337
vanilla @R{} installation). This location cna be overridden by
---
vanilla @R{} installation). This location can be overridden by
1343c1343
site libraries are always include by @samp{.libPaths()}.
---
site libraries are always included by @samp{.libPaths()}.
Kind regards,
Tobias
--
Tobias Verbeke - Consultant
Business Decision Benelux
Rue de la révolution 8
1000 Brussels - BELGIUM
+32 499 36 33 15
[EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] trivial typo R-lang
Please find below a patch for a trivial
typo in R-lang:
384c384
Symbol have mode @code{name}, storage mode @code{symbol}, and type
---
Symbols have mode @code{name}, storage mode @code{symbol}, and type
Kind regards,
Tobias
--
Tobias Verbeke - Consultant
Business Decision Benelux
Rue de la révolution 8
1000 Brussels - BELGIUM
+32 499 36 33 15
[EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] help search mechanism for ?$
I'm sure this is completely harmless, but by accident I discovered that ?nomatterwhat$ fires up ?$ Kind regards, Tobias __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] abline for intercept-only simple lm models (with and without offset)
Martin Maechler wrote:
Yes, I think all your propositions would be improvements.
OTOH, I don't think the improvements warrant a big increase in
code (complexity), nor do I think the improvements are crucial
for R's integrity.
So...
If you (our someone else) provides a patch {against
R-devel, as always} which keeps the code simple,
I'd strongly consider adding that to R.
Dear Martin,
Thank you for the encouragement.
Please find a patch in attachment.
As you will see, I also added a warning
for models with more than 2 parameters.
Kind regards,
Tobias
Regards,
Martin Maechler
Tobias == Tobias Verbeke [EMAIL PROTECTED]
on Sat, 09 Dec 2006 22:42:38 +0100 writes:
Tobias The abline function can be used to draw the
Tobias regression line when one passes the lm object as an
Tobias argument.
Tobias However, if it's an intercept-only model, it appears
Tobias to use the intercept as the slope of the abline:
Tobias mod - lm(dist ~ 1, data = cars) plot(dist ~ speed,
Tobias data = cars) abline(reg = mod) # nothing appears
Tobias This behaves as documented, but might catch
Tobias someone. Would it be an improvement if this
Tobias situation was detected so as to plot the appropriate
Tobias horizontal line, i.e.
Tobias abline(a = coef(mod), b = 0) ?
Tobias Would it also be an improvement if for a model like
Tobias mod2 - lm(dist ~ 1 + offset(speed), data = cars)
Tobias abline(reg = mod2) would be equivalent to
Tobias abline(a = coef(mod2), b = 1) ?
Tobias For models through the origin, the current function
Tobias works fine, but one might even consider models
Tobias through the origin and having the independent
Tobias variable in an offset() to be fully fool-proof, i.e.
Tobias abline(a = 0, b = 1)
Tobias Kind regards, Tobias
Tobias __
Tobias R-devel@r-project.org mailing list
Tobias https://stat.ethz.ch/mailman/listinfo/r-devel
11,12c11,15
temp - as.vector(coef(a))
if(length(temp) == 1) {
---
tempa - as.character(terms(a))
coefa - coef(a)
if (length(coefa) 2)
warning(The abline function is meant to only plot the regression
line for simple linear regression)
if (length(grep(-[[:blank:]]?1, tempa))) {
14c17
b - temp
---
b - ifelse(length(grep(offset, tempa)), 1, coefa[1])
16,17c19,22
a - temp[1]
b - temp[2]
---
a - coefa[1]
if (length(grep(offset, tempa))) b - 1
else if (length(coefa) = 2) b - coefa[2]
else b - 0
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] abline for intercept-only simple lm models (with and without offset)
The abline function can be used to draw the regression line when one passes the lm object as an argument. However, if it's an intercept-only model, it appears to use the intercept as the slope of the abline: mod - lm(dist ~ 1, data = cars) plot(dist ~ speed, data = cars) abline(reg = mod) # nothing appears This behaves as documented, but might catch someone. Would it be an improvement if this situation was detected so as to plot the appropriate horizontal line, i.e. abline(a = coef(mod), b = 0) ? Would it also be an improvement if for a model like mod2 - lm(dist ~ 1 + offset(speed), data = cars) abline(reg = mod2) would be equivalent to abline(a = coef(mod2), b = 1) ? For models through the origin, the current function works fine, but one might even consider models through the origin and having the independent variable in an offset() to be fully fool-proof, i.e. abline(a = 0, b = 1) Kind regards, Tobias __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] typo in ?dimnames
Dear list, In ?dimnames, section `Value' I read: For the 'data.frame' method both dimnames must be non-null, and the rownames must be contain no duplicates nor missing values. ^^^ Best regards, Tobias version platform i486-pc-linux-gnu arch i486 os linux-gnu system i486, linux-gnu status major 2 minor 3.0 year 2006 month 04 day24 svn rev37909 language R version.string Version 2.3.0 (2006-04-24) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
