Re: [Rd] Fourteen patches to speed up R
Thanks very much for the patches. I have spent a couple of days working through them, and others have looked at some of them as well and may continue to do so. Here are some notes on the individual patches describing things I have done or decided not to do and things others have done that I know about. patch-transpose Applied by Martin Maechler. patch-for Applied by Duncan Murdoch; revised by me. Some cosmetic revisions, including going back to PROTECT_WITH_INDEX. Also placed two variables 'n' and 'bgn' back under volatile declarations. Theoretically this shouldn't be needed, but gcc -O2 -Wclobbered warns about them, so to be safe and eliminate the warnings they are declared volatile as well. The current byte code compiler actually stores the binding cell rather than using setVar or defineVar -- this eliminates the search and does not have the destructive effect of modifying an outer variable if the loop variable is removed, but removing the loop variable will then reference an outer one if available or do other strange things. It doesn't actually make much performance difference (at least in simple examples) -- for that we would probably need to eliminate a number of the function calls involved at the moment. A better solution for preserving the semantics in the case of user code removing the loop variable might be to disallow removing the loop variable, or to allow removal to be detected easily (e.g. by having rm() put R_UnboundValue in the value cell). patch-parens Should not be applied. `(` is conceptually a BUILTIN, i.e. a strict function that evaluates all arguments in order. Making it a SPECIAL is conceptually wrong and confuses issues of code analysis and compilation. It is true that calling of BUILTINs is currently less efficient than calling of SPECIALS because the evaluated arguments for BUILTINs are stored in freshly allocated lists, but it would be better to work towards making that calling mechanism more efficient for all BUILTINs than to confuse internal semantics by converting BUILTINs to SPECIALs. We have currently a few things that are SPECIAL even though they really have BUILTIN semantics, but they are SPECIAL because of issues like needing to support missing arguments, which BUILTINs do not. We should be moving these to BUILTIN status, though perhaps not until BUILTIN calling performance is improved. Whether working on BUILTIN calling performance in the interpreter makes sense depends on where the byte code compiler gets to. The current compiler is much more efficient about the handling of inlined BUILTINs; the revised one in progress is likely to me much more efficient for all BUILTINs. I would rather not make the proposed change for braces (do_begin) as it makes it harder to find the relevant bits to remove if we want to change this. Source references are very useful, but we should be able to find a way of having them without incurring runtime overhead unless they are actually used. I have added an R_INLINE designation to getSrcref to encourage the compiler to do the inlining. Timing differences for test-parens.r are in the right direction but in the noise level on an Ubuntu laptop: inline byte develdecl comp curly: 10.25 10.13 1.94 parens: 11.21 10.91 1.91 The byte comp column is for the current byte code engine and compiler and illustrates that this approach has much more promise. patch-sum-prod I had looked at this a while back and had an uncommitted change along very similar lines. I think the reason I didn't commit this change is that I didn't like the code expansion that resulted, and I still don't. Looking at this again it turns out there is a very simple code change that preserves the code structure and achieves the same improvement in the narm == FALSE case: reverse the test order from if (!ISNAN(x[i]) || !narm) ... to if (!narm || !ISNAN(x[i])) ... That way the expensive ISNAN test is only done when the result might matter. This has been done for real and complex sum and prod. It provides the same level of improvement for the narm == FALSE case as the patch, and for the narm == TRUE cases the differences are in the noise level on my system. This has been committed as r52925. The specific six timings from test-sum-prod.r on my Ubuntu laptop are R 2.11 devel patch switch
Re: [Rd] Crash report: regexpr("a{2-}", "")
It crashes R on my linux: > regexpr("a{2-}", "") R: tre-compile.c:1825: tre_ast_to_tnfa: Assertion `iter->max == -1 || iter->max == 1' failed. Aborted My setup is: > sessionInfo() R version 2.11.1 (2010-05-31) i386-redhat-linux-gnu locale: [1] LC_CTYPE=en_NZ LC_NUMERIC=C LC_TIME=en_NZ [4] LC_COLLATE=en_NZ LC_MONETARY=CLC_MESSAGES=en_NZ [7] LC_PAPER=en_NZ LC_NAME=CLC_ADDRESS=C [10] LC_TELEPHONE=C LC_MEASUREMENT=en_NZ LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] djsmisc_1.0-1 David Scott On 23/09/10 04:37, Brian Diggs wrote: [Accidentally posted this to r-help instead of r-devel; reposting to put it into the correct list and thread. My apologies for the duplication.] On 9/21/2010 8:04 PM, Henrik Bengtsson wrote: Each of the following calls crash ("core dumps") R (R --vanilla) on various versions and OSes: regexpr("a{2-}", "") sub("a{2-}", "") gsub("a{2-}", "") EXAMPLES: To add another (windows) example it also crashes the 2.12.0 alpha build: > sessionInfo() R version 2.12.0 alpha (2010-09-20 r52948) Platform: i386-pc-mingw32/i386 (32-bit) ... > regexpr("a{2-}", "") Assertion failed: iter->max == -1 || iter->max == 1, file tre-compile.c, line 1825 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. sessionInfo() R version 2.11.1 Patched (2010-09-16 r52949) Platform: i386-pc-mingw32 (32-bit) ... regexpr("a{2-}", "") Assertion failed: iter->max == -1 || iter->max == 1, file tre-compile.c, line 1825 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. sessionInfo() R version 2.12.0 Under development (unstable) (2010-09-14 r52910) Platform: i386-pc-mingw32/i386 (32-bit) ... regexpr("a{2-}", "") Assertion failed: iter->max == -1 || iter->max == 1, file tre-compile.c, line 1825 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. sessionInfo() R version 2.11.0 Patched (2010-05-09 r51960) x86_64-unknown-linux-gnu ... regexpr("a{2-}", "") R: tre-compile.c:1825: tre_ast_to_tnfa: Assertion `iter->max == -1 || iter->max == 1' failed. Aborted /Henrik -- _ David Scott Department of Statistics The University of Auckland, PB 92019 Auckland 1142,NEW ZEALAND Phone: +64 9 923 5055, or +64 9 373 7599 ext 85055 Email: d.sc...@auckland.ac.nz, Fax: +64 9 373 7018 Director of Consulting, Department of Statistics __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Possible bug or annoyance with library.dynam.unload()
Le 22/09/10 17:31, Duncan Murdoch a écrit : On 22/09/2010 11:22 AM, Karl Forner wrote: Thanks Duncan for your suggestion. I could not find any package using dynamic library, namespaces and not the useDynLib pragma so I created a minimalistic package to demonstrate the problem. Please find attached a very small package foo (8.8k) Your package depends on Rcpp, so I didn't try it in the alpha version of 2.12.0 (Rcpp isn't available there in a Windows binary at the moment) (This might be moot given Karl's answer), but: We are working on having Rcpp to work with R 2.12.0, we have currently a few issues to deal with due to the use of a newer compiler for R 2.12.0. We hope we can make this happen before R 2.12.0 is out next month. Romain but I did try it in R-patched. With one minor change to your script (the lib.loc needs to be "local", not "local/" on Windows), I can reproduce the problem, and it looks like a bug to me. Thanks for the report, I'll put it on the bugs page, and hopefully it will be fixed before the 2.12.0 release. Duncan Murdoch Steps to reproduce the problem: * unarchive it ( tar zxvf foo_0.1.tar.gz ) * cd foo * install it locally ( mkdir local; R CMD INSTALL -l local . ) * R > library(foo, lib.loc="local/") >.dynLibs() # there you should be able to see the foo.so lib, in my case /x05/people/m160508/workspace/foo/local/foo/libs/foo.so > unloadNamespace("foo") .onUnload, libpath= local/fooWarning message: .onUnload failed in unloadNamespace() for 'foo', details: call: library.dynam.unload("foo", libpath) error: shared library 'foo' was not loaded #The libpath that the .onUnload() gets is "local/foo". #This fails: >library.dynam.unload("foo", "local/foo") Error in library.dynam.unload("foo", "local/foo") : shared library 'foo' was not loaded # but if you use the absolute path it works: >library.dynam.unload("foo", "/x05/people/m160508/workspace/foo/local/foo") Karl On Tue, Sep 21, 2010 at 5:33 PM, Duncan Murdochwrote: > On 21/09/2010 10:38 AM, Karl Forner wrote: > >> Hello, >> >> I got no reply on this issue. >> It is not critical and I could think of work-around, but it really looks >> like a bug to me. >> Should I file a bug-report instead of posting in this list ? >> > > I'd probably post instructions for a reproducible example first. Pick some > CRAN package, tell us what to do with it to trigger the error, and then we > can see if it's something special about your package or Roxygen or a general > problem. > > Duncan Murdoch > > Thanks, >> >> Karl >> >> On Thu, Sep 16, 2010 at 6:11 PM, Karl Forner >> wrote: >> >> > Hello, >> > >> > I have a package with a namespace. Because I use Roxygen that >> overwrites >> > the NAMESPACE file each time it is run, I use a R/zzz.R file with >> > an .onLoad() and .onUnload() functions to take care of loading and >> > unloading my shared library. >> > >> > The problem: if I load my library from a local directory, then the >> > unloading of the package fails, e.g: >> > >> > # loads fine >> > >library(Foo, lib.loc=".Rcheck") >> > >> > >unloadNamespace("Foo") >> > Warning message: >> > .onUnload failed in unloadNamespace() for 'Foo', details: >> > call: library.dynam.unload("Foo", libpath) >> > error: shared library 'Foo' was not loaded >> > >> > # I traced it a little: >> > >library.dynam.unload("Foo", ".Rcheck/Foo") >> > Error in library.dynam.unload("Foo", ".Rcheck/Foo") : >> > shared library 'Foo' was not loaded >> > >> > # using an absolute path works >> > >library.dynam.unload("Foo", "/home/toto/.Rcheck/Foo") >> > >> > >> > So from what I understand, the problem is either that the relative >> libpath >> > is sent to the .onUnload() function instead of the absolute one, >> > or that library.dynam.unload() should be modified to handle the >> relative >> > paths. >> > >> > Am I missing something ? What should I do ? >> > >> > Thanks, >> > >> > >> > Karl -- Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr |- http://bit.ly/cCmbgg : Rcpp 0.8.6 |- http://bit.ly/bzoWrs : Rcpp svn revision 2000 `- http://bit.ly/b8VNE2 : Rcpp at LondonR, oct 5th __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Crash report: regexpr("a{2-}", "")
[Accidentally posted this to r-help instead of r-devel; reposting to put it into the correct list and thread. My apologies for the duplication.] On 9/21/2010 8:04 PM, Henrik Bengtsson wrote: Each of the following calls crash ("core dumps") R (R --vanilla) on various versions and OSes: regexpr("a{2-}", "") sub("a{2-}", "") gsub("a{2-}", "") EXAMPLES: To add another (windows) example it also crashes the 2.12.0 alpha build: > sessionInfo() R version 2.12.0 alpha (2010-09-20 r52948) Platform: i386-pc-mingw32/i386 (32-bit) ... > regexpr("a{2-}", "") Assertion failed: iter->max == -1 || iter->max == 1, file tre-compile.c, line 1825 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. sessionInfo() R version 2.11.1 Patched (2010-09-16 r52949) Platform: i386-pc-mingw32 (32-bit) ... regexpr("a{2-}", "") Assertion failed: iter->max == -1 || iter->max == 1, file tre-compile.c, line 1825 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. sessionInfo() R version 2.12.0 Under development (unstable) (2010-09-14 r52910) Platform: i386-pc-mingw32/i386 (32-bit) ... regexpr("a{2-}", "") Assertion failed: iter->max == -1 || iter->max == 1, file tre-compile.c, line 1825 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. sessionInfo() R version 2.11.0 Patched (2010-05-09 r51960) x86_64-unknown-linux-gnu ... regexpr("a{2-}", "") R: tre-compile.c:1825: tre_ast_to_tnfa: Assertion `iter->max == -1 || iter->max == 1' failed. Aborted /Henrik -- Brian S. Diggs, PhD Senior Research Associate, Department of Surgery Oregon Health & Science University __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Possible bug or annoyance with library.dynam.unload()
> Your package depends on Rcpp, so I didn't try it in the alpha version of 2.12.0 It's a mistake, in fact it does not depend anymore. You can safely delete the src/Makevars file. Duncan Murdoch > > > Steps to reproduce the problem: >> >> * unarchive it ( tar zxvf foo_0.1.tar.gz ) >> * cd foo >> * install it locally ( mkdir local; R CMD INSTALL -l local . ) >> * R >> > library(foo, lib.loc="local/") >> >.dynLibs() >> # there you should be able to see the foo.so lib, in my case >> /x05/people/m160508/workspace/foo/local/foo/libs/foo.so >> >> > unloadNamespace("foo") >> .onUnload, libpath= local/fooWarning message: >> .onUnload failed in unloadNamespace() for 'foo', details: >> call: library.dynam.unload("foo", libpath) >> error: shared library 'foo' was not loaded >> >> #The libpath that the .onUnload() gets is "local/foo". >> >> #This fails: >> >library.dynam.unload("foo", "local/foo") >> Error in library.dynam.unload("foo", "local/foo") : >> shared library 'foo' was not loaded >> >> # but if you use the absolute path it works: >> >library.dynam.unload("foo", >> "/x05/people/m160508/workspace/foo/local/foo") >> >> Karl >> >> On Tue, Sep 21, 2010 at 5:33 PM, Duncan Murdoch> >wrote: >> >> > On 21/09/2010 10:38 AM, Karl Forner wrote: >> > >> >> Hello, >> >> >> >> I got no reply on this issue. >> >> It is not critical and I could think of work-around, but it really >> looks >> >> like a bug to me. >> >> Should I file a bug-report instead of posting in this list ? >> >> >> > >> > I'd probably post instructions for a reproducible example first. Pick >> some >> > CRAN package, tell us what to do with it to trigger the error, and then >> we >> > can see if it's something special about your package or Roxygen or a >> general >> > problem. >> > >> > Duncan Murdoch >> > >> > Thanks, >> >> >> >> Karl >> >> >> >> On Thu, Sep 16, 2010 at 6:11 PM, Karl Forner >> >> wrote: >> >> >> >> > Hello, >> >> > >> >> > I have a package with a namespace. Because I use Roxygen that >> >> overwrites >> >> > the NAMESPACE file each time it is run, I use a R/zzz.R file with >> >> > an .onLoad() and .onUnload() functions to take care of loading and >> >> > unloading my shared library. >> >> > >> >> > The problem: if I load my library from a local directory, then the >> >> > unloading of the package fails, e.g: >> >> > >> >> > # loads fine >> >> > >library(Foo, lib.loc=".Rcheck") >> >> > >> >> > >unloadNamespace("Foo") >> >> > Warning message: >> >> > .onUnload failed in unloadNamespace() for 'Foo', details: >> >> > call: library.dynam.unload("Foo", libpath) >> >> > error: shared library 'Foo' was not loaded >> >> > >> >> > # I traced it a little: >> >> > >library.dynam.unload("Foo", ".Rcheck/Foo") >> >> > Error in library.dynam.unload("Foo", ".Rcheck/Foo") : >> >> > shared library 'Foo' was not loaded >> >> > >> >> > # using an absolute path works >> >> > >library.dynam.unload("Foo", "/home/toto/.Rcheck/Foo") >> >> > >> >> > >> >> > So from what I understand, the problem is either that the relative >> >> libpath >> >> > is sent to the .onUnload() function instead of the absolute one, >> >> > or that library.dynam.unload() should be modified to handle the >> >> relative >> >> > paths. >> >> > >> >> > Am I missing something ? What should I do ? >> >> > >> >> > Thanks, >> >> > >> >> > >> >> > Karl >> >> > >> >> >> >> [[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
Re: [Rd] Possible bug or annoyance with library.dynam.unload()
On 22/09/2010 11:22 AM, Karl Forner wrote: Thanks Duncan for your suggestion. I could not find any package using dynamic library, namespaces and not the useDynLib pragma so I created a minimalistic package to demonstrate the problem. Please find attached a very small package foo (8.8k) Your package depends on Rcpp, so I didn't try it in the alpha version of 2.12.0 (Rcpp isn't available there in a Windows binary at the moment), but I did try it in R-patched. With one minor change to your script (the lib.loc needs to be "local", not "local/" on Windows), I can reproduce the problem, and it looks like a bug to me. Thanks for the report, I'll put it on the bugs page, and hopefully it will be fixed before the 2.12.0 release. Duncan Murdoch Steps to reproduce the problem: * unarchive it ( tar zxvf foo_0.1.tar.gz ) * cd foo * install it locally ( mkdir local; R CMD INSTALL -l local . ) * R > library(foo, lib.loc="local/") >.dynLibs() # there you should be able to see the foo.so lib, in my case /x05/people/m160508/workspace/foo/local/foo/libs/foo.so > unloadNamespace("foo") .onUnload, libpath= local/fooWarning message: .onUnload failed in unloadNamespace() for 'foo', details: call: library.dynam.unload("foo", libpath) error: shared library 'foo' was not loaded #The libpath that the .onUnload() gets is "local/foo". #This fails: >library.dynam.unload("foo", "local/foo") Error in library.dynam.unload("foo", "local/foo") : shared library 'foo' was not loaded # but if you use the absolute path it works: >library.dynam.unload("foo", "/x05/people/m160508/workspace/foo/local/foo") Karl On Tue, Sep 21, 2010 at 5:33 PM, Duncan Murdochwrote: > On 21/09/2010 10:38 AM, Karl Forner wrote: > >> Hello, >> >> I got no reply on this issue. >> It is not critical and I could think of work-around, but it really looks >> like a bug to me. >> Should I file a bug-report instead of posting in this list ? >> > > I'd probably post instructions for a reproducible example first. Pick some > CRAN package, tell us what to do with it to trigger the error, and then we > can see if it's something special about your package or Roxygen or a general > problem. > > Duncan Murdoch > > Thanks, >> >> Karl >> >> On Thu, Sep 16, 2010 at 6:11 PM, Karl Forner >> wrote: >> >> > Hello, >> > >> > I have a package with a namespace. Because I use Roxygen that >> overwrites >> > the NAMESPACE file each time it is run, I use a R/zzz.R file with >> > an .onLoad() and .onUnload() functions to take care of loading and >> > unloading my shared library. >> > >> > The problem: if I load my library from a local directory, then the >> > unloading of the package fails, e.g: >> > >> > # loads fine >> > >library(Foo, lib.loc=".Rcheck") >> > >> > >unloadNamespace("Foo") >> > Warning message: >> > .onUnload failed in unloadNamespace() for 'Foo', details: >> > call: library.dynam.unload("Foo", libpath) >> > error: shared library 'Foo' was not loaded >> > >> > # I traced it a little: >> > >library.dynam.unload("Foo", ".Rcheck/Foo") >> > Error in library.dynam.unload("Foo", ".Rcheck/Foo") : >> > shared library 'Foo' was not loaded >> > >> > # using an absolute path works >> > >library.dynam.unload("Foo", "/home/toto/.Rcheck/Foo") >> > >> > >> > So from what I understand, the problem is either that the relative >> libpath >> > is sent to the .onUnload() function instead of the absolute one, >> > or that library.dynam.unload() should be modified to handle the >> relative >> > paths. >> > >> > Am I missing something ? What should I do ? >> > >> > Thanks, >> > >> > >> > Karl >> > >> >> [[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] Possible bug or annoyance with library.dynam.unload()
Thanks Duncan for your suggestion. I could not find any package using dynamic library, namespaces and not the useDynLib pragma so I created a minimalistic package to demonstrate the problem. Please find attached a very small package foo (8.8k) Steps to reproduce the problem: * unarchive it ( tar zxvf foo_0.1.tar.gz ) * cd foo * install it locally ( mkdir local; R CMD INSTALL -l local . ) * R > library(foo, lib.loc="local/") >.dynLibs() # there you should be able to see the foo.so lib, in my case /x05/people/m160508/workspace/foo/local/foo/libs/foo.so > unloadNamespace("foo") .onUnload, libpath= local/fooWarning message: .onUnload failed in unloadNamespace() for 'foo', details: call: library.dynam.unload("foo", libpath) error: shared library 'foo' was not loaded #The libpath that the .onUnload() gets is "local/foo". #This fails: >library.dynam.unload("foo", "local/foo") Error in library.dynam.unload("foo", "local/foo") : shared library 'foo' was not loaded # but if you use the absolute path it works: >library.dynam.unload("foo", "/x05/people/m160508/workspace/foo/local/foo") Karl On Tue, Sep 21, 2010 at 5:33 PM, Duncan Murdoch wrote: > On 21/09/2010 10:38 AM, Karl Forner wrote: > >> Hello, >> >> I got no reply on this issue. >> It is not critical and I could think of work-around, but it really looks >> like a bug to me. >> Should I file a bug-report instead of posting in this list ? >> > > I'd probably post instructions for a reproducible example first. Pick some > CRAN package, tell us what to do with it to trigger the error, and then we > can see if it's something special about your package or Roxygen or a general > problem. > > Duncan Murdoch > > Thanks, >> >> Karl >> >> On Thu, Sep 16, 2010 at 6:11 PM, Karl Forner >> wrote: >> >> > Hello, >> > >> > I have a package with a namespace. Because I use Roxygen that >> overwrites >> > the NAMESPACE file each time it is run, I use a R/zzz.R file with >> > an .onLoad() and .onUnload() functions to take care of loading and >> > unloading my shared library. >> > >> > The problem: if I load my library from a local directory, then the >> > unloading of the package fails, e.g: >> > >> > # loads fine >> > >library(Foo, lib.loc=".Rcheck") >> > >> > >unloadNamespace("Foo") >> > Warning message: >> > .onUnload failed in unloadNamespace() for 'Foo', details: >> >call: library.dynam.unload("Foo", libpath) >> >error: shared library 'Foo' was not loaded >> > >> > # I traced it a little: >> > >library.dynam.unload("Foo", ".Rcheck/Foo") >> > Error in library.dynam.unload("Foo", ".Rcheck/Foo") : >> >shared library 'Foo' was not loaded >> > >> > # using an absolute path works >> > >library.dynam.unload("Foo", "/home/toto/.Rcheck/Foo") >> > >> > >> > So from what I understand, the problem is either that the relative >> libpath >> > is sent to the .onUnload() function instead of the absolute one, >> > or that library.dynam.unload() should be modified to handle the >> relative >> > paths. >> > >> > Am I missing something ? What should I do ? >> > >> > Thanks, >> > >> > >> > Karl >> > >> >>[[alternative HTML version deleted]] >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > foo_0.1.tar.gz Description: GNU Zip compressed data __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] some problems reported in 00check.log
On Wed, 22 Sep 2010, carol white wrote: So there is no sort of automatic way like using a markup command for the susceptible fields instead of splitting manually a line on different lines? Well, how is the automatic command to know how to do this? As you will see from the autmatic wrapping in e.g. deparse(), we are not able to do a very good job. There has been some talk about doing this automatically as a backstop, but I don't know the current state: in any case it does not happen in released versions of R. True that this doesn't happen in Arguments field (I confused with Format field). Also true that the codes used in Usage, Examples etc are in courrier. Is there any way to reduce the size and not to change the font of character for these fields? You can change Rd.sty, which already contains options for using other fontsets. Best, Carol --- On Wed, 9/22/10, Prof Brian Ripley wrote: From: Prof Brian Ripley Subject: Re: [Rd] some problems reported in 00check.log To: "carol white" Cc: "Uwe Ligges" , r-devel@r-project.org Date: Wednesday, September 22, 2010, 2:15 AM On Wed, 22 Sep 2010, carol white wrote: Thank you very much Uwe. It works now. I have a question about pdf formating in pdf manual file: How to format the long lines which go to the margin? For ex, this happens in Usage field if a function has many arguments. Also, it happens in examples or Arugment sections when the lines are long. Correct the sources by re-formatting over-long lines yourself. (This should only happen in verbatim-like sections, hence unlikely to happen in \argument{}.) One of the things we suggest when checking a package is to read through the PDF manual, and this is one of the problems to look out for. (Note that it does depend on the fonts used for the PDF, but the default Courier for monospaced text is somewhat wide.) -- 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, UK Fax: +44 1865 272595 -- 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
Re: [Rd] some problems reported in 00check.log
So there is no sort of automatic way like using a markup command for the susceptible fields instead of splitting manually a line on different lines? True that this doesn't happen in Arguments field (I confused with Format field). Also true that the codes used in Usage, Examples etc are in courrier. Is there any way to reduce the size and not to change the font of character for these fields? Best, Carol --- On Wed, 9/22/10, Prof Brian Ripley wrote: > From: Prof Brian Ripley > Subject: Re: [Rd] some problems reported in 00check.log > To: "carol white" > Cc: "Uwe Ligges" , r-devel@r-project.org > Date: Wednesday, September 22, 2010, 2:15 AM > On Wed, 22 Sep 2010, carol white > wrote: > > > Thank you very much Uwe. It works now. > > > > I have a question about pdf formating in pdf manual > file: > > > > How to format the long lines which go to the margin? > For ex, this happens in Usage field if a function has many > arguments. Also, it happens in examples or Arugment sections > when the lines are long. > > Correct the sources by re-formatting over-long lines > yourself. (This should only happen in verbatim-like > sections, hence unlikely to happen in \argument{}.) > > One of the things we suggest when checking a package is to > read through the PDF manual, and this is one of the problems > to look out for. (Note that it does depend on the > fonts used for the PDF, but the default Courier for > monospaced text is somewhat wide.) > > -- 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, UK > Fax: +44 1865 272595 > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] doc bug in ?residuals.gls
On Tue, 14 Sep 2010, Ben Bolker wrote: Under the description of the 'type' argument, ?residuals.gls says 'Defaults to ‘"pearson"’.' But residuals.gls starts residuals.gls <- function(object, type = c("response", "pearson", "normalized"), ...) { type <- match.arg(type) ... which sure looks to me like it defaults to "response", not "pearson" (and it behaves that way in tests). It would seem to make more sense to change the documentation rather than the code since anyone who looked at the docs would have been confused already, whereas someone who had been happily using the code without looking at the docs would see a sudden change in the results ... This is in nlme 3.1-96, from a fresh tools/rsync-recommended. Sending it to r-devel for comment because r-core is listed as the maintainer. Whereas bug reports should be sent to the maintainer or (for packages maintained by R-core) R-bugs. The SVN version of nlme has BugReports: http://bugs.r-project.org since reports here are easily overlooked. I've changed the SVN sources, but most likely a new release of nlme will be made only when something substantive is changed. -- 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
Re: [Rd] some problems reported in 00check.log
On Wed, 22 Sep 2010, carol white wrote: Thank you very much Uwe. It works now. I have a question about pdf formating in pdf manual file: How to format the long lines which go to the margin? For ex, this happens in Usage field if a function has many arguments. Also, it happens in examples or Arugment sections when the lines are long. Correct the sources by re-formatting over-long lines yourself. (This should only happen in verbatim-like sections, hence unlikely to happen in \argument{}.) One of the things we suggest when checking a package is to read through the PDF manual, and this is one of the problems to look out for. (Note that it does depend on the fonts used for the PDF, but the default Courier for monospaced text is somewhat wide.) -- 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
Re: [Rd] some problems reported in 00check.log
Thank you very much Uwe. It works now. I have a question about pdf formating in pdf manual file: How to format the long lines which go to the margin? For ex, this happens in Usage field if a function has many arguments. Also, it happens in examples or Arugment sections when the lines are long. Best, Carol __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] OT: Reason/history behind ## notation for comments?
For what concerns emacs users, the number of '#' has different effects on the position of the comment. From the ESS manual: 'By default, comments beginning with ‘###’ are aligned to the beginning of the line. Comments beginning with ‘##’ are aligned to the current level of indentation for the block containing the comment. Finally, comments beginning with ‘#’ are aligned to a column on the right...'. I guess that ## is the most wanted indentation for comments. Best wishes, Laurent On 22 September 2010 07:26, Henrik Bengtsson wrote: > Off topic, but since I've observe both styles, does anyone know the > history behind/reason for using ## instead of a single # to start > comments in R. I know some editors do this by default. Is it because > in C it is easier to distinguish (search/replace/...) comments from C > preprocessor directives such as #include, and that's became a de facto > standard elsewhere? > > /Henrik > > PS. I don't want to get into a debate on what's the best style. > > __ > 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