Re: [Rd] Unexpected failure when calling new() with unnamed arg and

[Joshua Wiley]

Hi Martin,

Thanks and apologies for not seeing that.  I had checked NEWS but not tried
it in R devel.

Thanks again.

Josh


On Thu, Oct 8, 2015 at 10:03 PM, Martin Maechler <maech...@stat.math.ethz.ch
> wrote:

> >>>>> Joshua Wiley <jwiley.ps...@gmail.com>
> >>>>> on Thu, 8 Oct 2015 12:19:16 +1100 writes:
>
> > Hi, I realize this is an old thread, but just wondering
> > whether a conclusion was ever reached on this issue?  I'm
> > using formula(NULL) but it would be nice if default
> > initialization worked for formula classes as well.
>
> Well,
> yes "of course", it was fixed quite a while ago ..
> as I had ("almost") promissed (below).
>
> Fixed only for R-devel though, e.g., because it potentially
> requires package re-installation, etc.
>
> Martin
>
> > Cheers,
> > Josh
>
>
> > On Thu, May 14, 2015 at 8:13 AM, Hervé Pagès
> > <hpa...@fredhutch.org> wrote:
>
> >> Thanks Martin for looking into this.  H.
> >>
> >>
> >> On 05/13/2015 03:57 AM, Martin Maechler wrote:
> >>
> >>> Hervé Pagès <hpa...@fredhutch.org>
> >>>>>>>> on Tue, 12 May 2015 15:18:42 -0700 writes:
> >>>>>>>>
> >>>>>>>
> >>> Hi,
> >>>>
> >>>
> >>> The man page for new() suggests that if 'a' is an object
> >>> with slots
> >>>> "slot1" and "slot2" and C is a class that extends the
> >>>> class of 'a', then the 2 following calls should be
> >>>> equivalent:
> >>>>
> >>>
> >>> new("C", a, ...)
> >>>> new("C", slot1=a@slot1, slot2=a@slot2, ...)
> >>>>
> >>>
> >>> This is generally the case but I just ran into a
> >>> situation where it's
> >>>> not. In the following example the former fails while
> >>>> the latter works:
> >>>>
> >>>
> >>> setClass("A", representation(slot1="numeric",
> >>> slot2="logical"))
> >>>> setClass("B", contains="A",
> >>>> representation(design="formula")) setClass("C",
> >>>> contains="B") a <- new("A", slot1=77, slot2=TRUE)
> >>>>
> >>>
> >>> new("C", a, design=x ~ y) # fails
> >>>> new("C", slot1=a@slot1, slot2=a@slot2, design=x ~ y) #
> >>>> works
> >>>>
> >>>
> >>> Note that new("B", a, design=x ~ y) works so the 3-level
> >>> class
> >>>> hierarchy is really needed in order to reproduce.
> >>>>
> >>>
> >>> Probably related to this, I also noted that new("B")
> >>> and/or new("C")
> >>>> return invalid objects:
> >>>>
> >>>
> >>> c <- new("C")
> >>>>
> >>>
> >>> validObject(c)
> >>>> # Error in validObject(c) : # invalid class “C” object:
> >>>> invalid object for slot "design" # in class "C": got
> >>>> class "S4", should be or extend class "formula"
> >>>>
> >>>
> >>> is(c@design, "formula")
> >>>> # [1] FALSE
> >>>>
> >>>
> >>> class(c@design)
> >>>> # [1] "S4"
> >>>>
> >>>
> >>> Note that 'c' can be fixed:
> >>>>
> >>>
> >>> c@design <- formula(NULL)
> >>>>
> >>>
> >>> validObject(c)
> >>>> # [1] TRUE
> >>>>
> >>>
> >>> Maybe something that the default "initialize" method
> >>> should take care
> >>>> of?
> >>>>
> >>>
> >>> Another singularity that is maybe at the root of all of
> >>> this is that
> >>>> the "formula" S4 class is 

Re: [Rd] Unexpected failure when calling new() with unnamed arg and

[Joshua Wiley]

Hi,

I realize this is an old thread, but just wondering whether a conclusion
was ever reached on this issue?  I'm using formula(NULL) but it would be
nice if default initialization worked for formula classes as well.

Cheers,

Josh


On Thu, May 14, 2015 at 8:13 AM, Hervé Pagès  wrote:

> Thanks Martin for looking into this.  H.
>
>
> On 05/13/2015 03:57 AM, Martin Maechler wrote:
>
>> Hervé Pagès 
>>>  on Tue, 12 May 2015 15:18:42 -0700 writes:
>>>
>>
>> Hi,
>>>
>>
>> The man page for new() suggests that if 'a' is an object with slots
>>> "slot1" and "slot2" and C is a class that extends the class of 'a',
>>> then the 2 following calls should be equivalent:
>>>
>>
>> new("C", a, ...)
>>> new("C", slot1=a@slot1, slot2=a@slot2, ...)
>>>
>>
>> This is generally the case but I just ran into a situation where it's
>>> not. In the following example the former fails while the latter works:
>>>
>>
>> setClass("A", representation(slot1="numeric", slot2="logical"))
>>> setClass("B", contains="A", representation(design="formula"))
>>> setClass("C", contains="B")
>>> a <- new("A", slot1=77, slot2=TRUE)
>>>
>>
>> new("C", a, design=x ~ y)  # fails
>>> new("C", slot1=a@slot1, slot2=a@slot2, design=x ~ y)  # works
>>>
>>
>> Note that new("B", a, design=x ~ y) works so the 3-level class
>>> hierarchy is really needed in order to reproduce.
>>>
>>
>> Probably related to this, I also noted that new("B") and/or new("C")
>>> return invalid objects:
>>>
>>
>> c <- new("C")
>>>
>>
>> validObject(c)
>>> # Error in validObject(c) :
>>> #  invalid class “C” object: invalid object for slot "design"
>>> #  in class "C": got class "S4", should be or extend class "formula"
>>>
>>
>> is(c@design, "formula")
>>> # [1] FALSE
>>>
>>
>> class(c@design)
>>> # [1] "S4"
>>>
>>
>> Note that 'c' can be fixed:
>>>
>>
>> c@design <- formula(NULL)
>>>
>>
>> validObject(c)
>>> # [1] TRUE
>>>
>>
>> Maybe something that the default "initialize" method should take care
>>> of?
>>>
>>
>> Another singularity that is maybe at the root of all of this is that
>>> the "formula" S4 class is virtual:
>>>
>>
>> showClass("formula")
>>> # Virtual Class "formula" [package "methods"]
>>> #
>>> # Slots:
>>> #
>>> # Name:   .S3Class
>>> # Class: character
>>> #
>>> # Extends: "oldClass"
>>>
>>
>> so a bare call to new("formula") fails:
>>>
>>
>> new("formula")
>>> # Error in new("formula") :
>>> #   trying to generate an object from a virtual class ("formula")
>>>
>>
>> Shouldn't new("formula") just return an "empty" S3 formula (like
>>> formula(NULL) does), in the same way that new("integer") returns
>>> an empty ordinary integer vector?
>>>
>>
>> Interesting .. and at least worth following.
>>
>> One problem and historical reason for the current setup seems
>> that the "formula" S3 class is not from 'base' but 'stats' :
>>
>> R's source, src/library/methods/R/BasicClasses.R,
>> lines 524 ff has the following comment block
>>
>> |  .OldClassesPrototypes is a list of S3 classes for which prototype
>> |  objects are known & reasonable.  The classes will reappear in
>> |  .OldClassesList, but will have been initialized first in
>> |  .InitBasicClasses.  NB:  the methods package will NOT set up
>> |  prototypes for S3 classes except those in package base and for "ts"
>> |  (and would rather not do those either).  The package that owns the
>> |  S3 class should have code to call setOldClass in its
>> |  initialization.
>>
>> So, when John Chambers wrote this, he envisioned that the
>> 'stats' package would do "the correct thing" for its own classes.
>> OTOH, as history went, the stats package was never allowed to
>> depend on methods.
>> There are many other S3 classes from 'stats' which also end up
>> similarly, being defined via  setOldClass() and that itself
>> produces a VIRTUAL class.
>> Also, another part of the (R source) comment above is no longer
>> quite accurate, e.g., "data.frame" is in .OldClassesPrototypes
>> but not in .OldClassesList ...
>>
>> As I do agree that "formula" is much more basic than these other classes,
>> I'm currently looking at tweaks to the methods (and stats) code,
>> to get this to work as indeed - you mentioned above -  we
>> already allow "empty S3 formula" objects anyway.
>>
>> ... half an hour later : Indeed, I've been able to use the above
>> information
>> such that  new("formula") and new("formula", y ~ x)
>> work.
>>
>> However, your code above now --- with my changes --- would  fail :
>>
>>   > setClass("A", representation(slot1="numeric", slot2="logical"))
>>   > setClass("B", contains="A", representation(design="formula"))
>>   > setClass("C", contains="B")
>>   Error in reconcilePropertiesAndPrototype(name, slots, prototype,
>> superClasses,  :
>> "B" is not eligible to be the data part of another class (must be a
>> basic 

Re: [Rd] no visible binding for global variable for data sets in a package

[Joshua Wiley]

I have had similar notes, but in cases where the dataset was created
internally by a function:

* checking R code for possible problems ... NOTE
vm_diagnostics: no visible binding for global variable 'Median'
vm_diagnostics: no visible binding for global variable 'Index'
vm_diagnostics: no visible binding for global variable 'LL'
vm_diagnostics: no visible binding for global variable 'UL'

and the relevant code is here (the function creates a dataset called
'sigma' and always names the variables Index, Median, LL, UL):

  p.sigma - ggplot(sigma, aes(Index, Median, ymin = LL, ymax = UL)) +
geom_pointrange() +
labs(y = Median + 95% CI for Sigma) +
theme_classic()

is the appropriate way to remove warnings in this case also to have the
function attach the data it internally created?




On Wed, Aug 27, 2014 at 8:09 PM, peter dalgaard pda...@gmail.com wrote:

 The change would seem to be this

   \item \command{R CMD check} now by default checks code usage
   directly on the package namespace without loading and attaching
   the package and its suggests and enhances.

 and perhaps the remedies could be stated more clearly?

 Putting the data objects in the namespace would seem the obvious thing to
 do.

 One oddity is that they are sort of in there already:

  Lahman::battingLabels
 variable label
 1   playerIDPlayer ID code
 2 yearID  Year
 3  stintPlayer's stint
 4 teamID  Team
 5   lgIDLeague
 6  G Games
 7  G_batting   Games as batter
 8 AB   At Bats
 9  R  Runs
 10 H  Hits
 11   X2B   Doubles
 12   X3B   Triples
 13HR  Homeruns
 14   RBIRuns Batted In
 15SB  Stolen Bases
 16CS   Caught Stealing
 17BB Base on Balls
 18SOStrikeouts
 19   IBB Intentional walks
 20   HBP  Hit by pitch
 21SHSacrifice hits
 22SF   Sacrifice flies
 23  GIDPGrounded into double plays
 24 G_Old Old version of games (deprecated)

 But then again, actually not:

  Lahman::Label()
 Error in rbind(battingLabels, pitchingLabels, fieldingLabels) :
   object 'battingLabels' not found

 This is documented (:: can access datasets made available by
 lazy-loading), but it sort of suggests that we might want to improve
 consistency in this area.

 -pd


 On 27 Aug 2014, at 11:24 , Martin Maechler maech...@stat.math.ethz.ch
 wrote:

  Michael Friendly frien...@yorku.ca
 on Tue, 26 Aug 2014 17:58:34 -0400 writes:
 
  I'm updating the Lahman package of baseball statistics to the 2013
  release. In addition to
  the main data sets, the package also contains several convenience
  functions that make use
  of these data sets.  These now trigger the notes below from R CMD check
  run with
  Win builder, R-devel.  How can I avoid these?
 
  * using R Under development (unstable) (2014-08-25 r66471)
  * using platform: x86_64-w64-mingw32 (64-bit)
  ...
  * checking R code for possible problems ... NOTE
  Label: no visible binding for global variable 'battingLabels'
  Label: no visible binding for global variable 'pitchingLabels'
  Label: no visible binding for global variable 'fieldingLabels'
  battingStats: no visible binding for global variable 'Batting'
  battingStats: no visible global function definition for 'mutate'
  playerInfo: no visible binding for global variable 'Master'
  teamInfo: no visible binding for global variable 'Teams'
 
  One such function:
 
  ## function for accessing variable labels
 
  Label - function(var, labels=rbind(battingLabels, pitchingLabels,
  fieldingLabels)) {
  wanted - which(labels[,1]==var)
  if (length(wanted)) labels[wanted[1],2] else var
  }
 
  and you are using the data sets you mentioned before,
  (and the checking has been changed recently here).
 
  This is a bit subtle:
  Your data sets are part of your package (thanks to the default
  lazyData), but *not* part of the namespace of your package.
  Now, the reasoning goes as following: if someone uses a function
  from your package, say Label() above,
  by
Lahman::Label(..)
  and your package has not been attached to the search path,
  your user will get an error, as the datasets are not found by
  Label().
 
  If you consider something like   Lahman::Label(..)
  for a bit and the emphasis we put on R functions being the
  primary entities, you can understand the current, i.e. new,
  R CMD check warnings.
 
  I see the following two options for you:
 
  1) export all 

Re: [Rd] How to (appropropriately) use require in a package?

[Joshua Wiley]

Dear Professor Ripley,

PkgB does not need to be on the search path---importing into the namespace
is fine.  I did not realize that namespace scoping ensured that if a
cluster is created from within a package, that packages entire environment
tree is available on all the workers.
I tried to apply how makeCluster works from an interactive R session, where
functions from packages that are loaded when the cluster is created are not
available on the workers, to how it works from within a package.

Thanks for your reply,

Josh



On Fri, Aug 8, 2014 at 4:47 PM, Prof Brian Ripley rip...@stats.ox.ac.uk
wrote:

 The safe, elegant way to do this is to use namespace scoping: it is still
 not at all clear why 'other code' needs PkgB *on the search path*.

 In other cases seen in CRAN submissions, 'other code' has been in PkgA's
 namespace, and hence things in PkgB's exports have been visible as it was
 imported by PkgA and hence in the environment tree for functions in PkgA.
  Then namespace scoping will ensure that PkgB's namespace is loaded on the
 cluster workers.



 On 08/08/2014 00:58, Joshua Wiley wrote:

 Someone kindly pointed out that it is not clear from my email why Depends
 will not work.  A more complete example is:

 PkgA:
 f - function(ncores) {
cl - makeCluster(ncores)

clusterEvalQ(cl, {
  require(PkgB)
})
[other code]

### this is the code I want to work and need to be able to call
### PkgB functions on each of the cluster slaves
output - parLapply(cl, 1:n, function(i) {
  [code from my package and using some functions from PkgB]
})

 }

 As far as I know, just because I add PkgB to the Depends (or imports,
 whatever) of PkgA, does not mean that the cluster started by PkgA will
 automatically have PkgB loaded and functions available.

 Thanks!



 On Fri, Aug 8, 2014 at 9:35 AM, Joshua Wiley jwiley.ps...@gmail.com
 wrote:

  Dear All,

 What is the preferred way for Package A, to initialize a cluster, and
 load
 Package B on all nodes?

 I am writing a package that parallelizes some functions through the use
 of
 a cluster if useRs are on a Windows machine (using parLapply and family).
   I also make use of another package in some of my code, so it is
 necessary
 to load the required packages on each slave once the cluster is started.

 Right now, I have done this, by evaluating require(packages) on each
 slave; however, Rcmd check has a note that I should remove the require
 in
 my code.

 Thanks!

 Josh

 --
 Joshua F. Wiley
 Ph.D. Student, UCLA Department of Psychology
 http://joshuawiley.com/
 Senior Analyst, Elkhart Group Ltd.
 http://elkhartgroup.com
 Office: 260.673.5518






 --
 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




-- 
Joshua F. Wiley
Ph.D. Student, UCLA Department of Psychology
http://joshuawiley.com/
Senior Analyst, Elkhart Group Ltd.
http://elkhartgroup.com
Office: 260.673.5518

[[alternative HTML version deleted]]

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

[Rd] How to (appropropriately) use require in a package?

[Joshua Wiley]

Dear All,

What is the preferred way for Package A, to initialize a cluster, and load
Package B on all nodes?

I am writing a package that parallelizes some functions through the use of
a cluster if useRs are on a Windows machine (using parLapply and family).
 I also make use of another package in some of my code, so it is necessary
to load the required packages on each slave once the cluster is started.

Right now, I have done this, by evaluating require(packages) on each slave;
however, Rcmd check has a note that I should remove the require in my
code.

Thanks!

Josh

-- 
Joshua F. Wiley
Ph.D. Student, UCLA Department of Psychology
http://joshuawiley.com/
Senior Analyst, Elkhart Group Ltd.
http://elkhartgroup.com
Office: 260.673.5518

[[alternative HTML version deleted]]

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

Re: [Rd] How to (appropropriately) use require in a package?

[Joshua Wiley]

Someone kindly pointed out that it is not clear from my email why Depends
will not work.  A more complete example is:

PkgA:
f - function(ncores) {
  cl - makeCluster(ncores)

  clusterEvalQ(cl, {
require(PkgB)
  })
  [other code]

  ### this is the code I want to work and need to be able to call
  ### PkgB functions on each of the cluster slaves
  output - parLapply(cl, 1:n, function(i) {
[code from my package and using some functions from PkgB]
  })

}

As far as I know, just because I add PkgB to the Depends (or imports,
whatever) of PkgA, does not mean that the cluster started by PkgA will
automatically have PkgB loaded and functions available.

Thanks!



On Fri, Aug 8, 2014 at 9:35 AM, Joshua Wiley jwiley.ps...@gmail.com wrote:

 Dear All,

 What is the preferred way for Package A, to initialize a cluster, and load
 Package B on all nodes?

 I am writing a package that parallelizes some functions through the use of
 a cluster if useRs are on a Windows machine (using parLapply and family).
  I also make use of another package in some of my code, so it is necessary
 to load the required packages on each slave once the cluster is started.

 Right now, I have done this, by evaluating require(packages) on each
 slave; however, Rcmd check has a note that I should remove the require in
 my code.

 Thanks!

 Josh

 --
 Joshua F. Wiley
 Ph.D. Student, UCLA Department of Psychology
 http://joshuawiley.com/
 Senior Analyst, Elkhart Group Ltd.
 http://elkhartgroup.com
 Office: 260.673.5518




-- 
Joshua F. Wiley
Ph.D. Student, UCLA Department of Psychology
http://joshuawiley.com/
Senior Analyst, Elkhart Group Ltd.
http://elkhartgroup.com
Office: 260.673.5518

[[alternative HTML version deleted]]

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

Re: [Rd] summary of lme4.0 model in package

[Joshua Wiley]

Dear Thierry,

You have lme4.0_0.99-4 attached and  lme4_1.1-5 loaded via a namespace.
 I wonder if changes between the versions and which was getting called when
are making the difference.  In particular, when you source it, I would
assume methods from the attached package are used.  When you use the
function from the package, the methods from the dependencies for the
package would be used.

Cheers,

Josh




On Thu, Apr 3, 2014 at 3:09 AM, ONKELINX, Thierry
thierry.onkel...@inbo.bewrote:

 Dear all,

 My package has Depends: lme4.0 in the DESCRIPTION. I need to extract the
 fixed effect of a model and their standard errors. I use
 coef(summary(model)) inside a function to do that. Model is the output of a
 call to glmer() from the lme4.0 package.

 coef(summary(model)) throws an error: $ operator is invalid for atomic
 vectors

 I have tracked it down to a problem with summary(model) because
 str(summary(model)) gives this

 Classes 'summaryDefault', 'table'  Named chr [1:3] 1 mer S4
   ..- attr(*, names)= chr [1:3] Length Class Mode

 But it should return

 Formal class 'summary.mer' [package lme4.0] with 42 slots
   ..@ methTitle: chr Generalized linear mixed model fit by the Laplace
 approximation
   ..@ logLik   :Class 'logLik' : -2265 (df=12)
 --- output snipped ---

 What puzzles me is that the function gives the error when called from the
 package, but works fine when I source the code of the function manually.

 #this fails
 MyPackage:MyFunction(model)
 #this works
 source(MyPackage/R/MyFunction.R)
 MyFunction(model)

 Any idea on what is going wrong and how to fix this?

 sessionInfo()
 R version 3.0.2 (2013-09-25)
 Platform: i386-w64-mingw32/i386 (32-bit)

 locale:
 [1] LC_COLLATE=Dutch_Belgium.1252  LC_CTYPE=Dutch_Belgium.1252
  LC_MONETARY=Dutch_Belgium.1252
 [4] LC_NUMERIC=C   LC_TIME=Dutch_Belgium.1252

 attached base packages:
 [1] stats graphics  grDevices utils datasets  methods   base

 other attached packages:
 [1] sendmailR_1.1-2   base64enc_0.1-1   ABV_0.2-21
  lme4.0_0.99-4 lattice_0.20-28   Matrix_1.1-3

 loaded via a namespace (and not attached):
  [1] AFLP_0.4.0-66   colorspace_1.2-4dichromat_2.0-0
 digest_0.6.4Epi_1.1.63
  [6] fortunes_1.5-2  ggplot2_0.9.3.1.99  grid_3.0.2
  gridExtra_0.9.1 gtable_0.1.2
 [11] labeling_0.2lme4_1.1-5  lubridate_1.3.3
 MASS_7.3-30 memoise_0.1
 [16] mgcv_1.7-28 minqa_1.2.3 multcomp_1.3-2
  munsell_0.4.2   mvtnorm_0.9-9997
 [21] nlme_3.1-115permute_0.8-3   plyr_1.8.1
  proto_0.3-10RColorBrewer_1.0-5
 [26] Rcpp_0.11.1 RcppEigen_0.3.2.1.1 reshape_0.8.4
 reshape2_1.2.2  RODBC_1.3-10
 [31] sandwich_2.3-0  scales_0.2.3seqinr_3.0-9
  signal_0.7-3splines_3.0.2
 [36] stats4_3.0.2stringr_0.6.2   survival_2.37-7
 TH.data_1.0-3   tools_3.0.2
 [41] vegan_2.1-41watervogels_0.5-51  xtable_1.7-3zoo_1.7-11


 Best regards,

 Thierry


 ir. Thierry Onkelinx
 Instituut voor natuur- en bosonderzoek / Research Institute for Nature and
 Forest
 team Biometrie  Kwaliteitszorg / team Biometrics  Quality Assurance
 Kliniekstraat 25
 1070 Anderlecht
 Belgium
 + 32 2 525 02 51
 + 32 54 43 61 85
 thierry.onkel...@inbo.be
 www.inbo.be

 To call in the statistician after the experiment is done may be no more
 than asking him to perform a post-mortem examination: he may be able to say
 what the experiment died of.
 ~ Sir Ronald Aylmer Fisher

 The plural of anecdote is not data.
 ~ Roger Brinner

 The combination of some data and an aching desire for an answer does not
 ensure that a reasonable answer can be extracted from a given body of data.
 ~ John Tukey


 * * * * * * * * * * * * * D I S C L A I M E R * * * * * * * * * * * * *
 Dit bericht en eventuele bijlagen geven enkel de visie van de schrijver
 weer en binden het INBO onder geen enkel beding, zolang dit bericht niet
 bevestigd is door een geldig ondertekend document.
 The views expressed in this message and any annex are purely those of the
 writer and may not be regarded as stating an official position of INBO, as
 long as the message is not confirmed by a duly signed document.

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




-- 
Joshua Wiley
Ph.D. Student, Health Psychology
University of California, Los Angeles
http://joshuawiley.com/
Senior Analyst - Elkhart Group Ltd.
http://elkhartgroup.com
260.673.5518

[[alternative HTML version deleted]]

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

Re: [Rd] ifelse can't return a list? Please explain (R-2.15.3)

[Joshua Wiley]

Hi Paul,

Wonder why this is an R devel thing?

ifelse is vectorizedthere should be logical conditions matching
the length of the output.

ifelse(c(1, 1, 1), list(a=2, b=3, c=4), list(d=1, e=2, f=3))

otherwise it is truncated.  Also note that both results have to be
valid, because both are typically evaluated.

Cheers,

Josh

On Sun, Mar 24, 2013 at 7:21 PM, Paul Johnson pauljoh...@gmail.com wrote:
 I hope you are doing well.

 For me, this was an unexpected problem. I've hoped for quite a few
 wrong things today, but I'm only asking you about this one. Why does

 ifelse(1, list(a, b, c), list(x, y, z))

 return a list with only a, not list(a, b, c) as I hoped.  I wish it
 would either
 cause an error or return the whole list, not just the first thing.

 Working example:

 x - 1
 y - 2
 z - 3
 a - 4
 b - 5
 c - 6
 list(x,y,z)
 [[1]]
 [1] 1

 [[2]]
 [1] 2

 [[3]]
 [1] 3

 list(a,b,c)
 [[1]]
 [1] 4

 [[2]]
 [1] 5

 [[3]]
 [1] 6

 ifelse(1, list(a,b,c), list(x,y,z))
 [[1]]
 [1] 4

 ifelse(0, list(a,b,c), list(x,y,z))
 [[1]]
 [1] 1


 sessionInfo()
 R version 2.15.3 (2013-03-01)
 Platform: x86_64-pc-linux-gnu (64-bit)

 locale:
  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
  [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
  [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
  [7] LC_PAPER=C LC_NAME=C
  [9] LC_ADDRESS=C   LC_TELEPHONE=C
 [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

 attached base packages:
 [1] stats graphics  grDevices utils datasets  methods   base

 other attached packages:
 [1] rockchalk_1.5.5.10 car_2.0-16 nnet_7.3-5 MASS_7.3-23

 loaded via a namespace (and not attached):
 [1] compiler_2.15.3 tools_2.15.3


 I realize I can code around this, but I'm just curious about why
 ifelse hates me so much :(

 if (1) myvar - list(a, b, c) else myvar - list(x, y, z)
 myvar
 [[1]]
 [1] 4

 [[2]]
 [1] 5

 [[3]]
 [1] 6

 myvar - if (1) list(a, b, c) else list(x, y, z)
 myvar
 [[1]]
 [1] 4

 [[2]]
 [1] 5

 [[3]]
 [1] 6


 --
 Paul E. Johnson
 Professor, Political Science  Assoc. Director
 1541 Lilac Lane, Room 504  Center for Research Methods
 University of Kansas University of Kansas
 http://pj.freefaculty.org   http://quant.ku.edu

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



-- 
Joshua Wiley
Ph.D. Student, Health Psychology
University of California, Los Angeles
http://joshuawiley.com/
Senior Analyst - Elkhart Group Ltd.
http://elkhartgroup.com

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

Re: [Rd] Found explanation for R-2.15.2 slowdown in one case; caution for any users of La_chol

[Joshua Wiley]

On Sat, Dec 15, 2012 at 8:29 PM, Paul Johnson pauljoh...@gmail.com wrote:
 On Sat, Dec 15, 2012 at 11:44 AM, Uwe Ligges
 lig...@statistik.tu-dortmund.de wrote:

 That is the reason why R CMD check gives a WARNING in the checks of your
 package for quite some time now:

 checking foreign function calls ... WARNING

 Foreign function calls with 'PACKAGE' argument in a base package:
 .Call(La_chol, ..., PACKAGE = base)
 .Call(La_chol2inv, ..., PACKAGE = base)
 Packages should not make .C/.Call/.Fortran calls to base packages. They
 are not part of the API, for use only by R itself and subject to change
 without notice.

[snip]

 Now, when I install that, I don't see a warning. (see below).

You won't on an install.  Uwe specifically mentioned Rcmd check which
runs more tests and checks than are done during a simple install.

Rcmd check really does catch a lot (there's even been some noise on
this list that it catches *too much*) so if you're having trouble with
a package, it is probably a reasonable place to start with the most
rigorous set of package checks, and then go from there.

Cheers,

Josh


--
Joshua Wiley
Ph.D. Student, Health Psychology
Programmer Analyst II, Statistical Consulting Group
University of California, Los Angeles
https://joshuawiley.com/

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

Re: [Rd] Quiz: How to get a named column from a data frame

[Joshua Wiley]

On Sat, Aug 18, 2012 at 9:33 AM, Martin Maechler
maech...@stat.math.ethz.ch wrote:
 Joshua Ulrich josh.m.ulr...@gmail.com
 on Sat, 18 Aug 2012 10:16:09 -0500 writes:

  I don't know if this is better, but it's the most obvious/shortest I
  could come up with.  Transpose the data.frame column to a 'row' vector
  and drop the dimensions.

 R identical(nv, drop(t(df)))
  [1] TRUE

 Yes, that's definitely shorter,
 congratulations!

 One gotta is that I'd want a solution that also works when the
 df has more columns than just one...

 Your idea to use  t(.) is nice and perfect insofar as it
 coerces the data frame to a matrix, and that's really the clue:

 Where as  df[,1]  is losing the names,
 the matrix indexing is not.
 So your solution can be changed into

  t(df)[1,]

 which is even shorter...
 and slightly less efficient, at least conceptually, than mine, which has
 been

as.matrix(df)[,1]

 Now, the remaining question is:  Shouldn't there be something
 more natural to achieve that?
 (There is not, currently, AFAIK).

Perhaps a data frame method for as.vector?

as.vector.data.frame - function(x, ...) as.matrix(x)[,1]
as.vector(df[1])

or an additional argument to `[.data.frame` like keep.names, which
defaults to FALSE to maintain current behavior but can optionally be
TRUE.

Cheers,

Josh


 Martin


  Best,
  --
  Joshua Ulrich  |  about.me/joshuaulrich
  FOSS Trading  |  www.fosstrading.com


  On Sat, Aug 18, 2012 at 10:03 AM, Martin Maechler
  maech...@stat.math.ethz.ch wrote:
  Today, I was looking for an elegant (and efficient) way to get a named
  (atomic) vector by selecting one column of a data frame.  Of course,
  the vector names must be the rownames of the data frame.
 
  Ok, here is the quiz, I know one quite cute/slick answer, but was
  wondering if there are obvious better ones, and also if this should
  not become more idiomatic (hence R-devel):
 
  Consider this toy example, where the dataframe already has only one
  column :
 
  nv - c(a=1, d=17, e=101); nv
  a   d   e
  1  17 101
 
  df - as.data.frame(cbind(VAR = nv)); df
  VAR
  a   1
  d  17
  e 101
 
  Now how, can I get 'nv' back from 'df' ?   I.e., how to get
 
  identical(nv, ...)
  [1] TRUE
 
  where .. only uses 'df' (and no non-standard R packages)?
 
  As said, I know a simple solution (*), but I'm sure it is not
  obvious to most R users and probably not even to the majority of
  R-devel readers... OTOH, people like Bill Dunlap will not take
  long to provide it or a better one.
 
  (*) In my solution, the above '...' consists of 17 letters.
  I'll post it later today (CEST time) ... or confirm
  that someone else has done so.
 
  Martin
 
  __
  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



-- 
Joshua Wiley
Ph.D. Student, Health Psychology
Programmer Analyst II, Statistical Consulting Group
University of California, Los Angeles
https://joshuawiley.com/

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

Re: [Rd] columnames changes behaviour of formula

[Joshua Wiley]

Hi Robin,

Seems like the intended behavior to me.  From the docs:
There are two special interpretations of '.' in a formula.  The usual
one is in the context of a 'data' argument of model fitting functions
and means 'all columns not otherwise in the formula' 

d is in the formula so the only column not in the formula is nd.  the
(.)^2 asks for all two way interactions, but with only one variable,
there are none.

What were you expecting?

Josh

On Thu, May 24, 2012 at 9:25 PM, robin hankin hankin.ro...@gmail.com wrote:
 Hello. precompiled R-2.15.0, svn58871, macosx 10.7.4.


 I have discovered that defining column names of a dataframe can alter the
 behaviour of lm():


 d - c(4,7,6,4)
 x - data.frame(cbind(0:3,5:2))
 coef(lm(d~ -1 + (.)^2,data=x))
   X1    X2 X1:X2
 -1.77  0.83  1.25
 R
 R


 OK, so far so good.  But change the column names of 'x' and the behaviour
 changes:


 colnames(x) - c(d,nd)   # 'd' == 'death' and 'nd' == 'no death'
 coef(lm(d~ -1 + (.)^2,data=x))
       nd
 0.2962963



 I am not sure if this is consistent with the special meaning of '.'
 described under ?formula.

 Is this the intended behaviour?


 --
 Robin Hankin
 Uncertainty Analyst
 hankin.ro...@gmail.com

        [[alternative HTML version deleted]]

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



-- 
Joshua Wiley
Ph.D. Student, Health Psychology
Programmer Analyst II, Statistical Consulting Group
University of California, Los Angeles
https://joshuawiley.com/

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

Re: [Rd] columnames changes behaviour of formula

[Joshua Wiley]

P.S. It really is sloppy code to mix variables from the global
environment with those inside a data frame. I.e.:

coef(lm(d ~ -1 + (.)^2, data = x))

the only time I think it makes sense to have different objects for the
outcome and predictors are when for speed purposes, you are using a
low level function, such as lm.fit or fastLmPure from the RcppEigen
package.


On Thu, May 24, 2012 at 9:46 PM, Joshua Wiley jwiley.ps...@gmail.com wrote:
 Hi Robin,

 Seems like the intended behavior to me.  From the docs:
 There are two special interpretations of '.' in a formula.  The usual
 one is in the context of a 'data' argument of model fitting functions
 and means 'all columns not otherwise in the formula' 

 d is in the formula so the only column not in the formula is nd.  the
 (.)^2 asks for all two way interactions, but with only one variable,
 there are none.

 What were you expecting?

 Josh

 On Thu, May 24, 2012 at 9:25 PM, robin hankin hankin.ro...@gmail.com wrote:
 Hello. precompiled R-2.15.0, svn58871, macosx 10.7.4.


 I have discovered that defining column names of a dataframe can alter the
 behaviour of lm():


 d - c(4,7,6,4)
 x - data.frame(cbind(0:3,5:2))
 coef(lm(d~ -1 + (.)^2,data=x))
   X1    X2 X1:X2
 -1.77  0.83  1.25
 R
 R


 OK, so far so good.  But change the column names of 'x' and the behaviour
 changes:


 colnames(x) - c(d,nd)   # 'd' == 'death' and 'nd' == 'no death'
 coef(lm(d~ -1 + (.)^2,data=x))
       nd
 0.2962963



 I am not sure if this is consistent with the special meaning of '.'
 described under ?formula.

 Is this the intended behaviour?


 --
 Robin Hankin
 Uncertainty Analyst
 hankin.ro...@gmail.com

        [[alternative HTML version deleted]]

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



 --
 Joshua Wiley
 Ph.D. Student, Health Psychology
 Programmer Analyst II, Statistical Consulting Group
 University of California, Los Angeles
 https://joshuawiley.com/



-- 
Joshua Wiley
Ph.D. Student, Health Psychology
Programmer Analyst II, Statistical Consulting Group
University of California, Los Angeles
https://joshuawiley.com/

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

Re: [Rd] R package dependency issues when namespace is not attached

[Joshua Wiley]

On Sun, May 13, 2012 at 10:14 AM, Uwe Ligges
lig...@statistik.tu-dortmund.de wrote:


 On 13.05.2012 10:59, Duncan Murdoch wrote:

 On 12-05-13 3:15 AM, Jeroen Ooms wrote:

 I have always assumed that having a package in the 'Depends' field
 would automatically also import the namespace. However, it seems that
 in R 2.15, dependencies do not become available until the package is
 actually attached to the searchpath. Is this intended behavior?

 The problem appears as follows: Suppose there is a package 'Child'
 which Depends, but does not explicitly import a package called
 'Parent' and contains a function that calls out to an object in the
 namespace of 'Parent'. When this function is called without attaching
 'Child' to the search path, the function in 'Parent' cannot be found.

 Here an example from the manual of the bigdata package, but the
 problem is very widespread:

 x = matrix(rnorm(50*80),50,80)
 beta = c(3,2,1.5,rep(0,77))
 y = rnorm(50) + x%*%beta
 z1 = bigdata::lasso.stars(x,y)

 The example fails because lasso.stars depends on 'glmnet' which is not
 loaded until bigdata is attached. The only way to be able to call
 lasso.stars is to actually attach the bigdata package:

 library(bigdata)
 z1 = bigdata::lasso.stars(x,y)

 Now to further complicate things, it seems that this problem is
 inherited to any 'grandchild' package that imports, in this case, the
 lasso.stars function. I have a hard time finding a good example but I
 am sure they are out there.

 Is this a bug? I know that it can be avoided by asking package authors
 to use Imports instead of Depends, but in practice the majority of the
 packages on CRAN still use Depends. It seems like the problem is
 easily fixed if R would automatically import the namespace of any
 Depends packages into to the child package namespace?


 Not sure if it's a bug, but the correct solution in bigdata is to import
 the glmnet function in its NAMESPACE. Then the namespace that gets
 loaded when you type bigdata::lasso.stars will be able to see the glmnet
 function.

 Perhaps Depends in the DESCRIPTION file should do the import
 automatically, but it will be faster to import just one function than
 everything from a package that has a lot of exports. So maybe it's a bug
 because we don't do that, but I think there would be complaints if we did.

 On the other hand, if bigdata::lasso.stars loaded glmnet onto the search
 path, I think that would be a bug. The search path belongs to the user,
 not to R, and the user might have used the :: notation to avoid messing
 with it.


 I do not see any problem in R. If someone is going to import a Namespace, he
 or she has to do that via import directives in the NAMESPACE file. If
 someone is going to have a package on the search path, he or she has to
 require() it. The DESCRIPTION file is used to derive the dependency
 structures among packages for installation order, check order etc.

So should package authors both list a package in the depends of
DESCRIPTION and explicitly import what is needed so if someone else
uses their code without loading the package, everything needed is
available?


 Best,
 Uwe





 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



-- 
Joshua Wiley
Ph.D. Student, Health Psychology
Programmer Analyst II, Statistical Consulting Group
University of California, Los Angeles
https://joshuawiley.com/

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

Re: [Rd] file 2 is not in sorted order error building unsuffered consequences

[Joshua Wiley]

On Tue, May 8, 2012 at 9:35 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote:
 This time it was a similar error on a different file.  Now fixed.

Works wonderfully now, thank you so much, Duncan!


 Duncan Murdoch


 On 08/05/2012 11:20 AM, Joshua Wiley wrote:

 On Tue, May 8, 2012 at 3:48 AM, Duncan Murdochmurdoch.dun...@gmail.com
  wrote:
   On 12-05-08 1:46 AM, Joshua Wiley wrote:
 
   Hi All,
 
   I just downloaded the source tar ball (Revision: 59324 Last Changed
   Date: 2012-05-07) and tried to compile on a Win x64 system.  I am
   using Rtools version 2.15.0.1919.  The only change I make is changing
   MkRules.dist -    MkRules.local and setting Multi=64  I have
  previously
   compiled unsuffered consquences without issue, but on the current
   version, I get this error
 
 
   windres -F pe-x86-64  -I../include -i dllversion.rc -o dllversion.o
   comm: file 2 is not in sorted order
   make[3]: *** [R.dll] Error 1
   make[2]: *** [../../bin/x64/R.dll] Error 2
   make[1]: *** [rbuild] Error 2
   make: *** [all] Error 2
 
   I did not note any other errors or warnings earlier on, though I may
   have missed some.  I can provide the full log if requested.  Any
   ideas?
 
 
   I believe that message is about the file src/gnuwin32/Rdll.hide.  It is
   supposed to be sorted, using ASCII collation order.  I believe the
  version
   in the repository is sorted properly; can you check yours?

 Thanks for your reply.  It looks sorted correctly and explicitly
 sorting prior to running make does not change the error.  here is a
 bit of output:

 BZ2_bzBuffToBuffCompress@28
 BZ2_bzBuffToBuffDecompress@24
 BZ2_bzCompress@8
 BZ2_bzCompressEnd@4
 BZ2_bzCompressInit@16
 BZ2_bzDecompress@4
 BZ2_bzDecompressEnd@4
 BZ2_bzDecompressInit@12
 BZ2_bzRead@16
 BZ2_bzReadClose@8
 BZ2_bzReadGetUnused@16
 BZ2_bzReadOpen@24
 BZ2_bzWrite@16
 BZ2_bzWriteClose64@28
 BZ2_bzWriteClose@20

 
   We've had some problems with recent versions of Cygwin not sorting
  properly.
     The last instance had it put names in the order
 
     BZ2_bzWriteClose@20
     BZ2_bzWriteClose64@28
 
   but ASCII order should put @ after 6.  Are you using the comm and
  Cygwin
   dlls from Rtools, or have you got newer ones?

 As far as I know I should only be using the dlls from Rtools.  It is
 the first thing on my path environment variable, and although cygwin
 is installed, I do not even have it on my path.  Interestingly, there
 are no problems if set MULTI=32 instead of 64 in MkRules.

 Thanks again,

 Josh

 
   Duncan Murdoch







-- 
Joshua Wiley
Ph.D. Student, Health Psychology
Programmer Analyst II, Statistical Consulting Group
University of California, Los Angeles
https://joshuawiley.com/

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

Re: [Rd] file 2 is not in sorted order error building unsuffered consequences

[Joshua Wiley]

On Tue, May 8, 2012 at 3:48 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote:
 On 12-05-08 1:46 AM, Joshua Wiley wrote:

 Hi All,

 I just downloaded the source tar ball (Revision: 59324 Last Changed
 Date: 2012-05-07) and tried to compile on a Win x64 system.  I am
 using Rtools version 2.15.0.1919.  The only change I make is changing
 MkRules.dist -  MkRules.local and setting Multi=64  I have previously
 compiled unsuffered consquences without issue, but on the current
 version, I get this error


 windres -F pe-x86-64  -I../include -i dllversion.rc -o dllversion.o
 comm: file 2 is not in sorted order
 make[3]: *** [R.dll] Error 1
 make[2]: *** [../../bin/x64/R.dll] Error 2
 make[1]: *** [rbuild] Error 2
 make: *** [all] Error 2

 I did not note any other errors or warnings earlier on, though I may
 have missed some.  I can provide the full log if requested.  Any
 ideas?


 I believe that message is about the file src/gnuwin32/Rdll.hide.  It is
 supposed to be sorted, using ASCII collation order.  I believe the version
 in the repository is sorted properly; can you check yours?

Thanks for your reply.  It looks sorted correctly and explicitly
sorting prior to running make does not change the error.  here is a
bit of output:

BZ2_bzBuffToBuffCompress@28
BZ2_bzBuffToBuffDecompress@24
BZ2_bzCompress@8
BZ2_bzCompressEnd@4
BZ2_bzCompressInit@16
BZ2_bzDecompress@4
BZ2_bzDecompressEnd@4
BZ2_bzDecompressInit@12
BZ2_bzRead@16
BZ2_bzReadClose@8
BZ2_bzReadGetUnused@16
BZ2_bzReadOpen@24
BZ2_bzWrite@16
BZ2_bzWriteClose64@28
BZ2_bzWriteClose@20


 We've had some problems with recent versions of Cygwin not sorting properly.
  The last instance had it put names in the order

  BZ2_bzWriteClose@20
  BZ2_bzWriteClose64@28

 but ASCII order should put @ after 6.  Are you using the comm and Cygwin
 dlls from Rtools, or have you got newer ones?

As far as I know I should only be using the dlls from Rtools.  It is
the first thing on my path environment variable, and although cygwin
is installed, I do not even have it on my path.  Interestingly, there
are no problems if set MULTI=32 instead of 64 in MkRules.

Thanks again,

Josh


 Duncan Murdoch



-- 
Joshua Wiley
Ph.D. Student, Health Psychology
Programmer Analyst II, Statistical Consulting Group
University of California, Los Angeles
https://joshuawiley.com/

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

[Rd] file 2 is not in sorted order error building unsuffered consequences

[Joshua Wiley]

Hi All,

I just downloaded the source tar ball (Revision: 59324 Last Changed
Date: 2012-05-07) and tried to compile on a Win x64 system.  I am
using Rtools version 2.15.0.1919.  The only change I make is changing
MkRules.dist - MkRules.local and setting Multi=64  I have previously
compiled unsuffered consquences without issue, but on the current
version, I get this error


windres -F pe-x86-64  -I../include -i dllversion.rc -o dllversion.o
comm: file 2 is not in sorted order
make[3]: *** [R.dll] Error 1
make[2]: *** [../../bin/x64/R.dll] Error 2
make[1]: *** [rbuild] Error 2
make: *** [all] Error 2

I did not note any other errors or warnings earlier on, though I may
have missed some.  I can provide the full log if requested.  Any
ideas?

Thanks,

Josh


-- 
Joshua Wiley
Ph.D. Student, Health Psychology
Programmer Analyst II, Statistical Consulting Group
University of California, Los Angeles
https://joshuawiley.com/

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

Re: [Rd] CRAN policies

[Joshua Wiley]

)
   anonymous: no visible binding for global variable 'Den' (:1)
 
    checkUsage(function(dataFrame) with(dataFrame, {Num/Den ; Resp ~
 Pred}), skipWith=TRUE)
 
    checkUsage(function(dataFrame) with(DataFrame, {Num/Den ; Resp ~
 Pred}), skipWith=TRUE)
   anonymous: no visible binding for global variable 'DataFrame'
 
  The only part that I don't see is the mechanism to add code-walker
 functions to
  the environment in codetools that has the standard list of them for
 functions with
  nonstandard evaluation:
    objects(codetools:::collectUsageHandlers, all=TRUE)
    [1] $             $-           .Internal
    [4] ::            :::           @
    [7] @-           {             ~
   [10] -            -           =
   [13] assign        binomial      bquote
   [16] data          detach        expression
   [19] for           function      Gamma
   [22] gaussian      if            library
   [25] local         poisson       quasi
   [28] quasibinomial quasipoisson  quote
   [31] Quote         require       substitute
   [34] with

 It seems like we really need a standard way to add metadata to functions:

 attr(with, special_args) - expr
 attr(lm, special_args) - c(formula, weights, subset)

 This would be useful because it could automatically contribute to the
 documentation.

 Similarly,

 attr(my.new.method, s3method) - c(my.new, method)

 could be useful.

 Hadley


 --
 Assistant Professor / Dobelman Family Junior Chair
 Department of Statistics / Rice University
 http://had.co.nz/

 __
 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




 --
 Kevin Wright

        [[alternative HTML version deleted]]

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



-- 
Joshua Wiley
Ph.D. Student, Health Psychology
Programmer Analyst II, Statistical Consulting Group
University of California, Los Angeles
https://joshuawiley.com/

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

Re: [Rd] R 2.14.1 memory management under Windows

[Joshua Wiley]

On Wed, Mar 21, 2012 at 10:14 PM, Spencer Graves
spencer.gra...@prodsyse.com wrote:
 I computed system.time(diag(3)) with R 2.12.0 on Fedora 13 Linux with
 4 GB RAM and with R 2.14.1 on Windows 7 with 8 GB RAM:


 Linux (4 GB RAM):  0, 0.21, 0.21 -- a fifth of a second


 Windows 7 (8 GB RAM):  11.37 7.47 93.19 -- over 1.5 minutes.  Moreover,
 during most of that time, I could not switch windows or get any response
 from the system.  When I first encountered this, I thought Windows was hung
 permanently and the only way out was a hard reset and reboot.


      On both systems, diag(3) generated, Error:  cannot allocate vector
 of size ___ Gb, with ___ = 3.4 for Linux with 4 GB RAM and 6.7 for
 Windows with 8 GB RAM.  Linux with half the RAM and an older version of R
 was done with this in 0.21 seconds.  Windows 7 went into suspension for over
 93 seconds -- 1.5 minutes before giving an error message.


       I don't know how easy this would be to fix under Windows, but I felt a
 need to report it.

This seems like it may be an issue with paging, which Windows has
traditionally not excelled at.  That said, on Windows 7 x64 with 6GB
RAM and another 6GB paging file with R version 2.14.1 (2011-12-22), I
get:

 system.time(diag(3))
Error: cannot allocate vector of size 3.4 Gb
Timing stopped at: 0.01 0 0.01


Cheers,

Josh

so the timing is comparable to nix.


      Best Wishes,
      Spencer


 --
 Spencer Graves, PE, PhD
 President and Chief Technology Officer
 Structure Inspection and Monitoring, Inc.
 751 Emerson Ct.
 San José, CA 95126
 ph:  408-655-4567
 web:  www.structuremonitoring.com

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



-- 
Joshua Wiley
Ph.D. Student, Health Psychology
Programmer Analyst II, Statistical Consulting Group
University of California, Los Angeles
https://joshuawiley.com/

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

Re: [Rd] Jazzing up the Task Views index page

[Joshua Wiley]

Hi,

In a way, a simple text based system is clean and is consistent with
the plain text requirements of the listservs, and interacting with R
through code/text.  However, for people with different backgrounds, it
can seem unappealing.  I definitely believe your page is more
inviting.

I work at a campus statistical consulting center and we are seeing a
substantial increase in researchers and grad students using R.  We
only recently began supporting R, and one thing I have noticed in both
clients and other consultants relatively unfamiliar with R is that
they often seem to not look beyond the core.  In my opinion, this is
partly responsible for the belief that R is difficult to use or that
task X is easier to do in program Y than in R.  I believe that better
marketing and navigability of the task views (which themselves are
excellent lists of packages relevant to particular disciplines or
applications) can help this perception.

Barry, is this a test/example only or would you plan on keeping
something like that on your site even if it is not adopted for cran
task views?  If it is not adopted elsewhere and you are willing to
maintain it, I would like to link to it.

Very nice work!

Cheers,

Josh

On Tue, Feb 21, 2012 at 4:58 AM, Barry Rowlingson
b.rowling...@lancaster.ac.uk wrote:
 A little while ago here we had a short discussion about Task Views - I
 think ignited by someone saying 'how many times do I have to say have
 you read the Optimisation Task View??' and I poured some fuel on that
 fire by saying Task Views was a stupid name.

 Anyway, I did say that Task Views were rather brilliant, but were let
 down by their hidden position on the R web sites (tucked away as the
 third element of a sub-menu of a CRAN mirror site linked to by the
 CRAN link from the Download menu on the main R home page). The index
 page is rather plain, so I designed a more engaging one. The result of
 my effort is now here:

 http://www.maths.lancs.ac.uk/~rowlings/R/TaskViews/

 Having done that, I even considered that something like that could
 replace the R Homepage. Giving new visitors an idea of the vast range
 of techniques and application areas available in R would seem to be
 better than the current graphic which has been there since perhaps
 2004.

 Comments, thoughts, flames, etc?

 Barry

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



-- 
Joshua Wiley
Ph.D. Student, Health Psychology
Programmer Analyst II, Statistical Consulting Group
University of California, Los Angeles
https://joshuawiley.com/

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

Re: [Rd] How to modify the start-up message

[Joshua Wiley]

Hi Ron,

If all you want changed is the message, this seems like a cosmetic
issue.  If that is true, something like this may work where you just
send the unwanted messages to a temporary file and print your own:

require2 - function(x) {
  junk - file(file.path(tempdir(), junk.txt), open = wt)
  sink(junk, type=message)
  eval(substitute(require(pkg), list(pkg = x)))
  sink(type=message)
  if (x == vegan) {
cat(The message I really want showing, fill = TRUE)
  }
}

require2(vegan)

You could rearrange so that it calls require() for most packages and
only does something special for the one package you want changed.

Cheers,

Josh

On Mon, Jan 16, 2012 at 11:30 AM, Ron Michael ron_michae...@yahoo.com wrote:
 Actually this is a paid package and developer was reluctant to distribute the 
 source. Therefore I was exploring whether I could do something by myself. So 
 you are talking about some tools. Are those tools available somewhere over 
 Net, or if it is not still available, is there any plan in any future from R 
 core team to build such one?

 Thanks,


 - Original Message -
 From: Uwe Ligges lig...@statistik.tu-dortmund.de
 To: Ron Michael ron_michae...@yahoo.com
 Cc: r-devel@r-project.org r-devel@r-project.org
 Sent: Monday, 16 January 2012 6:14 PM
 Subject: Re: [Rd] How to modify the start-up message



 On 16.01.2012 12:20, Ron Michael wrote:
 Thanks Uwe for you reply. However you used 'should' which brings some 
 confusion to me! Did you mean that, **it is never possible** to modify those 
 message given I only have windows binary?

 Actually, it may be possible (and I am not sure without reading the
 sources): One could read, implant and write back the databases, but we
 do not have the tools to do that easily, hence some work would be needed
 to find out. Anyway, it simply does not make sense to mess around given
 you just need to ask for the source package in order to change the stuff.

 Best,
 Uwe Ligges




 Thanks,


 - Original Message -
 From: Uwe Liggeslig...@statistik.tu-dortmund.de
 To: Ron Michaelron_michae...@yahoo.com
 Cc: r-devel@r-project.orgr-devel@r-project.org
 Sent: Monday, 16 January 2012 12:03 AM
 Subject: Re: [Rd] How to modify the start-up message



 On 12.01.2012 16:27, Ron Michael wrote:
 Hi all, I got a custom R package in .zip (i.e. meant only for Windows 
 installation). When I load that package, there are some start-up messages, 
 probably loading through .onLoad() function. However I want to modify those 
 messages. Please note that I do not have any other version of that package 
 like .tar.gz fomat etc.

 Having only the .zip version, is there any possibility to modify those 
 start-up functionalities of that package?


 You should always modify packages by applying the changes to the source
 package and reinstall that.  Hence ask those who provided the binary
 package for a source version.

 Uwe Ligges





 Thanks for your help.

 __
 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



-- 
Joshua Wiley
Ph.D. Student, Health Psychology
Programmer Analyst II, Statistical Consulting Group
University of California, Los Angeles
https://joshuawiley.com/

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

Re: [Rd] Subsetting a data frame vs. subsetting the columns

[Joshua Wiley]

On Wed, Dec 28, 2011 at 8:14 AM, Simon Urbanek
simon.urba...@r-project.org wrote:
 Hadley,

 there was a whole discussion about subsetting and subassigning data frames 
 (and general efficiency issues) some time ago (I can't find it in a hurry but 
 others might)

Yep, a rather lengthy discussion at that
http://r.789695.n4.nabble.com/speeding-up-perception-td3640920.html.
IIRC, there was also some off list stuff about what it would take to
push to C, which I may have in my inbox if anyone wants.

Cheers,

Josh

-- just look at the `[.data.frame` code to see why it's so slow. It
would need to be pushed into C code to allow certain optimizations,
but it's a quite complex code so I don't think there were volunteers.
So the advice is don't do it ;). Treating DFs as lists is always
faster since you get to the fast internal code.

 Cheers,
 S


 On Dec 28, 2011, at 10:37 AM, Hadley Wickham wrote:

 Hi all,

 There seems to be rather a large speed disparity in subsetting when
 working with a whole data frame vs. working with just columns
 individually:

 df - as.data.frame(replicate(10, runif(1e5)))
 ord - order(df[[1]])

 system.time(df[ord, ])
 #   user  system elapsed
 #  0.043   0.007   0.059
 system.time(lapply(df, function(x) x[ord]))
 #   user  system elapsed
 #  0.022   0.008   0.029

 What's going on?

 I realise this isn't quite a fair example because the second case
 makes a list not a data frame, but I thought it would be quick
 operation to turn a list into a data frame if you don't do any
 checking:

 list_to_df - function(list) {
  n - length(list[[1]])
  structure(list,
    class = data.frame,
    row.names = c(NA, -n))
 }
 system.time(list_to_df(lapply(df, function(x) x[ord])))
 #    user  system elapsed
 #  0.031   0.017   0.048

 So I guess this is slow because it has to make a copy of the whole
 data frame to modify the structure.  But couldn't [.data.frame avoid
 that?

 Hadley


 --
 Assistant Professor / Dobelman Family Junior Chair
 Department of Statistics / Rice University
 http://had.co.nz/

 __
 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

-- 
Joshua Wiley
Ph.D. Student, Health Psychology
Programmer Analyst II, Statistical Consulting Group
University of California, Los Angeles
https://joshuawiley.com/

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

Re: [Rd] NAMESPACES for data only packages

[Joshua Wiley]

Hi Michael,

You are correct that data does not *have* to be exported.  For
example, here is the contents of NAMESPACE for the datasets package
from a recent devel version:

# This package exports nothing (it uses lazydata)
# exportPattern(.)

Cheers,

Josh

On Tue, Nov 8, 2011 at 9:11 AM, Michael Friendly frien...@yorku.ca wrote:
 the NEWS file for R-devel says

  *

    Even data-only packages without *R* code need a namespace and so may
    need to be installed under *R* 2.14.0 or later.


 but what should this contain?  Can it simply be an empty NAMESPACE
 file?  I assume that data does not have to
 be exported.

 -Michael

 --
 Michael Friendly     Email: friendly AT yorku DOT ca
 Professor, Psychology Dept.
 York University      Voice: 416 736-5115 x66249 Fax: 416 736-5814
 4700 Keele Street    Web:   http://www.datavis.ca
 Toronto, ONT  M3J 1P3 CANADA


        [[alternative HTML version deleted]]

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




-- 
Joshua Wiley
Ph.D. Student, Health Psychology
Programmer Analyst II, ATS Statistical Consulting Group
University of California, Los Angeles
https://joshuawiley.com/

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

Re: [Rd] How do I use the new 'ByteCompile' field in R-2.14?

[Joshua Wiley]

Hi Slava,

Here is what I have in my DESCRIPTION:

ByteCompile: true

seems to work for me.

Cheers,

Josh

On Wed, Nov 2, 2011 at 3:27 AM, Slava Razbash slava.razb...@gmail.com wrote:
 Hello,


 I would like to the use the 'ByteCompile' field in R 2.14. However,
 Writing R Extensions only describes this field, but does not say
 what value it should be set to. How should i use it? Do you have
 examples?

 Is it the same as LazyData: yes?

 Thank you,

 Slava

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




-- 
Joshua Wiley
Ph.D. Student, Health Psychology
Programmer Analyst II, ATS Statistical Consulting Group
University of California, Los Angeles
https://joshuawiley.com/

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

Re: [Rd] cygwing warming when creating a package in windows

[Joshua Wiley]

That. Cygwin warning is expected on Windows.  You can still build the package 
and it should be fine, although it looks like the documentation may need a bit 
of tweaking to pass R CMD check.  2.13.2 is the latest version of R, and I 
would recommend using it over 2.12.2.  Both for the improvements and because 
others on this list tend to have the later version so helping is easier.

Cheers,

Josh

On Oct 18, 2011, at 7:56, Alba Martinez-Ruiz amart...@ucsc.cl wrote:

 Dear All,
 
 I am a beginner creating R packages.  I followed the Leisch (2009) tutorial
 and the document “Writing R Extensions” to write an example.
 
 I installed R 2.12.2 (I also tried R2.13.2),  the last version of Rtools and
 the recommended packages in a PC with Windows 7 Home Premium.
 
 I can run  R CMD INSTALL linmod in the command prompt and the R CMD check
 linmod. The following outputs are obtained:
 
 * installing *source* package 'linmod' ...
 ** R
 ** preparing package for lazy loading
 ** help
 *** installing help indices
 ** building package indices ...
 ** testing if installed package can be loaded
 
 * DONE (linmod)
 
 * using log directory 'D:/mypkg/linmod.Rcheck'
 * using R version 2.12.2 (2011-02-25)
 * using platform: i386-pc-mingw32 (32-bit)
 * using session charset: ISO8859-1
 * checking for file 'linmod/DESCRIPTION' ... OK
 * checking extension type ... Package
 * this is package 'linmod' version '1.0'
 * checking package dependencies ... OK
 * checking if this is a source package ... OK
 * checking for executable files ... OK
 * checking whether package 'linmod' can be installed ... OK
 * checking package directory ... OK
 * checking for portable file names ... OK
 * checking DESCRIPTION meta-information ... OK
 * checking top-level files ... OK
 * checking index information ... OK
 * checking package subdirectories ... OK
 * checking R files for non-ASCII characters ... OK
 * checking R files for syntax errors ... OK
 * checking whether the package can be loaded ... OK
 * checking whether the package can be loaded with stated dependencies ... OK
 * checking whether the package can be unloaded cleanly ... OK
 * checking for unstated dependencies in R code ... OK
 * checking S3 generic/method consistency ... OK
 * checking replacement functions ... OK
 * checking foreign function calls ... OK
 * checking R code for possible problems ... OK
 * checking Rd files ... OK
 * checking Rd metadata ... WARNING
 Rd files with duplicated alias 'linmod.default':
  linmod.Rd linmod.default.Rd
 Rd files with duplicated alias 'linmod.formula':
  linmod.Rd linmod.formula.Rd
 Rd files with duplicated alias 'print.linmod':
  linmod.Rd print.linmod.Rd
 Rd files with duplicated alias 'summary.linmod':
  linmod.Rd summary.linmod.Rd
 * checking Rd cross-references ... WARNING
 Unknown package(s) 'pkg' in Rd xrefs
 * checking for missing documentation entries ... OK
 * checking for code/documentation mismatches ... OK
 * checking Rd \usage sections ... OK
 * checking Rd contents ... OK
 * checking for unstated dependencies in examples ... OK
 * checking examples ... OK
 * checking PDF version of manual ... OK
 WARNING: There were 2 warnings, see   'D:/my pkg/linmod.Rcheck/00check.log'
 for details
 
 I don’t know if it is possible to run R CMD build linmod even though I have
 two warning. But if I do it, I get the following cygwin warning:
 
 cygwin warning:
 MS-DOS style path detected: D:/mypkg/linmod_1.0.tar
 Preferred POSIX equivalent is: /cygdrive/d/mypkg/linmod_1.0.tar
 CYGWIN environment variable option “nodosfilewarning” turns off this
 warning.
 Consult the user’s guide for more details about POSIX paths:
 http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
 
 I am not a Linux expert, and I don’t how to fix this error (I couldn’t find
 any help in the manuals or forums, at least for me). Please, any help would
 be really appreciated. 
 
 Many thanks in advance.
 
 Alba Martinez-Ruiz
 -
 Facultad de Ingeniería
 Universidad Católica de la Ssma. Concepción
 Alonso de Rivera 2850,
 C.P. 409-0541 Concepción, Chile
 Tel: + 0056 41 2345232
 Fax: + 0056 41 2345300
 
 --
 View this message in context: 
 http://r.789695.n4.nabble.com/cygwing-warming-when-creating-a-package-in-windows-tp3915660p3915660.html
 Sent from the R devel mailing list archive at Nabble.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

Re: [Rd] readRDS and saveRDS

[Joshua Wiley]

On Tue, Oct 18, 2011 at 9:34 AM, Duncan Murdoch
murdoch.dun...@gmail.com wrote:
 On 18/10/2011 9:37 AM, Hadley Wickham wrote:

 Hi all,

 Is there any chance that readRDS and saveRDS might one day become
 read.rds and write.rds?  That would make them more consistent with the
 other reading and writing functions.

 Ending names in .foo is a bad idea because of the S3 naming conventions, so
 I think this is unlikely.  But you can always create an alias yourself...

I always thought that S3 was part of the reason for read.ext write.ext. In:

/path/file.ext

the class of the file is ext.  I kind of like the idea of taking
this farther, generic functions read/write dispatch to the appropriate
method depending on the class of the file.  Generally, only read/write
would be used, specifying the specific method as needed.  read.rda and
write.rda could replace load/save where: dat - read.rda() would
create an environment, dat rather than simply loading them into the
global environment.

Though this is more of a hypothetical situation than a suggestion for change.



 Duncan Murdoch

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




-- 
Joshua Wiley
Ph.D. Student, Health Psychology
Programmer Analyst II, ATS Statistical Consulting Group
University of California, Los Angeles
https://joshuawiley.com/

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

Re: [Rd] Error in gzfile(file, mode) when checking a package with rcmd check

[Joshua Wiley]

Hmm, I have not had any difficulty with 2.13.2 on
x86_64-pc-mingw32/x64, but I do have trouble with R CMD check on R
devel, as has another user now.  It is never with building or
installing, just the checking.  In my case, the error comes when
building the manual.

2011/10/16 Patrick Giraudoux patrick.giraud...@univ-fcomte.fr:
 Also have just tried to build the package with no preliminary check. The
 package apparently builds OK, tar.gz as well as binary .zip. Really looks
 like the error has to do with the rcmd check command specifically... May it
 be a bug ? Suppose I am not the only one to have checked a package since R
 2.13.2 has been delivered ?

 Patrick


 Le 16/10/2011 11:02, Patrick Giraudoux a écrit :

 PS: looks like if it has something to do with moving from R 2.13.1 to R
 2.13.2, since I cannot even check earlier versions of the pgirmess package
 that where well checked and compiled under earlier R versions.


 Le 16/10/2011 09:50, Patrick Giraudoux a écrit :

 Hi,

 For the first time I have a strange behaviour when checking a package
 before 'packaging' the code. Looks like a file cannot be read.

 rcmd check pgirmess

 * using log directory 'U:/Documents and Settings/pgiraudo/Mes
 documents/R/pgir_arch/pgirmess_arch/On work/pgirmess.Rcheck'
 * using R version 2.13.2 (2011-09-30)
 * using platform: i386-pc-mingw32 (32-bit)
 * using session charset: ISO8859-1
 * checking for file 'pgirmess/DESCRIPTION' ... OK
 * this is package 'pgirmess' version '1.5.2'
 * checking package dependencies ... OK
 * checking if this is a source package ... OK
 * checking for .dll and .exe files ... OK
 * checking whether package 'pgirmess' can be installed ... ERROR
 Installation failed.
 See 'U:/Documents and Settings/pgiraudo/Mes
 documents/R/pgir_arch/pgirmess_arch/On work/pgirmess.Rcheck/00install.out'
 for details.


 In '00install.out',  I get:

 * installing *source* package 'pgirmess' ...
 ** R
 ** data
 ** preparing package for lazy loading
 ** help
 *** installing help indices
 ** building package indices ...
 ** testing if installed package can be loaded Error in gzfile(file, mode)
 : cannot open the connection
 Calls: %in% - match - installed.packages - saveRDS - gzfile
 In addition: Warning message:
 In gzfile(file, mode) :
  cannot open compressed file
 'U:\DOCUME~1\Admin\LOCALS~1\Temp\RtmpwWcmem/libloc_U%3a%2fDocuments%20and%20Settings%2fpgiraudo%2fMes%20documents%2fR%2fpgir_arch%2fpgirmess_arch%2fOn%20work%2fpgirmess.RcheckVersion,Priority,Depends,Imports,LinkingTo,Suggests,Enhances,OS_type,License,Archs,Built.rds',
 probable reason 'No such file or directory'
 Execution halted
 ERROR: loading failed
 * removing
 'U:/DOCUME~1/pgiraudo/MESDOC~1/R/PGIR_A~1/PGIRME~1/ONWORK~1/PGIRME~1.RCH/pgirmess'

 Any hint welcome ! I am stuck on that.

 Patrick


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




-- 
Joshua Wiley
Ph.D. Student, Health Psychology
Programmer Analyst II, ATS Statistical Consulting Group
University of California, Los Angeles
https://joshuawiley.com/

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

[Rd] trace an Rd conversion error in R cmd check

[Joshua Wiley]

Hi All,

Apologies if this is a very naive question.  Is there a way to see the
particular Rd file being processed right before a warning/error
occurs?  As far as I can tell, all my .Rd files use have names and
titles and they are unique between Rd files (sometimes in a file I use
something like \name{foo} \title{Foo}).  I seem to be able to convert
files to latex using: R CMD Rdconv --type=latex on all my Rd files
without problems.

Here is the warning and error:

* checking PDF version of manual ... ERROR
Rd conversion errors:
Warning in file(con, r) :
  file() only supports open = w+ and open = w+b: using the former
Error : : Sections \title, and \name must exist and be unique in Rd files

I am using:

R Under development (unstable) (2011-10-11 r57214)
Platform: x86_64-pc-mingw32/x64 (64-bit)
on Windows 7 with Rtools 2.14 and MikTeX 2.9

Any suggestions or pointers to manuals/documentation would be greatly
appreciated.

Thanks,

Josh


-- 
Joshua Wiley
Ph.D. Student, Health Psychology
Programmer Analyst II, ATS Statistical Consulting Group
University of California, Los Angeles
https://joshuawiley.com/

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

Re: [Rd] trace an Rd conversion error in R cmd check

[Joshua Wiley]

Thanks to Drs. Murdoch and Ripley for your fast and helpful replies.
I did not realize that R CMD check was R code, so that was incredibly
useful.

I spent the morning working on debugging this, and I think I must have
messed up setting up the Windows tool chain, because I get the error
even when running R CMD check on other packages (e.g., MASS).  I am
still not sure what exactly I am missing/setup incorrectly.  R
compiled from source and passed make check all without any trouble.  I
can install packages, and I can make PDFs using tools:::..Rd2pdf, but
when I try to use Rd2pdf on a package instead of specific files I get
the error.

Looking at the R code for CMD check helped me better understand the
process and I will just work with my tool chain until I get things
working.

Thanks again!

Josh



On Wed, Oct 12, 2011 at 4:10 AM, Prof Brian Ripley
rip...@stats.ox.ac.uk wrote:
 R CMD check is R code: you can run the R code for yourself using R's
 debugging facilities.  In this case start with 'R CMD Rd2pdf pkg-name'
 (which should give the same error, as that is what R CMD check calls), then
 run that R code directly (there are comments in the code in R-devel about
 how to do so).

 On Wed, 12 Oct 2011, Joshua Wiley wrote:

 Hi All,

 Apologies if this is a very naive question.  Is there a way to see the
 particular Rd file being processed right before a warning/error
 occurs?  As far as I can tell, all my .Rd files use have names and
 titles and they are unique between Rd files (sometimes in a file I use
 something like \name{foo} \title{Foo}).  I seem to be able to convert
 files to latex using: R CMD Rdconv --type=latex on all my Rd files
 without problems.

 Here is the warning and error:

 * checking PDF version of manual ... ERROR
 Rd conversion errors:
 Warning in file(con, r) :
  file() only supports open = w+ and open = w+b: using the former
 Error : : Sections \title, and \name must exist and be unique in Rd files

 I am using:

 R Under development (unstable) (2011-10-11 r57214)
 Platform: x86_64-pc-mingw32/x64 (64-bit)
 on Windows 7 with Rtools 2.14 and MikTeX 2.9

 Any suggestions or pointers to manuals/documentation would be greatly
 appreciated.

 This is far too rare a problem to be documented in detail.

 Thanks,

 Josh


 --
 Joshua Wiley
 Ph.D. Student, Health Psychology
 Programmer Analyst II, ATS Statistical Consulting Group
 University of California, Los Angeles
 https://joshuawiley.com/

 __
 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, UK                Fax:  +44 1865 272595




-- 
Joshua Wiley
Ph.D. Student, Health Psychology
Programmer Analyst II, ATS Statistical Consulting Group
University of California, Los Angeles
https://joshuawiley.com/

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

Re: [Rd] trace an Rd conversion error in R cmd check

[Joshua Wiley]

Hi Spencer,

Yes, I have versions that pass, but it is not package specific (i.e.,
I can download other package sources from CRAN and if I run R CMD
check on them, I get the same error).  When I run R CMD check using R
2.13.1 or R 2.13.2 it is fine.  Using either:

compiled from source:
R Under development (unstable) (2011-10-12 r57226)
Platform: x86_64-pc-mingw32/x64 (64-bit)

pre-built binary:
R Under development (unstable) (2011-10-10 r57203)
Platform: x86_64-pc-mingw32/x64 (64-bit)

I get the file error.  I am going to keep poking around and try Bill's
suggestion adding mustWork=TRUE.

Cheers,

Josh

On Wed, Oct 12, 2011 at 10:12 AM, Spencer Graves
spencer.gra...@prodsyse.com wrote:
 Hi, Josh:


      Have you had a recent version that passed R CMD check?  If yes, I
 suggest you save your recent changes then revert to that earlier version and
 add your recent changes back in again one at a time.  I've done that many
 times.  (It's also a major reason I make changes as small as I can and run
 R CMD check after each one.  Then if I get something like this I can't
 figure out, there aren't many changes to scan through to find the problem.)


      Hope this helps.
      Spencer


 On 10/12/2011 4:10 AM, Prof Brian Ripley wrote:

 R CMD check is R code: you can run the R code for yourself using R's
 debugging facilities.  In this case start with 'R CMD Rd2pdf pkg-name'
 (which should give the same error, as that is what R CMD check calls),
 then run that R code directly (there are comments in the code in
 R-devel about how to do so).

 On Wed, 12 Oct 2011, Joshua Wiley wrote:

 Hi All,

 Apologies if this is a very naive question.  Is there a way to see the
 particular Rd file being processed right before a warning/error
 occurs?  As far as I can tell, all my .Rd files use have names and
 titles and they are unique between Rd files (sometimes in a file I use
 something like \name{foo} \title{Foo}).  I seem to be able to convert
 files to latex using: R CMD Rdconv --type=latex on all my Rd files
 without problems.

 Here is the warning and error:

 * checking PDF version of manual ... ERROR
 Rd conversion errors:
 Warning in file(con, r) :
  file() only supports open = w+ and open = w+b: using the former
 Error : : Sections \title, and \name must exist and be unique in Rd
 files

 I am using:

 R Under development (unstable) (2011-10-11 r57214)
 Platform: x86_64-pc-mingw32/x64 (64-bit)
 on Windows 7 with Rtools 2.14 and MikTeX 2.9

 Any suggestions or pointers to manuals/documentation would be greatly
 appreciated.

 This is far too rare a problem to be documented in detail.

 Thanks,

 Josh


 --
 Joshua Wiley
 Ph.D. Student, Health Psychology
 Programmer Analyst II, ATS Statistical Consulting Group
 University of California, Los Angeles
 https://joshuawiley.com/

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




 --
 Spencer Graves, PE, PhD
 President and Chief Technology Officer
 Structure Inspection and Monitoring, Inc.
 751 Emerson Ct.
 San José, CA 95126
 ph:  408-655-4567
 web:  www.structuremonitoring.com

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




-- 
Joshua Wiley
Ph.D. Student, Health Psychology
Programmer Analyst II, ATS Statistical Consulting Group
University of California, Los Angeles
https://joshuawiley.com/

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

Re: [Rd] Increase transparency: suggestion on how to avoid namespaces and/or unnecessary overwrites of existing functions

[Joshua Wiley]

On Sat, Oct 1, 2011 at 3:14 PM, Duncan Murdoch murdoch.dun...@gmail.com wrote:
 On 11-10-01 5:14 PM, Dominick Samperi wrote:
[snip]
 Except that namespace::foo should be assigned to another local
 variable instead of using package::foo in a tight loop, because
 repeated calls to :: can introduce a significant performance
 penalty. (This has been discussed in another thread.)

 That's good advice too.

 Duncan Murdoch

Is this performance hit the sort of thing that byte compiling would
help with, or am I misunderstanding its use?



-- 
Joshua Wiley
Ph.D. Student, Health Psychology
Programmer Analyst II, ATS Statistical Consulting Group
University of California, Los Angeles
https://joshuawiley.com/

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

Re: [Rd] Overwriting imported function in another package

[Joshua Wiley]

 [Jeroen Ooms wrote:]
  I am running into a limitation of the grid::grid.newpage function, for 
  which I would like to overwrite this function
  with a slightly modified one. Hopefully this is a temporary working 
  solution until the package gets updated. I found a
  way to overwrite the function in the package:grid namespace. However, 
  lattice imports grid rather than depending on it.
  So I need a way to overwrite this imported version as well. The code below 
  shows the fix which works for ggplot (because
  it depends on grid), but it doesn't work for lattice, because it imports 
  grid. Is there any way to overwrite
  grid.newpage for all instantiations of it?

 [Duncan Murdoch wrote:]
 But everyone who uses your code has a right to expect that other
 packages are not affected by it.

mark.braving...@csiro.au wrote:
 One should of course only do such things reluctantly and responsibly, as 
 Duncan points out; any changes shouldn't modify *expectable* behaviour of 
 existing functions! But if it's just a bug-fix or innocuous extension of 
 functionality, and/or just in one's own work, then I can see two approaches 
 that might help.

As a user, I would be strongly opposed to this, even for buggy code.

 Second: *after* loading the offending package, (e.g. in the '.onLoad' of your 
 own package, if you're putting this into a package) you could use 
 'fun.locator' in 'mvbutils' to find all instances of the offending function 
 including imports, and then change each copy manually. An example is 'mtrace' 
 in 'debug', which deliberately tries to find and change all copies of a 
 function. (Whether 'fun.locator' finds absolutely every copy, I'm not sure, 
 but it does try; NB it won't work as-is for S4, and needs to be used 
 differently for ref classes.) This is uglier, but should be automatic (and 
 should also ensure that any subsequent imports of the offender pick up the 
 patched version, though I haven't checked).

 Note that this won't work retrospectively for copies that are imported into a 
 package namespace under an alias, which I think used to be a theoretical 
 possibility but may not be any more.

This strikes me as essentially as a package that, when
installed/loaded infects other packages and software.  R and CRAN
are open source.  If you need something different than what you have,
make something different.  You could make: JOsggplot2, JOslattice,
etc. and have your package depend on those.  User's do not need to
compile from source, and rather than hijacking other packages, it is
clear that a package similar to but different from ggplot2 and lattice
is being used.

Josh

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

Re: [Rd] dotchart {graphics} 2.11.1 vs. 2.12.1 [followed up from Rhelp]

[Joshua Wiley]

On Fri, Feb 18, 2011 at 5:44 AM, Prof Brian Ripley
rip...@stats.ox.ac.uk wrote:
 On Tue, 1 Feb 2011, Joshua Wiley wrote:

 Dear List,

 With the R 2.12.0 addition of table methods for points(), dotchart()
 struggles with tables.

 Which of course it is not documented to accept, not even the base type of
 such tables, a 1-D array.  So this is detecting a previously undetected user
 error.

Of course, I hope my wording did not imply there was any problem or
error.  I was interested in what is the best way to make this work?


 Because the table methods of lines/points have different defaults, your
 suggestions are not going to work (did you actually try them with the
 dotchart example?).

I thought I had, but evidently not.

The best we can do is to throw an error if 'y' is
 specified in a table method.

 I found several possible solutions, but it is beyond my skill to decide
 what is best.  Here is a small example:

 dotchart(as.vector(x)) works, but is probably not what you want.
 dotchart(unclass(x)) works, but it is not guaranteed to keep working.

 Unclassing is definitely dangerous, since the test is.numeric(x) invokes a
 generic function.  If methods have been written following the help page (and
 not all have), as.numeric(x) should do the trick, but needs to be done after
 names are extracted.

I take it creating a named vector using name extraction and
as.numeric(x) is the best approach.

Thanks for the information,

Josh


 OTOH, learning the discipline of consulting the help pages if things do not
 work as you expect is a good one, since there is no way R is going to check
 all inputs to all functions.


 #
 x - table(infert$education)
 y - 1:3L

 dotchart(x) # error about incorrect plot type

 ## moving closer to the cause, dotchart() essentially does
 plot(x = c(0, 150), y = c(0, 5), type = n)
 points(x, y) # error, because arg #2 is the type

 ## One option would be to explicitly name the arguments in dotchart()
 points(x = x, y = y) # works, but misses the point (no pun intended)

 ## Another possibility would be to add unclass(). I'm not sure
 ## if this would have other repercussions.  line 71 could become:
 points(unclass(x), y, pch = pch, col = color, bg = bg)

 ## Other options could be adding a method for dotchart()
 ## or to update the table method for points()
 points.table - function (x, y, type = h, lwd = 2, ...)
 {
   if (length(dim(x)) == 1L) {
       nx - dimnames(x)[[1L]]
       is.num - suppressWarnings(!any(is.na(xx - as.numeric(nx
       x0 - if (is.num)
           xx
       else seq.int(x)
       if (missing(y)) {
         points(x0, unclass(x), type = type, lwd = lwd, ...)
       } else points(unclass(x), y, type = type, lwd = lwd, ...)
   }
   else stop(only for 1-D table)
 }

 plot(x = c(0, 150), y = c(0, 5), type = n)
 points(x, y, type = p)

 #



 --
 Joshua Wiley
 Ph.D. Student, Health Psychology
 University of California, Los Angeles
 http://www.joshuawiley.com/

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

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

[Rd] dotchart {graphics} 2.11.1 vs. 2.12.1 [followed up from Rhelp]

[Joshua Wiley]

Dear List,

With the R 2.12.0 addition of table methods for points(), dotchart()
struggles with tables.  I found several possible solutions, but it is
beyond my skill to decide what is best.  Here is a small example:


#
x - table(infert$education)
y - 1:3L

dotchart(x) # error about incorrect plot type

## moving closer to the cause, dotchart() essentially does
plot(x = c(0, 150), y = c(0, 5), type = n)
points(x, y) # error, because arg #2 is the type

## One option would be to explicitly name the arguments in dotchart()
points(x = x, y = y) # works, but misses the point (no pun intended)

## Another possibility would be to add unclass(). I'm not sure
## if this would have other repercussions.  line 71 could become:
points(unclass(x), y, pch = pch, col = color, bg = bg)

## Other options could be adding a method for dotchart()
## or to update the table method for points()
points.table - function (x, y, type = h, lwd = 2, ...)
{
if (length(dim(x)) == 1L) {
nx - dimnames(x)[[1L]]
is.num - suppressWarnings(!any(is.na(xx - as.numeric(nx
x0 - if (is.num)
xx
else seq.int(x)
if (missing(y)) {
  points(x0, unclass(x), type = type, lwd = lwd, ...)
} else points(unclass(x), y, type = type, lwd = lwd, ...)
}
else stop(only for 1-D table)
}

plot(x = c(0, 150), y = c(0, 5), type = n)
points(x, y, type = p)

#



-- 
Joshua Wiley
Ph.D. Student, Health Psychology
University of California, Los Angeles
http://www.joshuawiley.com/

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

Re: [Rd] R 2.12.0 doesn't install properly under Windows Vista

[Joshua Wiley]

On Sat, Oct 16, 2010 at 4:01 PM, Duncan Murdoch
murdoch.dun...@gmail.com wrote:
 On 16/10/2010 4:55 PM, Dominick Samperi wrote:

 After installing R 2.12.0 under windows Vista it does not start because it
 cannot
 find Rgui.exe. Indeed, the contents of R\R-2.12.0\bin are:

 config.sh
 R.exe
 Rscript.exe
 Sd2Rd.pl

 It appears that a few things are missing...

 The original build was missing the contents of bin/i386, which is where 32
 bit binaries are stored now.  A new build has been done, and it will
 eventually make it to CRAN and the mirrors.

 Check the date on the bottom of the bin/windows/base page on CRAN:
 2010-10-15 is bad, 2010-10-16 is good (as far as I know).

Just FYI, I successfully installed R 2.12.0 (2010-10-16) on Windows XP
32bit.  I'll try it on 7 x64 tomorrow, but so far the GUI, Rterm, and
R CMD BATCH all worked great.

Thanks for spending your Saturday making this available, Duncan!

Josh


 Duncan Murdoch

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



-- 
Joshua Wiley
Ph.D. Student, Health Psychology
University of California, Los Angeles
http://www.joshuawiley.com/

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