Re: [Rd] Dynamic linking to binary code from other packages??
On Nov 12, 2008, at 23:16 , Jeff Ryan wrote:
Charles,
I've looked through the Writing R Extensions manual, and can't find
this documented very clearly. A previous question to the list gave
me
the very kind response pasted below. I've looked at the suggested
examples (lme4 using C functions from Matrix).
It isn't really clearly explained. I will give it a try though.
You can't use compiled/packaged functions from within _your_ compiled
code unless the package that you are referring to (affxparser) makes
them available for export.
If affxparser doesn't do this you are back to Dirk's method.
For the sake of others who have gone down this road I will explain
what I know, and probably in the process learn what I may be doing
wrong. (all of this I learned by reading the sources for R and lme4
and Matrix).
Matrix has a copy of the Matrix.h header in its /inst directory,
specifically /inst/include/Matrix.h
This gets installed as /include/Matrix.h, which is where LinkingTo
links to during compilation.
You (or the affxparser author) will also need a handful of C calls
that are complementary to ones in the package you are getting the
functions from.
An example from Matrix:
/include/Matrix_stubs.c contains
...
CHM_DN attribute_hidden
M_as_cholmod_dense(CHM_DN ans, SEXP x)
{
static CHM_DN(*fun)(CHM_DN,SEXP) = NULL;
if(fun == NULL)
fun = (CHM_DN(*)(CHM_DN,SEXP))
R_GetCCallable(Matrix, as_cholmod_dense);
return fun(ans, x);
}
...
FWIW this is not exactly the most efficient way to do it. It's much
easier to do it the commonly used way of setting the function pointers
directly (taking the situation above):
CHM_DN(*M_as_cholmod_dense)(CHM_DN,SEXP);
in the initialization function of the package populate all the pointers:
M_as_cholmod_dense = (CHM_DN(*)(CHM_DN,SEXP)) R_GetCCallable(Matrix,
as_cholmod_dense);
By setting the functions right away you save yourself the trouble of
checking it on every call and using a function call twice. This allows
you to use the function transparently in your code, so you don' t need
any function wrappers:
x = M_as_cholmod_dense(a, b);
This is pretty much standard C programming, so the above should be
quite obvious (I hope).
The only reason to do it the complicated way above is if you want to
do some extra processing in the wrapper function so your function
pointer is not visible from outside the function.
Cheers,
Simon
The above is far from obvious, so I will try my best to explain.
With respect to the R_GetCCallable call, Writing R Extensions says:
p_myCfun = R_GetCCallable(packA, myCfun);
The author of packB is responsible for ensuring that p_myCfun has an
appropriate declaration. What exactly that means was hard to determine
at first.
Taking the first line, the first CHM_DN is the function return type
(could be int, SEXP, etc), and the second (along with the SEXP) is the
argument type(s).
Generalized you'd have something like:
SEXP attribute_hidden
FUNNAME(SEXP ans, SEXP x)
{
static SEXP(*fun)(SEXP,SEXP) = NULL;
if(fun == NULL)
fun = (SEXP(*)(SEXP,SEXP))
R_GetCCallable(PACKAGE, FUNCTION);
return fun(ans, x);
}
lme4 then simply #includes this .c file in a file
/src/local_stubs.c, which is compiled right along side of the src code
in lme4.
At this point you can then use the functions that are
'exported/registered' as you would a C function defined in your own
package.
The other side of this is what the Matrix (affxparser?) package needs
to do. It needs a registration routine that specifically registers
the routines as callable using:
R_RegisterCCallable (which is documented in Writing R Extensions)
In Matrix this is in /src/init.c via a macro.
A simpler in-progress bit of code can be found in the /dev branch of
xts on R-forge. Take a look at
http://r-forge.r-project.org/scm/?group_id=118
/dev/src/init.c
/dev/inst/include/xts.h
/dev/inst/include/xts_stubs.c
As far as C++ goes, I would suspect the Matrix package again has all
the bits you are looking for.
HTH
Jeff
--
Jeffrey Ryan
[EMAIL PROTECTED]
ia: insight algorithmics
www.insightalgo.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
[Rd] Experimental Rd parser in trunk.
I've just committed the parse_Rd() function to R-devel. This is a parser for Rd files, described in http://developer.r-project.org/parseRd.pdf It is not identical to the current parser, and about a dozen of the base man pages currently signal syntax errors. It also detected errors in 10 files that were errors according to both definitions, but were missed by the current system, and I've already fixed those. I plan to patch the rest so that they work in both systems soon. The differences between the two systems are described in the document above. I would like to hear comments about the changes -- some of them are still optional. I will be continuing to work on support functions for the parser, e.g. the print routine is currently quite primitive. I expect there may be incompatibilities with platforms on which I haven't tested. I developed the parser on Windows, and have tested it on a Linux system. There may be problems handling Rd files with unusual encodings (UTF-8 and Latin1 should be supported, but I don't know about others, and haven't even tested those yet). Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] gfortran optimization problems
Bill and Mike, Thanks for your help. I think Mike was right about the 80-bit/64-bit compare. As Mike thought, the error occurs at a test for equality, i.e. if (x .ge. y) then I know better than to test reals for equality, but this is a closed interval test, and it still fails. if (x-y .gt. -0.1) worked. Bill, thanks for the tip on --ffloat-store. I tried gfortran -c alt_duleg.f gcc -std=gnu99 -ffloat-store -shared -L/usr/local/lib -o alt_duleg.so alt_duleg.o -lgfortran -lm -lgcc_s (standard R CMD SHLIB except for the addition of --float-store) and it seems to have cleared up the problem. I should have seen this coming, since I once had a comparison fail on a 4-byte real versus a double precision that I know are exactly the same in base10. To fix that I canged EVERYTHING to double precision, but I didn't see the register problem coning at all. Now I need to figure out how to implement a makefile for my package, but that's another story and easily solved I suspect. Thanks to everyone who took a stab at this one. I learned a lot. Sorry to have taken so long to get back to it, but other priorities demanded so. Dave David W. Roberts office 406-994-4548 Professor and Head FAX 406-994-3190 Department of Ecology email [EMAIL PROTECTED] Montana State University Bozeman, MT 59717-3460 William Dunlap wrote: -Original Message- From: William Dunlap Sent: Monday, November 03, 2008 8:34 AM To: 'Mike Prager'; '[EMAIL PROTECTED]' Subject: RE: [Rd] gfortran optimization problems ... Another common problem, in C or Fortran, is that optimization can result in a very small floating point number remaining in an 80-bit floating-point-unit register instead of being truncated to the 64-bits available in main memory. The difference in roundoff error can result in big differences in results if your algorithm is ill conditioned or has a test for an exact 0.0. Adding a debugging WRITE or printf statement generally causes the variable to be copied to 64-bit main memory. A quick way to see if using floating point registers or not affects your results is to add the gcc flag (probably a gfortran flag as well) '-ffloat-store'. 'man gcc' says: The following options control compiler behavior regarding floating point arithmetic. These options trade off between speed and correct- ness. All must be specifically enabled. -ffloat-store Do not store floating point variables in registers, and inhibit other options that might change whether a floating point value is taken from a register or memory. This option prevents undesirable excess precision on machines such as the 68000 where the floating registers (of the 68881) keep more precision than a double is supposed to have. Similarly for the x86 architecture. For most programs, the excess precision does only good, but a few programs rely on the precise definition of IEEE floating point. Use -ffloat-store for such programs, after modifying them to store all pertinent intermediate computations into variables. Bill Dunlap TIBCO Spotfire Inc wdunlap tibco.com -- David W. Roberts office 406-994-4548 Professor and Head FAX 406-994-3190 Department of Ecology email [EMAIL PROTECTED] Montana State University Bozeman, MT 59717-3460 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Experimental Rd parser in trunk.
On 11/13/2008 11:51 AM, Simon Urbanek wrote:
Duncan,
I had a quick look at the parsers differences and I'm worried about
points 1. and 2. (on p.6) -- does that imply that \R{} is illegal and
so is any \foo{} for any macro \foo that doesn't take any arguments?
IMHO that would be fatal (if I understand it correctly), since that
construct is very often used (and I know of no alternatives) in cases
where you are referencing a macro that is followed by something that
is not a space. E.g.: 1\foo{}2 cannot be written as 1\foo2 as per 6.
so if \foo{} is disallowed there is no way to call \foo between 1 and
2 when you don't want any spaces to be generated).
Maybe I'm just interpreting is incorrectly, so I just wanted to point
out that issue.
Thanks for the comment. You are interpreting it correctly, and that is
something that probably needs to change.
The reasoning behind the current choice is that macros with optional
arguments are ambiguous: for example, in R code, {} might be part of
the code, not something for the Rd parser. We currently have \eqn and
\deqn that have one or two args, but they're not going to occur in R
code, so things currently work. (But if you want to see ugly Bison
coding, look at how those VERBMACRO2 macros are handled. The Rd format
is not easy to parse, being a mix of latex-like stuff, R code, and just
about anything else in verbatim sections.)
So I'd really strongly prefer to say that \foo *always* requires an arg,
rather than let it be optional, if there are circumstances where it
needs one.
If we say that \foo never takes an arg, we'll need a way to distinguish
between the following space being significant or not. One way is to
allow {} or some other marker that signals a break without inserting
anything, and is only interpreted in Latex-like mode. Another way (that
I prefer) is described below.
We could relax things a lot, and allow balanced braces as no-ops in
Latex-like mode, but that will miss some typos. I fixed typos in 10
files in r46908, and at least one of those was caught this way, in
methods/man/Classes.Rd. It would also introduce an ambiguity, because
\eqn and \deqn *are* going to occur in Latex-like mode. So
\eqn{foo}{}bar
could be either the two-arg version or the one-arg version followed by a
no-op before the bar. (The default handling in Bison is that it would
be the two-op version.) And I think it would be tricky to write the
parser so that {} was handled differently in Latex-like mode from the
way it's handled in the other modes. (The other modes count braces and
echo them out.)
There are currently only 5 macros which take no args: \cr, \dots,
\ldots, \R, and \tab. I think the issue will only arise with \dots and
\ldots. So my preferred decision would be to push this up a level:
when the code is interpreted, \dots and \ldots are not followed by a
space. To allow for a user who wants a space, we should introduce a 6th
no-argument macro, \sp. Then 1\dots 10 will be rendered as 1...10
and 1\dots\sp 10 will be rendered as 1... 10.
Duncan Murdoch
Thanks,
Simon
On Nov 13, 2008, at 11:02 , Duncan Murdoch wrote:
I've just committed the parse_Rd() function to R-devel. This is a
parser for Rd files, described in
http://developer.r-project.org/parseRd.pdf
It is not identical to the current parser, and about a dozen of the
base man pages currently signal syntax errors. It also detected
errors in 10 files that were errors according to both definitions,
but were missed by the current system, and I've already fixed
those. I plan to patch the rest so that they work in both systems
soon. The differences between the two systems are described in the
document above.
I would like to hear comments about the changes -- some of them are
still optional. I will be continuing to work on support functions
for the parser, e.g. the print routine is currently quite primitive.
I expect there may be incompatibilities with platforms on which I
haven't tested. I developed the parser on Windows, and have tested
it on a Linux system. There may be problems handling Rd files with
unusual encodings (UTF-8 and Latin1 should be supported, but I don't
know about others, and haven't even tested those yet).
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] Experimental Rd parser in trunk.
Just one additional comment in line below:
On 11/13/2008 1:44 PM, Duncan Murdoch wrote:
On 11/13/2008 11:51 AM, Simon Urbanek wrote:
Duncan,
I had a quick look at the parsers differences and I'm worried about
points 1. and 2. (on p.6) -- does that imply that \R{} is illegal and
so is any \foo{} for any macro \foo that doesn't take any arguments?
IMHO that would be fatal (if I understand it correctly), since that
construct is very often used (and I know of no alternatives) in cases
where you are referencing a macro that is followed by something that
is not a space. E.g.: 1\foo{}2 cannot be written as 1\foo2 as per 6.
so if \foo{} is disallowed there is no way to call \foo between 1 and
2 when you don't want any spaces to be generated).
Maybe I'm just interpreting is incorrectly, so I just wanted to point
out that issue.
Thanks for the comment. You are interpreting it correctly, and that is
something that probably needs to change.
The reasoning behind the current choice is that macros with optional
arguments are ambiguous: for example, in R code, {} might be part of
the code, not something for the Rd parser. We currently have \eqn and
\deqn that have one or two args, but they're not going to occur in R
code, so things currently work. (But if you want to see ugly Bison
coding, look at how those VERBMACRO2 macros are handled. The Rd format
is not easy to parse, being a mix of latex-like stuff, R code, and just
about anything else in verbatim sections.)
So I'd really strongly prefer to say that \foo *always* requires an arg,
rather than let it be optional, if there are circumstances where it
needs one.
If we say that \foo never takes an arg, we'll need a way to distinguish
between the following space being significant or not. One way is to
allow {} or some other marker that signals a break without inserting
anything, and is only interpreted in Latex-like mode. Another way (that
I prefer) is described below.
I should say that allowing {} to immediately follow one of the 5 no-arg
macros, and having it gobbled up by the lexer, would be relatively easy
to implement. So then the two examples below could be coded as
1\dots{}10 versus 1\dots 10, which is I think what you were asking
for. I have a mild preference for adding \sp (I don't like special
cases), but not a strong one.
Duncan Murdoch
We could relax things a lot, and allow balanced braces as no-ops in
Latex-like mode, but that will miss some typos. I fixed typos in 10
files in r46908, and at least one of those was caught this way, in
methods/man/Classes.Rd. It would also introduce an ambiguity, because
\eqn and \deqn *are* going to occur in Latex-like mode. So
\eqn{foo}{}bar
could be either the two-arg version or the one-arg version followed by a
no-op before the bar. (The default handling in Bison is that it would
be the two-op version.) And I think it would be tricky to write the
parser so that {} was handled differently in Latex-like mode from the
way it's handled in the other modes. (The other modes count braces and
echo them out.)
There are currently only 5 macros which take no args: \cr, \dots,
\ldots, \R, and \tab. I think the issue will only arise with \dots and
\ldots. So my preferred decision would be to push this up a level:
when the code is interpreted, \dots and \ldots are not followed by a
space. To allow for a user who wants a space, we should introduce a 6th
no-argument macro, \sp. Then 1\dots 10 will be rendered as 1...10
and 1\dots\sp 10 will be rendered as 1... 10.
Duncan Murdoch
Thanks,
Simon
On Nov 13, 2008, at 11:02 , Duncan Murdoch wrote:
I've just committed the parse_Rd() function to R-devel. This is a
parser for Rd files, described in
http://developer.r-project.org/parseRd.pdf
It is not identical to the current parser, and about a dozen of the
base man pages currently signal syntax errors. It also detected
errors in 10 files that were errors according to both definitions,
but were missed by the current system, and I've already fixed
those. I plan to patch the rest so that they work in both systems
soon. The differences between the two systems are described in the
document above.
I would like to hear comments about the changes -- some of them are
still optional. I will be continuing to work on support functions
for the parser, e.g. the print routine is currently quite primitive.
I expect there may be incompatibilities with platforms on which I
haven't tested. I developed the parser on Windows, and have tested
it on a Linux system. There may be problems handling Rd files with
unusual encodings (UTF-8 and Latin1 should be supported, but I don't
know about others, and haven't even tested those yet).
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
Re: [Rd] Experimental Rd parser in trunk.
A couple more comments on the \dots problem:
1. Allowing {} after \dots is unsatisfactory, because the current
parser will render the braces, i.e. 1\dots{}10 is rendered as 1..{}10.
I'd like to have enough back-compatibility that it is possible to
rewrite a man page to work in either system.
2. I could change the rules for what ends a markup macro, to allow only
alphabetic chars in one, so that 1\dots10 is legal again. This would
require changing or making exceptions for \linkS4class, \S3method, and
\S4method, because they contain digits. I think this would rule out
ever creating macros \linkS or \S because of the ambiguity; the latter
might be a worry.
So I'm still leaning towards adding \sp...
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Documentation error in Writing R Extensions (PR#13282)
Full_Name: Peter K Dunn Version: NA OS: NA Submission from: (NULL) (203.29.106.59) Reading the manual Writing R Extensions, the html and pdf versions both contain important typos in Section 1.10. As an example: An installed file named CTIATION will be used by the citation() function. .. The word CTIATION presumably should be CITATION. This occurs four times in Section 1.10, even though the section is called CITATION files. P. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R crashes on sprintf with bad format specification (PR#13283)
Full_Name: Oren Cheyette Version: 2.7.2 OS: Win XP Submission from: (NULL) (64.161.123.194) Enter the following at the R command prompt: sprintf(A %S %S %S XYZ, 1, 1, 1); Note the erroneous capitalized %S instead of %s and the numeric inputs instead of strings. With strings there's no crash - R reports bad format specifications. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Package install problem on Windows (PR#13284)
Thanks for the response. Are the problems with versioned installs fundamental, or are they just a case of incomplete implementation and rough edges? If the latter, would fixes be considered? I ask because we would find versioned installs very useful in maintaining stable production systems, each of which might run with different versions of various packages, while making it easy to continually develop and refine our packages. As a point of info, our primary use for versioning would be with our own packages, so we could probably get away without using versioned installs for base or contributed packages. However, if the problems with versioned installs are not amenable to the kinds of fixes that users can contribute, then I guess we should look for a different approach. Suggestions and comments are welcome! Do many people use versioned installs? -- Tony Plate (coworker of Lars @ blackmesacapital.com) Prof Brian Ripley wrote: Installing versioned packages is not supported with namespaces. I have suggested from time to time that versioned installs be removed because of this and other known issues, and recommend that you do not attempt to use them. On Thu, 13 Nov 2008, [EMAIL PROTECTED] wrote: Full_Name: Lars Hansen Version: 2.8.0 OS: Windows XP Pro x64 SP2 Submission from: (NULL) (71.39.177.36) Hi, I have run into a problem using R CMD INSTALL with the --with-package-versions option under Windows. It is a bit obscure, which could explain why other people have not run into it. We happen to have two packages with almost the same name. One name is a subset of the other. The names are RtTests and RtTestsEG1. I have no problem installing RtTests and many other packages, but run into problems installing RtTestsEG1. The RtTestsEG1 package happens to be a simple example of how to use the RtTests package, so it depends on RtTests (which is probably the problem). OK, so this is what happens when I attempt to install RtTestsEG1: $ R CMD INSTALL --with-package-versions --library=$R_LIBS RtTestsEG1 installing RtTestsEG1 package -- Making package RtTestsEG1 adding build stamp to DESCRIPTION installing R files preparing package RtTestsEG1 for lazy loading Loading required package: RtTests ... [lost of lines removed] Loading required package: RtTests Error: evaluation nested too deeply: infinite recursion / options(expressions=)? Execution halted make[2]: *** [lazyload] Error 1 make[1]: *** [all] Error 2 make: *** [pkg-RtTestsEG1] Error 2 *** Installation of RtTestsEG1 failed *** After some digging in the Windows makefiles, I found out that changing the locale from C to us in the lazyload target of $R_HOME/src/gnuwin32/MakePkg, i.e. using LC_ALL=us instead of LC_ALL=C, solves the infinite recursion problem and give an useful message. It still fails but now says: Loading required package: RtTests Warning: S3 methods 'summary.RtTestSetResults', 'print.RtTestSetResults', 'print.RtTestSetResults.summary' were declared in NAMESPACE but not found Error in namespaceExport(ns, exports) : undefined exports: parseTranscriptFile, compareTranscriptAndOutput Error: package 'RtTests' could not be loaded Execution halted It is true that RtTests declares the various functions in its name space, but why can they suddenly not be found? If I load RtTests by itself, i.e. library(RtTests), there is no problem. I happen to have all this working under Linux, so I tracked down the difference. Turns out that under Linux the equivalent to the lazyload target is in /usr/lib/R/bin/INSTALL and the difference is in the argument passed to tools:::makeLazyLoading. Under Linux the full package name with version number is used, i.e. RtTests_0.1-1. Windows just uses RtTests. So I managed to fix the problem by making Windows use the full package name in the lazyload target. I replaced tools:::makeLazyLoading(\$(PKG)\ with tools:::makeLazyLoading(\$(notdir $(DPKG))\ If I now reinstall RtTests, I can finally install RtTestsEG1. I must confess, that I do not fully understand exactly what it takes to reproduce this problem. I am guessing that all it takes is a package depending on a versioned package. Maybe the similarity in names introduces a problem because of partial matching. I am guessing that has nothing to do with it. To sum up the report. I see two problems: 1) LC_ALL=C causes infinite recursion. It is as if the C locale does not work under Windows. I do not know what the fix is. It is used many places in install scripts and makefiles. Fixing it in the lazyload target is not enough. Even with my change I still get infinite recursion and no error message if I try to install RtTestsEG1 without first installing RtTests. 2) makeLazyLoading() in lazyload target needs to be called with full package name with embedded version number. I think this is bug under Windows and my fix takes care of it. It took some time to figure this out. I am hoping this
Re: [Rd] Package install problem on Windows (PR#13284)
On Nov 13, 2008, at 6:11 PM, Tony Plate wrote: Thanks for the response. Are the problems with versioned installs fundamental, or are they just a case of incomplete implementation and rough edges? If the latter, would fixes be considered? I ask because we would find versioned installs very useful in maintaining stable production systems, each of which might run with different versions of various packages, while making it easy to continually develop and refine our packages. As a point of info, our primary use for versioning would be with our own packages, so we could probably get away without using versioned installs for base or contributed packages. I find it more useful to work with multiple library paths (.libPaths()) than versioning packages in the above scenario. We usually maintain stable package library which is individually overridden by additional paths added by the user (e.g. developer library for testing) and/or subsystems. The override can also be revertive, i.e. a subsystem is free to use older packages in its library than the stable library when desired. Cheers, S However, if the problems with versioned installs are not amenable to the kinds of fixes that users can contribute, then I guess we should look for a different approach. Suggestions and comments are welcome! Do many people use versioned installs? -- Tony Plate (coworker of Lars @ blackmesacapital.com) Prof Brian Ripley wrote: Installing versioned packages is not supported with namespaces. I have suggested from time to time that versioned installs be removed because of this and other known issues, and recommend that you do not attempt to use them. On Thu, 13 Nov 2008, [EMAIL PROTECTED] wrote: Full_Name: Lars Hansen Version: 2.8.0 OS: Windows XP Pro x64 SP2 Submission from: (NULL) (71.39.177.36) Hi, I have run into a problem using R CMD INSTALL with the --with-package-versions option under Windows. It is a bit obscure, which could explain why other people have not run into it. We happen to have two packages with almost the same name. One name is a subset of the other. The names are RtTests and RtTestsEG1. I have no problem installing RtTests and many other packages, but run into problems installing RtTestsEG1. The RtTestsEG1 package happens to be a simple example of how to use the RtTests package, so it depends on RtTests (which is probably the problem). OK, so this is what happens when I attempt to install RtTestsEG1: $ R CMD INSTALL --with-package-versions --library=$R_LIBS RtTestsEG1 installing RtTestsEG1 package -- Making package RtTestsEG1 adding build stamp to DESCRIPTION installing R files preparing package RtTestsEG1 for lazy loading Loading required package: RtTests ... [lost of lines removed] Loading required package: RtTests Error: evaluation nested too deeply: infinite recursion / options(expressions=)? Execution halted make[2]: *** [lazyload] Error 1 make[1]: *** [all] Error 2 make: *** [pkg-RtTestsEG1] Error 2 *** Installation of RtTestsEG1 failed *** After some digging in the Windows makefiles, I found out that changing the locale from C to us in the lazyload target of $R_HOME/src/gnuwin32/MakePkg, i.e. using LC_ALL=us instead of LC_ALL=C, solves the infinite recursion problem and give an useful message. It still fails but now says: Loading required package: RtTests Warning: S3 methods 'summary.RtTestSetResults', 'print.RtTestSetResults', 'print.RtTestSetResults.summary' were declared in NAMESPACE but not found Error in namespaceExport(ns, exports) : undefined exports: parseTranscriptFile, compareTranscriptAndOutput Error: package 'RtTests' could not be loaded Execution halted It is true that RtTests declares the various functions in its name space, but why can they suddenly not be found? If I load RtTests by itself, i.e. library(RtTests), there is no problem. I happen to have all this working under Linux, so I tracked down the difference. Turns out that under Linux the equivalent to the lazyload target is in /usr/lib/R/bin/INSTALL and the difference is in the argument passed to tools:::makeLazyLoading. Under Linux the full package name with version number is used, i.e. RtTests_0.1-1. Windows just uses RtTests. So I managed to fix the problem by making Windows use the full package name in the lazyload target. I replaced tools:::makeLazyLoading(\$(PKG)\ with tools:::makeLazyLoading(\$(notdir $(DPKG))\ If I now reinstall RtTests, I can finally install RtTestsEG1. I must confess, that I do not fully understand exactly what it takes to reproduce this problem. I am guessing that all it takes is a package depending on a versioned package. Maybe the similarity in names introduces a problem because of partial matching. I am guessing that has nothing to do with it. To sum up the report. I see two problems: 1) LC_ALL=C causes infinite recursion. It is as if the C locale does
Re: [Rd] R crashes on sprintf with bad format specification (PR#13283)
On 12/11/2008 8:30 PM, [EMAIL PROTECTED] wrote:
Full_Name: Oren Cheyette
Version: 2.7.2
OS: Win XP
Submission from: (NULL) (64.161.123.194)
Enter the following at the R command prompt:
sprintf(A %S %S %S XYZ, 1, 1, 1);
Note the erroneous capitalized %S instead of %s and the numeric inputs instead
of strings. With strings there's no crash - R reports bad format
specifications.
2.7.2 is obsolete, but I can confirm a crash on Windows with a recent
R-devel.
The last few entries in the stack dump at the time of the crash are
shown below; these make it look as though the problem is in the Trio
library, so it may be hard to fix.
Duncan Murdoch
Rgui.exe caused an Access Violation at location 6c913fb3 in module R.dll
Reading from location 0001.
Registers:
eax=7fff ebx= ecx=00e17b21 edx=0001 esi=00e1c83b
edi=000a
eip=6c913fb3 esp=00e17944 ebp=00e17b3c iopl=0 nv up ei pl nz na
po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=
efl=0206
Call stack:
6C913FB3 R.dll:6C913FB3 TrioFormatProcess trio.c:2724
...
while (length 0)
{
size = TrioWriteWideStringCharacter(self, *wstring++, flags,
length);
if (size == 0)
break; /* while */
...
6C916592 R.dll:6C916592 trio_vsprintf trio.c:3771
...
return status;
status = TrioFormatProcess(data, format, parameters);
if (data.error != 0)
{
...
6C911F62 R.dll:6C911F62 sprintf compat.c:46
...
va_end(ap);
return res;
}
...
6C889F1E R.dll:6C889F1E do_sprintf sprintf.c:297
...
sprintf(bit, fmtp, NaN);
else
sprintf(bit, fmtp, NaN);
} else if (x == R_PosInf) {
if (strcspn(fmtp, +) strlen(fmtp))
...
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Documentation error in Writing R Extensions (PR#13282)
On 12/11/2008 6:05 PM, [EMAIL PROTECTED] wrote: Full_Name: Peter K Dunn Version: NA OS: NA Submission from: (NULL) (203.29.106.59) Reading the manual Writing R Extensions, the html and pdf versions both contain important typos in Section 1.10. As an example: An installed file named ‘CTIATION’ will be used by the citation() function. .. The word CTIATION presumably should be CITATION. This occurs four times in Section 1.10, even though the section is called CITATION files. Thanks, I'll fix those. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R crashes on sprintf with bad format specification (PR#13283)
* On 2008-11-13 at 18:51 -0500 Duncan Murdoch wrote: On 12/11/2008 8:30 PM, [EMAIL PROTECTED] wrote: Full_Name: Oren Cheyette Version: 2.7.2 OS: Win XP Submission from: (NULL) (64.161.123.194) Enter the following at the R command prompt: sprintf(A %S %S %S XYZ, 1, 1, 1); Note the erroneous capitalized %S instead of %s and the numeric inputs instead of strings. With strings there's no crash - R reports bad format specifications. 2.7.2 is obsolete, but I can confirm a crash on Windows with a recent R-devel. Can confirm as well on OSX with a fairly recent R-devel. (gdb) bt 10 #0 0x9575e299 in _UTF8_wcsnrtombs () #1 0x957bb3a0 in wcsrtombs_l () #2 0x956ebc1e in __vfprintf () #3 0x95711e66 in sprintf () #4 0x00492bb8 in do_sprintf (call=0x10cb470, op=0x1018924, args=value temporarily unavailable, due to optimizations, env=0x10a40b0) at ../../../../R-devel-all/src/main/sprintf.c:179 #5 0x003fe1af in do_internal (call=0x10cb4a8, op=0x100fc38, args=0x10a40e8, env=0x10a40b0) at ../../../../R-devel-all/src/main/names.c:1140 + seth -- Seth Falcon | http://userprimary.net/user/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R crashes on sprintf with bad format specification (PR#13285)
* On 2008-11-13 at 18:51 -0500 Duncan Murdoch wrote: On 12/11/2008 8:30 PM, [EMAIL PROTECTED] wrote: Full_Name: Oren Cheyette Version: 2.7.2 OS: Win XP Submission from: (NULL) (64.161.123.194) Enter the following at the R command prompt: sprintf(A %S %S %S XYZ, 1, 1, 1); Note the erroneous capitalized %S instead of %s and the numeric inputs instead of strings. With strings there's no crash - R reports bad format specifications. 2.7.2 is obsolete, but I can confirm a crash on Windows with a recent R-devel. Can confirm as well on OSX with a fairly recent R-devel. (gdb) bt 10 #0 0x9575e299 in _UTF8_wcsnrtombs () #1 0x957bb3a0 in wcsrtombs_l () #2 0x956ebc1e in __vfprintf () #3 0x95711e66 in sprintf () #4 0x00492bb8 in do_sprintf (call=0x10cb470, op=0x1018924, args=value temporarily unavailable, due to optimizations, env=0x10a40b0) at ../../../../R-devel-all/src/main/sprintf.c:179 #5 0x003fe1af in do_internal (call=0x10cb4a8, op=0x100fc38, args=0x10a40e8, env=0x10a40b0) at ../../../../R-devel-all/src/main/names.c:1140 + seth -- Seth Falcon | http://userprimary.net/user/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] multiple item lists in value section of *.Rd
Hi,
If an *.Rd file documents more than one object, and each object returns
several objects, which should ideally be described in an itemized list.
When documenting single objects, I've been doing this using simple
\item(s) inside the value section, like:
\value{This function returns:
\item{1st}{one}
\item{2nd}{two.}
}
How should more than one itemized list be written? The manual says that
a small introductory phrase can precede the \item(s), but it doesn't
show what to do when we have 2 lists, requiring 2 introductory phrases.
Something like:
\value{One function returns:
\item{1st}{one}
\item{2nd}{two.}
Another function returns:
\item{1st}{one}
\item{2nd}{two.}
}
Any suggestions welcome.
Cheers,
--
Seb
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] grid error: protection stack overflow
I have isolated an error that can be reproduced by the following code.
The same thing happens in 2.8.0pat and 2.9.0dev. It looks like the
try() code is ending up in the display list, or something?
library(grid)
library(lattice)
xyplot(1:100 ~ 1:100)
test - try(downViewport(pageAnnotationVp), silent = TRUE)
downViewport(trellis.vpname(toplevel))
pushViewport(viewport(name = pageAnnotationVp, yscale = c(1, 0)))
upViewport(0)
## resize device to trigger a couple of redraws...
Error: protect(): protection stack overflow
Enter a frame number, or 0 to exit
1: no.children(environment)
2: ls(children, all.names = TRUE)
3: try(name)
4: tryCatch(expr, error = function(e) {
5: tryCatchList(expr, classes, parentenv, handlers)
6: tryCatchOne(expr, names, parentenv, handlers[[1]])
7: doTryCatch(return(expr), name, parentenv, handler)
sessionInfo()
R version 2.8.0 Patched (2008-11-10 r46884)
i386-pc-mingw32
locale:
LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MONETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252
attached base packages:
[1] grid stats graphics grDevices utils datasets
methods base
other attached packages:
[1] lattice_0.17-15
--
Felix Andrews / 安福立
http://www.neurofractal.org/felix/
3358 543D AAC6 22C2 D336 80D9 360B 72DD 3E4C F5D8
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
