Re: [Rd] Strange number produced by dnorm

[Martin Becker]

Hi,

I think the only thing that's wrong is "%d" in your printf statement, 
shouldn't it be "%f"? ("%d" is used for decimal (integer) numbers, "%f" 
for float (double) numbers)

Regards,

  Martin

Tong Wang wrote:
> Hi All,
> I just started to learn compiling C codes for R usage, and got a problem 
> when I was playing with my 'hello world' code. 
>   
> #include 
> #include 
> #include 
>
> SEXP test( ) {
>   double x;
>   x=dnorm(1.0,0.0,1.0,1);
>   printf(" x value is: %d \n",x);
>   return(R_NilValue);
> }
>
>I got the result :x value is: -466460838 
>
> Could someone explain to me what was wrong here ?
>
> Thanks a lot. 
>
> tong
>
> __
> 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] Strange number produced by dnorm

[Prof Brian Ripley]

On Tue, 3 Apr 2007, Tong Wang wrote:

> Hi All,

>I just started to learn compiling C codes for R usage, and got a 
> problem when I was playing with my 'hello world' code.
>
> #include 
> #include 
> #include 
>
> SEXP test( ) {
>  double x;
>  x=dnorm(1.0,0.0,1.0,1);
>  printf(" x value is: %d \n",x);
>  return(R_NilValue);
> }
>
>   I got the result :x value is: -466460838
>
> Could someone explain to me what was wrong here ?

double value, integer format (you want %g).
[Also, using printf not Rprintf.]

Please do make use of the ability if your compiler to tell you this.
You haven't told us your platform, but if it is still Windows XP, you 
want to add -Wall -pedantic to your CFLAGS.

-- 
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R callbacks

[Prof Brian Ripley]

On Tue, 3 Apr 2007, Deepayan Sarkar wrote:

> On 4/3/07, Simon Urbanek <[EMAIL PROTECTED]> wrote:
>> On Apr 2, 2007, at 8:51 PM, Deepayan Sarkar wrote:
>>
>>> Hi,
>>>
>>> I'm trying to understand (mostly from the R-exts manual) how to use
>>> the callbacks declared in Rinterface.h. As a first attempt, I'm trying
>>> to redefine ptr_R_WriteConsole in a very trivial manner. Here's my
>>> code:
>>>
>>> ---
>>> $ cat altr.c
>>>
>>> int Rf_initialize_R(int ac, char **av);
>>>
>>> #define R_INTERFACE_PTRS 1
>>> #include 
>>>
>>> extern int R_running_as_main_program;
>>>
>>> static void my_R_WriteConsole(char *buf, int len)
>>> {
>>> printf("R<< %s", buf);
>>> }
>>>
>>> int main(int ac, char **av)
>>> {
>>> R_running_as_main_program = 1;
>>> ptr_R_WriteConsole = my_R_WriteConsole;
>>> Rf_initialize_R(ac, av);
>>> Rf_mainloop();
>>> return 0;
>>> }
>>> ---
>>>
>>> I compile and run this in bash with
>>>
>>>
>>> RPROG=R
>>>
>>> INC=`${RPROG} CMD config --cppflags`
>>> LDF=`${RPROG} CMD config --ldflags`
>>> export LD_LIBRARY_PATH=`${RPROG} RHOME`/lib
>>> gcc -o altr ${INC} ${LDF} altr.c
>>>
>>> ${RPROG} CMD ./altr
>>>
>>> However, my customized version seems not to be used. What am I
>>> missing?
>>>
>>
>> 1) see Byron's e-mail
>> 2) by default R uses stdout/err connections instead of the console
>> API, you need to disable that
>>
>> so the resulting code should look like this:
>>
>>  Rf_initialize_R(ac, av);
>>  ptr_R_WriteConsole = my_R_WriteConsole;
>>  R_Outputfile = NULL;
>>  R_Consolefile = NULL;
>>  Rf_mainloop();
>
> Thanks, setting things to NULL was the critical piece (I had tried
> Byron's suggestion myself). A note mentioning this in R-exts would be
> helpful.

Done for 2.5.0.

-- 
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Strange number produced by dnorm

[Peter Dalgaard]

Tong Wang wrote:
> Hi All,
> I just started to learn compiling C codes for R usage, and got a problem 
> when I was playing with my 'hello world' code. 
>   
> #include 
> #include 
> #include 
>
> SEXP test( ) {
>   double x;
>   x=dnorm(1.0,0.0,1.0,1);
>   printf(" x value is: %d \n",x);
>   return(R_NilValue);
> }
>
>I got the result :x value is: -466460838 
>
> Could someone explain to me what was wrong here ?
>
>   
Wrong printf format. "%d" is for integers.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] source(..., echo=TRUE) broken in R-2.5.0 alpha and in R-2.6.0 devel

[Martin Maechler]

> "Herve" == Herve Pages <[EMAIL PROTECTED]>
> on Tue, 03 Apr 2007 11:29:25 -0700 writes:

Herve> Hi, I get this error with R-2.5.0 alpha and R-2.6.0
Herve> devel:

>> source("http://bioconductor.org/biocLite.R";, echo=TRUE)
Herve>   Error in if (timestamp != srcfile$timestamp)
Herve> warning("Timestamp of '", : missing value where TRUE/FALSE needed

Indeed, there's a bug 
 iff both 'echo' is TRUE and the ``file'' that is sourced is not
 a proper file (but e.g. a http:// connection).

It looks like the current code in source() and some of its
helper functions such as getSrcLines()
have not yet been "robustified" to work correctly in such a case.

We (R-core) will look at a patch ASAP.

Herve> Same with 'verbose=TRUE':

yes, since that automatically uses  echo = TRUE

 [...]

Herve> The above works fine with R-2.4.1.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] source(..., echo=TRUE) broken in R-2.5.0 alpha and in R-2.6.0 devel

[Duncan Murdoch]

On 4/4/2007 5:21 AM, Martin Maechler wrote:
>> "Herve" == Herve Pages <[EMAIL PROTECTED]>
>> on Tue, 03 Apr 2007 11:29:25 -0700 writes:
> 
> Herve> Hi, I get this error with R-2.5.0 alpha and R-2.6.0
> Herve> devel:
> 
> >> source("http://bioconductor.org/biocLite.R";, echo=TRUE)
> Herve>   Error in if (timestamp != srcfile$timestamp)
> Herve> warning("Timestamp of '", : missing value where TRUE/FALSE needed
> 
> Indeed, there's a bug 
>  iff both 'echo' is TRUE and the ``file'' that is sourced is not
>  a proper file (but e.g. a http:// connection).
> 
> It looks like the current code in source() and some of its
> helper functions such as getSrcLines()
> have not yet been "robustified" to work correctly in such a case.
> 
> We (R-core) will look at a patch ASAP.
> 
> Herve> Same with 'verbose=TRUE':
> 
> yes, since that automatically uses  echo = TRUE
> 
>  [...]
> 
> Herve> The above works fine with R-2.4.1.

Thanks for reporting this.

This is now fixed and committed to svn.  It will take a day or two for 
the change to make it onto CRAN.

Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Problem with S4 inheritance: unexpected re-initialization?

[cstrato]

Dear Herve

Thank you for your helpful comments, and I especially appreciate that
you tried to run my package. I will try to answer each point separately.

Herve Pages wrote:

Hi Christian,

I can only give you a few reasons why IMO it is very unlikely that anybody
will be able to help you on this, with the current form of your post.

1) Unless you have a really good reason to do so, don't attach a package
   to your post. Do your best to provide a few lines of code that anybody
   can easily copy and paste into their session.
  

Sorrowly, sometimes, a few lines of code are not sufficient to show
the problem. Furthermore, most of the time there are complaints that
people do not provide enough information, an issue I wanted to avoid.

At the end of my answer I provide now the minimal necessary code for
people to easily copy-paste into their session.

Nevertheless, I also attach the same code as package, since some
problems only appear when compiling the package, concretely:
The behavior of the attached package is completely different, when
I "exportMethods("initialize")" in the NAMESPACE file or not. To see
the changes, please comment-out this one line in the NAMESPACE file.


2) Your package is messy (yes I looked at it). You have far too many classes
   with far too many slots that we don't care about. If you could provide
   the smallest possible set of classes with the smallest possible set of slots
   with the smallest possible set of generics and methods that still allow to
   reproduce the issue you want to show us, that would help!
  

You are correct, I wanted to provide a complete demo-package. As
mentioned above, I provide now the minimal necessary code (at least
I hope so).


3) You show us an example where BaseClass is VIRTUAL (which is indeed how it is
   defined in your package) and then an example where BaseClass is NOT VIRTUAL.
   How can we reproduce the latter? Don't expect people to go into your package,
   change the class definition, reinstall, restart R and then run your example!
  

I thought, it would be easy for developers to understand what I mean
and to simply comment-out the one line in the definition of BaseClass.


4) Note that for clarity and conformance to almost universal convention, it's
   better to use arrows pointing from derived classes to base classes
   in your inheritance tree.
  

Sorry, my mistake.


5) It's good to provide the inheritance tree, but it's better when it's 
complete.
   I've looked at what you actually have in your package and the complete
   inheritance tree is something like this:

 BaseClass <- SubClassA
   <- SubClassB <- SubSubClassA
<- SubSubClassB

   Where is the SubClassA class in the inheritance tree that you included in 
your
   post below?
  

Sorry, my mistake.


6) Another thing I note is that you have a naming problem: any reason why you 
name
   "SubSubClassA" a subclass of SubClassB? Given that you also have defined 
SubClassA,
   this can only lead to confusion!
  

Again, you are correct, my mistake. Here is the corrected inheritance tree:

  BaseClass <- SubClassA
<- SubClassB <- SubSubClassB1
<- SubClassB <- SubSubClassB2


7) You need to use proper terminology if you expect people to follow you. In 
your post
   below, every time you instanciate a class you say that your are creating it:
 o "First, I need to create SubClassA..."
 o "I create both subclasses, SubSubClassA and SubSubClassB..."
 o etc...
   Creating a class is not the same as instanciating it!
  

You are correct, this was confusing. I meant, theat I create an object,
which is probably the same as instanciating a class?

Here is the actual code to use:
> subA <- 
new("SubClassA",filename="OutSubA",filedir="/Volumes/CoreData/CRAN/",namesubA="NameSubA")
> subsubB1 <- 
new("SubSubClassB1",filename="MyFileNameB1",filedir="/Volumes/CoreData/",subA=subA)
> subsubB2 <- 
new("SubSubClassB2",filename="MyFileNameB2",filedir="/Volumes/CoreExtra",subA=subA)



8) You start your examples by "First, I need to create SubClassA..." so you are
   introducing us a class that doesn't show up in your inheritance tree so we 
don't
   know how it is related to the other classes. Also you say that you "need" to
   create SubClassA but we have no idea why!
  

Once again you are correct, this was confusing. I need to create object
"subA" of class SubClassA, since it is a slot of SubClassB, and needs to
be included in the instanciation of objects "subsubB1" and "subsubB2".


9) You have a slot in SubClassB that is of class SubClassA! This means "a 
SubClassB
   object _is_ a BaseClass object and it _has_ a slot that is itself a BaseClass
   object (since a SubClassA object is a BaseClass object too)". I hope that 
this
   is really what you want... but maybe this could be related to the fact that 
you
   see 2 instanciations of BaseClass when you instanciate SubSubClassA or 
SubSubClassB.
  

This is the mos

Re: [Rd] Probem with argument "append" in "Rprof"

[Thomas Lumley]

Thanks for this.  I will look at it over the weekend.

-thomas


On Sun, 1 Apr 2007, Romain Francois wrote:

>  And now I realize I gave the patches in the wrong order, let me try
> again
>
> Cheers,
>
> Romain
>
> Romain Francois wrote:
>> [forgot to attach the second patch in the first mail, sorry.]
>>
>> Hello,
>>
>> Appending information to the profiler's output seems to generate
>> problems. Here is a small example of code :
>>
>> 
>> require(boot)
>> Rprof( memory.profiling = TRUE)
>> Rprof(NULL)
>> for(i in 1:2){
>>   Rprof( memory.profiling = TRUE, append = TRUE)
>>   example(boot)
>>   Rprof(NULL)
>> }
>> 
>>
>> The problem is that the file Rprof.out contains more than once the
>> header information:
>>
>> $ grep "sample.interval=" Rprof.out
>> memory profiling: sample.interval=2
>> memory profiling: sample.interval=2
>> memory profiling: sample.interval=2
>>
>> and `summaryRprof` or `R CMD Rprof` are not dealing with it
>>
>>
>>> idx <- grep( "sample", rownames( smp <- summaryRprof()[[1]] ) );
>>>
>> smp[idx, ]
>>   self.time self.pct total.time total.pct
>> sample.interval=2 00   0.04   0.1
>>
>> `sample.interval=2` is incorrectly considered as a function.
>>
>>
>> This is not too much of a big deal, but then if I ask for memory
>> profiling information as well, I get nothing:
>>
>>
>>> summaryRprof( mem = "stats")
>>>
>> Error in tapply(1:1L, list(index = c("sample.interval=2:profiling:",  :
>> arguments must have same length
>>
>>> summaryRprof( mem = "tseries")
>>>
>> Error in data.frame(..., check.names = FALSE) :
>> arguments imply differing number of rows: 1, 1490
>>
>>> summaryRprof( mem = "both")
>>>
>> Error in apply(sapply(strsplit(memstuff, ":"), as.numeric), 1, diff) :
>> dim(X) must have a positive length
>>
>> $ R CMD Rprof Rprof.out
>>
>> Each sample represents  seconds.
>> Total run time: 0 seconds.
>>
>> Total seconds: time spent in function and callees.
>> Self seconds: time spent in function alone.
>>
>>%   total   %   self
>>  totalseconds selfsecondsname
>> Illegal division by zero at /usr/local/lib/R/bin/Rprof line 91, <> line
>> 1491.
>>
>> A quick fix could be to ignore all the lines containing sample.interval=
>> except the first one, but then if someone wants to actually change the
>> interval argument in Rprof, it would not be correct. I attach a patch
>> against R-devel/src/library/utils/R/summRprof.R to do that anyway, but I
>> will look at a better solution.
>>
>> I am not fluent enough in Perl to do the same in the Rprof script, it
>> looks like it does not handle the memory profiling information anyway. I
>> am about to learn Perl, so I guess it could be a useful way to do it. I
>> also attach a patch against R-devel/src/scripts/Rprof that would at
>> least get rid of the memory profiling information (if any). This is not
>> as good as dealing with it, but ... this is the first time I ever touch
>> a Perl script.
>>
>>
>> Cheers,
>>
>> Romain
>>
>>
>>
>>
>>> version
>>>
>>
>> _
>> platform
>> i686-pc-linux-gnu
>> arch
>> i686
>> os
>> linux-gnu
>> system i686,
>> linux-gnu
>> status Under development
>> (unstable)
>> major
>> 2
>> minor  6.0
>> year
>> 2007
>> month
>> 03
>> day
>> 30
>> svn rev
>> 40983
>> language
>> R
>> version.string R version 2.6.0 Under development (unstable) (2007-03-30
>> r40983)
>>
> -- 
> Mango Solutions
> data analysis that delivers
>
> Tel:  +44(0) 1249 467 467
> Fax:  +44(0) 1249 467 468
> Mob:  +44(0) 7813 526 123
>
>

Thomas Lumley   Assoc. Professor, Biostatistics
[EMAIL PROTECTED]   University of Washington, Seattle

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] broken link in posting-guide.html

[Paul Gilbert]

There seems to be a broken link at 
 in the line

*Technical details of posting*: See General Instructions 
 for more details of the 
following:

Paul Gilbert


La version française suit le texte anglais.



This email may contain privileged and/or confidential inform...{{dropped}}

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] broken link in posting-guide.html

[Duncan Murdoch]

On 4/4/2007 12:10 PM, Paul Gilbert wrote:
> There seems to be a broken link at 
>  in the line
> 
> *Technical details of posting*: See General Instructions 
>  for more details of the 
> following:
> 

Thanks, I'll fix it.  ("mail" should be "mail.html".)

Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] source(..., echo=TRUE) broken in R-2.5.0 alpha and in R-2.6.0 devel

[Herve Pages]

Duncan Murdoch wrote:
> 
> Thanks for reporting this.
> 
> This is now fixed and committed to svn.  It will take a day or two for
> the change to make it onto CRAN.

OK. Thanks Martin and Duncan!

Cheers,
H.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Exchange of information between functions aside from argument/return-value interface

[Peter Ruckdeschel]

Hi R-devels,

I would like to ask for your advice on the preferred way to exchange
information between functions aside from the regular argument/return-value
interface.

I am well aware that, S being a functional language, this is to be avoided
where possible. There are exceptions, though:

Let myF() and myH() be functions provided by me, and notmyG() be a function
provided by someone else.

The calling hierarchie is myF() calls notmyG() which calls --- possibly
with other functions being called in between ---  myH().

notmyG() takes as argument a function with return value of type numeric
--- typically a function for optimizing, integrating or zero-finding ---
and is a function which I do not want to modify (and subsequently maintain
the modification).

As myH() is expensive as to evaluation time and, as a side effect, also
provides important side information, I would like to pass this information
back to myF(). (Also see example below).

Using information from myF() in myH() by lexical scoping is straight
forward, whereas to pass information from myH() to myF() directly, the
solution I found so far is to use assign() with a corresponding
envir=./pos=.-argument.

(Q1) Is there a better way to do so?

While it is not too difficult to find out the correct value for the
envir/pos argument when using "pure" R-functions for notmyG(), the
situation is a little more complicated as soon as notmyG() calls myH()
through intermediate calls to .Internal() as in case of optim(),
uniroot().

Is there any way to

(Q2a) find out a corresponding correct value for argument envir/pos in assign
  ---on run-time---, i.e. how many layers of calls are between
  myF() and myH()?

 --- my first guess was to use sys.frame() but I am not convinced...

(Q2b) to make myH() when called from within a call to .Internal()
  perform assignments in the environment of myF()

?

Or should we proceed in a completely different way?

Thank you already for your advice,

Peter

--
--- Example:

To given clipping height b, myH() calculates an "optimal"  influence curve
which involves determining certain Lagrange multipliers in a fixed-point type
algorithm.
To determine b according to a certain criterium, moreover, myH() evaluates
a function H0 in b, the zero of which will be the "optimal" b.

So to use notmyG()=uniroot() as zero-finder the return value of myH()
should be H0(b), while myF() should also get to know about the Lagrange
multipliers determined in myH().

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Accessing C++ code from R

[Jos Elkink]

Hi,

I am trying to use existing C++ code from R. I have no problems
compiling C code and using it in R, but with C++ I'm running into
problems.

Here's the compiler output:

Macintosh-10:~/Desktop/dissertation/Model - CPP version/R labguest$
g++ -I/Library/Frameworks/R.framework/Resources/include
-I/Library/Frameworks/R.framework/Resources/include/i386 *.cpp
In file included from /usr/include/c++/4.0.0/bits/locale_facets.h:1533,
 from /usr/include/c++/4.0.0/bits/basic_ios.h:44,
 from /usr/include/c++/4.0.0/ios:50,
 from /usr/include/c++/4.0.0/ostream:44,
 from /usr/include/c++/4.0.0/iostream:44,
 from main.cpp:5:
/usr/include/c++/4.0.0/bits/codecvt.h:217:45: error: macro "length"
passed 4 arguments, but takes just 1
/usr/include/c++/4.0.0/bits/codecvt.h:216: error: expected ';' before 'const'
/usr/include/c++/4.0.0/bits/codecvt.h:220: error: expected `;' before 'int'
main.cpp:51: error: brace-enclosed initializer used to initialize
'R_NativePrimitiveArgType*'


Line 51 refers to the standard part to register the function in R:

R_CMethodDef cMethods[] = {
  {"runSimulation", (void* (*) ()) &runSimulation, 27, {INTSXP,
INTSXP, INTSXP, REALSXP, REALSXP, REALSXP, INTSXP, INTSXP, INTSXP,
INTSXP, INTSXP, INTSXP, REALSXP, REALSXP, INTSXP, INTSXP, INTSXP,
INTSXP, INTSXP, INTSXP, INTSXP, INTSXP, INTSXP, INTSXP, REALSXP,
REALSXP, REALSXP}},
  {NULL, NULL, 0}
};


I had to add the explicit cast of &runSimulation to get rid of one
compiler error, but do not know how to deal with this one.
Encapsulating this part of the code in

extern "C" {
}

has no effect.

runSimulation is just a regular function, with a lot of int* and
double* parameters, and it is not part of a class. It does inside
create a class, though.

Outline:

void runSimulation(int *p_1 ... etc) {

   try {
 CModel Model();
 Model.Run();
   } catch (CException& e) {
 cout << "exception" << endl;
   }
}

Encapsulating this function in extern "C" also has no effect.

Anyone any ideas what I should do? The system I am using is an Intel-based Mac.

Thanks in advance!

Jos

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Exchange of information between functions aside from argument/return-value interface

[Luke Tierney]

On Wed, 4 Apr 2007, Peter Ruckdeschel wrote:

> Hi R-devels,
>
> I would like to ask for your advice on the preferred way to exchange
> information between functions aside from the regular argument/return-value
> interface.
>
> I am well aware that, S being a functional language, this is to be avoided
> where possible. There are exceptions, though:
>
> Let myF() and myH() be functions provided by me, and notmyG() be a function
> provided by someone else.
>
> The calling hierarchie is myF() calls notmyG() which calls --- possibly
> with other functions being called in between ---  myH().
>
> notmyG() takes as argument a function with return value of type numeric
> --- typically a function for optimizing, integrating or zero-finding ---
> and is a function which I do not want to modify (and subsequently maintain
> the modification).
>
> As myH() is expensive as to evaluation time and, as a side effect, also
> provides important side information, I would like to pass this information
> back to myF(). (Also see example below).
>
> Using information from myF() in myH() by lexical scoping is straight
> forward, whereas to pass information from myH() to myF() directly, the
> solution I found so far is to use assign() with a corresponding
> envir=./pos=.-argument.
>
> (Q1) Is there a better way to do so?
>

Sounds like lexical scoping should work for this also -- use <<- to
assign to the variable in the containing scope.

Best,

luke

> While it is not too difficult to find out the correct value for the
> envir/pos argument when using "pure" R-functions for notmyG(), the
> situation is a little more complicated as soon as notmyG() calls myH()
> through intermediate calls to .Internal() as in case of optim(),
> uniroot().
>
> Is there any way to
>
> (Q2a) find out a corresponding correct value for argument envir/pos in assign
>  ---on run-time---, i.e. how many layers of calls are between
>  myF() and myH()?
>
> --- my first guess was to use sys.frame() but I am not convinced...
>
> (Q2b) to make myH() when called from within a call to .Internal()
>  perform assignments in the environment of myF()
>
> ?
>
> Or should we proceed in a completely different way?
>
> Thank you already for your advice,
>
> Peter
>
> --
> --- Example:
>
> To given clipping height b, myH() calculates an "optimal"  influence curve
> which involves determining certain Lagrange multipliers in a fixed-point type
> algorithm.
> To determine b according to a certain criterium, moreover, myH() evaluates
> a function H0 in b, the zero of which will be the "optimal" b.
>
> So to use notmyG()=uniroot() as zero-finder the return value of myH()
> should be H0(b), while myF() should also get to know about the Lagrange
> multipliers determined in myH().
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

-- 
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa  Phone: 319-335-3386
Department of Statistics andFax:   319-335-3017
Actuarial Science
241 Schaeffer Hall  email:  [EMAIL PROTECTED]
Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Exchange of information between functions aside from argument/return-value interface

[Peter Ruckdeschel]

Thank you, Luke, for your promptous response.

[snipped away my original message; to be found on
 https://stat.ethz.ch/pipermail/r-devel/2007-April/045216.html]

> Sounds like lexical scoping should work for this also -- use <<- to
> assign to the variable in the containing scope.
> 
> Best,
> 
> luke

yes, in my application, this really solves the problem. Thank you.


But I am not quite sure for the general situation:

Recall that we have the sequence of calls

myF() calls notmyG() which --with possibly more functions involved in between--
directly or indirectly calls myH().

Now, if I do not know exactly which variables are defined
in the intermediate notmyG() or in some of the functions called "in between",
I would have thought that using

VariableInMyF <<- something

within myH() bears the danger that I am overwriting
a variable of name VariableInMyF in notmyG() and "in-between's"
instead of in myF().

Or did I get something wrong?

Thanks for your help
Peter

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Accessing C++ code from R

[Simon Urbanek]

Jos,

you omitted the crucial part but my guess would be that all you have  
to do is to put #include  *before* R headers includes (R  
defines "length" which throws off iostream).
Also note that using cout is not a good idea, because it is not  
captured by R, you should be using Rprintf instead.

Cheers,
Simon

On Apr 4, 2007, at 1:44 PM, Jos Elkink wrote:

> Hi,
>
> I am trying to use existing C++ code from R. I have no problems
> compiling C code and using it in R, but with C++ I'm running into
> problems.
>
> Here's the compiler output:
>
> Macintosh-10:~/Desktop/dissertation/Model - CPP version/R labguest$
> g++ -I/Library/Frameworks/R.framework/Resources/include
> -I/Library/Frameworks/R.framework/Resources/include/i386 *.cpp
> In file included from /usr/include/c++/4.0.0/bits/locale_facets.h: 
> 1533,
>  from /usr/include/c++/4.0.0/bits/basic_ios.h:44,
>  from /usr/include/c++/4.0.0/ios:50,
>  from /usr/include/c++/4.0.0/ostream:44,
>  from /usr/include/c++/4.0.0/iostream:44,
>  from main.cpp:5:
> /usr/include/c++/4.0.0/bits/codecvt.h:217:45: error: macro "length"
> passed 4 arguments, but takes just 1
> /usr/include/c++/4.0.0/bits/codecvt.h:216: error: expected ';'  
> before 'const'
> /usr/include/c++/4.0.0/bits/codecvt.h:220: error: expected `;'  
> before 'int'
> main.cpp:51: error: brace-enclosed initializer used to initialize
> 'R_NativePrimitiveArgType*'
>
>
> Line 51 refers to the standard part to register the function in R:
>
> R_CMethodDef cMethods[] = {
>   {"runSimulation", (void* (*) ()) &runSimulation, 27, {INTSXP,
> INTSXP, INTSXP, REALSXP, REALSXP, REALSXP, INTSXP, INTSXP, INTSXP,
> INTSXP, INTSXP, INTSXP, REALSXP, REALSXP, INTSXP, INTSXP, INTSXP,
> INTSXP, INTSXP, INTSXP, INTSXP, INTSXP, INTSXP, INTSXP, REALSXP,
> REALSXP, REALSXP}},
>   {NULL, NULL, 0}
> };
>
>
> I had to add the explicit cast of &runSimulation to get rid of one
> compiler error, but do not know how to deal with this one.
> Encapsulating this part of the code in
>
> extern "C" {
> }
>
> has no effect.
>
> runSimulation is just a regular function, with a lot of int* and
> double* parameters, and it is not part of a class. It does inside
> create a class, though.
>
> Outline:
>
> void runSimulation(int *p_1 ... etc) {
>
>try {
>  CModel Model();
>  Model.Run();
>} catch (CException& e) {
>  cout << "exception" << endl;
>}
> }
>
> Encapsulating this function in extern "C" also has no effect.
>
> Anyone any ideas what I should do? The system I am using is an  
> Intel-based Mac.
>
> Thanks in advance!
>
> Jos
>
> __
> 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] Problem with S4 inheritance: unexpected re-initialization?

[Herve Pages]

Hi Christian,

cstrato wrote:
> Dear Herve
> 
> Thank you for your helpful comments, and I especially appreciate that
> you tried to run my package. I will try to answer each point separately.
> 
> Herve Pages wrote:
>> Hi Christian,
>>
>> I can only give you a few reasons why IMO it is very unlikely that
>> anybody
>> will be able to help you on this, with the current form of your post.
>>
>> 1) Unless you have a really good reason to do so, don't attach a package
>>to your post. Do your best to provide a few lines of code that anybody
>>can easily copy and paste into their session.
>>   
> Sorrowly, sometimes, a few lines of code are not sufficient to show
> the problem. Furthermore, most of the time there are complaints that
> people do not provide enough information, an issue I wanted to avoid.

The code you provide below is still too long and overcluttered with stuff that 
is
probably unrelated with the issue you want to discuss. Your class definitions
still have slots that we don't care about. Basically if you want to
discuss an S4 issue, you should get rid of all this file system related stuff
(the 'dirfile', 'filedir', 'filename' slots, the 'pathFile' function, the dozens
of calls to 'basename', 'dirname', 'getwd', 'file.dir' etc...)

Also your code is dirty and hard to read. Take this for example:

  "initialize.BaseClass" <-
  function(.Object, filename=character(), filedir=as.character(getwd()), ...) {
print("--initialize:BaseClass--")
  print(paste("BaseClass:init:class(.Object) = ", class(.Object)))

  #   .Object <- callNextMethod(.Object, ...);

dirfile <- pathFile(filename, filedir);
  print(paste("BaseClass:init:dirfile = ", dirfile))

.Object <- callNextMethod(.Object, filename=filename, filedir=filedir, ...);

[EMAIL PROTECTED] <- filename;
[EMAIL PROTECTED]  <- filedir;
.Object;
  }#initialize.BaseClass

  setMethod("initialize", "BaseClass", initialize.BaseClass);

o It's not properly indented.
o Why those empty lines in the middle of such a short function?
o Why those semi-columns at the end of lines?
o Why put the implementation of the initialize method into a separate function?
o Why use this construct 'print(paste())' instead of just 'cat()'?
o Why leave the first call to callNextMethod() commented?
o What do you do with 'dirfile', except that you print it? Do you need this for
  the purpose of the S4 discussion?

What about adopting this style:

setMethod("initialize", "BaseClass",
function(.Object, filename=character(), filedir=as.character(getwd()), 
...)
{
cat("--initialize:BaseClass--\n")
cat("BaseClass:init:class(.Object) = ", class(.Object))
.Object <- callNextMethod(.Object, filename=filename, 
filedir=filedir, ...)
[EMAIL PROTECTED] <- filename
[EMAIL PROTECTED]  <- filedir
.Object
}
)

That's for the style. Now let's talk about the semantic. Here is the definition 
of
your BaseClass class:

setClass("BaseClass",
representation(
"VIRTUAL",
filename="character",
filedir="character"
),
prototype(
filename = character(),
filedir  = as.character(getwd())
)
)

(Note that this definition is what _I_ get after I cleaned it and indented it 
which
is something that _you_ are expected to do.)

o Initializing the 'filename' slot to character() is useless since this is the 
default.
o Wrapping getwd() inside as.character() is useless since getwd() returns a 
character vector.
o BUT MOST IMPORTANTLY THAN ANYTHING ELSE: given the fact that you've provided 
a prototype
  for class BaseClass, your initialize method is useless since it does 
_nothing_ more
  than what the default initialize method does! If you want to define your own 
"initialize"
  method for the only purpose of printing messages, then you could do it in a 
much simpler
  way:

setMethod("initialize", "BaseClass",
function(.Object, ...)
{
cat("--initialize:BaseClass--\n")
cat("BaseClass:init:class(.Object) = ", class(.Object), "\n", 
sep="")
callNextMethod()
}
)

But as I said initially, the file system related stuff is useless to illustrate 
the
S4 issue you want to show us so why didn't you just provide:

setClass("BaseClass",
representation("VIRTUAL", slot1="character"),
prototype(slot1="aaa")
)

setMethod("initialize", "BaseClass",
function(.Object, ...)
{
cat("--initialize:BaseClass--\n")
cat("BaseClass:init:class(.Object) = ", class(.Object), "\n", 
sep="")
callNextMethod()
}
)

See? I ended up by replacing 25 lines of your hard-to-read/confusing code by 12
lines of clean code containing only the STRICTLY NECESSARY stuff for an S4 
discussion.
That's what you should have done instead of sending u

Re: [Rd] Accessing C++ code from R

[Jos Elkink]

Hi Simon,

Thank you - that indeed fixes the first problem (about cout). It still
leaves the second error, though:

main.cpp:52: error: brace-enclosed initializer used to initialize
'R_NativePrimitiveArgType*'

Any ideas about that?

Thanks again for the first suggestion, anyway, and I'll keep your
point about cout in mind.

Jos

On 4/4/07, Simon Urbanek <[EMAIL PROTECTED]> wrote:
> Jos,
>
> you omitted the crucial part but my guess would be that all you have
> to do is to put #include  *before* R headers includes (R
> defines "length" which throws off iostream).
> Also note that using cout is not a good idea, because it is not
> captured by R, you should be using Rprintf instead.
>
> Cheers,
> Simon
>
> On Apr 4, 2007, at 1:44 PM, Jos Elkink wrote:
>
> > Hi,
> >
> > I am trying to use existing C++ code from R. I have no problems
> > compiling C code and using it in R, but with C++ I'm running into
> > problems.
> >
> > Here's the compiler output:
> >
> > Macintosh-10:~/Desktop/dissertation/Model - CPP version/R labguest$
> > g++ -I/Library/Frameworks/R.framework/Resources/include
> > -I/Library/Frameworks/R.framework/Resources/include/i386 *.cpp
> > In file included from /usr/include/c++/4.0.0/bits/locale_facets.h:
> > 1533,
> >  from /usr/include/c++/4.0.0/bits/basic_ios.h:44,
> >  from /usr/include/c++/4.0.0/ios:50,
> >  from /usr/include/c++/4.0.0/ostream:44,
> >  from /usr/include/c++/4.0.0/iostream:44,
> >  from main.cpp:5:
> > /usr/include/c++/4.0.0/bits/codecvt.h:217:45: error: macro "length"
> > passed 4 arguments, but takes just 1
> > /usr/include/c++/4.0.0/bits/codecvt.h:216: error: expected ';'
> > before 'const'
> > /usr/include/c++/4.0.0/bits/codecvt.h:220: error: expected `;'
> > before 'int'
> > main.cpp:51: error: brace-enclosed initializer used to initialize
> > 'R_NativePrimitiveArgType*'
> >
> >
> > Line 51 refers to the standard part to register the function in R:
> >
> > R_CMethodDef cMethods[] = {
> >   {"runSimulation", (void* (*) ()) &runSimulation, 27, {INTSXP,
> > INTSXP, INTSXP, REALSXP, REALSXP, REALSXP, INTSXP, INTSXP, INTSXP,
> > INTSXP, INTSXP, INTSXP, REALSXP, REALSXP, INTSXP, INTSXP, INTSXP,
> > INTSXP, INTSXP, INTSXP, INTSXP, INTSXP, INTSXP, INTSXP, REALSXP,
> > REALSXP, REALSXP}},
> >   {NULL, NULL, 0}
> > };
> >
> >
> > I had to add the explicit cast of &runSimulation to get rid of one
> > compiler error, but do not know how to deal with this one.
> > Encapsulating this part of the code in
> >
> > extern "C" {
> > }
> >
> > has no effect.
> >
> > runSimulation is just a regular function, with a lot of int* and
> > double* parameters, and it is not part of a class. It does inside
> > create a class, though.
> >
> > Outline:
> >
> > void runSimulation(int *p_1 ... etc) {
> >
> >try {
> >  CModel Model();
> >  Model.Run();
> >} catch (CException& e) {
> >  cout << "exception" << endl;
> >}
> > }
> >
> > Encapsulating this function in extern "C" also has no effect.
> >
> > Anyone any ideas what I should do? The system I am using is an
> > Intel-based Mac.
> >
> > Thanks in advance!
> >
> > Jos
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> >
>
>


-- 
Jos Elkink
PhD Candidate, Trinity College Dublin
HMDC Fellow, Harvard University
http://jaeweb.cantr.net

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Exchange of information between functions aside from argument/return-value interface

[Luke Tierney]

On Wed, 4 Apr 2007, Peter Ruckdeschel wrote:

> Thank you, Luke, for your promptous response.
>
> [snipped away my original message; to be found on
> https://stat.ethz.ch/pipermail/r-devel/2007-April/045216.html]
>
>> Sounds like lexical scoping should work for this also -- use <<- to
>> assign to the variable in the containing scope.
>>
>> Best,
>>
>> luke
>
> yes, in my application, this really solves the problem. Thank you.
>
>
> But I am not quite sure for the general situation:
>
> Recall that we have the sequence of calls
>
> myF() calls notmyG() which --with possibly more functions involved in 
> between--
> directly or indirectly calls myH().
>
> Now, if I do not know exactly which variables are defined
> in the intermediate notmyG() or in some of the functions called "in between",
> I would have thought that using
>
> VariableInMyF <<- something
>
> within myH() bears the danger that I am overwriting
> a variable of name VariableInMyF in notmyG() and "in-between's"
> instead of in myF().
>
> Or did I get something wrong?

I think you did. You seem to be thinking in terms of dynamic scope,
which looks for variables in the caller and then the caller's caller.

Lexical scope addresses exactly this problem.  In lexical scope
variable references are resolved on the basis of how function
definitions are nested in the written code (hence the term lexical).
If you define myH inside myF then free variables in myH are looked up
first in myF and then in the context where myF is defined. How myH is
called does not matter.  Nested functions in Pascal work the same way
if that helps.

[In terms of the internal implementation, the enclosing environment of
the environment of myH is the frame of the call to myF that created
myH.]

Best,

luke


THis is exactly the pro
>
> Thanks for your help
> Peter
>
>
>

-- 
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa  Phone: 319-335-3386
Department of Statistics andFax:   319-335-3017
Actuarial Science
241 Schaeffer Hall  email:  [EMAIL PROTECTED]
Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Exchange of information between functions aside from argument/return-value interface

[Peter Ruckdeschel]

Thank you, Luke, once again.

>> [snipped away my original message; to be found on
>> https://stat.ethz.ch/pipermail/r-devel/2007-April/045219.html]

>> Or did I get something wrong?
> 
> I think you did. You seem to be thinking in terms of dynamic scope,
> which looks for variables in the caller and then the caller's caller.
> 
> Lexical scope addresses exactly this problem.  In lexical scope
> variable references are resolved on the basis of how function
> definitions are nested in the written code (hence the term lexical).
> If you define myH inside myF then free variables in myH are looked up
> first in myF and then in the context where myF is defined. How myH is
> called does not matter.  Nested functions in Pascal work the same way
> if that helps.

OK got it. I should have known this. I am pretty much embarrassed to
have bothered you.

Thanks again for your help
Peter

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Accessing C++ code from R

[Simon Urbanek]

On Apr 4, 2007, at 2:46 PM, Jos Elkink wrote:

> Thank you - that indeed fixes the first problem (about cout). It  
> still leaves the second error, though:
>
> main.cpp:52: error: brace-enclosed initializer used to initialize  
> 'R_NativePrimitiveArgType*'
>
> Any ideas about that?
>

Sure, do what the compiler tells you to - use a reference instead:

static R_NativePrimitiveArgType runSimulation_t[] =
   {INTSXP, INTSXP, INTSXP, REALSXP, REALSXP, REALSXP, INTSXP,  
INTSXP, INTSXP,
INTSXP, INTSXP, INTSXP, REALSXP, REALSXP, INTSXP, INTSXP, INTSXP,
INTSXP, INTSXP, INTSXP, INTSXP, INTSXP, INTSXP, INTSXP, REALSXP,
REALSXP, REALSXP};

R_CMethodDef cMethods[] = {
   {"runSimulation", (DL_FUNC) &runSimulation, 27, runSimulation_t},
   {NULL, NULL, 0}
};

BTW have a look at registration.c in R sources for an elegant way to  
make this less error-prone when registering multiple functions (and  
looking at your argument list ... you should seriously consider  
using .Call :P)

Cheers,
Simon



>
> On 4/4/07, Simon Urbanek <[EMAIL PROTECTED]> wrote:
>> Jos,
>>
>> you omitted the crucial part but my guess would be that all you have
>> to do is to put #include  *before* R headers includes (R
>> defines "length" which throws off iostream).
>> Also note that using cout is not a good idea, because it is not
>> captured by R, you should be using Rprintf instead.
>>
>> Cheers,
>> Simon
>>
>> On Apr 4, 2007, at 1:44 PM, Jos Elkink wrote:
>>
>>> Hi,
>>>
>>> I am trying to use existing C++ code from R. I have no problems
>>> compiling C code and using it in R, but with C++ I'm running into
>>> problems.
>>>
>>> Here's the compiler output:
>>>
>>> Macintosh-10:~/Desktop/dissertation/Model - CPP version/R labguest$
>>> g++ -I/Library/Frameworks/R.framework/Resources/include
>>> -I/Library/Frameworks/R.framework/Resources/include/i386 *.cpp
>>> In file included from /usr/include/c++/4.0.0/bits/locale_facets.h:
>>> 1533,
>>>  from /usr/include/c++/4.0.0/bits/basic_ios.h:44,
>>>  from /usr/include/c++/4.0.0/ios:50,
>>>  from /usr/include/c++/4.0.0/ostream:44,
>>>  from /usr/include/c++/4.0.0/iostream:44,
>>>  from main.cpp:5:
>>> /usr/include/c++/4.0.0/bits/codecvt.h:217:45: error: macro "length"
>>> passed 4 arguments, but takes just 1
>>> /usr/include/c++/4.0.0/bits/codecvt.h:216: error: expected ';'
>>> before 'const'
>>> /usr/include/c++/4.0.0/bits/codecvt.h:220: error: expected `;'
>>> before 'int'
>>> main.cpp:51: error: brace-enclosed initializer used to initialize
>>> 'R_NativePrimitiveArgType*'
>>>
>>>
>>> Line 51 refers to the standard part to register the function in R:
>>>
>>> R_CMethodDef cMethods[] = {
>>>   {"runSimulation", (void* (*) ()) &runSimulation, 27, {INTSXP,
>>> INTSXP, INTSXP, REALSXP, REALSXP, REALSXP, INTSXP, INTSXP, INTSXP,
>>> INTSXP, INTSXP, INTSXP, REALSXP, REALSXP, INTSXP, INTSXP, INTSXP,
>>> INTSXP, INTSXP, INTSXP, INTSXP, INTSXP, INTSXP, INTSXP, REALSXP,
>>> REALSXP, REALSXP}},
>>>   {NULL, NULL, 0}
>>> };
>>>
>>>
>>> I had to add the explicit cast of &runSimulation to get rid of one
>>> compiler error, but do not know how to deal with this one.
>>> Encapsulating this part of the code in
>>>
>>> extern "C" {
>>> }
>>>
>>> has no effect.
>>>
>>> runSimulation is just a regular function, with a lot of int* and
>>> double* parameters, and it is not part of a class. It does inside
>>> create a class, though.
>>>
>>> Outline:
>>>
>>> void runSimulation(int *p_1 ... etc) {
>>>
>>>try {
>>>  CModel Model();
>>>  Model.Run();
>>>} catch (CException& e) {
>>>  cout << "exception" << endl;
>>>}
>>> }
>>>
>>> Encapsulating this function in extern "C" also has no effect.
>>>
>>> Anyone any ideas what I should do? The system I am using is an
>>> Intel-based Mac.
>>>
>>> Thanks in advance!
>>>
>>> Jos
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>>
>>
>>
>
>
> -- 
> Jos Elkink
> PhD Candidate, Trinity College Dublin
> HMDC Fellow, Harvard University
> http://jaeweb.cantr.net
>
> __
> 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] 'R CMD check' fails when suggested package is not available

[Herve Pages]

Hi there,

I was wondering why I get the following error message:

  * checking package dependencies ... ERROR
  Packages required but not available:
Rmpi

when I run 'R CMD check' on a package that _suggests_ Rmpi?
Why isn't it OK to not have all the suggested packages installed?

Maybe one of the 3 following behaviours would be more appropriate:

  a) Having the error saying something like:

Package suggested but not available:
  Rmpi

  b) Make this a warning instead of an error.

  c) Don't do anything at all for suggested packages.

This issue showed up today while I was checking a new Bioconductor package:
the package suggests Rmpi but the vignette and the examples don't use it. If I 
remove
Rmpi from the Suggests field then 'R CMD check' runs all the examples and 
re-create
the vignette with no problem. Most users will not have Rmpi on their machine 
neither
will they be interested in getting into the trouble of installing it.
The package I was checking suggests Rmpi only because it contains 1 function 
that tries
to use it if it's installed but will work perfectly fine otherwise.
In this case it seems reasonable to have Rmpi in the Suggests field but this 
will
make 'R CMD check' to fail which is problematic in the context of automated 
builds :-/
If 'R CMD check' can't be a little bit more relaxed about this, then I guess we 
will
need to remove Rmpi from the Suggests field, but then 'R CMD check' will 
complain that:

  * checking for unstated dependencies in R code ... WARNING
  'library' or 'require' calls not declared from:
Rmpi

which is always better than getting an ERROR.

Thanks!

H.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] 'R CMD check' fails when suggested package is not available

[Prof Brian Ripley]

This is a configurable option 'R_check_force_suggests' documented in 
'Writing R Extensions'.

This package should be using Enhances: Rmpi, it seems.

On Wed, 4 Apr 2007, Herve Pages wrote:

> Hi there,
>
> I was wondering why I get the following error message:
>
>  * checking package dependencies ... ERROR
>  Packages required but not available:
>Rmpi
>
> when I run 'R CMD check' on a package that _suggests_ Rmpi?
> Why isn't it OK to not have all the suggested packages installed?
>
> Maybe one of the 3 following behaviours would be more appropriate:
>
>  a) Having the error saying something like:
>
>Package suggested but not available:
>  Rmpi
>
>  b) Make this a warning instead of an error.
>
>  c) Don't do anything at all for suggested packages.
>
> This issue showed up today while I was checking a new Bioconductor package:
> the package suggests Rmpi but the vignette and the examples don't use it. If 
> I remove
> Rmpi from the Suggests field then 'R CMD check' runs all the examples and 
> re-create
> the vignette with no problem. Most users will not have Rmpi on their machine 
> neither
> will they be interested in getting into the trouble of installing it.

'Most users' will not be running 'R CMD check', of course.

> The package I was checking suggests Rmpi only because it contains 1 function 
> that tries
> to use it if it's installed but will work perfectly fine otherwise.
> In this case it seems reasonable to have Rmpi in the Suggests field but this 
> will
> make 'R CMD check' to fail which is problematic in the context of automated 
> builds :-/
> If 'R CMD check' can't be a little bit more relaxed about this, then I guess 
> we will
> need to remove Rmpi from the Suggests field, but then 'R CMD check' will 
> complain that:
>
>  * checking for unstated dependencies in R code ... WARNING
>  'library' or 'require' calls not declared from:
>Rmpi
>
> which is always better than getting an ERROR.
>
> Thanks!
>
> H.


-- 
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel