[Rd] OT: Reason/history behind ## notation for comments?
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
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 h...@stat.berkeley.edu 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
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] 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] 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
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 rip...@stats.ox.ac.uk wrote:
From: Prof Brian Ripley rip...@stats.ox.ac.uk
Subject: Re: [Rd] some problems reported in 00check.log
To: carol white wht_...@yahoo.com
Cc: Uwe Ligges lig...@statistik.tu-dortmund.de, 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] 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 rip...@stats.ox.ac.uk wrote:
From: Prof Brian Ripley rip...@stats.ox.ac.uk
Subject: Re: [Rd] some problems reported in 00check.log
To: carol white wht_...@yahoo.com
Cc: Uwe Ligges lig...@statistik.tu-dortmund.de, 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] 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 murdoch.dun...@gmail.comwrote: 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 Fornerkarl.for...@gmail.com 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] 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 Murdochmurdoch.dun...@gmail.comwrote: 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 Fornerkarl.for...@gmail.com 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()
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 Murdochmurdoch.dun...@gmail.com 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 Fornerkarl.for...@gmail.com 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] 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()
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 Murdochmurdoch.dun...@gmail.comwrote: 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 Fornerkarl.for...@gmail.com 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-}, )
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] 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
