Re: [Rd] CRAN: MacOS X binary: not available, see check log?

2010-04-15 Thread Simon Urbanek

On Apr 15, 2010, at 2:26 AM, Henrik Bengtsson wrote:

> For a couple of days, MacOS X binaries are not build on CRAN (for my
> recently uploaded packages only?):
> 

AFAICS your package was posted on Apr 13 so at the earliest it can be built in 
the Apr 14 run = yesterday. There was no Apr 14 run because the R build failed 
on Apr 13. I was chasing the subsequent issues yesterday and I think the latest 
R build is now working so today's package update should be on CRAN soon. Don't 
forget that packages have to swim across the Atlantic to get built and then 
back as binaries, so the migration can take a day or two ;).

Cheers,
Simon


> The R.oo package is listed as "MacOS X binary: not available, see
> check log?", but the 'check log' show no errors
> URL: http://cran.r-project.org/web/packages/R.oo/
> 
> Is this a known issue?
> 



> /Henrik
> 
> __
> 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] callNextMethod() and NAMESPACE

2010-04-15 Thread Adrian Waddell

Hello there,

I define a accessor method for one of my classes, i.e.

setMethod(f = "[",
  signature = "NG_data",
definition = function(x,i,j,drop){
   if(all(is.na(match(j,x...@shortnames)) == FALSE)){
 return(x[,match(j,x...@shortnames)])   }else{
 callNextMethod()
   }
}
)

where the class "NG_data" inherits from the "data.frame" class. Hence I 
added the line


exportMethods("[")

to my NAMESPACE file. After package building, installing and loading, I 
try to use this accessor method


myObject[,1]

but I get the error message:

Error in callNextMethod() : bad object found as method (class "function")

Interestingly, if I then execute the setMethod(f = "["...  in the 
command prompt


myObject[,1]

works. Does anybody has a clue what could go wrong?


Adrian Waddell

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


[Rd] "°" not accepted under MacOSX

2010-04-15 Thread Patrick Giraudoux
I am developping a package (pgirmess) that since long does not go 
through CRAN MacOSX checks, just because I have this command in one of 
the examples.


text(mydata[,3],mydata[,4],paste(round(dirs,0),"°"),cex=0.7)

It makes:


text(mydata[,3],mydata[,4],paste(round(dirs,0),"+
+
+
+ cleanEx()
+ nameEx("distNode")
Error: unexpected symbol in:
"cleanEx()
nameEx("distNode"
Execution halted

The description file (following some earlier recommandation) includes:
Encoding: latin1

Is there any way to make "°" accepted by MacOSX checks ?

Cheers,

Patrick

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


Re: [Rd] "°" not accepted under MacOSX

2010-04-15 Thread Prof Brian Ripley

The subject line is untrue.

We recommend in 'Writing R Extensions' that you encode such characters 
as \u sequences, in this case "\u00b0".  However, this is more 
likely to be a locale problem on the check server, as pgirmess checks 
out on my Mac.  In fact, the top of the log is


# using R version 2.11.0 beta (2010-04-12 r51689)
# using session charset: ASCII
# checking for file 'pgirmess/DESCRIPTION' ... OK
# this is package 'pgirmess' version '1.4.4'
# package encoding: latin1

and you cannot reencode latin1 to ASCII 

I don't know why you would choose to use something that makes your 
package fail on many Japanese or Greek or Russian systems, and of 
course in C locales.  Plotmath is portable, and these days "\u00b0" is 
also pretty portable.


On Thu, 15 Apr 2010, Patrick Giraudoux wrote:

I am developping a package (pgirmess) that since long does not go through 
CRAN MacOSX checks, just because I have this command in one of the examples.


text(mydata[,3],mydata[,4],paste(round(dirs,0),"°"),cex=0.7)

It makes:


text(mydata[,3],mydata[,4],paste(round(dirs,0),"+
+
+
+ cleanEx()
+ nameEx("distNode")
Error: unexpected symbol in:
"cleanEx()
nameEx("distNode"
Execution halted

The description file (following some earlier recommandation) includes:
Encoding: latin1

Is there any way to make "°" accepted by MacOSX checks ?

Cheers,

Patrick

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



--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] "°" not accepted under MacOSX

2010-04-15 Thread Patrick Giraudoux

Prof Brian Ripley a écrit :

The subject line is untrue.

We recommend in 'Writing R Extensions' that you encode such characters 
as \u sequences, in this case "\u00b0".  However, this is more 
likely to be a locale problem on the check server, as pgirmess checks 
out on my Mac.  In fact, the top of the log is


# using R version 2.11.0 beta (2010-04-12 r51689)
# using session charset: ASCII
# checking for file 'pgirmess/DESCRIPTION' ... OK
# this is package 'pgirmess' version '1.4.4'
# package encoding: latin1

and you cannot reencode latin1 to ASCII 

I don't know why you would choose to use something that makes your 
package fail on many Japanese or Greek or Russian systems, and of 
course in C locales.  Plotmath is portable, and these days "\u00b0" is 
also pretty portable.




Thanks a lot. Strictly speaking, I did not choose:  I was just not 
familiar with \u  encoding, and will document on it now I have a 
good hint to start with...


Thanks again,

Patrick

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


Re: [Rd] R CMD check tells me 'no visible binding for globalvariable ', what does it mean?

2010-04-15 Thread luke

On Mon, 12 Apr 2010, William Dunlap wrote:




-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Henrik Bengtsson
Sent: Monday, April 12, 2010 8:24 AM
To: Duncan Murdoch
Cc: r-devel; Michael Dewey
Subject: Re: [Rd] R CMD check tells me 'no visible binding
for globalvariable ', what does it mean?

On Mon, Apr 12, 2010 at 5:08 PM, Duncan Murdoch
 wrote:

On 12/04/2010 10:51 AM, Michael Dewey wrote:


When I run R CMD check on a package I have recently

started work on I get

the following:

* checking R code for possible problems ... NOTE
addlinear: no visible binding for global variable 'x'

I appreciate that this is only a NOTE and so I assume is

R's equivalent of

'This is perfectly legal but I wonder whether it is really what you
intended' but I would like to understand it.

In the relevant function addlinear the following function

is defined

locally:

   orfun <- function(x, oddsratio) {1/(1+1/(oddsratio *

(x/(1-x}


and then used later in curve

      curve(orfun(x, exp(estimate)), from = 0.001, to =

0.999, add = TRUE)


These are the only occurrences of 'x'.

Is it just telling me that I have never assigned a value

to x? Or is it

more sinister than that? As far as I can tell the function

does what I

intended.


The curve() function evaluates the first argument in a

strange way, and this

confuses the code checking.  (The variable name "x" is

special to curve().)


I think you can avoid the warning by rewriting that call to

curve() as


curve(function(x) orfun(x, exp(estimate)), from = 0.001, to

= 0.999, add =

TRUE)


...or

x <- NULL; rm(x); # Dummy to trick R CMD check
curve(orfun(x, exp(estimate)), from = 0.001, to = 0.999, add = TRUE)


Or we could come up with a scheme to telling the usage checking functions
in codetools that some some or all arguments of certain functions
are evaluated in odd ways so it should not check them.  E.g.,
  irregularUsage(curve, expr)
  irregularUsage(lm, subset, formula) # subset and formula arguments of lm
  irregularUsage(expression, ...) # ... arguments to expression
Perhaps one could add such indications to the NAMESPACE file
or to a new file in a package.  The former is kludgy but the
latter requires changes to the packaging system.



This is done at the moment in a very ad hoc way for functions in the
core packages.  I will make a note to add something for curve.  This
is an interesting case, as only the variable 'x' should be viewed as
special for code analysis purposes if I understand the intent in curve
properly.

Providing a mechanism for user functions to be annotated for code
analysis might be useful, and might help in making the handling of
core package functions with special evaluation rulesa little less ad
hloc.  On the other hand I'm not sure I want to do anything that
encourages further use of nonstantard evaluation in new code.

luke


Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com




/Henrik



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



__
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:  l...@stat.uiowa.edu
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] R CMD check tells me 'no visible binding for globalvariable ', what does it mean?

2010-04-15 Thread Mark.Bravington
Speaking as a copious generator of CMD CHECK notes: I don't see that there's a 
problem to be solved here-- i.e. I don't see why it's worth changing good code 
or adding conventions just to circumvent CMD CHECK notes. (If the code is bad, 
of course it should be changed!) As the original poster said, the CMD CHECK 
note is only a note, not a warning-- it's checking for "*possible* problems". 
With my packages, especially debug & mvbutils, CHECK issues 100s of lines of 
"notes", which (after inspection) I don't worry about-- they arise from RCMD 
CHECK not understanding my code (eg non-default scopings), not from coding 
errors. I would be very unhappy at having to add enormous amounts of 
"explanation" to the packages simply to alleviate a non-problem!

Similarly, some compilers give notes about possibly non-initialized variables 
etc, but these are often a result of the compiler not understanding the code. I 
do look at them, and decide whether there are problems that need fixing or 
not-- it's no big deal to ignore them if not useful. Presumably the RCMD CHECK 
notes are useful to some coders, in which case good; but nothing further really 
seems needed.

Mark

-- 
Mark Bravington
CSIRO Mathematical & Information Sciences
Marine Laboratory
Castray Esplanade
Hobart 7001
TAS

ph (+61) 3 6232 5118
fax (+61) 3 6232 5012
mob (+61) 438 315 623

l...@stat.uiowa.edu wrote:
> On Mon, 12 Apr 2010, William Dunlap wrote:
> 
>> 
>>> -Original Message-
>>> From: r-devel-boun...@r-project.org
>>> [mailto:r-devel-boun...@r-project.org] On Behalf Of Henrik Bengtsson
>>> Sent: Monday, April 12, 2010 8:24 AM
>>> To: Duncan Murdoch
>>> Cc: r-devel; Michael Dewey
>>> Subject: Re: [Rd] R CMD check tells me 'no visible binding for
>>> globalvariable ', what does it mean?
>>> 
>>> On Mon, Apr 12, 2010 at 5:08 PM, Duncan Murdoch
>>>  wrote:
 On 12/04/2010 10:51 AM, Michael Dewey wrote:
> 
> When I run R CMD check on a package I have recently started work
> on I get the following: 
> 
> * checking R code for possible problems ... NOTE
> addlinear: no visible binding for global variable 'x'
> 
> I appreciate that this is only a NOTE and so I assume is R's
> equivalent of 'This is perfectly legal but I wonder whether it is
> really what you intended' but I would like to understand it.
> 
> In the relevant function addlinear the following function is
> defined locally: 
> 
>    orfun <- function(x, oddsratio) {1/(1+1/(oddsratio *
> (x/(1-x} 
> 
> and then used later in curve
> 
>       curve(orfun(x, exp(estimate)), from = 0.001, to = 0.999,
> add = TRUE) 
> 
> These are the only occurrences of 'x'.
> 
> Is it just telling me that I have never assigned a value to x? Or
> is it more sinister than that? As far as I can tell the function
> does what I intended.
 
 The curve() function evaluates the first argument in a strange
 way, and this confuses the code checking.  (The variable name "x"
 is special to curve().) 
 
 I think you can avoid the warning by rewriting that call to
 curve() as 
 
 curve(function(x) orfun(x, exp(estimate)), from = 0.001, to =
 0.999, add = TRUE)
>>> 
>>> ...or
>>> 
>>> x <- NULL; rm(x); # Dummy to trick R CMD check curve(orfun(x,
>>> exp(estimate)), from = 0.001, to = 0.999, add = TRUE)
>> 
>> Or we could come up with a scheme to telling the usage checking
>> functions in codetools that some some or all arguments of certain
>> functions are evaluated in odd ways so it should not check them. 
>>   E.g.,   irregularUsage(curve, expr) irregularUsage(lm, subset,
>>   formula) # subset and formula arguments of lm
>> irregularUsage(expression, ...) # ... arguments to expression 
>> Perhaps one could add such indications to the NAMESPACE file or to a
>> new file in a package.  The former is kludgy but the latter requires
>> changes to the packaging system.
>> 
> 
> This is done at the moment in a very ad hoc way for functions in the
> core packages.  I will make a note to add something for curve.  This
> is an interesting case, as only the variable 'x' should be viewed as
> special for code analysis purposes if I understand the intent in
> curve properly.
> 
> Providing a mechanism for user functions to be annotated for code
> analysis might be useful, and might help in making the handling of
> core package functions with special evaluation rulesa little less ad
> hloc.  On the other hand I'm not sure I want to do anything that
> encourages further use of nonstantard evaluation in new code.
> 
> luke
> 
>> Bill Dunlap
>> Spotfire, TIBCO Software
>> wdunlap tibco.com
>> 
>> 
>>> 
>>> /Henrik
>>> 
 
 Duncan Murdoch
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel
 
>>> 
>>> __
>>> R-devel@r-pr