[Rd] Surprising length() of POSIXlt vector (PR#14073)

[mark]

Arrays of POSIXlt dates always return a length of 9.  This
is correct (they're really lists of vectors of seconds,
hours, and so forth), but other methods disguise them as
flat vectors, giving superficially surprising behaviour:

  strings <- paste('2009-1-', 1:31, sep='')
  dates <- strptime(strings, format="%Y-%m-%d")

  print(dates)
  #  [1] "2009-01-01" "2009-01-02" "2009-01-03" "2009-01-04" "2009-01-05"
  #  [6] "2009-01-06" "2009-01-07" "2009-01-08" "2009-01-09" "2009-01-10"
  # [11] "2009-01-11" "2009-01-12" "2009-01-13" "2009-01-14" "2009-01-15"
  # [16] "2009-01-16" "2009-01-17" "2009-01-18" "2009-01-19" "2009-01-20"
  # [21] "2009-01-21" "2009-01-22" "2009-01-23" "2009-01-24" "2009-01-25"
  # [26] "2009-01-26" "2009-01-27" "2009-01-28" "2009-01-29" "2009-01-30"
  # [31] "2009-01-31"

  print(length(dates))
  # [1] 9
  
  str(dates)
  # POSIXlt[1:9], format: "2009-01-01" "2009-01-02" "2009-01-03" "2009-01-04" 
...

  print(dates[20])
  # [1] "2009-01-20"

  print(length(dates[20]))
  # [1] 9

I've since realised that POSIXct makes date vectors easier,
but could we also have something like:

  length.POSIXlt <- function(x) { length(x$sec) }

in datetime.R, to avoid breaking functions (like the
str.POSIXt method) which use length() in this way?

Thanks,
Mark <><

--

Version:
 platform = i686-pc-linux-gnu
 arch = i686
 os = linux-gnu
 system = i686, linux-gnu
 status = 
 major = 2
 minor = 10.0
 year = 2009
 month = 10
 day = 26
 svn rev = 50208
 language = R
 version.string = R version 2.10.0 (2009-10-26)

Locale:
C

Search Path:
 .GlobalEnv, package:stats, package:graphics, package:grDevices, package:utils, 
package:datasets, package:methods, Autoloads, package:base

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

Re: [Rd] Surprising length() of POSIXlt vector (PR#14073)

[mark]

Benilton Carvalho writes:
> I'm no expert on this, but my understanding is that the choice was
> to stick to the definition.
> 
> The help file for length() [1] says:
> 
> "For vectors (including lists) and factors the length is the number
> of elements."
> 
> The help file for POSIXlt [2] (for example) says:
> 
> "Class ?"POSIXlt"? is a named list of vectors representing (...)"
> 
> and then lists the 9 elements (sec / min / hour / mday / mon / year
> / wday / yday / isdst).
> 
> So, by [1] length of POSIXlt objects is 9, because it "is a named
> list of vectors representing (...)".

Thanks, all.  Yes, I'd already read both, and it's obviously
true that a length() of 9 is correct (as I said up-front).

The difficulty is that some functions -- importantly
including "[" -- already have methods which make POSIXlt
behave like a vector.  The documentation for POSIXlt just
says it's a list of 9 elements: it mentions methods for
addition etc, but AFAICT it doesn't say that subsetting won't
behave is "["'s help says for a list-like object.

In the end, "[" sees a different length to "[[" and "$"
here, so a length.POSIXlt() just shuffles the issue around.

Anyhow, I somehow missed there have been other PRs on this,
including discussion on r-devel of "[" and logical vs physical
length() under PR#10507.  I'm sorry for being repetitive.

Mark <><

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

[Rd] load, environment[[, and attr<-/attributes<- (PR#8457)

[mark . bravington]

Full_Name: Mark Bravington
Version: 2.2.1
OS: Windows XP
Submission from: (NULL) (203.132.243.69)


#   [EMAIL PROTECTED]

There is a bug to do with 'load', environment access via '[[', and 'attr<-' or
'attributes<-'. Modifying the attributes of a *copy* of an object can modify the
original too, under certain conditions:

 - the copy needs to be created using env[[ not by env$ nor just by name
 - the original object must have been 'load'ed and not subsequently
read-accessed before the copy was created
 
The script below might clarify this. BTW the problem is not only for
.GlobalEnv.

It's intriguing that 'load' doesn't seem to be "fully creating" the object-- is
it just creating a promise or something like that?

Mark Bravington
[EMAIL PROTECTED]

a <- 1
attr( a, 'thing') <- 99
  
tf <- tempfile()
save( a, file=tf)

load( tf)
y <- .GlobalEnv[[ 'a']]
attr( y, 'thing') <- NULL
a # attr gone!

load( tf)
y <- .GlobalEnv$a
attr( y, 'thing') <- NULL
a # OK

load( tf)
a # to force access
y <- .GlobalEnv[[ 'a']]
attr( y, 'thing') <- NULL
a # OK

unlink( tf)



--please do not edit the information below--

Version:
 platform = i386-pc-mingw32
 arch = i386
 os = mingw32
 system = i386, mingw32
 status = 
 major = 2
 minor = 2.1
 year = 2005
 month = 12
 day = 20
 svn rev = 36812
 language = R

Windows XP Professional (build 2600) Service Pack 1.0

Locale:
LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MONETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252

Search Path:
 .GlobalEnv, package:methods, package:stats, package:graphics,
package:grDevices, package:utils, package:datasets, Autoloads, package:base

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

[Rd] Warning from Sys.junction when using network drive.

[MARK BANGHART]

I am running 3.4.3 on a windows server and I ran the code in a new session.


I get a warning when running packrat::init() on a project that is located on a 
windows network drive.
The warning I get is


Warning message:
cannot set reparse point 'U:/packrat5/packrat/lib-R/base', reason 'Access is 
denied'


The error is created based inside the function .Internal(mkjunction(fr, link)) 
which is called from Sys.junction().  I have run Sys.junction inside the 
RStudio debugger and I checked that the 'U:/packrat5/packrat/lib-R/base'
could be accessed via the windows file explorer before the 
.Internal(mkjunction(fr, link)) call is made.  Looking at the code for 
do_mkjunction(), the warning looks to be thrown based on the return status from 
DeviceIoControl.


I setup a project on the C: drive and tried the same packrat::init() code.

The call to .Internal(mkjunction(fr, link)) did not produce an error.


I would appreciate any help you can provide on this issue.

Thanks,

Mark

[[alternative HTML version deleted]]

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

[Rd] undefined symbol errors when compiling package using ALTREP API

[Mark Klik]

Hello,

I'm developing a package (lazyvec) that makes full use of the ALTREP
framework (R >= 3.6.0).
One application of the package is to wrap existing ALTREP vectors in a new
ALTREP vector and pass all calls from R to the contained object. The
purpose of this is to provide a diagnostic framework for working with
ALTREP vectors and show information about internal calls.

The package builds on Windows and OSX but fails to build on Linux as can be
seen from the link to the Travis build:
https://travis-ci.org/fstpackage/lazyvec/jobs/539442806

The reason of build failure is that many ALTREP methods generate 'undefined
symbol' errors upon building the package (on Linux). I've checked the R
source code and the undefined symbols seems to be related to the
'attribute_hidden' before the function definition. For example, the method
'ALTVEC_EXTRACT_SUBSET' is defined as:

SEXP attribute_hidden ALTVEC_EXTRACT_SUBSET(SEXP x, SEXP indx, SEXP call)

My question is why these differences between Windows / OSX and Linux exist
and if they are intentional?
Do I need special build parameters to make sure my package builds correctly
on Linux?

thanks for all the hard work!

best,
Mark

PS: some additional info:

package github repository: https://github.com/fstpackage/lazyvec
AppVeyor package build logs:
https://ci.appveyor.com/project/fstpackage/lazyvec
Travis package build logs: https://travis-ci.org/fstpackage/lazyvec/builds

[[alternative HTML version deleted]]

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

Re: [Rd] [External] undefined symbol errors when compiling package using ALTREP API

[Mark Klik]

thanks for clearing that up, so these methods are actually not meant to be
exported on Windows and OSX?
Some of the ALTREP methods that now use 'attribute_hidden' would be very
useful to packages that aim to be ALTREP aware, should the currently
(exported) API be considered final?

thanks  for your time & best,
Mark

On Tue, Jun 4, 2019 at 6:52 PM Tierney, Luke  wrote:

> On Tue, 4 Jun 2019, Mark Klik wrote:
>
> > Hello,
> >
> > I'm developing a package (lazyvec) that makes full use of the ALTREP
> > framework (R >= 3.6.0).
> > One application of the package is to wrap existing ALTREP vectors in a
> new
> > ALTREP vector and pass all calls from R to the contained object. The
> > purpose of this is to provide a diagnostic framework for working with
> > ALTREP vectors and show information about internal calls.
> >
> > The package builds on Windows and OSX but fails to build on Linux as can
> be
> > seen from the link to the Travis build:
> > https://travis-ci.org/fstpackage/lazyvec/jobs/539442806
> >
> > The reason of build failure is that many ALTREP methods generate
> 'undefined
> > symbol' errors upon building the package (on Linux). I've checked the R
> > source code and the undefined symbols seems to be related to the
> > 'attribute_hidden' before the function definition. For example, the
> method
> > 'ALTVEC_EXTRACT_SUBSET' is defined as:
> >
> > SEXP attribute_hidden ALTVEC_EXTRACT_SUBSET(SEXP x, SEXP indx, SEXP call)
> >
> > My question is why these differences between Windows / OSX and Linux
> exist
> > and if they are intentional?
>
> It is intentional that this not be part of the public API. This is
> true of almost all functions with an ALTREP prefix. You need a
> different approach that avoids using these directly.
>
> Best,
>
> luke
>
> > Do I need special build parameters to make sure my package builds
> correctly
> > on Linux?
> >
> > thanks for all the hard work!
> >
> > best,
> > Mark
> >
> > PS: some additional info:
> >
> > package github repository: https://github.com/fstpackage/lazyvec
> > AppVeyor package build logs:
> > https://ci.appveyor.com/project/fstpackage/lazyvec
> > Travis package build logs:
> https://travis-ci.org/fstpackage/lazyvec/builds
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> --
> Luke Tierney
> 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:   luke-tier...@uiowa.edu
> Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu
>

[[alternative HTML version deleted]]

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

Re: [Rd] [External] undefined symbol errors when compiling package using ALTREP API

[Mark Klik]

Hi Gabriel,

thanks for your detailed explanation, that definitely clarifies the design
choices that were made in setting up the ALTREP framework and I can see how
those choices make sure existing code won't break.

My specific use-case for wanting to check whether a vector is an ALTREP is
the following: the fst package wraps an external C++ library (fstlib,
independent from R) that was made for high speed serialization of
dataframe's. Sequences are fairly common in dataframe's and I'm planning to
add the concept of a sequence to the (R-agnostic) fst format. When I can
detect, e.g. a 'compact_intseq' ALTREP vector and just retrieve it's 3
integer internal representation, serialization could be very fast.
Alternatively, as you describe, the vector needs to be expanded first
before serialization, which will actually be slower than using an already
expanded vector and can take a lot of RAM for large datasets.

So being able to make use of the internal representation of (a few of the)
base ALTREP vectors can be very interesting for (non-R) serialization
schemes.

thanks for your time!
Mark


On Tue, Jun 4, 2019 at 11:50 PM Gabriel Becker 
wrote:

> Hi Mark,
>
> So depending pretty strongly on what you mean by "ALTREP aware", packages
> aren't necessarily supposed to be ALTREP aware. What I mean by this is that
> as of right now, ALTREP objects are designed to be interacted with by
> non-ALTREP-implementing package code, *more-or-less *exactly as standard
> (non-AR) SEXPs are: via the published C API. The more or less comes from
> the fact that in some cases, doing things that are good ideas on standard
> SEXPS will work, but may not be a good idea for ALTREPs.
>
> The most "low-hanging-fruit" example of something that was best practice
> for standard vectors but is not a good idea for ALTREP vectors is grabbing
> a DATAPTR and iterating over the values without modification in a tight
> loop.  This will work (absent allocation  failure or, I suppose, the ALTREP
> being specifically designed to refuse to give you a full DATAPTR), but with
> ALTREP in place its no longer what you want to do.
>
> That said, you don't want to check whether something is an ALTREP yourself
> and branch your code, what you want to do is use the ITERATE_BY_REGION
> macro in R_ext/Itermacros.h for ALL SEXPs, which will be nearly as for
> standard vectors and work safely for ALTREP vectors.
>
> Basically any time you find yourself wanting to check if something is an
> ALTREP and if so, call a specific ALT*_BLAH method, the intention is that
> there should be a universal API point you can call which will work for both
> types.
>
> This is true, e.g., of INTEGER_IS_SORTED (which will always work and just
> returns UNKNOWN_SORTEDNESS, ie INT_MIN, ie NA_INTEGER for non-ALTREPs).,
> for REAL_GET_REGION, (which populates a double* with the requested values
> for both standard and ALTREP REALSXPs), etc.
>
> Does the above make sense?
>
> If you feel a universal API point is missing, you can raise that here,
> though I can't promise that will ultimately result in the method being
> added.
>
> Best,
> ~G
>
> On Tue, Jun 4, 2019 at 2:22 PM Mark Klik  wrote:
>
>> thanks for clearing that up, so these methods are actually not meant to be
>> exported on Windows and OSX?
>> Some of the ALTREP methods that now use 'attribute_hidden' would be very
>> useful to packages that aim to be ALTREP aware, should the currently
>> (exported) API be considered final?
>>
>> thanks  for your time & best,
>> Mark
>>
>> On Tue, Jun 4, 2019 at 6:52 PM Tierney, Luke 
>> wrote:
>>
>> > On Tue, 4 Jun 2019, Mark Klik wrote:
>> >
>> > > Hello,
>> > >
>> > > I'm developing a package (lazyvec) that makes full use of the ALTREP
>> > > framework (R >= 3.6.0).
>> > > One application of the package is to wrap existing ALTREP vectors in a
>> > new
>> > > ALTREP vector and pass all calls from R to the contained object. The
>> > > purpose of this is to provide a diagnostic framework for working with
>> > > ALTREP vectors and show information about internal calls.
>> > >
>> > > The package builds on Windows and OSX but fails to build on Linux as
>> can
>> > be
>> > > seen from the link to the Travis build:
>> > > https://travis-ci.org/fstpackage/lazyvec/jobs/539442806
>> > >
>> > > The reason of build failure is that many ALTREP methods generate
>> > 'undefined
>> > > symbol' errors upon building the package (on Linux). I've checked the
>> R
>&g

Re: [Rd] [External] undefined symbol errors when compiling package using ALTREP API

[Mark Klik]

thanks Luke, I can work with that and will watch out for changes and new
developments in the ALTREP code with great interest.

all the best,
Mark



On Wed, Jun 5, 2019 at 6:02 PM Tierney, Luke  wrote:

> For now you can use
>
> R_altrep_inherits(x, R_compact_intseq_class)
>
> The variable R_compact_intseq_class should currently be visible to
> packages on all platforms, though that may change if we eventually
> provide a string-based lookup mechanism, e.g. somehting like
>
> R_find_altrep_class("compact_intseq", "base")
>
> Best,
>
> luke
>
>
> On Tue, 4 Jun 2019, Mark Klik wrote:
>
> > Hi Gabriel,
> >
> > thanks for your detailed explanation, that definitely clarifies the
> design
> > choices that were made in setting up the ALTREP framework and I can see
> how
> > those choices make sure existing code won't break.
> >
> > My specific use-case for wanting to check whether a vector is an ALTREP
> is
> > the following: the fst package wraps an external C++ library (fstlib,
> > independent from R) that was made for high speed serialization of
> > dataframe's. Sequences are fairly common in dataframe's and I'm planning
> to
> > add the concept of a sequence to the (R-agnostic) fst format. When I can
> > detect, e.g. a 'compact_intseq' ALTREP vector and just retrieve it's 3
> > integer internal representation, serialization could be very fast.
> > Alternatively, as you describe, the vector needs to be expanded first
> > before serialization, which will actually be slower than using an already
> > expanded vector and can take a lot of RAM for large datasets.
> >
> > So being able to make use of the internal representation of (a few of
> the)
> > base ALTREP vectors can be very interesting for (non-R) serialization
> > schemes.
> >
> > thanks for your time!
> > Mark
> >
> >
> > On Tue, Jun 4, 2019 at 11:50 PM Gabriel Becker 
> > wrote:
> >
> >> Hi Mark,
> >>
> >> So depending pretty strongly on what you mean by "ALTREP aware",
> packages
> >> aren't necessarily supposed to be ALTREP aware. What I mean by this is
> that
> >> as of right now, ALTREP objects are designed to be interacted with by
> >> non-ALTREP-implementing package code, *more-or-less *exactly as standard
> >> (non-AR) SEXPs are: via the published C API. The more or less comes from
> >> the fact that in some cases, doing things that are good ideas on
> standard
> >> SEXPS will work, but may not be a good idea for ALTREPs.
> >>
> >> The most "low-hanging-fruit" example of something that was best practice
> >> for standard vectors but is not a good idea for ALTREP vectors is
> grabbing
> >> a DATAPTR and iterating over the values without modification in a tight
> >> loop.  This will work (absent allocation  failure or, I suppose, the
> ALTREP
> >> being specifically designed to refuse to give you a full DATAPTR), but
> with
> >> ALTREP in place its no longer what you want to do.
> >>
> >> That said, you don't want to check whether something is an ALTREP
> yourself
> >> and branch your code, what you want to do is use the ITERATE_BY_REGION
> >> macro in R_ext/Itermacros.h for ALL SEXPs, which will be nearly as for
> >> standard vectors and work safely for ALTREP vectors.
> >>
> >> Basically any time you find yourself wanting to check if something is an
> >> ALTREP and if so, call a specific ALT*_BLAH method, the intention is
> that
> >> there should be a universal API point you can call which will work for
> both
> >> types.
> >>
> >> This is true, e.g., of INTEGER_IS_SORTED (which will always work and
> just
> >> returns UNKNOWN_SORTEDNESS, ie INT_MIN, ie NA_INTEGER for non-ALTREPs).,
> >> for REAL_GET_REGION, (which populates a double* with the requested
> values
> >> for both standard and ALTREP REALSXPs), etc.
> >>
> >> Does the above make sense?
> >>
> >> If you feel a universal API point is missing, you can raise that here,
> >> though I can't promise that will ultimately result in the method being
> >> added.
> >>
> >> Best,
> >> ~G
> >>
> >> On Tue, Jun 4, 2019 at 2:22 PM Mark Klik  wrote:
> >>
> >>> thanks for clearing that up, so these methods are actually not meant
> to be
> >>> exported on Windows and OSX?
> >>> Some of the ALTREP methods that now use 'attribut

Re: [Rd] Help useRs to use R's own Time/Date objects more efficiently

[Mark Leeds]

Hi All: I've been following this thread and just want to add one pointer.

For those who aren't interested in using new packages that try to make
dates-times easier but also find the
base R tools confusing, below is link to an extremely well written document
from over 15 years ago. It's probably
already known by quite a few people but, for people with less than 10 years
of R experience it could very well be unknown.
It's the clearest explanation of base R tools  for dates and times ( note:
one needs to consider chron a
base package but who's counting )  that I know of.

https://www.researchgate.net/publication/229087103_R_Help_Desk_Date_and_time_classes_in_R






On Sun, Apr 5, 2020 at 4:58 PM Abby Spurdle  wrote:

> I think POSIXct and POSIXlt are badly-chosen names.
> The name "POSIX" implies UNIX.
> (i.e. XYZix operating system is mostly POSIX compliant... Woo-Hoo!).
> My assumption is that most people modelling industrial/econometric
> data etc, or data imported from databases, don't want system
> references everywhere.
>
> Historically, I've use the principle that:
> If programming language A uses functionality from programming language
> B, then bindings should be as close as possible to whatever is in
> programming language B. Any additional functionality in programming
> language A, should be distinct from the bindings.
> R hasn't done this here, where POSIX-bindings have added in additional
> R functionality and semantics.
> Possibly introducing problems at an early stage.
>
> The help file entitled DateTimeClasses, only covers a small subset of
> information on date and time classes, with no obvious information
> about how to construct date and time objects, except for what's in the
> examples. The Date class has a similar problem, omitting information
> about how to construct Date objects.
>
> The "convenience extraction functions" aren't necessarily convenient
> because they return text rather than integers, requiring many users to
> still use the POSIXlt class.
>
> I don't think your example is simple.
> And I suspect it may discourage some people from using base packages.
> Having opposite effect to what's intended.
>
> It's probably too late to change the functions, but here's what I would
> suggest:
>
> (1) Create a top-level help page with a title like "Date and Time
> Classes" to give a brief but general overview. This would mean the
> existing DateTimeClasses would need a new title.
> (2) Create a another function the same as as.POSIXlt, but with a more
> user-friendly name, which would increase readability.
> (3) If help files for describing classes are separate from the help
> files for creating/coercing objects (e.g. Date vs as.Date), then I
> think they should cross reference each other in the description field,
> not just the details or seealso fields.
> (4) Reference relevant extraction/formatting functions, in most
> date/time help files, even if there's some (small) duplication in the
> help files.
> (5) Focus on keeping the examples simple rather than comprehensive.
>
> Expanding on suggestion (4), if you read the help file for as.Date
> (which seems like an obvious starting point, because that's where I
> started reading...), there's no reference at all to getting the month,
> or the day of the week, etc. To make it worse it doesn't mention
> coercion to POSIXlt objects either (but does mention coercion from
> POSIXlt to Date objects). This could give the wrong impression to many
> readers...
>
> In it's defense, it does link to Date, which links to weekdays, which
> links to as.POSIXlt.
>
> Of course the note and seealso fields are near the bottom, and there's
> an implicit (possibly false) assumption that the reader will read all
> the help file*s*, and follow the links at the bottom, at least three
> times over.
> And a new-ish R user is likely to have to read more than four help files.
> Unless they Google it, read stack exchange, or read some fancy
> (apparently modern) textbook on data science...
>
> Reinforcing the need for the help files to be clear about what the
> functions (collectively) can do and specifically what
> extraction/formatting functionality is available...
>
> My guess is the that most common tasks with date and time objects are:
> (1) Reading a character vector representing dates/times.
> (2) Formatting a date/time (i.e. Object to character vector, or
> character vector to another character vector).
> (3) Extracting information such as month, weekday, etc, either as an
> integer or as text.
>
> So, I in short, these should be easy (to do, and find out how to do)...
>
>
> On Sat, Apr 4, 2020 at 10:51 PM Martin Maechler
>  wrote:
> >
> > This is mostly a RFC  [but *not* about the many extra packages,
> please..]:
> >
> > Noticing to my chagrin  how my students work in a project,
> > googling for R code and cut'n'pasting stuff together, accumulating
> > this and that package on the way  all just for simple daily time series
> > (though with partly missing

Re: [Rd] [External] Re: Help useRs to use R's own Time/Date objects more efficiently

[Mark Leeds]

I should have mentioned that it was in R-news. My mistake. Thanks Luke for
clarification.



On Sun, Apr 5, 2020 at 9:36 PM  wrote:

> On Mon, 6 Apr 2020, Abby Spurdle wrote:
>
> >> (1) Create a top-level help page with a title like "Date and Time
> >> Classes" to give a brief but general overview. This would mean the
> >> existing DateTimeClasses would need a new title.
> >
> > I wanted to modify my first suggestion.
> > Perhaps a better idea would be to reference an external document
> > giving an overview of the subject.
> > I couldn't find a discussion of POSIXct/POSIXlt objects in the R
> > manuals (unless I missed it somewhere), so perhaps "An Introduction to
> > R" could be updated to include this subject, and then the help files
> > could reference that?
> >
> > Mark Leeds has already mentioned one possible (unofficial) source.
> > And I suspect that there are others.
>
> Not entirely unofficial as it waw published in R News:
>
> @article{grothendieck2004r,
>title={R help desk: Date and time classes in R},
>author={Grothendieck, Gabor and Petzoldt, Thomas},
>journal={R News},
>volume={4},
>number={1},
>pages={29--32},
>year={2004}
> }
>
> Best,
>
> luke
>
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> --
> Luke Tierney
> 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:   luke-tier...@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
>

[[alternative HTML version deleted]]

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

Re: [Rd] Trying to understand the search path and namespaces

[Mark Leeds]

Hi Duncan: Luke's article is in the June,  2003 edition of R-news

On Mon, Nov 15, 2010 at 8:43 PM, Duncan Murdoch wrote:

> Hadley Wickham wrote:
>
>> Hi all,
>>
>> I'm trying to understand how the search path and namespaces interact.
>> For example, take the devtools package which suggests the testthat
>> package.  Here's what the search path looks like after I load each of
>> those packages:
>>
>
> Luke Tierney wrote up a nice description of this a few years ago.  It's
> either on developer.r-project.org, or in an old issue of R News.
>
> Duncan Murdoch
>
>
>>  library(devtools)
>>> search()
>>>
>>  [1] ".GlobalEnv""package:devtools"  "package:stats"
>>  [4] "package:graphics"  "package:grDevices" "package:utils"
>>  [7] "package:datasets"  "package:methods"   "Autoloads"
>> [10] "package:base"
>>
>>> library(testthat)
>>> search()
>>>
>>  [1] ".GlobalEnv""package:testthat"  "package:devtools"
>>  [4] "package:stats" "package:graphics"  "package:grDevices"
>>  [7] "package:utils" "package:datasets"  "package:methods"
>> [10] "Autoloads" "package:base"
>>
>> My question is this: when I execute the test function in devtools
>> function it calls the the test_package function in the testthat
>> package - but that function is located higher up the search path - how
>> does R find it?
>>
>> (I ask this question because I'm trying to simulate package loading
>> from within R to simplify the development cycle, but something is
>> missing in my knowledge of namespaces, and so I have the devel
>> versions of my packages can't access packages that are loaded after
>> they are)
>>
>> Hadley
>>
>>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

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

[Rd] how to store package options over sessions?

[Mark Heckmann]

Hi,
I posted this a week ago on r-help but did not get an answer. So I hope that 
someone here can help me:
I want to define some options for my package the user may change.
It would be convenient if the changes could be saved when terminating  
an R session and recovered automatically on the next package load.

Is that possible and if yes, is the standard way to implement this?

Thanks,
Mark

–––
Mark Heckmann
Dipl. Wirt.-Ing. cand. Psych.
Celler Straße 27
28205 Bremen
Blog: www.markheckmann.de
R-Blog: http://ryouready.wordpress.com






[[alternative HTML version deleted]]

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

[Rd] R crashes if "toFile" given "~/" in Linux envirnonment

[Mark Kimpel]

I was running some sample code from a help page tonight and wished to
redirect the sample output to my Desktop under Linux (Mint-Debian 64 if it
makes a different). I was surprised to find that file name expansion using
the ubuquitious "~/" was not recognized, in fact it caused R to crash. Is
this expected behavior? See my output below and sessionInfo().  Also, not
shown, but 'setwd("~/Desktop")' works just fine.  Thanks, Mark

# sample code from Rgraphviz clusterData help page
library(graph)
library(Rgraphviz)
g1_gz <- gzfile(system.file("GXL/graphExample-01.gxl.gz",package="graph"),
open="rb")
g11_gz <- gzfile(system.file("GXL/graphExample-11.gxl.gz",package="graph"),
open="rb")
g1 <- fromGXL(g1_gz)
g11 <- fromGXL(g11_gz)
g1_11 <- join(g1, g11)
sgl <- vector(mode="list", length=2)
sgl[[1]] <- list(graph=g1, cluster=TRUE)
sgl[[2]] <- list(graph=g11, cluster=TRUE)
ng <- agopenSimple(g1_11, "tmpsg", subGList=sgl)
clusterData(ng, 1, c("bgcolor")) <- c("blue")
clusterData(ng, 2, c("bgcolor")) <- c("red")

# and now 2 usually equivalent ways to specify the location for output file,
with the second way crashing:
toFile(ng, layoutType="dot", filename="/home/mkimpel/Desktop/g1_11_dot.ps",
fileType="ps")
NULL
toFile(ng, layoutType="dot", filename="~/Desktop/g1_11_dot.ps",
fileType="ps")
~/Desktop/g1_11_dot.ps: No such file or directory

Process R exited abnormally with code 1 at Mon May 16 22:42:12 2011
#
# and my sessionInfo()
R version 2.13.0 (2011-04-13)
Platform: x86_64-unknown-linux-gnu (64-bit)

locale:
 [1] LC_CTYPE=en_US.utf8   LC_NUMERIC=C
LC_TIME=en_US.utf8LC_COLLATE=en_US.utf8 LC_MONETARY=C

 [6] LC_MESSAGES=en_US.utf8LC_PAPER=en_US.utf8
LC_NAME=C     LC_ADDRESS=C  LC_TELEPHONE=C

[11] LC_MEASUREMENT=en_US.utf8 LC_IDENTIFICATION=C

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

Mark W. Kimpel MD  ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield, IN  46074

(317) 490-5129 Work, & Mobile & VoiceMail
(317) 399-1219 Skype No Voicemail please

[[alternative HTML version deleted]]

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

Re: [Rd] R crashes if "toFile" given "~/" in Linux envirnonment

[Mark Kimpel]

Thanks Simon. There was no help page for "toFile" (the first thing I tried)
so I didn't realize it was an Rgraphviz function. I'll contact the
maintainers.

Mark

Mark W. Kimpel MD  ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield, IN  46074

(317) 490-5129 Work, & Mobile & VoiceMail
(317) 399-1219 Skype No Voicemail please


On Mon, May 16, 2011 at 11:02 PM, Simon Urbanek  wrote:

> Mark,
>
> I think you have the wrong list - this has nothing to do with R. to File()
> is a function in Rgraphviz and it doesn't crash, it simply exits R.
> Obviously it doesn't support path expansion (I suppose it should consider
> calling path.expand()) and it should also consider using R_error() instead
> of quitting -- but both issues should be best addressed to the Rgraphviz
> maintainers.
>
> Cheers,
> Simon
>
>
> On May 16, 2011, at 10:50 PM, Mark Kimpel wrote:
>
> > I was running some sample code from a help page tonight and wished to
> > redirect the sample output to my Desktop under Linux (Mint-Debian 64 if
> it
> > makes a different). I was surprised to find that file name expansion
> using
> > the ubuquitious "~/" was not recognized, in fact it caused R to crash. Is
> > this expected behavior? See my output below and sessionInfo().  Also, not
> > shown, but 'setwd("~/Desktop")' works just fine.  Thanks, Mark
> >
> > # sample code from Rgraphviz clusterData help page
> > library(graph)
> > library(Rgraphviz)
> > g1_gz <-
> gzfile(system.file("GXL/graphExample-01.gxl.gz",package="graph"),
> > open="rb")
> > g11_gz <-
> gzfile(system.file("GXL/graphExample-11.gxl.gz",package="graph"),
> > open="rb")
> > g1 <- fromGXL(g1_gz)
> > g11 <- fromGXL(g11_gz)
> > g1_11 <- join(g1, g11)
> > sgl <- vector(mode="list", length=2)
> > sgl[[1]] <- list(graph=g1, cluster=TRUE)
> > sgl[[2]] <- list(graph=g11, cluster=TRUE)
> > ng <- agopenSimple(g1_11, "tmpsg", subGList=sgl)
> > clusterData(ng, 1, c("bgcolor")) <- c("blue")
> > clusterData(ng, 2, c("bgcolor")) <- c("red")
> > 
> > # and now 2 usually equivalent ways to specify the location for output
> file,
> > with the second way crashing:
> > toFile(ng, layoutType="dot", filename="/home/mkimpel/Desktop/
> g1_11_dot.ps",
> > fileType="ps")
> > NULL
> > toFile(ng, layoutType="dot", filename="~/Desktop/g1_11_dot.ps",
> > fileType="ps")
> > ~/Desktop/g1_11_dot.ps: No such file or directory
> >
> > Process R exited abnormally with code 1 at Mon May 16 22:42:12 2011
> > #
> > # and my sessionInfo()
> > R version 2.13.0 (2011-04-13)
> > Platform: x86_64-unknown-linux-gnu (64-bit)
> >
> > locale:
> > [1] LC_CTYPE=en_US.utf8   LC_NUMERIC=C
> > LC_TIME=en_US.utf8LC_COLLATE=en_US.utf8 LC_MONETARY=C
> >
> > [6] LC_MESSAGES=en_US.utf8LC_PAPER=en_US.utf8
> > LC_NAME=C LC_ADDRESS=C  LC_TELEPHONE=C
> >
> > [11] LC_MEASUREMENT=en_US.utf8 LC_IDENTIFICATION=C
> >
> > attached base packages:
> > [1] stats graphics  grDevices datasets  utils methods   base
> > 
> > Mark W. Kimpel MD  ** Neuroinformatics ** Dept. of Psychiatry
> > Indiana University School of Medicine
> >
> > 15032 Hunter Court, Westfield, IN  46074
> >
> > (317) 490-5129 Work, & Mobile & VoiceMail
> > (317) 399-1219 Skype No Voicemail please
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> >
>
>

[[alternative HTML version deleted]]

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

[Rd] Graphical option to update.packages in development version (build of the 2011-07-31 r56569) for Windows not working properly

[Mark Difford]

Dear R-core/development-team,

The problem noted in the subject-line has been a problem in the last three
development versions of R for Windows that I have downloaded and tested, the
most recent of them being a version I downloaded this morning.

Update.packages() using the graphical option, i.e. called as

update.packages(ask='graphics', checkBuilt=TRUE)

does not work as it should, but presents a list of all of the installed
packages, regardless of version/time-stamp.

The call

update.packages(old.packages())

works as it should.

> sessionInfo()
R Under development (unstable) (2011-07-31 r56569)
Platform: x86_64-pc-mingw32/x64 (64-bit)

locale:
[1] LC_COLLATE=English_South Africa.1252  LC_CTYPE=English_South Africa.1252   
[3] LC_MONETARY=English_South Africa.1252 LC_NUMERIC=C 
[5] LC_TIME=English_South Africa.1252

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

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


-
Mark Difford (Ph.D.)
Research Associate
Botany Department
Nelson Mandela Metropolitan University
Port Elizabeth, South Africa
--
View this message in context: 
http://r.789695.n4.nabble.com/Graphical-option-to-update-packages-in-development-version-build-of-the-2011-07-31-r56569-for-Windowy-tp3718847p3718847.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

Re: [Rd] Graphical option to update.packages in development version (build of the 2011-07-31 r56569) for Windows not working properly

[Mark Difford]

Thanks for the feedback, Uwe. Will try the most recent development version.

Best,
Mark Difford.

-
Mark Difford (Ph.D.)
Research Associate
Botany Department
Nelson Mandela Metropolitan University
Port Elizabeth, South Africa
--
View this message in context: 
http://r.789695.n4.nabble.com/Graphical-option-to-update-packages-in-development-version-build-of-the-2011-07-31-r56569-for-Windowy-tp3718847p3757596.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

[Rd] suppressing stderr output from system() calls

[Mark Cowley]

Dear list,
I'm trying to suppress/redirect/squash the output from commands like 
install.packages, or download.file. The problem is that none of: sink(..., 
type="message"), sink(..., type="output"), capture.output, suppressMessages are 
quite doing the trick. Output gets written to the stderr stream, despite any 
combination of the above suppression commands.
According to ?sink:
Messages sent to ‘stderr()’ (including those from ‘message’, ‘warning’ and 
‘stop’) can be diverted by ‘sink(type = "message")’ (see below).

I'm pretty sure it's the system(), or .Internal() calls which are the culprit, 
which currently write the majority (all?) of their output to the stderr stream.

Simple example:
con <- file("stderr.txt", "w")
sink(con, type="message")
system("ls")
sink(NULL, type="message")
close(con)
# instead of the output going to stderr.txt, it gets printed to the console.

# no good either
capture.output(system("ls"))
character(0)

This is an issue, since i'm writing GenePattern modules to run R code, and if 
anything is written to stderr, then the job gets hit with a 'job failed' 
status, when all that might have happened is an R package got installed, or a 
file got downloaded via FTP.

Any ideas? Can system() and .Internal() output be redirected to stdout?

cheers,
Mark


sessionInfo()
R version 2.13.1 (2011-07-08)
Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)

locale:
[1] en_AU.UTF-8/en_AU.UTF-8/C/C/en_AU.UTF-8/en_AU.UTF-8

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



-
Mark Cowley, PhD

Pancreatic Cancer Program | Peter Wills Bioinformatics Centre
Garvan Institute of Medical Research, Sydney, Australia
-


[[alternative HTML version deleted]]

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

[Rd] Fresh build from source of R-3.2.5 failing "make check" under 64-bit Ubuntu

[Mark Dalphin]

Hi,

Let me justify building R from source. While I can obtain R built for me
under Ubuntu, I tend to build it from scratch as we use a NFS-shared
build as well as shared R libraries for all the bioinfo staff at this
company. Only one build and one set of packages to ensure uniformity
across all workstations.

My problem is that despite using a pretty standard build process, I am
failing at the "make check" step. I don't see what I might have done
that is causing the failure.

My platform is:

> uname -a
Linux littlebourne 3.13.0-85-generic #129-Ubuntu SMP Thu Mar 17 20:50:15
UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

> cat /etc/issue
Ubuntu 14.04.4 LTS \n \l

I've downloaded the recent R-3.2.5 tar-gz file and gone through the
standard build, though in a non-standard location. I keep copies of the
tar-gzipped file in an "Archive" directory.

> gunzip -c Archive/R-3.2.5.tar.gz | tar xf -
> cd R-3.2.5/
> ./configure --prefix=/opt/apps/x86_64/R/R-3.2.5 LIBnn=lib
[ ... much output ...]
R is now configured for x86_64-pc-linux-gnu

  Source directory:  .
  Installation directory:/opt/apps/x86_64/R/R-3.2.5

  C compiler:gcc -std=gnu99  -g -O2
  Fortran 77 compiler:   gfortran  -g -O2

  C++ compiler:  g++  -g -O2
  C++ 11 compiler:   g++  -std=c++11 -g -O2
  Fortran 90/95 compiler:gfortran -g -O2
  Obj-C compiler: gcc -g -O2 -fobjc-exceptions

  Interfaces supported:  X11, tcltk
  External libraries:readline, zlib, bzlib, lzma, PCRE
  Additional capabilities:   PNG, JPEG, TIFF, NLS, cairo
  Options enabled:   shared BLAS, R profiling

  Capabilities skipped:  ICU
  Options not enabled:   memory profiling

  Recommended packages:  yes

# Note: I use tcsh, not bash
> make >& make.out &
# There are no obvious errors and the 'make' proceeds finally through
some Java configuration
# and then exits with a zero status.

> make check >& make_check.out &
[ ... much output captured ...]
make[3]: Entering directory `/opt/apps/x86_64/R/src/R-3.2.5/tests'
running code in 'reg-tests-1a.R' ... OK
running code in 'reg-tests-1b.R' ... OK
running code in 'reg-tests-1c.R' ... OK
running code in 'reg-tests-2.R' ... OK
  comparing 'reg-tests-2.Rout' to './reg-tests-2.Rout.save' ... OK
running code in 'reg-examples1.R' ... OK
running code in 'reg-examples2.R' ... OK
running code in 'reg-packages.R' ...make[3]: *** [reg-packages.Rout] Error 1
make[3]: Leaving directory `/opt/apps/x86_64/R/src/R-3.2.5/tests'
make[2]: *** [test-Reg] Error 2
make[2]: Leaving directory `/opt/apps/x86_64/R/src/R-3.2.5/tests'
make[1]: *** [test-all-basics] Error 1
make[1]: Leaving directory `/opt/apps/x86_64/R/src/R-3.2.5/tests'
make: *** [check] Error 2

> cd tests
> tail -30 reg-packages.Rout.fail
*** installing help indices
** building package indices
** testing if installed package can be loaded
* DONE (pkgB)
Loading required package: pkgB
building package exNSS4 ...

installing package exNSS4 using file exNSS4_1.1.tar.gz ...
* installing *source* package 'exNSS4' ...
** R
** preparing package for lazy loading
Creating a generic function for 'plot' from package 'graphics' in
package 'exNSS4'
** help
No man pages found in package  'exNSS4'
*** installing help indices
** building package indices
** testing if installed package can be loaded
* DONE (exNSS4)
Loading required package: exNSS4
> (res <- installed.packages(lib.loc = "myLib", priority = "NA"))
  Package LibPath Version Priority Depends   Imports LinkingTo Suggests
myTst "myTst" "myLib" "1.0"   NA   "methods" NA  NANA 
  Enhances License License_is_FOSS
myTst NA   "What license is it under?" NA
  License_restricts_use OS_type MD5sum NeedsCompilation Built 
myTst NANA  NA NA   "3.2.5"
> stopifnot(identical(res[,"Package"], setNames(,sort(c(p.lis, "myTst",
+   res[,"LibPath"] == "myLib")
Error: identical(res[, "Package"], setNames(, sort(c(p.lis, "myTst"
is not TRUE
Execution halted

> ls myLib
exNSS4  myTst  pkgA  pkgB

So, it looks like the "installed.packages()" is not correctly detecting
what is present in "myLib".

Has anyone else seen this? Has anyone got any ideas about what is going
wrong? My environment does not include R_LIBS, LD_LIBRARY, etc. The PATH
does include an older version of R, 3.1.1.

Regards,
Mark Dalphin

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

Re: [Rd] Fresh build from source of R-3.2.5 failing "make check" under 64-bit Ubuntu [SOLVED]

[Mark Dalphin]

Testing for an NFS effect on the failure of 'make check':

Try first on /usr/local/

9:42cd /usr/local/src/
9:42sudo mkdir R
9:43 sudo chown mdalphin:mdalphin R
9:43 cd R
9:43 gunzip -c /opt/apps/x86_64/R/Archive/R-3.2.5.tar.gz | tar xf -
9:43 cd R-3.2.5/
9:44 ./configure --prefix=/opt/apps/x86_64/R/R-3.2.5 LIBnn=lib
9:44 make
9:57 make check

This PASSES all tests. Exit status of ZERO. 
  
Now try on NFS:

10:04cd /opt/apps/x86_64/R/src/
10:05gunzip -c /opt/apps/x86_64/R/Archive/R-3.2.5.tar.gz | tar xf -
10:06   cd R-3.2.5/
10:06   ./configure --prefix=/opt/apps/x86_64/R/R-3.2.5 LIBnn=lib
10:06   make
10:14make check
 This FAILS (see below). Exit status of NON-ZERO:

running code in 'reg-packages.R' ...make[3]: *** [reg-packages.Rout] Error 1
make[3]: Leaving directory `/opt/apps/x86_64/R/src/R-3.2.5/tests'
make[2]: *** [test-Reg] Error 2
make[2]: Leaving directory `/opt/apps/x86_64/R/src/R-3.2.5/tests'
make[1]: *** [test-all-basics] Error 1
make[1]: Leaving directory `/opt/apps/x86_64/R/src/R-3.2.5/tests'
make: *** [check] Error 2

What might be different?

> ls -ld /opt/apps/x86_64/R/src/R-3.2.5/ /usr/local/src/R/R-3.2.5/
drwxr-xr-x 15 mdalphin mdalphin 4096 Apr 22 09:57 
/opt/apps/x86_64/R/src/R-3.2.5/
drwxr-xr-x 15 mdalphin mdalphin 4096 Apr 22 09:50 /usr/local/src/R/R-3.2.5/

> mount | grep /opt/
myHost.science:/mnt/home/opt/apps on /opt/apps type nfs 
(rw,soft,bg,nfsvers=3,addr=XXX.XXX.XXX.XXX)

Just the NFS, I guess. This is not good, but not an R-Devel problem.

Thanks for the help.

Cheers,

Mark Dalphin PhD

Director of Bioinformatics
mark.dalp...@pacificedge.co.nz
Ph: +64 3 479 4690
Cell: +64 21 156 7625
Skype: mark.dalphin.pel



87 St David St, PO Box 56, Dunedin, New Zealand 9016www.pacificedgedx.com


____
From: Mark Dalphin 
Sent: Friday, 22 April 2016 9:19
To: peter dalgaard; Prof Brian Ripley
Subject: Re: [Rd] Fresh build from source of R-3.2.5 failing "make check" under 
64-bit Ubuntu

I have run it both ways; for the purposes of this email, it was easier
to capture both STDOUT and STDERR ( '>&') into one file and have the
process run in the background (second '&'). That way I could more
readily capture the exact commands used and not have them scroll off the
top of the screen (make's output is quite large). The exact same error
occurs when I run the 'make' command as:

./configure PARAMETERS
make
make check

It is on an NFS file system; I'll look into building on a local file
system (/usr/local/) and see if I get the same errors.

Cheers,
Mark Dalphin


On 22/04/16 00:35, peter dalgaard wrote:
> On 21 Apr 2016, at 14:11 , Prof Brian Ripley  wrote:
>
>> On 21/04/2016 12:20, peter dalgaard wrote:
>>> Hmm. I don't think this has been seen by other Ubuntu users, or other 
>>> Linuxen for that matter.
>>>
>>> You have a gratuitous use of "&", but I don't really see how that would 
>>> give these symptoms, unless you accidentally run a command twice, creating 
>>> a race condition between two background processes.
>> He did say he used tcsh, for which >& is legal and far more memorable than 
>> (goes to look it up to get the order right) >foo 2>&1
> I know (old tcsh user, before bash got traction[*], in fact). It was the "&" 
> at the end that I was talking about:
>
> make check >& make_check.out &
>
> This runs make in the background and redirects stdout/err to a file. As I 
> said, it is most likely harmless unless you accidentally get two processes 
> running at the same time, but I think I'd try runnning in the foreground, 
> just in case.
>
> -pd
>
> [*] That'll be before Linux; the first versions of Slackware used bash (ash 
> for boot disks). So... like 1991, 25 years back. Yikes!
>
>>> More likely it is file system related, like NFS directory caching or maybe 
>>> permissions, although the latter seems unlikely if one package does install 
>>> properly. You might want to recheck whether  installed.packages(lib.loc = 
>>> "myLib", priority = "NA") gives different results a bit later, and if not, 
>>> check that the package descriptions are sane.
>>>
>>> -pd
>>>
>>> On 21 Apr 2016, at 00:50 , Mark Dalphin  
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Let me justify building R from source. While I can obtain R built for me
>>>> under Ubuntu, I tend to build it from scratch as we use a NFS-shared
>>>> build as well as sha

[Rd] A bug in the R Mersenne Twister (RNG) code?

[Mark Roberts]

Whomever,

I recently sent the "bug report" below tor-c...@r-project.org and have 
just been asked to instead submit it to you.

Although I am basically not an R user, I have installed version 3.3.1 
and am also the author of a statistics program written in Visual Basic 
that contains a component which correctly implements the Mersenne 
Twister (MT) algorithm.  I believe that it is not possible to generate 
the correct stream of pseudorandom numbers using the MT default random 
number generator in R, and am not the first person to notice this.  Here 
is a posted 2013 entry 
(www.r-bloggers.com/reproducibility-and-randomness/) on an R website 
that asserts that the SAS computer program implementation of the MT 
algorithm produces different numbers than R does when using the same 
starting seed number.  The author of this post didn’t get anyone to 
respond to his query about the reason for this SAS vs. R discrepancy.

There are two ways of initializing the original MT computer program 
(written in C) so that an identical stream of numbers can be repeatedly 
generated:  1) with a particular integer seed number, and 2) with a 
particular array of integers.   In the 'compilation and usage' section 
of this webpage (https://github.com/cslarsen/mersenne-twister) there is 
a listing of the first 200 random numbers the MT algorithm should 
produce for seed number = 1.  The inventors of the Mersenne Twister 
random number generator provided two different sets of the first 1000 
numbers produced by a correctly coded 32-bit implementation of the MT 
algorithm when initializing it with a particular array of integers at: 
www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/MT2002/CODES/mt19937ar.out. 
[There is a link to this output at: 
www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/MT2002/emt19937ar.html.]

My statistics program obtains exactly those 200 numbers from the first 
site mentioned in the previous paragraph and also obtains those same 
numbers from the second website (though I didn't check all 2000 values). 
   Assuming that the MT code within R uses the 32-bit MT algorithm, I 
suspect that the current version of R can't do that.  If you (i.e., 
anyone who might knowledgeably respond to this report) is able to 
duplicate those reference test-values, then please send me the R code to 
initialize the MT code within R to successfully do that, and I apologize 
for having wasted your time. If you (collectively) can't do that, then R 
is very likely using incorrectly implemented MT code.  And if this 
latter possibility is true, it seems to me that this is something that 
should be fixed.

Mark Roberts, Ph.D.

[[alternative HTML version deleted]]

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

Re: [Rd] optim(…, method=‘L-BFGS-B’) stops with an error message while violating the lower bound

[Mark Leeds]

Hi Spencer: See the link below about L-BFGS-B below because  I had problems
with it a good while back (and I think the link description is the cause
but I can't prove it )  so  eventually I moved to the  Rvmmin(b) package.
It's a package but really an algorithm. Rvmmin(b) uses a variable-metric
algorithm similar to that of L-BFGS-B but without the problem below. It's
not surprisingly a creation of John Nash and quite impressive based on my
experience. Just like L-BFGS, it can implement box constraints by adding
the b.

http://users.eecs.northwestern.edu/~morales/PSfiles/acm-remark.pdf







On Sat, Oct 8, 2016 at 2:50 PM, Spencer Graves 
wrote:

> Hello:
>
>
>   The development version of Ecdat on R-Forge contains a vignette in
> which optim(…, method=‘L-BFGS-B’) stops with an error message while
> violating the lower bound.
>
>
>   To see all the details, try the following:
>
>
> install.packages("Ecdat", repos="http://R-Forge.R-project.org";)
>
>
>   Then do "help(pac=Ecdat)" -> "User guides, package vignettes and
> other documentation" -> "Ecdat::AverageIncomeModels".
>
>
>   I've found other optimizers that will get around the problem in this
> case but none that performs as well as optim with many other problems.
>
>
>   Thanks,
>   Spencer Graves
>
>
> p.s.  I've also tested bobyqa{minqa} or nloptr{nloptr}, recommended in a
> vignette in the lme4 package.  These did better than optim in this example
> but worse in others I tried.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

[[alternative HTML version deleted]]

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

Re: [Rd] optim(…, method=‘L-BFGS-B’) stops with an error message while violating the lower bound

[Mark Leeds]

Hi Spencer:

1)  I can't help much as far as your results but one thing you could do is
check what
the convergence flag of Rvmmin is. There are difference ones depending
on what happened during the optimization and they're pretty helpful IIRC.
But that may require running Rvmmin directly rather than in optimx.
I did a lot of optimizations ( hundreds ) at one point and I never saw it
return NA ??

2) I wasn't sure about 2) either so I figured it was safer to get away from
L-BFGS-B.








On Sat, Oct 8, 2016 at 7:03 PM, Spencer Graves 
wrote:

> Hi, Mark et al.:
>
>
>   Thanks, Mark.
>
>
>   Three comments:
>
>
> 1.  Rvmmin was one of the methods I tried after Ravi directed
> me to optimx.  It returned NAs for essentially everything.  See my email of
> this subject stamped 4:43 PM Central time = 21:43 UTC.
>
>
> 2.  It would be interesting to know if the current algorithm
> behind optim and optimx with method='L-BFGS-B' incorporates Morales and
> Nocedal (2011) 'Remark on “Algorithm 778: L-BFGS-B: Fortran Subroutines for
> Large-Scale Bound Constrained Optimization”'.  I created this vignette and
> started this threat hoping that someone on the R Core team might decide
> it's worth checking things like that.
>
>
> 3.  The vignette mentioned below was extracted from a larger
> vignette fitting several models that seem to encounter convergence
> problems.  I should probably switch to optimx using all the methods that
> offers for constrained optimization, including nminb.
>
>
>   Best Wishes,
>   Spencer Graves
>
>
>
> On 10/8/2016 5:00 PM, Mark Leeds wrote:
>
> Hi Spencer: See the link below about L-BFGS-B below because  I had problems
> with it a good while back (and I think the link description is the cause
> but I can't prove it )  so  eventually I moved to the  Rvmmin(b) package.
> It's a package but really an algorithm. Rvmmin(b) uses a variable-metric
> algorithm similar to that of L-BFGS-B but without the problem below. It's
> not surprisingly a creation of John Nash and quite impressive based on my
> experience. Just like L-BFGS, it can implement box constraints by adding
> the b.
>
> http://users.eecs.northwestern.edu/~morales/PSfiles/acm-remark.pdf
>
>
>
>
>
>
>
> On Sat, Oct 8, 2016 at 2:50 PM, Spencer Graves <
> spencer.gra...@prodsyse.com> wrote:
>
>> Hello:
>>
>>
>>   The development version of Ecdat on R-Forge contains a vignette in
>> which optim(…, method=‘L-BFGS-B’) stops with an error message while
>> violating the lower bound.
>>
>>
>>   To see all the details, try the following:
>>
>>
>> install.packages("Ecdat", repos="http://R-Forge.R-project.org";)
>>
>>
>>   Then do "help(pac=Ecdat)" -> "User guides, package vignettes and
>> other documentation" -> "Ecdat::AverageIncomeModels".
>>
>>
>>   I've found other optimizers that will get around the problem in
>> this case but none that performs as well as optim with many other problems.
>>
>>
>>   Thanks,
>>   Spencer Graves
>>
>>
>> p.s.  I've also tested bobyqa{minqa} or nloptr{nloptr}, recommended in a
>> vignette in the lme4 package.  These did better than optim in this example
>> but worse in others I tried.
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
>

[[alternative HTML version deleted]]

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

Re: [Rd] getGraphicsEvent() alternative for cairo graphics device?

[Mark O'Connell]

Hi Paul,

No problem. Is it best if I post examples to the bug report 16951?

Kind regards,
Mark

--

Mark O'Connell, PhD student
Department of Mathematics & Statistics
231 Top Logic
National University of Ireland, Maynooth

- Paul Murrell  wrote:
> 
> Thanks Frederick.
> 
> Mark, if you have any examples to share, they would also be gratefully 
> received.
> 
> Paul
> 
> On 14/11/16 14:53, frede...@ofb.net wrote:
> > Hi Paul,
> >
> > OK I tried not to make the examples too fancy.
> >
> > Please let me know what you think. They should probably be amended to
> > support the Windows platform, but I think that task would be much
> > easier for someone with access to Windows...
> >
> > By the way I'm Cc'ing Mark O'Connell who shared with me some great
> > getGraphicsEvent examples - well, I found them useful, perhaps if
> > these are going to the R distro somewhere, then his examples should be
> > included as well.
> >
> > Thank you,
> >
> > Frederick
> >
> > On Mon, Nov 14, 2016 at 01:51:08PM +1300, Paul Murrell wrote:
> >>
> >> Great.  Thanks!
> >>
> >> Paul
> >>
> >> On 14/11/16 13:41, frede...@ofb.net wrote:
> >>> Hi Paul,
> >>>
> >>> Thank you, for some reason I didn't seem to get an email notification
> >>> for your bugzilla comment!
> >>>
> >>> I will try to send you something shortly.
> >>>
> >>> Frederick
> >>>
> >>> On Mon, Nov 14, 2016 at 08:55:20AM +1300, Paul Murrell wrote:
> >>>> Hi
> >>>>
> >>>> The current status is that I am keen for people to contribute some 
> >>>> testing
> >>>> code (see https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951)
> >>>>
> >>>> There were also some getGraphicsEvent() changes/fixes suggested by 
> >>>> Richard
> >>>> Bodewits (cc'ed), for which I am also seeking test code.
> >>>>
> >>>> Paul
> >>>>
> >>>> On 13/11/16 09:00, frede...@ofb.net wrote:
> >>>>> Hi Paul,
> >>>>>
> >>>>> Just checking in to see what the status is.
> >>>>>
> >>>>> From my perspective it seems logical to split off X11 into a separate
> >>>>> package, so development can proceed at a reasonable rate, but I
> >>>>> haven't yet tried to see if that's even possible.
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Frederick
> >>>>>
> >>>>> On Tue, Jul 26, 2016 at 09:23:35AM +1200, Paul Murrell wrote:
> >>>>>> Hi
> >>>>>>
> >>>>>> Taking a look at those patches is now on my todo list, so I may be in 
> >>>>>> touch
> >>>>>> with both of you at some point to request some testing.
> >>>>>>
> >>>>>> Paul
> >>>>>>
> >>>>>> On 26/07/16 07:17, frede...@ofb.net wrote:
> >>>>>>> Dear Daniel Greenidge,
> >>>>>>>
> >>>>>>> To enable getGraphicsEvent on Cairo, you have two patches to choose
> >>>>>>> from:
> >>>>>>>
> >>>>>>> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=14364
> >>>>>>> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951
> >>>>>>>
> >>>>>>> The second one is by me, and the first one is from five years ago by
> >>>>>>> Hugo Mildenberger.
> >>>>>>>
> >>>>>>> Both patches are very simple, they move some lines enabling
> >>>>>>> getGrahpicsEvent outside of a if(!cairo) statement. My patch also adds
> >>>>>>> the ability to execute code (e.g. for animation) while the interface
> >>>>>>> is idle.
> >>>>>>>
> >>>>>>> Top guy Duncan Murdoch has expressed that he doesn't have time to work
> >>>>>>> on applying these patches, and I haven't had any responses from the
> >>>>>>> rest of the R Core Team. I was thinking that perhaps your best bet is
> >>>>>>> to try to create a package called e.g. "X11-fixes" which people can
> >>>>

Re: [Rd] Wrongly converging glm()

[Mark Leeds]

Hi Harm-Jan. I've been following this thread to some degree and just want
to add that
 this issue is not specific to the GLM. It's a problem with optimization of
functions in general. I was using use Rvmmin with constraints which is an
extremely solid optimization package written by John Nash ( uses a modified
BFGS  algorithm) and it took me two years to realize that, although my
optimization generally converged, there was an idenitifiability issue with
my model that basically meant that the results meant nothing. I only
eventually found this out because, in the econometrics literature,  the
type of economic model I was estimating ( rational expectations ) is known
to have an identifiability issue. I guess if I was an economics expert, I
may have been able to know this but, in general, I think what you are
asking
optimization code to do is EXTREMELY DIFFICULT.

John Nash can say more because he's THE optimization masteR but it's much
more difficult to write optimization algorithms with convergence rules that
are able to identify when mathematical convergence ( norm near zero say )
is not necessarily model convergence. That I can tell you from experience
!!!








On Thu, Jul 20, 2017 at 2:32 PM, Harm-Jan Westra  wrote:

> My apologies if I seemed to ‘blame R’. This was in no way my intention. I
> get the feeling that you’re missing my point as well.
>
> I observed something that I thought was confusing, when comparing two more
> or less identical methods (when validating the C code), and wanted to make
> a suggestion as to how to help future R users. Note that I already
> acknowledged that my data was bad. Note that I also mention that the way R
> determines convergence is a valid approach.
>
> What strikes me as odd is that R would warn you when your data is faulty
> for a function such as cor(), but not for glm(). I don’t see why you
> wouldn’t want to check both convergence criteria if you know multiple of
> such criteria exist. It would make the software more user friendly in the
> end.
>
> It may be true that there are millions of edge cases causing issues with
> glm(), as you say, but here I am presenting an edge case that can be easily
> detected, by checking whether the difference in beta estimates between the
> current and previous iteration is bigger than a certain epsilon value.
>
> I agree ‘that everybody using R should first do the effort of learning
> what they're doing’, but it is a bit of a non-argument, because we all know
> that, the world just doesn’t work that way, plus this is one of the
> arguments that has held for example the Linux community back for quite a
> while (i.e. let’s not make the software more user friendly because the user
> should be more knowledgeable).
>
> Harm-Jan
>
>
> From: Joris Meys
> Sent: Thursday, July 20, 2017 13:16
> To: Harm-Jan Westra
> Cc: r-devel@r-project.org
> Subject: Re: [Rd] Wrongly converging glm()
>
>
>
> On Thu, Jul 20, 2017 at 6:21 PM, Harm-Jan Westra <
> westra.harm...@outlook.com> wrote:
> Dear Joris,
>
>
> I agree that such a covariate should not be used in the analysis, and
> fully agree with your assessment. However, your response assumes that
> everybody who uses R knows what they're doing, which is a dangerous
> assumption to make. I bet there are a lot of people who blindly trust the
> output from R, even when there's clearly something wrong with the estimates.
>
> You missed my point then. I don't assume that everybody who uses R knows
> what they're doing. Actually, I know for a fact quite a few people using R
> have absolutely no clue about what they are doing. My point is that
> everybody using R should first do the effort of learning what they're
> doing. And if they don't, one shouldn't blame R. There's a million
> different cases where both algorithms would converge and the resulting
> estimates are totally meaningless regardless. R cannot be held responsible
> for that.
>
>
>
> In terms of your conclusion that the C++ estimate corresponds to a value
> within the R estimated confidence interval: if I allow the C++ code to run
> for 1000 iterations, it's estimate would be around -1000. It simply never
> converges.
>
> I didn't test that far, and you're right in the sense that -100 is indeed
> not the final estimate. After looking at the C code, it appears as if the
> author of that code combines a Newton-Raphson approach with a different
> convergence rule. And then it's quite understandible it doesn't converge.
> You can wildly vary that estimate, the effect it has on the jacobian, log
> likelihood or deviance will be insignificant. So the model won't improve,
> it would just move all over the parameter space.
>
>
>
> I think there's nothing wrong with letting the user know there might be
> something wrong with one of the estimates, especially if your code can
> easily figure it out for you, by addi

Re: [Rd] Wrongly converging glm()

[Mark Leeds]

Hi Ravi: Well said. In John's Rvmmin package, he has codes for explaining
the cause
of the termination. The codes returned were fine. The problem was that
the model I was using could have multiple solutions ( regardless of the data
sent in ) so, even though the stopping criteria was reached, it turned out
that one of the parameters ( there were two parameters ) could have really
been anything and the same likelihood value would  be returned. So, what I
learned the hard way was  termination due to reasonable stopping  criteria
DOES NOT NECESSARILY EQUAL OPTIMAL. But I lived in the dark about this for
a long time and only happened to notice it when playing around with the
likelihood by fixing the offending parameter to various values and
optimizing over the
non-offending parameter. Thanks for eloquent explanation.


  Mark




























On Fri, Jul 21, 2017 at 9:22 AM, Ravi Varadhan 
wrote:

> Please allow me to add my 3 cents.  Stopping an iterative optimization
> algorithm at an "appropriate" juncture is very tricky.  All one can say is
> that the algorithm terminated because it triggered a particular stopping
> criterion.  A good software will tell you why it stopped - i.e. the
> stopping criterion that was triggered.  It is extremely difficult to make a
> failsafe guarantee that the triggered stopping criterion is the correct one
> and that the answer obtained is trustworthy. It is up to the user to
> determine whether the answer makes sense.  In the case of maximizing a
> likelihood function, it is perfectly reasonable to stop when the algorithm
> has not made any progress in increasing the log likelihood.  In this case,
> the software should print out something like "algorithm terminated due to
> lack of improvement in log-likelihood."  Therefore, I don't see a need to
> issue any warning, but simply report the stopping criterion that was
> applied to terminate the algorithm.
>
> Best,
> Ravi
>
> -Original Message-
> From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of
> Therneau, Terry M., Ph.D.
> Sent: Friday, July 21, 2017 8:04 AM
> To: r-devel@r-project.org; Mark Leeds ;
> jorism...@gmail.com; westra.harm...@outlook.com
> Subject: Re: [Rd] Wrongly converging glm()
>
> I'm chiming in late since I read the news in digest form, and I won't copy
> the entire conversation to date.
>
> The issue raised comes up quite often in Cox models, so often that the
> Therneau and Grambsch book has a section on the issue (3.5, p 58).  After a
> few initial iterations the offending coefficient will increase by a
> constant at each iteration while the log-likelihood approaches an asymptote
> (essentially once the other coefficients "settle down").
>
> The coxph routine tries to detect this case and print a warning, and this
> turns out to be very hard to do accurately.  I worked hard at tuning the
> threshold(s) for the message several years ago and finally gave up; I am
> guessing that the warning misses > 5% of the cases when the issue is true,
> and that 5% of the warnings that do print are incorrect.
> (And these estimates may be too optimistic.)   Highly correlated
> predictors tend to trip
> it up, e.g., the truncated power spline basis used by the rcs function in
> Hmisc.
>
> All in all, I am not completely sure whether the message does more harm
> than good.  I'd be quite reluctant to go down the same path again with the
> glm function.
>
> Terry Therneau
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

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

Re: [Rd] Wrongly converging glm()

[Mark Leeds]

H Ravi: Yes, IIRC that's EXACTLY what was going on in my case. Based on
the codes from Rvmmin,  the objective functon wasn't changing much and I
think norm of the gradient was close to zero so it was difficult for me to
detect the issue. I found it when I
happenered to notice that the objective function seemed independent of one
of the parameters.






On Fri, Jul 21, 2017 at 4:36 PM, Ravi Varadhan 
wrote:

> “So, what I learned the hard way was  termination due to reasonable
> stopping  criteria DOES NOT NECESSARILY EQUAL OPTIMAL.”
>
>
>
> Yes, I agree, Mark.
>
>
>
> Let me add another observation.  In the “optimx” package, John Nash and I
> implemented a check for optimality conditions – first and second order KKT
> conditions.  This involves checking whether the gradient is sufficiently
> small and the Hessian is positive definite (for local minimum) at the final
> parameter values.  However, it can be quite time consuming to compute these
> quantities and in some problems checking KKT can take up more effort than
> finding the solution!  Furthermore, it is difficult to come up with good
> thresholds for determining “small” gradient and “positive definite”
> Hessian, since these can depend upon the scale of the objective function
> and the parameters.
>
>
>
> Ravi
>
>
>
> *From:* Mark Leeds [mailto:marklee...@gmail.com]
> *Sent:* Friday, July 21, 2017 3:09 PM
> *To:* Ravi Varadhan 
> *Cc:* Therneau, Terry M., Ph.D. ; r-devel@r-project.org;
> jorism...@gmail.com; westra.harm...@outlook.com
>
> *Subject:* Re: [Rd] Wrongly converging glm()
>
>
>
> Hi Ravi: Well said. In John's Rvmmin package, he has codes for explaining
> the cause
>
> of the termination. The codes returned were fine. The problem was that
>
> the model I was using could have multiple solutions ( regardless of the
> data
> sent in ) so, even though the stopping criteria was reached, it turned out
> that one of the parameters ( there were two parameters ) could have really
> been anything and the same likelihood value would  be returned. So, what I
> learned the hard way was  termination due to reasonable stopping  criteria
> DOES NOT NECESSARILY EQUAL OPTIMAL. But I lived in the dark about this for
> a long time and only happened to notice it when playing around with the
> likelihood by fixing the offending parameter to various values and
> optimizing over the
> non-offending parameter. Thanks for eloquent explanation.
>
>
> Mark
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Fri, Jul 21, 2017 at 9:22 AM, Ravi Varadhan 
> wrote:
>
> Please allow me to add my 3 cents.  Stopping an iterative optimization
> algorithm at an "appropriate" juncture is very tricky.  All one can say is
> that the algorithm terminated because it triggered a particular stopping
> criterion.  A good software will tell you why it stopped - i.e. the
> stopping criterion that was triggered.  It is extremely difficult to make a
> failsafe guarantee that the triggered stopping criterion is the correct one
> and that the answer obtained is trustworthy. It is up to the user to
> determine whether the answer makes sense.  In the case of maximizing a
> likelihood function, it is perfectly reasonable to stop when the algorithm
> has not made any progress in increasing the log likelihood.  In this case,
> the software should print out something like "algorithm terminated due to
> lack of improvement in log-likelihood."  Therefore, I don't see a need to
> issue any warning, but simply report the stopping criterion that was
> applied to terminate the algorithm.
>
> Best,
> Ravi
>
> -Original Message-
> From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of
> Therneau, Terry M., Ph.D.
> Sent: Friday, July 21, 2017 8:04 AM
> To: r-devel@r-project.org; Mark Leeds ;
> jorism...@gmail.com; westra.harm...@outlook.com
> Subject: Re: [Rd] Wrongly converging glm()
>
> I'm chiming in late since I read the news in digest form, and I won't copy
> the entire conversation to date.
>
> The issue raised comes up quite often in Cox models, so often that the
> Therneau and Grambsch book has a section on the issue (3.5, p 58).  After a
> few initial iterations the offending coefficient will increase by a
> constant at each iteration while the log-likelihood approaches an asymptote
> (essentially once the other coefficients "settle down").
>
> The coxph routine tries to detect this case and print a warning, and this
> turns out to be very hard to do accurately.  I worked hard at tuning the
> threshold(s) for the message several years

Re: [Rd] suppressing stderr output from system() calls

[Mark Cowley]

Thanks Martin, Simon and Brian,
They're all good suggestions for code that I write, however how can I suppress 
stderr from pre-existing code. For instance, install.packages has 3 system 
calls.
Perhaps a better worded question would be: how can I redirect the output of 
this command:

install.packages("MASS", lib="/tmp", type="source")

As I mentioned before, sink doesn't do the trick
con <- file("stderr.txt", "w")
sink(con, type="message")
install.packages("MASS", lib="/tmp", type="source")
sink(NULL, type="message")
close(con)

Martin will be familiar with the Bioconductor package oligo, which likes to 
download pd info package on the fly and install them - the embedded call to 
download.file is noisy, as is the resulting installation of said package.

Short of rewriting install.package & all code which has embedded 
install.packages calls, are there any other ways?

@Brian, thanks for the pointer to the news article on connections - I did learn 
something there
cheers,

Mark

On 06/10/2011, at 3:59 AM, Martin Morgan wrote:

> On 10/05/2011 02:36 AM, Mark Cowley wrote:
>> Dear list,
> 
>> I'm trying to suppress/redirect/squash the output from commands like
>> install.packages, or download.file. The problem is that none of:
>> sink(..., type="message"), sink(..., type="output"), capture.output,
>> suppressMessages are quite doing the trick. Output gets written to
>> the stderr stream, despite any combination of the above suppression
>> commands.
> 
> Hi Mark --
> 
> For download.file, the argument quiet=TRUE suppresses output messages; this 
> option can be used in ... for install.packages, too (according to the 
> documentation). This is good enough to quieten the regular chatter on a 
> successful operation. To catch errors and suppress warnings also, maybe a 
> construct like
> 
> url = "http://r-project.org/doesnotexist";
> tryCatch(suppressWarnings(
>capture.output(download.file(url, tempfile(), quiet=TRUE))),
>error=function(...) {})
> 
> Martin
> 
>> According to ?sink:
>> Messages sent to ‘stderr()’ (including those from ‘message’, ‘warning’ and 
>> ‘stop’) can be diverted by ‘sink(type = "message")’ (see below).
>> 
>> I'm pretty sure it's the system(), or .Internal() calls which are the 
>> culprit, which currently write the majority (all?) of their output to the 
>> stderr stream.
>> 
>> Simple example:
>> con<- file("stderr.txt", "w")
>> sink(con, type="message")
>> system("ls")
>> sink(NULL, type="message")
>> close(con)
>> # instead of the output going to stderr.txt, it gets printed to the console.
>> 
>> # no good either
>> capture.output(system("ls"))
>> character(0)
>> 
>> This is an issue, since i'm writing GenePattern modules to run R code, and 
>> if anything is written to stderr, then the job gets hit with a 'job failed' 
>> status, when all that might have happened is an R package got installed, or 
>> a file got downloaded via FTP.
>> 
>> Any ideas? Can system() and .Internal() output be redirected to stdout?
>> 
>> cheers,
>> Mark
>> 
>> 
>> sessionInfo()
>> R version 2.13.1 (2011-07-08)
>> Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
>> 
>> locale:
>> [1] en_AU.UTF-8/en_AU.UTF-8/C/C/en_AU.UTF-8/en_AU.UTF-8
>> 
>> attached base packages:
>> [1] stats graphics  grDevices utils datasets  methods   base
>>> 
>> 
>> 
>> 
>> -
>> Mark Cowley, PhD
>> 
>> Pancreatic Cancer Program | Peter Wills Bioinformatics Centre
>> Garvan Institute of Medical Research, Sydney, Australia
>> -
>> 
>> 
>>  [[alternative HTML version deleted]]
>> 
>> 
>> 
>> 
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> 
> -- 
> Computational Biology
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109
> 
> Location: M1-B861
> Telephone: 206 667-2793

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

[Rd] R CMD INSTALL writes to stderr

[Mark Cowley]

Dear list,
(this is a follow up from a previous query)

Why does R CMD INSTALL write most of its messages to stderr? If it wrote to 
stdout, then we could capture its output within an R session when calling 
sink("stdout.txt", type="output")
install.packages("MASS", type="source")
sink()

As it stands, the stderr messages can't be captured via 
sink/capture.output/suppressMessages within an R session. Interestingly, the 
make output goes to stdout, but the R messages go to stderr:

# the 'make' output goes to stdout
$ R --vanilla CMD INSTALL -l /tmp MASS_7.3-14.tar.gz 2>/dev/null
gcc-4.2 -arch i386 -std=gnu99 
-I/Library/Frameworks/R.framework/Resources/include 
-I/Library/Frameworks/R.framework/Resources/include/i386  -I/usr/local/include  
  -fPIC  -g -O2 -c MASS.c -o MASS.o
gcc-4.2 -arch i386 -std=gnu99 
-I/Library/Frameworks/R.framework/Resources/include 
-I/Library/Frameworks/R.framework/Resources/include/i386  -I/usr/local/include  
  -fPIC  -g -O2 -c lqs.c -o lqs.o
gcc-4.2 -arch i386 -std=gnu99 -dynamiclib -Wl,-headerpad_max_install_names 
-undefined dynamic_lookup -single_module -multiply_defined suppress 
-L/usr/local/lib -o MASS.so MASS.o lqs.o -F/Library/Frameworks/R.framework/.. 
-framework R -Wl,-framework -Wl,CoreFoundation
gcc-4.2 -arch x86_64 -std=gnu99 
-I/Library/Frameworks/R.framework/Resources/include 
-I/Library/Frameworks/R.framework/Resources/include/x86_64  
-I/usr/local/include-fPIC  -g -O2 -c MASS.c -o MASS.o
gcc-4.2 -arch x86_64 -std=gnu99 
-I/Library/Frameworks/R.framework/Resources/include 
-I/Library/Frameworks/R.framework/Resources/include/x86_64  
-I/usr/local/include-fPIC  -g -O2 -c lqs.c -o lqs.o
gcc-4.2 -arch x86_64 -std=gnu99 -dynamiclib -Wl,-headerpad_max_install_names 
-undefined dynamic_lookup -single_module -multiply_defined suppress 
-L/usr/local/lib -o MASS.so MASS.o lqs.o -F/Library/Frameworks/R.framework/.. 
-framework R -Wl,-framework -Wl,CoreFoundation

# the R CMD INSTALL output goes to stderr
$ R --vanilla CMD INSTALL -l /tmp MASS_7.3-14.tar.gz >/dev/null
* installing *source* package ‘MASS’ ...
** libs
*** arch - i386
installing to /private/tmp/MASS/libs/i386
*** arch - x86_64
installing to /private/tmp/MASS/libs/x86_64
** R
** data
**  moving datasets to lazyload DB
** inst
** preparing package for lazy loading
** help
*** installing help indices
** building package indices ...
** testing if installed package can be loaded

* DONE (MASS)

$ R --vanilla CMD INSTALL -l /tmp MASS_7.3-14.tar.gz &>/dev/null
# no output

Why do I care? i'm writing some software which uses R behind the scenes, and 
would like to suppress the messages that are produced by install.packages() 
when R libraries are being installed.

So, will it be possible for R CMD INSTALL output be written to stdout in the 
future?

kind regards,
Mark


-
Mark Cowley, PhD

Pancreatic Cancer Program | Peter Wills Bioinformatics Centre
Garvan Institute of Medical Research, Sydney, Australia
-

sessionInfo()
R version 2.13.1 (2011-07-08)
Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)

locale:
[1] en_AU.UTF-8/en_AU.UTF-8/C/C/en_AU.UTF-8/en_AU.UTF-8

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


[[alternative HTML version deleted]]

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

Re: [Rd] R CMD INSTALL writes to stderr

[Mark Cowley]

Thanks for the tip Simon,
i've just written a simplified version of install.packages -- 
install.package.file which will silently R CMD INSTALL a package, assuming 
you've already downloaded it & if there's an installation problem, the R CMD 
INSTALL output is spat to stderr. Code available if anyone's interested

cheers,
Mark


On 11/10/2011, at 12:23 PM, Simon Urbanek wrote:

> 
> On Oct 10, 2011, at 8:48 PM, Mark Cowley wrote:
> 
>> Dear list,
>> (this is a follow up from a previous query)
>> 
>> Why does R CMD INSTALL write most of its messages to stderr? If it wrote to 
>> stdout, then we could capture its output within an R session when calling 
>> sink("stdout.txt", type="output")
>> install.packages("MASS", type="source")
>> sink()
>> 
>> As it stands, the stderr messages can't be captured via 
>> sink/capture.output/suppressMessages within an R session. Interestingly, the 
>> make output goes to stdout, but the R messages go to stderr:
>> 
>> # the 'make' output goes to stdout
>> $ R --vanilla CMD INSTALL -l /tmp MASS_7.3-14.tar.gz 2>/dev/null
>> gcc-4.2 -arch i386 -std=gnu99 
>> -I/Library/Frameworks/R.framework/Resources/include 
>> -I/Library/Frameworks/R.framework/Resources/include/i386  
>> -I/usr/local/include-fPIC  -g -O2 -c MASS.c -o MASS.o
>> gcc-4.2 -arch i386 -std=gnu99 
>> -I/Library/Frameworks/R.framework/Resources/include 
>> -I/Library/Frameworks/R.framework/Resources/include/i386  
>> -I/usr/local/include-fPIC  -g -O2 -c lqs.c -o lqs.o
>> gcc-4.2 -arch i386 -std=gnu99 -dynamiclib -Wl,-headerpad_max_install_names 
>> -undefined dynamic_lookup -single_module -multiply_defined suppress 
>> -L/usr/local/lib -o MASS.so MASS.o lqs.o 
>> -F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework 
>> -Wl,CoreFoundation
>> gcc-4.2 -arch x86_64 -std=gnu99 
>> -I/Library/Frameworks/R.framework/Resources/include 
>> -I/Library/Frameworks/R.framework/Resources/include/x86_64  
>> -I/usr/local/include-fPIC  -g -O2 -c MASS.c -o MASS.o
>> gcc-4.2 -arch x86_64 -std=gnu99 
>> -I/Library/Frameworks/R.framework/Resources/include 
>> -I/Library/Frameworks/R.framework/Resources/include/x86_64  
>> -I/usr/local/include-fPIC  -g -O2 -c lqs.c -o lqs.o
>> gcc-4.2 -arch x86_64 -std=gnu99 -dynamiclib -Wl,-headerpad_max_install_names 
>> -undefined dynamic_lookup -single_module -multiply_defined suppress 
>> -L/usr/local/lib -o MASS.so MASS.o lqs.o 
>> -F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework 
>> -Wl,CoreFoundation
>> 
>> # the R CMD INSTALL output goes to stderr
>> $ R --vanilla CMD INSTALL -l /tmp MASS_7.3-14.tar.gz >/dev/null
>> * installing *source* package ŒMASS‚ ...
>> ** libs
>> *** arch - i386
>> installing to /private/tmp/MASS/libs/i386
>> *** arch - x86_64
>> installing to /private/tmp/MASS/libs/x86_64
>> ** R
>> ** data
>> **  moving datasets to lazyload DB
>> ** inst
>> ** preparing package for lazy loading
>> ** help
>> *** installing help indices
>> ** building package indices ...
>> ** testing if installed package can be loaded
>> 
>> * DONE (MASS)
>> 
>> $ R --vanilla CMD INSTALL -l /tmp MASS_7.3-14.tar.gz &>/dev/null
>> # no output
>> 
>> Why do I care? i'm writing some software which uses R behind the scenes, and 
>> would like to suppress the messages that are produced by install.packages() 
>> when R libraries are being installed.
>> 
>> So, will it be possible for R CMD INSTALL output be written to stdout in the 
>> future?
>> 
> 
> It can simply with 2>&1
> 
> I agree that this doesn't help you with install.packages directly. There are 
> various degrees of ugliness that you can apply - ranging from using 
> INSTALL_opts to force routing to stdout, to using your own system() front-end 
> to handle the details yourself.
> 
> Why you don't simply use a variation of system("R -e 
> 'install.packages(...)'", ...) where you have full control over the routing 
> and yet sill use install.packages? That is generally how custom installers do 
> this ... It sort of seems what you are trying to do anyway since you don't 
> want the internal R output ... 
> 
> Cheers,
> Simon
> 
> 
>> kind regards,
>> Mark
>> 
>> 
>> -
>> Mark Cowley, PhD
>> 
>> Pancreatic Cancer Program | Peter Wills Bioinformatics Centre
>> Garvan Institut

[Rd] R fails when converting units using Hershey-Fonts

[Mark Heckmann]

I run into some problems when trying to convert units using Hershey-Fonts: R 
chrashes.

> library(grid)
> label <- "some text"
> pushViewport(viewport(gp=gpar(fontfamily="HersheySerif")))
> convertHeight(stringHeight(label), unitTo="mm")  

 *** caught segfault ***
address 0xadc838f8, cause 'memory not mapped'

Traceback:
 1: .Call(fnname, ..., PACKAGE = "grid")
 2: grid.Call("L_convert", x, as.integer(whatfrom), as.integer(whatto), 
valid.units(unitTo))
 3: convertUnit(x, unitTo, "y", "dimension", "y", "dimension", valueOnly = 
valueOnly)
 4: convertHeight(stringHeight(label), unitTo = "mm")

Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace


System: MacOS 10.6.4
R version 2.13.2 (2011-09-30)
Platform: i386-apple-darwin9.8.0/i386 (32-bit)

–––
Mark Heckmann
Blog: www.markheckmann.de
R-Blog: http://ryouready.wordpress.com





[[alternative HTML version deleted]]

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

[Rd] cygwin R-2.14.0 build fail

[Mark Carter]

I tried to build R-2.14.0 on cygwin using the commands:
./configure --with-x=no
make

I started to get a whole lot of errors starting with:
/cygdrive/c/Users/mcarter/src/R-2.14.0/src/modules/internet/Rhttpd.c:275: 
undefined reference to `_R_InputHandlers'
which I have pasted at 

http://pastebin.com/GFb2pq92

I'm aware that there is a cygwinports ports, but it seems outdated, and when I 
tried installing it, it was very lengthy and seemed more trouble that it was 
worth. I abandoned the installation attempt.


Any tips on a way forward?

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

[Rd] Unable to reload Rdoc

[Mark Cowley]

Dear list,
I'm hoping the R guru's can help with an error i've been getting for at least a 
year during active package development.

I have a package loaded & spot a documentation bug, so I:
edit the Rd file (or in the roxygen header + roxygenize); then
R CMD BUILD, 
R CMD INSTALL
then in the same R session, reload the library & lookup a man page, I always 
get this error:
Error in fetch(key) : internal error -3 in R_decompress1

I've tried all ways of reloading the package that i'm aware of:
detach then library
unloadNamespace then library
devtools::install
devtools::reload

all lead to the error.

I see from ?detach:
... So detaching and re-attaching a package may
not refresh some or all components of the package, and is
inadvisable.

restarting the R session results in loading the updated man file, but do you 
have any ideas how to word around this & continue within the same R session?

cheers,
Mark

# 1) using Hadley's devtools
> library(devtools)
> library(updateR) # my package under development
> install("~/src/R/updateR")
> install("~/src/R/updateR")
Installing updateR
* checking for file ‘/Users/marcow/src/R/updateR/DESCRIPTION’ ... OK
* preparing ‘updateR’:
* checking DESCRIPTION meta-information ... OK
* checking for LF line-endings in source and make files
* checking for empty or unneeded directories
* building ‘updateR_1.0.4.tar.gz’

Warning in normalizePath(c(new, .Library.site, .Library), "/") :
  path[3]="": No such file or directory
* installing *source* package ‘updateR’ ...
** R
** inst
** preparing package for lazy loading
** help
*** installing help indices
** building package indices ...
** testing if installed package can be loaded

* DONE (updateR)
Reloading installed updateR
> ?get.full.path
Error in fetch(key) : internal error -3 in R_decompress1

2) using detach + library
$ R --vanilla
library(updateR)
# ?list.my.packages
detach(pos=2, unload=TRUE, force=TRUE)
# <>
system("cd ~/src/R && R CMD BUILD updateR && R CMD INSTALL updateR")
library("updateR")
?list.my.packages
Error in fetch(key) : internal error -3 in R_decompress1


3) using unloadNamespace
$ R --vanilla
library(updateR)
# ?list.my.packages
unloadNamespace("updateR")
# <>
system("cd ~/src/R && R CMD BUILD updateR && R CMD INSTALL updateR")
library("updateR")
?list.my.packages
Error in fetch(key) : internal error -3 in R_decompress1


> sessionInfo()
R version 2.13.1 (2011-07-08)
Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)

locale:
[1] en_AU.UTF-8/en_AU.UTF-8/C/C/en_AU.UTF-8/en_AU.UTF-8

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

other attached packages:
[1] updateR_1.0.4   codetools_0.2-8 devtools_0.4   

loaded via a namespace (and not attached):
[1] RCurl_1.6-7

-
Mark Cowley, PhD

Pancreatic Cancer Program | Peter Wills Bioinformatics Centre
Garvan Institute of Medical Research, Sydney, Australia
-


[[alternative HTML version deleted]]

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

Re: [Rd] Unable to reload Rdoc

[Mark Cowley]

Gentlemen,
Thanks for your insights, all 3 hints are very useful.

Mark
On 28/01/2012, at 8:29 AM, Henrik Bengtsson wrote:

> Related: To simplify reloading a help page after restarting R, I do
> have the following in my ~/.Rprofile:
> 
> # Always only the HTML help on the same port
> local({
>  port <- sum(c(1e3,10)*as.double(R.Version()[c("major", "minor")]));
>  ports <- 10*port + 0:9;
>  options(help.ports=ports);
> });
> 
> # Try to start HTML help server
> tryCatch({
>  if (interactive()) {
>tools::startDynamicHelp();
>  }
> }, error = function(ex) {
>  print(ex);
> })
> 
> That way the URL for the help page remain the same (as long as you
> only run one R session) and the internal web server is up and running
> (no need for help.start()).
> 
> My $.02
> 
> /Henrik
> 
> On Fri, Jan 27, 2012 at 6:15 AM, Hadley Wickham  wrote:
>> On Fri, Jan 27, 2012 at 3:47 AM, Mark Cowley  wrote:
>>> Dear list,
>>> I'm hoping the R guru's can help with an error i've been getting for at 
>>> least a year during active package development.
>>> 
>>> I have a package loaded & spot a documentation bug, so I:
>>> edit the Rd file (or in the roxygen header + roxygenize); then
>>> R CMD BUILD,
>>> R CMD INSTALL
>>> then in the same R session, reload the library & lookup a man page, I 
>>> always get this error:
>>> Error in fetch(key) : internal error -3 in R_decompress1
>>> 
>>> I've tried all ways of reloading the package that i'm aware of:
>>> detach then library
>>> unloadNamespace then library
>>> devtools::install
>>> devtools::reload
>>> 
>>> all lead to the error.
>>> 
>>> I see from ?detach:
>>> ... So detaching and re-attaching a package may
>>> not refresh some or all components of the package, and is
>>> inadvisable.
>>> 
>>> restarting the R session results in loading the updated man file, but do 
>>> you have any ideas how to word around this & continue within the same R 
>>> session?
>>> 
>>> cheers,
>>> Mark
>>> 
>>> # 1) using Hadley's devtools
>>>> library(devtools)
>>>> library(updateR) # my package under development
>>>> install("~/src/R/updateR")
>> 
>> To avoid this problem, the latest version of devtools has show_rd(),
>> which allows you to preview an Rd file in R without having to
>> reinstall the package.  This was actually really simple to implement,
>> and I don't know why I didn't think of it ages ago - it's certainly
>> made my workflow much smoother.
>> 
>> 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

Re: [Rd] Higher Resolution Icons for Windows / Mac

[Mark Lang]

Hi,
I have installed R on a Windows 7 machine and wanted to offer a set of icons 
that are higher resolution than the existing icon.  The icon set uses the R 
logo available from this link: http://developer.r-project.org/Logo/ , 
specifically http://developer.r-project.org/Logo/Rlogo.svg .  The first icon is 
the entire R Logo, while the second icon is simply the R logo without the 
associated oval behind it.  The icons should scale in Windows 7 to 256x256 
pixels, and will scale downwards, as well.  There are no jagged edges on the 
icons.

I am offering these free and clear and for total use by the R project.  We have 
a few faculty here that want to use R, and as I have been installing the 
software I noticed the low resolution icon.  Creating a higher resolution icon 
is an easy task for me, so I created it and wanted to share it.  

I have uploaded the files here: 
http://www.somas.stonybrook.edu/downloads/Rprojecticons.zip 

Please let me know if there are any problems.  There are four files contained 
within the .zip file:  Rproject1.icns, Rproject1.ico, Rproject2.icns, 
Rproject2.ico.  The .icns files are Mac-formatted icon files while the .ico 
files are Windows-formatted icon files.  

Again, the files were created using your previously posted logos, so I give 
them to you under the Creative Commons Attribution ShareAlike license.

Thank you,

Mark Lang
School of Marine and Atmospheric Sciences
Stony Brook University
133 Endeavour Hall
mark.l...@stonybrook.edu

http://somas.stonybrook.edu 

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

Re: [Rd] The constant part of the log-likelihood in StructTS

[Mark Leeds]

Hi Ravi: As far as I know ( well , really read ) and Bert et al can say
more , the AIC is not dependent on the models being nested as long as the
sample sizes used are the same when comparing. In some cases, say comparing
MA(2), AR(1), you have to be careful with sample size usage but there is no
nesting requirement for AIC atleast, I'm pretty sure.

So, Jouni's worry I think should be the different likelihoods. Jouni:
There are ways of re-writing ARIMA as STRUCta type models  which might be
easier than trying to consistentitize the likelihoods across different
packages/base. StructTS is really a specific DLM as far as I understand it
so you may be better off going to the DLM package. The DLM likelihoods
still will not necessarily be consistent with arima likelihoods..But there
are ways of transforming arimas so that they can be written as DLM's so
that you can DLM  for those also. My point is that,  if you're comparing
likelihoods of different models, if possible, it's best to use ONE
package/function so that you don't use different likelihoods by accident.


Mark

Also, not sure why this is on R-dev ?








     Mark















On Wed, May 2, 2012 at 11:19 AM, Ravi Varadhan  wrote:

> Comparing such disparate, non-nested models can be quite problematic.  I
> am not sure what AIC/BIC comparisons mean in such cases.  The issue of
> different constants should be the least of your worries.
>
> Ravi
>
> -Original Message-
> From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org]
> On Behalf Of Jouni Helske
> Sent: Tuesday, May 01, 2012 2:17 PM
> To: r-devel@r-project.org
> Subject: Re: [Rd] The constant part of the log-likelihood in StructTS
>
> Ok, it seems that R's AIC and BIC functions warn about different
> constants, so that's probably enough. The constants are not irrelevant
> though, if you compute the log-likelihood of one model using StructTS, and
> then fit alternative model using other functions such as arima(), which do
> take account the constant term, and use those loglikelihoods for computing
> for example BIC, you get wrong results when checking which model gives
> lower BIC value. Hadn't though about it before, have to be more careful in
> future when checking results from different packages etc.
>
> Jouni
>
>
> On Tue, May 1, 2012 at 4:51 PM, Ravi Varadhan  wrote:
>
> > This is not a problem at all.  The log likelihood function is a
> > function of the model parameters and the data, but it is defined up to
> > an additive arbitrary constant, i.e. L(\theta) and L(\theta) + k are
> > completely equivalent, for any k. This does not affect model
> > comparisons or hypothesis tests.
> >
> > Ravi
> > 
> > From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] on
> > behalf of Jouni Helske [jounihel...@gmail.com]
> > Sent: Monday, April 30, 2012 7:37 AM
> > To: r-devel@r-project.org
> > Subject: [Rd] The constant part of the log-likelihood in StructTS
> >
> > Dear all,
> >
> > I'd like to discuss about a possible bug in function StructTS of stats
> > package. It seems that the function returns wrong value of the
> > log-likelihood, as the added constant to the relevant part of the
> > log-likelihood is misspecified. Here is an simple example:
> >
> > > data(Nile)
> > > fit <- StructTS(Nile, type = "level") fit$loglik
> > [1] -367.5194
> >
> > When computing the log-likelihood with other packages such as KFAS and
> > FKF, the loglikelihood value is around -645.
> >
> > For the local level model, the likelihood is defined by
> > -0.5*n*log(2*pi) -
> > 0.5*sum(log(F_t) + v_t^2/sqrt(F_t)) (see for example  Durbin and
> > Koopman (2001, page 30). But in StructTS, the likelihood is computed
> like this:
> >
> > loglik <- -length(y) * res$value + length(y) * log(2 * pi),
> >
> > where the first part coincides with the last part of the definition,
> > but the constant part has wrong sign and it is not multiplied by 0.5.
> > Also in case of missing observations, I think there should be
> > sum(!is.na(y)) instead of length(y) in the constant term, as the
> > likelihood is only computed for those y which are observed.
> >
> > This does not affect in estimation of model parameters, but it could
> > have effects in model comparison or some other cases.
> >
> > Is there some reason for this kind of constant, or is it just a bug?
> >
> > Best regards,
> >
> > Jouni Helske
> > PhD student in Statistics
> > University of Jyväskylä
> > Finland
> >
> > [[alternative HTML version deleted]]
>
>[[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

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

[Rd] R-2.15.1 CMD CHECK output: "Call Sequence"

[Mark Cowley]

Hi guRus,
i'm running R-2.15.1 and the R CMD CHECK output appears to have changed 
substantially, in that instead of pointing me to the offending functions or 
files, I get lots of 'call sequence' traces as below.

I've been using R CMD CHECK for years &  never seen anything like this before. 
This is on a pretty fresh OSX 10.8 Mountain Lion installation, where I 
installed R from CRAN via pkg. Is this a problem unique to me?

cheers,
Mark

heres' a snippet from testing one of my packages under development:

* checking for unstated dependencies in R code ... WARNING
Error: package/namespace load failed for ‘metaGSEA’
Call sequence:
2: stop(gettextf("package/namespace load failed for %s", sQuote(package)), 
  call. = FALSE, domain = NA)
1: library(package, lib.loc = lib.loc, character.only = TRUE, verbose = FALSE)
Execution halted
See the information on DESCRIPTION files in the chapter ‘Creating R
packages’ of the ‘Writing R Extensions’ manual.
* checking S3 generic/method consistency ... WARNING
Error: package/namespace load failed for ‘metaGSEA’
Call sequence:
2: stop(gettextf("package/namespace load failed for %s", sQuote(package)), 
  call. = FALSE, domain = NA)
1: library(package, lib.loc = lib.loc, character.only = TRUE, verbose = FALSE)
Execution halted
See section ‘Generic functions and methods’ of the ‘Writing R
Extensions’ manual.
* checking replacement functions ... WARNING
Error: package/namespace load failed for ‘metaGSEA’
Call sequence:
2: stop(gettextf("package/namespace load failed for %s", sQuote(package)), 
  call. = FALSE, domain = NA)
1: library(package, lib.loc = lib.loc, character.only = TRUE, verbose = FALSE)
Execution halted
The argument of a replacement function which corresponds to the right
hand side must be named ‘value’.
* checking foreign function calls ... WARNING
Error: package/namespace load failed for ‘metaGSEA’
Call sequence:
2: stop(gettextf("package/namespace load failed for %s", sQuote(package)), 
  call. = FALSE, domain = NA)
1: library(package, lib.loc = lib.loc, character.only = TRUE, verbose = FALSE)
Execution halted

> sessionInfo()
R version 2.15.1 (2012-06-22)
Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)

locale:
[1] en_AU.UTF-8/en_AU.UTF-8/en_AU.UTF-8/C/en_AU.UTF-8/en_AU.UTF-8

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base 
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R-2.15.1 CMD CHECK output: "Call Sequence"

[Mark Cowley]

Dear Brian,
thanks for the reply. 

Indeed, metaGSEA was the package being CHECK'ed & it turns out that the R CMD 
CHECK metaGSEA errors were due to a missing 'Depends: methods' from the 
DESCRIPTION of a dependent package.

I went back and CHECK'ed under R 2.14.2 and R 2.13.1, and indeed you're right 
re the call sequence's having been there for a while, however I did notice that 
R 2.15.1's output was somewhat less useful than R 2.14.2's in these 2 sections:
* checking S3 generic/method consistency ... WARNING
* checking Rd \usage sections ... NOTE
which under R 2.14.2 printed the offending functions (see full R CMD CHECK 
output for R 2.15, 2.14, 2.13 here: git://gist.github.com/3926486.git)

fixing the DESCRIPTION of the depedent package removed the package/namespace 
errors in this package, and all of the Call Sequence dumps. Importantly, fixing 
the dependent package also reinstated the usual verbose output under the 2 
sections above.



In hindsight, what this specific scenario boiled down to was this section of 
the CHECK output:
Error : objects ¡.__T__sort:mjcbase¢, ¡sort¢ are not exported by 
¡namespace:mjcbase¢
Error: package/namespace load failed for ¡metaGSEA¢
Execution halted

It looks like this package (or one of its dependent packages) has an
unstated dependence on a standard package.  All dependencies must be
declared in DESCRIPTION.

which was not actually that I didn't export the S4 method sort, but that I was 
missing the 'Depends: methods' from mjcbase's DESCRIPTION.

It would be *really* helpful if the error produced when checking 'metaGSEA' 
looked like this:
Error : objects ¡.__T__sort:mjcbase¢, ¡sort¢ are not exported by 
¡namespace:mjcbase¢
Error: package/namespace load failed for ¡mjcbase¢
Error: package/namespace load failed for ¡metaGSEA¢
Execution halted

It looks like this package (or one of its dependent packages) has an
unstated dependence on a standard package.  All dependencies must be
declared in DESCRIPTION.

as when developing, I think we can all be guilty of not looking beyond the 
spotlight of the current package.

kind regards,
Mark

On 21/10/2012, at 1:50 AM, Prof Brian Ripley  wrote:

> On Sat, 20 Oct 2012, Mark Cowley wrote:
> 
>> Hi guRus,
> 
>> i'm running R-2.15.1 and the R CMD CHECK output appears to have changed 
>> substantially, in that instead of pointing me to the
> 
> Changed since when?   This has been the behaviour for years with the error 
> quoted.
> 
>> offending functions or files, I get lots of 'call sequence' traces as below.
> 
> It is an offending _package_, and it tells you which one in
> 
>> Error: package/namespace load failed for ¡metaGSEA¢
> 
> Package 'metaGSEA' seems not to be installed properly.  It also tells you 
> that 'library' is involved, so it looks like it is a package load and not a 
> namespace load.
> 
> You have not told us if ¡metaGSEA¢ is the package under test or a dependent.  
> Given that in earlier 'check' output which you excised the loading of the 
> package under test was checked, the latter looks more plausible.
> 
>> I've been using R CMD CHECK for years & never seen anything like this 
>> before. This is on a pretty fresh OSX 10.8 Mountain Lion installation, where 
>> I installed R from CRAN via pkg. Is this a problem unique to me?
> 
> Maybe not, but unusual.  It is a lot harder to get a package installed 
> non-functionally these days, but it can happen if it were installed with a 
> different version or architecture, or if binary packages are involved.
> 
>> 
>> cheers,
>> Mark
>> 
>> heres' a snippet from testing one of my packages under development:
>> 
>> * checking for unstated dependencies in R code ... WARNING
>> Error: package/namespace load failed for ¡metaGSEA¢
>> Call sequence:
>> 2: stop(gettextf("package/namespace load failed for %s", sQuote(package)),
>> call. = FALSE, domain = NA)
>> 1: library(package, lib.loc = lib.loc, character.only = TRUE, verbose = 
>> FALSE)
>> Execution halted
>> See the information on DESCRIPTION files in the chapter ¡Creating R
>> packages¢ of the ¡Writing R Extensions¢ manual.
>> * checking S3 generic/method consistency ... WARNING
>> Error: package/namespace load failed for ¡metaGSEA¢
>> Call sequence:
>> 2: stop(gettextf("package/namespace load failed for %s", sQuote(package)),
>> call. = FALSE, domain = NA)
>> 1: library(package, lib.loc = lib.loc, character.only = TRUE, verbose = 
>> FALSE)
>> Execution halted
>> See section ¡Generic functions and methods¢ of the ¡Writing R
>> Extensions¢ manual.
>> * checking replacement f

[Rd] Getting ordered factor levels from C

[Mark Lilback]

I'm working on an R package in C and can't seem to get the same level 
information about a factor that the R console displays.

If I define a factor as:

lvls <- factor(c('red','blue','blue','green','red'), c('blue','green','red'), 
ordered=TRUE)

When I get the "levels" attribute in C, I get back the the first vector, not 
the second. If I run attr(lvls,"levels") in R, I get back the second vector. 
There are no attributes besides class and levels, so how do I get the list of 
levels in the correct order?

Thanks

-- 
Mark Lilback
West Virginia University Department of Statistics
mlilb...@stat.wvu.edu

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

Re: [Rd] Getting ordered factor levels from C

[Mark Lilback]

I was banging my head for an hour on this. I just pasted the code into an email 
and see that I was getting the contents of the SEXP for the factor, not the one 
returned by getAttrib. Sorry for the waste of time.


On Oct 24, 2012, at 4:16 PM, Simon Urbanek  wrote:

> 
> On Oct 24, 2012, at 2:14 PM, Mark Lilback wrote:
> 
>> I'm working on an R package in C and can't seem to get the same level 
>> information about a factor that the R console displays.
>> 
>> If I define a factor as:
>> 
>> lvls <- factor(c('red','blue','blue','green','red'), 
>> c('blue','green','red'), ordered=TRUE)
>> 
>> When I get the "levels" attribute in C, I get back the the first vector, not 
>> the second.
> 
> What are you using in C? AFAICS it works just fine:
> 
>> f=cfunction(c(foo="factor"), "return getAttrib(foo, R_LevelsSymbol);")
>> f(lvls)
> [1] "blue"  "green" "red"  
> 



-- 
Mark Lilback
West Virginia University Department of Statistics
mlilb...@stat.wvu.edu

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

Re: [Rd] Recommended way to call/import functions from a Suggested package

[Mark Leeds]

Hi David: According to the description on cran, lattice imports grid.

I don't know if you've seen it but www.obeautifulcode.com has a very nice
topic in its archives called "How R Searches and Finds Stuff" which is
relatde to your question that I found it to be really helpful. A lot of
people  on this list ( you know who they are as well as I do ) know it all
in their heads but, for me, sitting down and reading it was truly
enlightening. I think it should be required reading for anyone starting out
with R.












On Fri, Feb 22, 2013 at 9:50 PM, David Winsemius wrote:

>
> On Feb 22, 2013, at 6:39 PM, David Winsemius wrote:
>
> >
> > On Feb 22, 2013, at 6:13 PM, Hadley Wickham wrote:
> >
> >> Hi Davor,
> >>
> >> To the best of my knowledge, there's only one way to use functions
> >> from a suggested package: with require:
> >>
> >> if (require("suggested_package")) {
> >> function_from_suggested_package()
> >> } else {
> >> stop("suggested package not installed")
> >> }
> >>
> >> Unfortunately I don't think there's any way to use a suggested package
> >> without polluting the search path.
> >
> > I've always wondered: How does lattice manage to use grid functions
> without putting them on the search path?
>
> Maybe I am using the wrong terminology, so here is the behavior I'm
> referring to:
>
> > sessionInfo()
> snipped version an locale ino
>
> attached base packages:
> [1] grDevices datasets  splines   graphics  utils stats methods
> base
>
> other attached packages:
> [1] rms_3.6-2   Hmisc_3.10-1survival_2.37-2 sos_1.3-5
> brew_1.0-6
> [6] lattice_0.20-10
>
> loaded via a namespace (and not attached):
> [1] cluster_1.14.3 grid_2.15.2
>
> Notice that lattice is loaded from my profile
>
> > require(ggplot2)
> Loading required package: ggplot2
> > sessionInfo()
>  snipped version an locale ino
> attached base packages:
> [1] grDevices datasets  splines   graphics  utils stats methods
> base
>
> other attached packages:
> [1] ggplot2_0.9.3   rms_3.6-2   Hmisc_3.10-1survival_2.37-2
> sos_1.3-5
> [6] brew_1.0-6  lattice_0.20-10
>
> loaded via a namespace (and not attached):
>  [1] cluster_1.14.3 colorspace_1.2-1   dichromat_2.0-0digest_0.6.0
>  [5] grid_2.15.2gtable_0.1.2   labeling_0.1   MASS_7.3-22
>  [9] munsell_0.4plyr_1.8   proto_0.3-10
> RColorBrewer_1.0-5
> [13] reshape2_1.2.2 scales_0.2.3   stringr_0.6.2
> > ?grid.text
> No documentation for ‘grid.text’ in specified packages and libraries:
> you could try ‘??grid.text’
>
> So at least the help system cannot find a grid function.
>
>
> > ?grid::grid.text
> starting httpd help server ... done
> > grid.text
> Error: object 'grid.text' not found
>
> Neither can the R interpreter find it. But it's clearly available if you
> ask nicely:
>
> > grid::grid.text
> function (label, x = unit(0.5, "npc"), y = unit(0.5, "npc"),
> just = "centre", hjust = NULL, vjust = NULL, rot = 0, check.overlap =
> FALSE,
> default.units = "npc", name = NULL, gp = gpar(), draw = TRUE,
> vp = NULL)
> {
> tg <- textGrob(label = label, x = x, y = y, just = just,
> hjust = hjust, vjust = vjust, rot = rot, check.overlap =
> check.overlap,
> default.units = default.units, name = name, gp = gp,
> vp = vp)
> if (draw)
> grid.draw(tg)
> invisible(tg)
> }
> 
> 
>
> --
> David/
>
> >
> > --
> > David
> >>
> >> Hadley
> >>
> >> On Fri, Feb 22, 2013 at 6:26 PM, Davor Cubranic 
> wrote:
> >>> If in my package "Foo" I call a function from another package "Bar" if
> it's available, according to R-exts, this sounds like I should include
> "Suggests: Bar" in package Foo's description. But the manual is silent on
> how to treat Bar's namespace. Should I import it? If so, should this be
> conditional or unconditional? There is a thread from 2008 in which Duncan
> Murdoch suggests trying conditionally importing a package if it's
> installed, with the caveat "If this is allowed" (
> http://tolstoy.newcastle.edu.au/R/e5/devel/08/10/0488.html). This appears
> to work in current release of R, 2.15.2, but I'm still not clear if it's
> officially allowed, much less recommended.
> >>>
> >>> The manual also says:
> >>>
>  If a package only needs a few objects from another package it can use
> a fully qualified variable reference in the code instead of a formal
> import. A fully qualified reference to the function f in package foo is of
> the form foo::f. This is slightly less efficient than a formal import and
> also loses the advantage of recording all dependencies in the NAMESPACE
> file, so this approach is usually not recommended. Evaluating foo::f will
> cause package foo to be loaded, but not attached, if it was not loaded
> already—this can be an advantage in delaying the loading of a rarely used
> package.
> 
> >>>
> >>>
> >>> Would this be a better solution than importing when calling into a
> suggested package?
> >>>
> >>> Davor
> >>>
> >>>
>

Re: [Rd] Recommended way to call/import functions from a Suggested package

[Mark Leeds]

david: I was slightly misleading about the usefulness of that link for your
question because it
doesn't explicitly talk about the case where base packages import packages.
But it talks about
the general case of importing so hopefully base handles importing just like
a package  that would
be installed from cran.




On Fri, Feb 22, 2013 at 10:07 PM, Mark Leeds  wrote:

> Hi David: According to the description on cran, lattice imports grid.
>
> I don't know if you've seen it but www.obeautifulcode.com has a very nice
> topic in its archives called "How R Searches and Finds Stuff" which is
> relatde to your question that I found it to be really helpful. A lot of
> people  on this list ( you know who they are as well as I do ) know it all
> in their heads but, for me, sitting down and reading it was truly
> enlightening. I think it should be required reading for anyone starting out
> with R.
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Fri, Feb 22, 2013 at 9:50 PM, David Winsemius 
> wrote:
>
>>
>> On Feb 22, 2013, at 6:39 PM, David Winsemius wrote:
>>
>> >
>> > On Feb 22, 2013, at 6:13 PM, Hadley Wickham wrote:
>> >
>> >> Hi Davor,
>> >>
>> >> To the best of my knowledge, there's only one way to use functions
>> >> from a suggested package: with require:
>> >>
>> >> if (require("suggested_package")) {
>> >> function_from_suggested_package()
>> >> } else {
>> >> stop("suggested package not installed")
>> >> }
>> >>
>> >> Unfortunately I don't think there's any way to use a suggested package
>> >> without polluting the search path.
>> >
>> > I've always wondered: How does lattice manage to use grid functions
>> without putting them on the search path?
>>
>> Maybe I am using the wrong terminology, so here is the behavior I'm
>> referring to:
>>
>> > sessionInfo()
>> snipped version an locale ino
>>
>> attached base packages:
>> [1] grDevices datasets  splines   graphics  utils stats methods
>> base
>>
>> other attached packages:
>> [1] rms_3.6-2   Hmisc_3.10-1survival_2.37-2 sos_1.3-5
>> brew_1.0-6
>> [6] lattice_0.20-10
>>
>> loaded via a namespace (and not attached):
>> [1] cluster_1.14.3 grid_2.15.2
>>
>> Notice that lattice is loaded from my profile
>>
>> > require(ggplot2)
>> Loading required package: ggplot2
>> > sessionInfo()
>>  snipped version an locale ino
>> attached base packages:
>> [1] grDevices datasets  splines   graphics  utils stats methods
>> base
>>
>> other attached packages:
>> [1] ggplot2_0.9.3   rms_3.6-2   Hmisc_3.10-1survival_2.37-2
>> sos_1.3-5
>> [6] brew_1.0-6  lattice_0.20-10
>>
>> loaded via a namespace (and not attached):
>>  [1] cluster_1.14.3 colorspace_1.2-1   dichromat_2.0-0digest_0.6.0
>>  [5] grid_2.15.2gtable_0.1.2   labeling_0.1   MASS_7.3-22
>>  [9] munsell_0.4plyr_1.8   proto_0.3-10
>> RColorBrewer_1.0-5
>> [13] reshape2_1.2.2 scales_0.2.3   stringr_0.6.2
>> > ?grid.text
>> No documentation for ‘grid.text’ in specified packages and libraries:
>> you could try ‘??grid.text’
>>
>> So at least the help system cannot find a grid function.
>>
>>
>> > ?grid::grid.text
>> starting httpd help server ... done
>> > grid.text
>> Error: object 'grid.text' not found
>>
>> Neither can the R interpreter find it. But it's clearly available if you
>> ask nicely:
>>
>> > grid::grid.text
>> function (label, x = unit(0.5, "npc"), y = unit(0.5, "npc"),
>> just = "centre", hjust = NULL, vjust = NULL, rot = 0, check.overlap =
>> FALSE,
>> default.units = "npc", name = NULL, gp = gpar(), draw = TRUE,
>> vp = NULL)
>> {
>> tg <- textGrob(label = label, x = x, y = y, just = just,
>> hjust = hjust, vjust = vjust, rot = rot, check.overlap =
>> check.overlap,
>> default.units = default.units, name = name, gp = gp,
>> vp = vp)
>> if (draw)
>> grid.draw(tg)
>> invisible(tg)
>> }
>> 
>> 
>>
>> --
>> David/
>>
>> >
>> > --
>> > David
>> >>
>> >> Hadley
>> >>
>> >> On Fri, Feb 22, 2013 at 6:26 PM, Davor Cub

Re: [Rd] install.packages now intentionally references .Rprofile?

[Mark Kimpel]

This was my original post, with the code example only slightly modified by
Martin for clarity. Prior to R-2.9.0, this repeated downloading did not
occur, the code worked as intended. In fact, if memory serves me correctly,
it even worked at least during the first 3 months of R-2.0.0 in its
development stage, before release as a numbered version. Is there a reason
for that? Is there a work-around? As I mentioned in my original post, the
code is actually wrapped in a function that checks the date and the date of
the last update, and proceeds to update package once per week. It was quite
handy when it was working, hence my desire for a fix for my code.

Thanks,
Mark

Mark W. Kimpel MD  ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield, IN  46074

(317) 490-5129 Work, & Mobile & VoiceMail
(317) 399-1219  Home
Skype:  mkimpel

"The real problem is not whether machines think but whether men do." -- B.
F. Skinner
**


On Thu, May 21, 2009 at 2:17 AM, Prof Brian Ripley wrote:

> On Wed, 20 May 2009, Martin Morgan wrote:
>
>  A post on the Bioconductor mailing list
>>
>>  https://stat.ethz.ch/pipermail/bioconductor/2009-May/027700.html
>>
>> suggests that install.packages now references .Rprofile (?), whereas
>> in R-2-8 it did not. Is this intentional?
>>
>
> Yes.  And in fact it did in earlier versions, to find the default library
> into which to install.
>
>
>
>> The example is, in .Rprofile
>>
>>  library(utils)
>>  install.packages("Biobase",
>>  repos="http://bioconductor.org/packages/2.4/bioc";)
>>
>> then starting R from the command line results in repeated downloads
>> of Biobase
>>
>> mtmor...@mm:~/tmp> R --quiet
>> trying URL
>> '
>> http://bioconductor.org/packages/2.4/bioc/src/contrib/Biobase_2.4.1.tar.gz
>> '
>> Content type 'application/x-gzip' length 1973533 bytes (1.9 Mb)
>> opened URL
>> ==
>> downloaded 1.9 Mb
>>
>> trying URL
>> '
>> http://bioconductor.org/packages/2.4/bioc/src/contrib/Biobase_2.4.1.tar.gz
>> '
>> Content type 'application/x-gzip' length 1973533 bytes (1.9 Mb)
>> opened URL
>> ==
>> downloaded 1.9 Mb
>>
>> ^C
>> Execution halted
>>
>>  sessionInfo()
>>>
>> R version 2.9.0 Patched (2009-05-20 r48588)
>> x86_64-unknown-linux-gnu
>>
>> locale:
>>
>> LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C
>>
>> attached base packages:
>> [1] stats graphics  grDevices utils datasets  methods   base
>>
>> Martin
>> --
>> Martin Morgan
>> Computational Biology / Fred Hutchinson Cancer Research Center
>> 1100 Fairview Ave. N.
>> PO Box 19024 Seattle, WA 98109
>>
>> Location: Arnold Building M1 B861
>> Phone: (206) 667-2793
>>
>> __
>> 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/<http://www.stats.ox.ac.uk/%7Eripley/>
> 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
>

[[alternative HTML version deleted]]

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

[Rd] rJava fails compilation on R-2.9.1 but not R-2.7.1 on Debian Lenny

[Mark Kimpel]

I have been futzing around for days tying to get rJava to install on
my freshly build Debian Lenny installation. I have R-2.9.1 installed
from source in my R_HOME directory and R-2.7.1 installed via apt-get
install r-recommended. I was tried many different things, but by
accident started up R-2.7.1 as root and viola, successful install. I
immediately exited out of R-2.7.1 and started R-2.9.1 as root and
compilation fails. The file

The output is voluminous, but is included below. I had originally
thought that my problem had to do with setting environmental
variables, but now it seems not.

Thanks,
Mark

mkimpel-debian-xps /usr/lib/jvm/java-6-sun/include: su root
Password:
mkimpel-debian-xps:/usr/lib/jvm/java-6-sun/include#
/home/mkimpel/R_HOME/R-2.9.1/R-build/bin/R
WARNING: ignoring environment value of R_HOME

R version 2.9.1 (2009-06-26)
Copyright (C) 2009 The R Foundation for Statistical Computing
ISBN 3-900051-07-0

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> install.packages('rJava')
Warning in install.packages("rJava") :
  argument 'lib' is missing: using '/usr/local/lib/R/site-library'
--- Please select a CRAN mirror for use in this session ---
Loading Tcl/Tk interface ... done
trying URL 'http://cran.fhcrc.org/src/contrib/rJava_0.6-3.tar.gz'
Content type 'application/x-gzip' length 240527 bytes (234 Kb)
opened URL
==
downloaded 234 Kb

* Installing *source* package ‘rJava’ ...
checking for gcc... gcc -std=gnu99
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc -std=gnu99 accepts -g... yes
checking for gcc -std=gnu99 option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -std=gnu99 -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/wait.h that is POSIX.1 compatible... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for string.h... (cached) yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking for unistd.h... (cached) yes
checking for an ANSI C-conforming const... yes
checking whether time.h and sys/time.h may both be included... yes
configure: checking whether gcc -std=gnu99 supports static inline...
yes
checking Java support in R... present:
interpreter : '/usr/bin/java'
archiver: '/usr/bin/jar'
compiler: '/usr/bin/javac'
header prep.: '/usr/bin/javah'
cpp flags   : '-I$(JAVA_HOME)/../include -I$(JAVA_HOME)/../include/linux'
java libs   : '-L$(JAVA_HOME)/lib/amd64/server
-L$(JAVA_HOME)/lib/amd64 -L$(JAVA_HOME)/../lib/amd64 -L
-L/usr/java/packages/lib/amd64 -L/lib -L/usr/lib -ljvm'
checking whether JNI programs can be compiled... yes
checking JNI data types... ok
checking whether JRI should be compiled (autodetect)... no
checking whether debugging output should be enabled... no
checking whether memory profiling is desired... no
checking whether threads support is requested... no
checking whether callbacks support is requested... no
checking whether JNI cache support is requested... no
checking whether JRI is requested... no
configure: creating ./config.status
config.status: creating src/Makevars
config.status: creating R/zzz.R
config.status: creating src/config.h
** libs
gcc -std=gnu99 -I/home/mkimpel/R_HOME/R-2.9.1/R-build/lib64/R/include
-I. -I/usr/lib/jvm/java-1.5.0-gcj-4.3-1.5.0.0/jre/../include
-I/usr/lib/jvm/java-1.5.0-gcj-4.3-1.5.0.0/jre/../include/linux
-I/usr/local/include-fpic  -g -O2 -c Rglue.c -o Rglue.o
In file included from Rglue.c:2:
rJava.h:17:17: error: jni.h: No such file or directory
In file included from Rglue.c:2:
rJava.h:115: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
before ‘*’ token
rJava.h:117: error: expected ‘=’, ‘,’, ‘;’, 

Re: [Rd] rJava fails compilation on R-2.9.1 but not R-2.7.1 on Debian Lenny

[Mark Kimpel]

Sorry, My sentence that starts "The file" was truncated and should say
"The file "jni.h" is present and on my PATH, see output below"

mkimpel-debian-xps /usr/lib/jvm/java-6-sun/include: ls
classfile_constants.h  jawt.h  jdwpTransport.h  jni.h  jvmti.h  linux
mkimpel-debian-xps /usr/lib/jvm/java-6-sun/include: printenv PATH
/home/mkimpel/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:/usr/lib/jvm/
mkimpel-debian-xps /usr/lib/jvm/java-6-sun/include:




On Wed, Jul 15, 2009 at 2:46 PM, Mark Kimpel wrote:
> I have been futzing around for days tying to get rJava to install on
> my freshly build Debian Lenny installation. I have R-2.9.1 installed
> from source in my R_HOME directory and R-2.7.1 installed via apt-get
> install r-recommended. I was tried many different things, but by
> accident started up R-2.7.1 as root and viola, successful install. I
> immediately exited out of R-2.7.1 and started R-2.9.1 as root and
> compilation fails. The file
>
> The output is voluminous, but is included below. I had originally
> thought that my problem had to do with setting environmental
> variables, but now it seems not.
>
> Thanks,
> Mark
>
> mkimpel-debian-xps /usr/lib/jvm/java-6-sun/include: su root
> Password:
> mkimpel-debian-xps:/usr/lib/jvm/java-6-sun/include#
> /home/mkimpel/R_HOME/R-2.9.1/R-build/bin/R
> WARNING: ignoring environment value of R_HOME
>
> R version 2.9.1 (2009-06-26)
> Copyright (C) 2009 The R Foundation for Statistical Computing
> ISBN 3-900051-07-0
>
> R is free software and comes with ABSOLUTELY NO WARRANTY.
> You are welcome to redistribute it under certain conditions.
> Type 'license()' or 'licence()' for distribution details.
>
>  Natural language support but running in an English locale
>
> R is a collaborative project with many contributors.
> Type 'contributors()' for more information and
> 'citation()' on how to cite R or R packages in publications.
>
> Type 'demo()' for some demos, 'help()' for on-line help, or
> 'help.start()' for an HTML browser interface to help.
> Type 'q()' to quit R.
>
>> install.packages('rJava')
> Warning in install.packages("rJava") :
>  argument 'lib' is missing: using '/usr/local/lib/R/site-library'
> --- Please select a CRAN mirror for use in this session ---
> Loading Tcl/Tk interface ... done
> trying URL 'http://cran.fhcrc.org/src/contrib/rJava_0.6-3.tar.gz'
> Content type 'application/x-gzip' length 240527 bytes (234 Kb)
> opened URL
> ==
> downloaded 234 Kb
>
> * Installing *source* package ‘rJava’ ...
> checking for gcc... gcc -std=gnu99
> checking for C compiler default output file name... a.out
> checking whether the C compiler works... yes
> checking whether we are cross compiling... no
> checking for suffix of executables...
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc -std=gnu99 accepts -g... yes
> checking for gcc -std=gnu99 option to accept ISO C89... none needed
> checking how to run the C preprocessor... gcc -std=gnu99 -E
> checking for grep that handles long lines and -e... /bin/grep
> checking for egrep... /bin/grep -E
> checking for ANSI C header files... yes
> checking for sys/wait.h that is POSIX.1 compatible... yes
> checking for sys/types.h... yes
> checking for sys/stat.h... yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for memory.h... yes
> checking for strings.h... yes
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for unistd.h... yes
> checking for string.h... (cached) yes
> checking sys/time.h usability... yes
> checking sys/time.h presence... yes
> checking for sys/time.h... yes
> checking for unistd.h... (cached) yes
> checking for an ANSI C-conforming const... yes
> checking whether time.h and sys/time.h may both be included... yes
> configure: checking whether gcc -std=gnu99 supports static inline...
> yes
> checking Java support in R... present:
> interpreter : '/usr/bin/java'
> archiver    : '/usr/bin/jar'
> compiler    : '/usr/bin/javac'
> header prep.: '/usr/bin/javah'
> cpp flags   : '-I$(JAVA_HOME)/../include -I$(JAVA_HOME)/../include/linux'
> java libs   : '-L$(JAVA_HOME)/lib/amd64/server
> -L$(JAVA_HOME)/lib/amd64 -L$(JAVA_HOME)/../lib/amd64 -L
> -L/usr/java/packages/lib/amd64 -L/lib -L/usr/lib -ljvm'
> checking whether JNI programs can be compiled... yes
> checkin

Re: [Rd] rJava fails compilation on R-2.9.1 but not R-2.7.1 on Debian Lenny

[Mark Kimpel]

Well, guess what, rJava also compiles on R-devel (soon to be
R-2.10.0). I'll stick with that for my purposes. Thanks for your
suggestion. Mark

Mark W. Kimpel MD  ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield, IN  46074

(317) 490-5129 Work, & Mobile & VoiceMail

"The real problem is not whether machines think but whether men do."
-- B. F. Skinner
**



On Wed, Jul 15, 2009 at 3:13 PM, Joshua Ulrich wrote:
> Hi Mark,
>
> The first thing that jumps out to me is that 2.7.1 compiles JRI, while
> 2.9.1 does not (for some reason, autodetect decides not to compile).
>
> HTH,
> Josh
> --
> http://www.fosstrading.com
>
>
>
> On Wed, Jul 15, 2009 at 1:46 PM, Mark Kimpel wrote:
>> I have been futzing around for days tying to get rJava to install on
>> my freshly build Debian Lenny installation. I have R-2.9.1 installed
>> from source in my R_HOME directory and R-2.7.1 installed via apt-get
>> install r-recommended. I was tried many different things, but by
>> accident started up R-2.7.1 as root and viola, successful install. I
>> immediately exited out of R-2.7.1 and started R-2.9.1 as root and
>> compilation fails. The file
>>
>> The output is voluminous, but is included below. I had originally
>> thought that my problem had to do with setting environmental
>> variables, but now it seems not.
>>
>> Thanks,
>> Mark
>>
>> mkimpel-debian-xps /usr/lib/jvm/java-6-sun/include: su root
>> Password:
>> mkimpel-debian-xps:/usr/lib/jvm/java-6-sun/include#
>> /home/mkimpel/R_HOME/R-2.9.1/R-build/bin/R
>> WARNING: ignoring environment value of R_HOME
>>
>> R version 2.9.1 (2009-06-26)
>> Copyright (C) 2009 The R Foundation for Statistical Computing
>> ISBN 3-900051-07-0
>>
>> R is free software and comes with ABSOLUTELY NO WARRANTY.
>> You are welcome to redistribute it under certain conditions.
>> Type 'license()' or 'licence()' for distribution details.
>>
>>  Natural language support but running in an English locale
>>
>> R is a collaborative project with many contributors.
>> Type 'contributors()' for more information and
>> 'citation()' on how to cite R or R packages in publications.
>>
>> Type 'demo()' for some demos, 'help()' for on-line help, or
>> 'help.start()' for an HTML browser interface to help.
>> Type 'q()' to quit R.
>>
>>> install.packages('rJava')
>> Warning in install.packages("rJava") :
>>  argument 'lib' is missing: using '/usr/local/lib/R/site-library'
>> --- Please select a CRAN mirror for use in this session ---
>> Loading Tcl/Tk interface ... done
>> trying URL 'http://cran.fhcrc.org/src/contrib/rJava_0.6-3.tar.gz'
>> Content type 'application/x-gzip' length 240527 bytes (234 Kb)
>> opened URL
>> ==
>> downloaded 234 Kb
>>
>> * Installing *source* package ‘rJava’ ...
>> checking for gcc... gcc -std=gnu99
>> checking for C compiler default output file name... a.out
>> checking whether the C compiler works... yes
>> checking whether we are cross compiling... no
>> checking for suffix of executables...
>> checking for suffix of object files... o
>> checking whether we are using the GNU C compiler... yes
>> checking whether gcc -std=gnu99 accepts -g... yes
>> checking for gcc -std=gnu99 option to accept ISO C89... none needed
>> checking how to run the C preprocessor... gcc -std=gnu99 -E
>> checking for grep that handles long lines and -e... /bin/grep
>> checking for egrep... /bin/grep -E
>> checking for ANSI C header files... yes
>> checking for sys/wait.h that is POSIX.1 compatible... yes
>> checking for sys/types.h... yes
>> checking for sys/stat.h... yes
>> checking for stdlib.h... yes
>> checking for string.h... yes
>> checking for memory.h... yes
>> checking for strings.h... yes
>> checking for inttypes.h... yes
>> checking for stdint.h... yes
>> checking for unistd.h... yes
>> checking for string.h... (cached) yes
>> checking sys/time.h usability... yes
>> checking sys/time.h presence... yes
>> checking for sys/time.h... yes
>> checking for unistd.h... (cached) yes
>> checking for an ANSI C-conforming const... yes
>> checking whether time.h and sys/time.h may both be included... yes
&g

[Rd] What changed in the R Windows interface from v2.6.2 to v2.7.0?

[Mark Thyer]

Dear R-devel,

 

I would like to launch the Rgui.exe from a Fortran console application (we
will call this FortranCon.exe), that I have written myself. To do this, I
send the command line "C:\Program Files\R\R-X.X.X\Rgui.exe" (where X.X.X is
the version number) as an argument to the
Windows API function CreateProcess (see
http://msdn.microsoft.com/en-us/library/ms682425(VS.85).aspx) 

 

I use the createprocess command because I want the Rgui.exe and the Fortran
console application to run in parallel. 

 

I have done this before with other executables (e.g. Tinn-R.exe,
textpad.exe) and there hasn't been a problem.

 

But with the current version of R(v2.9.1), there is a problem. 

 

The problem is that after Rgui.exe is launched by FortranCon.exe, the
console window for FortanCon.exe does not close properly when it finishes
running. 

I have to manually close it, by clicking on the topright X on the window.
When I do this the Rgui.exe window also closes - which again is different to
normal, and then the Windows EndProgram dialog comes up and asks me whether
I wish to close FortranCon.exe

 

I have experimented with different versions of R, and this problem only
occurs in R(>=v2.7.0)

 

If I launch Rgui.exe for v2.6.2, then the FortranCon.exe window closes
automatically when it finishes and the Rgui.exe window remains open - this
is the behaviour I expect and want to happen. Indeed, this is what usually
happens If I launch other executables using the CreateProcess function.

 

This error does not occur if I launch Rgui.exe from a Fortran windows
application. (as opposed to console application) 

 

I am running R on Windows XP (Service Pack 3) 32-bit (I have also found the
problem occurs using 64-bit Windows XP). The FortranCon.exe is complied and
linked by Intel Visual Fortran IVF11.1.035 and Visual Studio 2008.

 

So my query is. What has changed in the R Windows interface from v2.6.2 to
v2.7.0 to cause this problem. I had a look at the CHANGES for R2.7.0 and I
couldn't see anything the instantly could cause this problem. 

 

Any help on this matter is greatly appreciated. 

 

The ability to launch R from a Fortran application is important for the
usability of the RFortran software library (www.rfortran.org
<http://www.rfortran.org/> ) that we are developing. 

 

Cheers,

Mark

 

_

Dr Mark Thyer

Senior Lecturer in Environmental Engineering

Discipline of Civil, Surveying and Environmental Engineering

School of Engineering, University of Newcastle

Callaghan, NSW, Australia 2308

T: 02 4921 6057

F: 02 4921 6991

E: mark.th...@newcastle.edu.au

W:
www.newcastle.edu.au/school/engineering/our_staff/profiles/thyer_mark.html

 

"It is easy to lie with statistics, but it is difficult to tell the truth
without them." Andrejs Dunkels

 

 

 

 

 


[[alternative HTML version deleted]]

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

[Rd] 2.10.0 Under development (unstable) (2009-09-15 r49711) just built segfaults on Debian Squeeze

[Mark Kimpel]

I just downloaded R-devel and when loaded it immediately segfaults. I'm not
sure how much or what sort of diagnostic info and can provide, but below is
my build script, my console output, and the output of uname -r. I am
currently dependent on the development version of a package, so I'd like to
get R-devel up and running if possible. I am sure there is more info I can
provide, but before deluging the list with unnecessary output, I thought I
would ask first what would be helpfu. Mark

#Make R
cd ~/R_HOME
wget ftp://ftp.stat.math.ethz.ch/Software/R/R-devel.tar.gz
tar -xzf R-devel.tar.gz
cd ~/R_HOME/R-devel
mkdir R-build
cd R-build
../configure --prefix=/home/mkimpel/R_HOME/R-devel/R-build
make all
make install

#33
# console output
mkimpel-XPS ~/R_HOME/R-devel/R-build/bin: ./R

R version 2.10.0 Under development (unstable) (2009-09-15 r49711)
Copyright (C) 2009 The R Foundation for Statistical Computing
ISBN 3-900051-07-0

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.


 *** caught segfault ***
address (nil), cause 'memory not mapped'

Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 2
Save workspace image? [y/n/c]: n

##
# kernel version
mkimpel-XPS ~/R_HOME/R-devel/R-build/bin: uname -r
2.6.30-1-amd64
mkimpel-XPS ~/R_HOME/R-devel/R-build/bin:


Mark W. Kimpel MD  ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield, IN  46074

(317) 490-5129 Work, & Mobile & VoiceMail
(317) 399-1219 Skype No Voicemail please

[[alternative HTML version deleted]]

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

Re: [Rd] 2.10.0 Under development (unstable) (2009-09-15 r49711) just built segfaults on Debian Squeeze

[Mark Kimpel]

Peter,

I have not yet tried Simon's suggestion of using gcc 4.3 (just got back from
a meeting), but running your commands produces the output below. As you can
see, R --vanilla works, but just plain "R" doesn't. See the results of gdb
far below.

I do not have a saved workspace in my R_HOME or any of its subdirectories.

Will report back on what I get with gcc 4.3 just as soon as I read the
R-admin manual and figure out how to get configure configured

Mark


mkimpel-XPS ~/sshfs: R --vanilla

R version 2.10.0 Under development (unstable) (2009-09-15 r49711)
Copyright (C) 2009 The R Foundation for Statistical Computing
ISBN 3-900051-07-0

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> q()
mkimpel-XPS ~/sshfs: R

R version 2.10.0 Under development (unstable) (2009-09-15 r49711)
Copyright (C) 2009 The R Foundation for Statistical Computing
ISBN 3-900051-07-0

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.


 *** caught segfault ***
address (nil), cause 'memory not mapped'

Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 4
mkimpel-XPS ~/sshfs: R -d gdb
GNU gdb (GDB) 6.8.50.20090628-cvs-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
(gdb) run
Starting program: /home/mkimpel/R_HOME/R-devel/R-build/lib64/R/bin/exec/R

R version 2.10.0 Under development (unstable) (2009-09-15 r49711)
Copyright (C) 2009 The R Foundation for Statistical Computing
ISBN 3-900051-07-0

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.


Program received signal SIGSEGV, Segmentation fault.
Rf_setAttrib (vec=0x12e3d68, name=0x94d450, val=0x0) at
../../../src/main/attrib.c:226
226if (NAMED(val)) val = duplicate(val);
(gdb) bt
#0  Rf_setAttrib (vec=0x12e3d68, name=0x94d450, val=0x0) at
../../../src/main/attrib.c:226
#1  0x0056264f in xxexprlist1 () at gram.y:574
#2  Rf_yyparse () at gram.y:337
#3  0x00563469 in R_Parse1 (status=0x94d450) at gram.y:1126
#4  0x00563cfb in R_Parse1File (fp=0x1200920, gencode=1,
status=0x7fffcd94, first=) at gram.y:1164
#5  0x00416cb2 in R_ReplFile (fp=0x1200920, rho=0x973338,
savestack=0, browselevel=) at
../../../src/main/main.c:87
#6  0x00416e08 in R_LoadProfile (fparg=,
env=0x973338) at ../../../src/main/main.c:651
#7  0x004172c2 in setup_Rmainloop () at ../../../src/main/main.c:875
#8  0x004185c9 in Rf_mainloop () at ../../../src/main/main.c:967
#9  0x00415c38 in main (ac=, av=) at ../../../src/main/Rmain.c:33
#10 0x76ed05c6 in __libc_start_main () from /lib/libc.so.6
#11 0x00415b29 in _start () at ../sysdeps/x86_64/elf/start.S:113
(gdb)

Mark W. Kimpel MD  ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield

Re: [Rd] 2.10.0 Under development (unstable) (2009-09-15 r49711) just built segfaults on Debian Squeeze

[Mark Kimpel]

Below is my .Rprofile and the my.update.packages function that it calls
(which is in the right place and has not caused problems before). As I was
writing this, R just finished compiling using gcc-4.3. R once again crashes
as it did with the 4.4 compile. Just for completeness, immediately below is
my build script, the followed by .Rprofile. Thanks guys!

#3
# build R-devel
cd ~/R_HOME
wget ftp://ftp.stat.math.ethz.ch/Software/R/R-devel.tar.gz
tar -xzf R-devel.tar.gz
cd ~/R_HOME/R-devel
mkdir R-build
cd R-build
../configure --prefix=/home/mkimpel/R_HOME/R-devel/R-build
CC=/usr/bin/gcc-4.3 CXX=/usr/bin/g++-4.3 F77=/usr/bin/gfortran-4.3
make all
make install
# end build script
#
# .Rprofile
#tell R where site-library is
ver <- getRversion()
options(editor="emacs")

if (ver == "2.9.1"){.libPaths(new= "~/R_HOME/site-library-2.9.0")}
if (ver == "2.10.0"){.libPaths(new= "~/R_HOME/site-library-2.10.0")}

options(htmlhelp=TRUE)
options(browser="firefox newTab")

#update packages
source("~/R.functions/General_Functions/my.update.packages.func.R")
if (interactive()) { #needed to keep R from looping as it calls R for
install scripts
  my.update.packages.func(force = FALSE)
  ##
  # source function loader function and execute it

source("~/R.functions/General_Functions/UtilityFunctions/load.R.func.files.R")
  get.and.load.functions.func()
  ##
  # set error recovery option
  options(error=utils::recover)
}
#
# end .Rprofile

# ~/R.functions/General_Functions/UtilityFunctions/load.R.func.files.R
my.update.packages.func <- function(update.interveral.days = 7, force =
TRUE){
require(utils)
old.wd <- getwd()
setwd("~/")
last.update.error <- try(load(file = ".Rupdate.date"), TRUE)
if(inherits(last.update.error, "try-error")) {last.update <-
as.POSIXct("2007-01-01")} else {
  load(file = ".Rupdate.date")} #if .Rupdate.date does not exist or
can't load, update
if(force) {last.update <-  as.POSIXct("2007-01-01")} #allow to force
updates
current.time <- Sys.time()
time.diff <- current.time - last.update
   if(
   (
(units(time.diff) == "days")
  &&
(time.diff[[1]][1] >= update.interveral.days)
) ||
   inherits(last.update.error, "try-error")
   ){  #then update

##From Jim McDonald: I just have the above in my .Rprofile file, so
biocLite() is always there for me.
   source("http://www.bioconductor.org/biocLite.R";)
   biocLite("Biobase")
   library("Biobase")
   repos <- biocReposList()
   update.packages(repos=repos,
ask=FALSE)###
   update.packages(repos="http://www.omegahat.org/R";, ask = FALSE)
   last.update <- current.time
   local(save(last.update, file = ".Rupdate.date"))
   print("packages updated")
   } else {print("packages do not need updated")}
setwd(old.wd)
  }
###
# End file

Mark W. Kimpel MD  ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield, IN  46074

(317) 490-5129 Work, & Mobile & VoiceMail
(317) 399-1219 Skype No Voicemail please


On Wed, Sep 16, 2009 at 8:10 PM, Simon Urbanek
wrote:

>
> On Sep 16, 2009, at 7:48 PM, Mark Kimpel wrote:
>
>  Peter,
>>
>> I have not yet tried Simon's suggestion of using gcc 4.3 (just got back
>> from
>> a meeting), but running your commands produces the output below. As you
>> can
>> see, R --vanilla works, but just plain "R" doesn't.
>>
>
> Please send us you .Rprofile because that's likely what's causing the crash
> ... (reading a profile causes the crash, so unless you have a custom site
> profile the .Rprofile is the one to blame).
>
> Thanks,
> S
>
>
>
>
>  See the results of gdb
>> far below.
>>
>> I do not have a saved workspace in my R_HOME or any of its subdirectories.
>>
>> Will report back on what I get with gcc 4.3 just as soon as I read the
>> R-admin manual and figure out how to get configure configured
>>
>> Mark
>>
>>
>> mkimpel-XPS ~/sshfs: R --vanilla
>>

Re: [Rd] 2.10.0 Under development (unstable) (2009-09-15 r49711) just built segfaults on Debian Squeeze

[Mark Kimpel]

Okay, now that I knew what to look at, I've narrowed to the problem down to
the line
'source("~/R.functions/General_Functions/my.update.packages.func.R")'

if just this line is commented out, R loads fine. If not, it crashes
reliably. Interestingly, if commented out, once R is loaded, the function
loads into R just fine and in facts runs as intended. So, perhaps there is
something in the way R is sourcing the file or with the source command
itself?

Thanks for helping me to figure this out, let me know if there is anything
specific you want me to try.

Mark

Mark W. Kimpel MD  ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield, IN  46074

(317) 490-5129 Work, & Mobile & VoiceMail
(317) 399-1219 Skype No Voicemail please


On Wed, Sep 16, 2009 at 8:07 PM, Duncan Murdoch wrote:

> On 16/09/2009 7:48 PM, Mark Kimpel wrote:
>
>> Peter,
>>
>> I have not yet tried Simon's suggestion of using gcc 4.3 (just got back
>> from
>> a meeting), but running your commands produces the output below. As you
>> can
>> see, R --vanilla works, but just plain "R" doesn't. See the results of gdb
>> far below.
>>
>
> That's helpful.  It died in the parser while trying to read your user
> profile.  I can't tell what file it was trying to read, but the order it
> tries them is as follows:
>
> If you have R_PROFILE_USER set, it tries to read the file named there.
>
> It tries to read .Rprofile in the current directory.
>
> If you have HOME set, it tries to read .Rprofile in that directory.
>
> It appears that you found a bug in the parser while trying to read that
> file:  you shouldn't be able to get a segfault, at worst you should get a
> syntax error.
>
> Can you work out what file it read, and send me a copy?  I'd like to track
> this down.
>
> Duncan Murdoch
>
>
>
>> I do not have a saved workspace in my R_HOME or any of its subdirectories.
>>
>> Will report back on what I get with gcc 4.3 just as soon as I read the
>> R-admin manual and figure out how to get configure configured
>>
>> Mark
>>
>>
>> mkimpel-XPS ~/sshfs: R --vanilla
>>
>> R version 2.10.0 Under development (unstable) (2009-09-15 r49711)
>> Copyright (C) 2009 The R Foundation for Statistical Computing
>> ISBN 3-900051-07-0
>>
>> R is free software and comes with ABSOLUTELY NO WARRANTY.
>> You are welcome to redistribute it under certain conditions.
>> Type 'license()' or 'licence()' for distribution details.
>>
>>  Natural language support but running in an English locale
>>
>> R is a collaborative project with many contributors.
>> Type 'contributors()' for more information and
>> 'citation()' on how to cite R or R packages in publications.
>>
>> Type 'demo()' for some demos, 'help()' for on-line help, or
>> 'help.start()' for an HTML browser interface to help.
>> Type 'q()' to quit R.
>>
>>  q()
>>>
>> mkimpel-XPS ~/sshfs: R
>>
>> R version 2.10.0 Under development (unstable) (2009-09-15 r49711)
>> Copyright (C) 2009 The R Foundation for Statistical Computing
>> ISBN 3-900051-07-0
>>
>> R is free software and comes with ABSOLUTELY NO WARRANTY.
>> You are welcome to redistribute it under certain conditions.
>> Type 'license()' or 'licence()' for distribution details.
>>
>>  Natural language support but running in an English locale
>>
>> R is a collaborative project with many contributors.
>> Type 'contributors()' for more information and
>> 'citation()' on how to cite R or R packages in publications.
>>
>> Type 'demo()' for some demos, 'help()' for on-line help, or
>> 'help.start()' for an HTML browser interface to help.
>> Type 'q()' to quit R.
>>
>>
>>  *** caught segfault ***
>> address (nil), cause 'memory not mapped'
>>
>> Possible actions:
>> 1: abort (with core dump, if enabled)
>> 2: normal R exit
>> 3: exit R without saving workspace
>> 4: exit R saving workspace
>> Selection: 4
>> mkimpel-XPS ~/sshfs: R -d gdb
>> GNU gdb (GDB) 6.8.50.20090628-cvs-debian
>> Copyright (C) 2009 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later <
>> http://gnu.org/licenses/gpl.html
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "s

Re: [Rd] 2.10.0 Under development (unstable) (2009-09-15 r49711) just built segfaults on Debian Squeeze

[Mark Kimpel]

Thanks, no problem for me to wait for the fix. It's just nice to know that I
was able to help improve R in a small way by using R-devel. Usually, it is
ME making the error! Thanks again for all your development efforts. Cheers,
Mark

Mark W. Kimpel MD  ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield, IN  46074

(317) 490-5129 Work, & Mobile & VoiceMail
(317) 399-1219 Skype No Voicemail please


On Wed, Sep 16, 2009 at 9:49 PM, Duncan Murdoch wrote:

> Okay, I've tracked this down, and it's a stupid error I made when trying to
> improve the error messages.  I tried to make the parser remember its
> position in a file when parsing it line by line so that it could report on
> syntax errors properly; the trouble is that when it executes one of those
> lines (like yours containing source()), it might re-enter the parser.  It
> needs to save and restore its state around that sort of call.
>
> This will be fairly easy to fix, but I won't be able to do it until
> tomorrow.
>
> Duncan Murdoch
>
>
>
> On 16/09/2009 3:51 PM, Mark Kimpel wrote:
>
>> I just downloaded R-devel and when loaded it immediately segfaults. I'm
>> not
>> sure how much or what sort of diagnostic info and can provide, but below
>> is
>> my build script, my console output, and the output of uname -r. I am
>> currently dependent on the development version of a package, so I'd like
>> to
>> get R-devel up and running if possible. I am sure there is more info I can
>> provide, but before deluging the list with unnecessary output, I thought I
>> would ask first what would be helpfu. Mark
>>
>
>  #Make R
>> cd ~/R_HOME
>> wget ftp://ftp.stat.math.ethz.ch/Software/R/R-devel.tar.gz
>> tar -xzf R-devel.tar.gz
>> cd ~/R_HOME/R-devel
>> mkdir R-build
>> cd R-build
>> ../configure --prefix=/home/mkimpel/R_HOME/R-devel/R-build
>> make all
>> make install
>>
>> #33
>> # console output
>> mkimpel-XPS ~/R_HOME/R-devel/R-build/bin: ./R
>>
>> R version 2.10.0 Under development (unstable) (2009-09-15 r49711)
>> Copyright (C) 2009 The R Foundation for Statistical Computing
>> ISBN 3-900051-07-0
>>
>> R is free software and comes with ABSOLUTELY NO WARRANTY.
>> You are welcome to redistribute it under certain conditions.
>> Type 'license()' or 'licence()' for distribution details.
>>
>>  Natural language support but running in an English locale
>>
>> R is a collaborative project with many contributors.
>> Type 'contributors()' for more information and
>> 'citation()' on how to cite R or R packages in publications.
>>
>> Type 'demo()' for some demos, 'help()' for on-line help, or
>> 'help.start()' for an HTML browser interface to help.
>> Type 'q()' to quit R.
>>
>>
>>  *** caught segfault ***
>> address (nil), cause 'memory not mapped'
>>
>> Possible actions:
>> 1: abort (with core dump, if enabled)
>> 2: normal R exit
>> 3: exit R without saving workspace
>> 4: exit R saving workspace
>> Selection: 2
>> Save workspace image? [y/n/c]: n
>>
>> ##
>> # kernel version
>> mkimpel-XPS ~/R_HOME/R-devel/R-build/bin: uname -r
>> 2.6.30-1-amd64
>> mkimpel-XPS ~/R_HOME/R-devel/R-build/bin:
>>
>>
>> Mark W. Kimpel MD  ** Neuroinformatics ** Dept. of Psychiatry
>> Indiana University School of Medicine
>>
>> 15032 Hunter Court, Westfield, IN  46074
>>
>> (317) 490-5129 Work, & Mobile & VoiceMail
>> (317) 399-1219 Skype No Voicemail please
>>
>>[[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>

[[alternative HTML version deleted]]

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

Re: [Rd] 2.10.0 Under development (unstable) (2009-09-15 r49711) just built segfaults on Debian Squeeze

[Mark Kimpel]

Just downloaded and installed "R version 2.10.0 Under development (unstable)
(2009-09-21 r49771)" and am happy to report that my .Rprofile loads
appropriately with no segfaults. Thanks Duncan! Mark

Mark W. Kimpel MD  ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield, IN  46074

(317) 490-5129 Work, & Mobile & VoiceMail
(317) 399-1219 Skype No Voicemail please


On Fri, Sep 18, 2009 at 2:11 PM, Duncan Murdoch wrote:

> I've just committed (r49747) some changes that should fix the re-entrancy
> bug Mark reported the other day.  The problem was that R reads some files
> (e.g. Mark's .Rprofile) in a read-eval-print loop, and only parses them a
> few lines at a time.  This means that within that loop, one of the evals
> could cause it to start parsing something else. One of the changes I put in
> a few days ago got confused by this.
>
> Hopefully the latest change hasn't introduced a new bug...
>
> BTW, one of the effects of this change is that a syntax error in .Rprofile
> should now be reported on the correct line number.  In R 2.9.x the line
> number was relative to the current statement, so it was pretty meaningless.
>
> Duncan Murdoch
>

[[alternative HTML version deleted]]

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

Re: [Rd] Surprising length() of POSIXlt vector (PR#14073)

[Mark White]

Benilton Carvalho writes:
> I'm no expert on this, but my understanding is that the choice was
> to stick to the definition.
> 
> The help file for length() [1] says:
> 
> "For vectors (including lists) and factors the length is the number
> of elements."
> 
> The help file for POSIXlt [2] (for example) says:
> 
> "Class ?"POSIXlt"? is a named list of vectors representing (...)"
> 
> and then lists the 9 elements (sec / min / hour / mday / mon / year
> / wday / yday / isdst).
> 
> So, by [1] length of POSIXlt objects is 9, because it "is a named
> list of vectors representing (...)".

Thanks, all.  Yes, I'd already read both, and it's obviously
true that a length() of 9 is correct (as I said up-front).

The difficulty is that some functions -- importantly
including "[" -- already have methods which make POSIXlt
behave like a vector.  The documentation for POSIXlt just
says it's a list of 9 elements: it mentions methods for
addition etc, but AFAICT it doesn't say that subsetting won't
behave is "["'s help says for a list-like object.

In the end, "[" sees a different length to "[[" and "$"
here, so a length.POSIXlt() just shuffles the issue around.

Anyhow, I somehow missed there have been other PRs on this,
including discussion on r-devel of "[" and logical vs physical
length() under PR#10507.  I'm sorry for being repetitive.

Mark <><

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

[Rd] question about differences in behavior with NA subscripts in matrix vs. data.frame

[Mark Kimpel]

I ran into a problem today when using a conditional for sub-setting a
data.frame and tracked it down to a difference in behavior between the
treatment of NA when sub-setting matrices and data.frames. A self-contained
example is below followed by sessionInfo(). I'm not questioning the
documentation of the behavior, but the rationale for its existence.

Could someone explain to me why the difference is logical and useful? This
seems more of a devel than a help issue, my apologies if I've posted to the
incorrect list.

Mark
#
a.vec <- c("A", "", "B", "DEF", NA, "", NA, "Q")
a.vec[a.vec == ""] <- NA
a.vec
## [1] "A"   NA"B"   "DEF" NANANA"Q"

a.mat <- matrix(rep(c("A", "", "B", "DEF", NA, "", NA, "Q"), 5), nrow = 5,
ncol = 8)
a.mat[a.mat[,3] == "", 3] <- NA
a.mat
##  [,1]  [,2] [,3]  [,4]  [,5] [,6]  [,7] [,8]
## [1,] "A"   ""   "B"   "Q"   NA   ""NA   "DEF"
## [2,] ""NA   "DEF" "A"   ""   "B"   "Q"  NA
## [3,] "B"   "Q"  NA""NA   "DEF" "A"  ""
## [4,] "DEF" "A"  NA"B"   "Q"  NA""   NA
## [5,] NA""   NA"DEF" "A"  """B"  "Q"

a.df <- data.frame(matrix(rep(c("A", "", "B", "DEF", NA, "", NA, "Q"), 5),
nrow = 5, ncol = 8))
a.df[a.df[,3] == "", 3] <- NA
a.df
## Error in `[<-.data.frame`(`*tmp*`, a.df[, 3] == "", 3, value = NA) :
##   missing values are not allowed in subscripted assignments of data
frames

## Enter a frame number, or 0 to exit

## 1: `[<-`(`*tmp*`, a.df[, 3] == "", 3, value = NA)
## 2: `[<-.data.frame`(`*tmp*`, a.df[, 3] == "", 3, value = NA)
## remove plain text non-codes from codes.df
sessionInfo()
## R version 2.10.0 Patched (2009-10-27 r50222)
## x86_64-unknown-linux-gnu

## 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=C  LC_MESSAGES=en_US.UTF-8
##  [7] LC_PAPER=en_US.UTF-8   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 datasets  utils methods   base

## loaded via a namespace (and not attached):
## [1] tools_2.10.0
Mark W. Kimpel MD  ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield, IN  46074

(317) 490-5129 Work, & Mobile & VoiceMail
(317) 399-1219 Skype No Voicemail please

[[alternative HTML version deleted]]

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

Re: [Rd] Rcpp: Clarifying the meaning of GPL?

[Mark Kimpel]

I don't think this is off-topic, in the sense that it is the contribution of
the developers of the multitude of packages available that has led to the
success of R. How packages are maintained, forked, etc., is an important
issue. I should say that I am not a developer, only a user appreciative of
the tremendous effort it takes to develop and maintain packages. In the
past, however, when I have inquired about developing a BioConductor package
for R, I was told that should I do so I should commit to maintain the
package. It seems to me, again as a matter of courtesy and cooperation, that
should someone wish to make substantive changes to a package that someone
else is maintaining, then they should do so in concert with the package
maintainer. If the package is "orphaned", however, then the story would be
different. If the original developer/maintainer is still active and does not
agree with suggested changes, then a fork, with a different name would be
the wisest course of action.

I am not taking sides here, I have no idea which of my hypothetical
scenarios might have in reality taken place with this particular package. I
just wanted to say that I think the issue is important, that good
communication is important, and that there are some basic principals that
seem reasonable to uphold should we wish the R community to continue to be
developer friendly.

Mark

Mark W. Kimpel MD  ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield, IN  46074

(317) 490-5129 Work, & Mobile & VoiceMail
(317) 399-1219 Skype No Voicemail please


On Wed, Dec 23, 2009 at 12:32 AM, Jeff Ryan  wrote:

> This is fantastically off-topic, and has nothing to do with *R*.
>
> Out of "courtesy" to this list, the subscribers, and future readers,
> please take this off-list where it belongs.
>
> Jeff
>
> On Tue, Dec 22, 2009 at 11:27 PM, Dominick Samperi
>  wrote:
> > Stavros Macrakis wrote:
> >>
> >> That said, as a matter of courtesy and clarity, I'd think that a fork
> >> should use a different name.
> >
> > Yes, the point is that this is not a legal or technical matter, it is a
> > matter of professional courtesy.
> >
> > I take this as one vote for the name change.
> >
> > On US copyright law, this should not be confused with "copyright" notices
> > that appear in GPL
> > source code. Remember that these are really "copyleft" notices, and
> copyleft
> > is designed to
> > protect the rights of copiers, not original contributors. My concern
> about
> > the copyright notice
> > should be viewed in the same spirit as the name change (professional
> > courtesy).
> >
> > Since GPL is largely silent on these issues I have asked the R community
> to
> > vote...
> >
> > Thanks,
> > Dominick
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
>
>
> --
> Jeffrey Ryan
> jeffrey.r...@insightalgo.com
>
> ia: insight algorithmics
> www.insightalgo.com
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

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

Re: [Rd] Best style to organize code, namespaces

[Mark Kimpel]

I'm going to suggest something that is probably not the coolest thing to do,
but it gets me by with almost all my debugging. I set options(error=recover)
and then in the function I want to debug I put some unassigned variable name
on the first line (example: ThisIsMyDebuggingVariable). Then I will get the
error message "Error: object 'ThisIsMyDebuggingVariable' not found" and, if
the function is nested within other functions, the nice menu that allows me
to choose what level I want to be in. In Emacs I just step through the
function of interest. This allows for Duncan's wish of single stepping
through multiple levels (if I am interpreting him correctly). It's not very
fancy, but it has gotten the job done for me.

Mark


Mark W. Kimpel MD  ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield, IN  46074

(317) 490-5129 Work, & Mobile & VoiceMail
(317) 399-1219 Skype No Voicemail please


On Tue, Feb 23, 2010 at 5:42 PM, Duncan Murdoch wrote:

> On 22/02/2010 10:15 PM, Gabor Grothendieck wrote:
>
>> As you mention ease of debugging basically precludes subfunctions so
>> style 1 is left.
>>
>
> I think you are also unaware of setBreakpoint() (and trace(), which
> underlies it).  So more detail:
>
> If you put this into file test.R, starting on line 1:
>
> outer <- function(x) {
>   inner <- function() {
>   if (x > 3) {
>  x <- 0
>   }
>   }
>
>   inner()
>   print(x)
> }
>
> you might want to debug why outer(10) prints 10, not 0.  So set a
> breakpoint on line 4 to see if you get there:
>
> > setBreakpoint("test.R#4")
> c:\temp\test.R#4:
>  outer step 2,3,3,2,3,2 in 
> > outer(10)
> test.R#4
> Called from: eval(expr, envir, enclos)
> Browse[1]>
>
> Yes, we got there.  Take a step:
>
> Browse[1]> n
> debug: x <- 0
>
> Now recognize we should have used x <<- 0.
>
> Now, it would be nice if we had more flexible debugging (e.g. single
> stepping that would stay as single stepping when we exited from inner()),
> but debug() is certainly not the only possibility for debugging.  It's not
> even the best choice in a lot of situations where it does work.
>
> Duncan Murdoch
>
>
>
>> Functions can be nested in environments rather than in other functions
>> and this will allow debugging to still occur.
>>
>> The proto package which makes it particularly convenient to nest
>> functions in environments giving an analog to #3 while still allowing
>> debugging.  See http//:r-proto.googlecode.com
>>
>>  library(proto)
>>> # p is proto object with variable a and method f
>>> p <- proto(a = 1, f = function(., x = 1) .$a <- .$a + 1)
>>> with(p, debug(f))
>>> p$f()
>>>
>> debugging in: get("f", env = p, inherits = TRUE)(p, ...)
>> debug: .$a <- .$a + 1
>> Browse[2]>
>> exiting from: get("f", env = p, inherits = TRUE)(p, ...)
>> [1] 2
>>
>>> p$a
>>>
>> [1] 2
>>
>>
>> On Mon, Feb 22, 2010 at 9:49 PM, Ben  wrote:
>>
>>> Hi all,
>>>
>>> I'm hoping someone could tell me what best practices are as far as
>>> keeping programs organized in R.  In most languages, I like to keep
>>> things organized by writing small functions.  So, suppose I want to
>>> write a function that would require helper functions or would just be
>>> too big to write in one piece.  Below are three ways to do this:
>>>
>>>
>>> ### Style 1 (C-style) ###
>>> Foo <- function(x) {
>>>  
>>> }
>>> Foo.subf <- function(x, blah) {
>>>  
>>> }
>>> Foo.subg <- function(x, bar) {
>>>  
>>> }
>>>
>>> ### Style 2 (Lispish?) ##
>>> Foo <- function(x) {
>>>  Subf <- function(blah) {
>>>   
>>>  }
>>>  Subg <- function(bar) {
>>>   
>>>  }
>>>  
>>> }
>>>
>>> ### Object-Oriented #
>>> Foo <- function(x) {
>>>  Subf <- function(blah) {
>>>   
>>>  }
>>>  Subg <- function(bar) {
>>>   
>>>  }
>>>  Main <- function() {
>>>   
>>>  }
>>>  return(list(subf=subf, subg=subg, foo=foo))
>>> }
>>> ### End examples 
>>>
>>> Which of these ways is best?  Style 2 

Re: [Rd] Windows Vista Issues

[Mark Difford]

Hi Dominick,

No offence intended, but I have been running R (presently 2.5.1.patched) on
a Vista (Home Basic) machine without a hitch since March 2007.  Initially I
had to turn off "User Account Control" to install new packages, but that was
a known issue.  I still run it that way, though it's not necessary anymore
(to have a truly smooth R).  You really don't need it switched on if you
have decent anti-virus stuff &c.

Regards,
Mark Difford.


Dominick Samperi-2 wrote:
> 
> Uwe Ligges wrote:
>> There is not a single R-Vista issue here (and no R issue at all). All 
>> are problems of the user who has not read Windows Vista documentation.
>> Uwe Ligges
> Oh, and this probably explains why my previous two postings mysteriously 
> disappeared.
> 
> I took the time to post this message for the benefit of readers of this 
> group.
> 
> Can you please tell me how I can remove R software packages that I 
> previously
> contributed from your archives?
> 
> Thanks,
> Dominick
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Windows-Vista-Issues-tf4377458.html#a12527646
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

[Rd] Regression test failed when building on an "older" Linux cluster

[Dalphin, Mark]

We have an aging Linux Cluster here, running Red Hat 7.3. We have some
business reasons for not upgrading the OS version. I don't recall the exact
hardware (dual Pentium III, 4 Gbyte RAM, 1 GHz clock?), but it was pretty
good in 2001 or so.

We recently tried to build and install R, ver 2.6.0, for this cluster.
It built and apparently ran correctly, but it failed "make check".
Earlier versions of R failed "make check" as well, not always for the same
reason.

I just located the failure in the tests.
It is in the file: R-2.6.0/tests/reg-tests-1.R and fails in the code:

## related checks on eff.aovlist
example(eff.aovlist) # helmert contrasts
eff1 <- eff.aovlist(fit)
fit <- aov(Yield ~ A * B * C + Error(Block), data = aovdat)
eff2 <- eff.aovlist(fit)
stopifnot(all.equal(eff1, eff2)) # will have rounding-error differences
options(contrasts = old)
## Were different in earlier versions

The failure occurred in the 'stopifnot()' call, but was preceded by a
warning about a lack of documentation in "example(eff.aovlist)". I looked at
"example" and found that it relies on available documentation to work,
returning this warning when no documentation is found:

file <- index.search(topic, INDICES, "AnIndex", "R-ex")
if (file == "") {
warning(gettextf("no help file found for '%s'", topic), 
domain = NA)
return(invisible())

Well, our old Linux cluster doesn't support building R documentation; why
would it when we are very limited on disk space for each node? No one can
log in there; it is all run via LSF. The lack of documentation makes
"example()" fail to return anything and the "reg-tests-1.R" requires that a
value for 'fit' be returned in the global environment for comparison. In
short, in the absence of documentation, this regression test must fail. (I
am assuming that my interpretation of the failure is correct; please feel
free to let me know that I am mis-interpreting the cause of failure!).

If I comment out the above code, all the other tests run correctly. Of
course, normally we would build on another, better equipped host, and then
copy R to each host. That is not possible in this case as the glibc is so
old that it is not compatible with the calls generated on newer hosts.

I am surprised that this problem with "example()" doesn't cause other
failures in the "make check". It makes me think that the use of "example()"
here is unusual (or that I am misinterpreting the failure). If that is the
case, then I suggest removing the call to "example" and replacing it with
the code from within that example. I believe that running R on a compute
cluster without documentation building tools is not an unreasonable use
case. (If that is so, why haven't others stumbled onto this problem before
me? I don't know.) Making the regression tests work in the absence of
documentation, along with the rest of R seems reasonable.

We are now using R on the compute cluster. This email's purpose is to
suggest that R may at times be built in an environment without documentation
tools and it would be nice if the regression tests still worked there. I
hope the developers will consider this use case.

Regards,
Mark Dalphin

PS Having written this email, I am consumed by guilt; I haven't properly and
recently checked the "R admin manual" that I should be able to build R
without documentation. Checking for "essential programs for building and
running R" doesn't seem to show that building documentation is required. I
am relieved to report that building documentation, despite being under
"Essential Programs" section is described in a manner suggesting that
documentation is optional.
http://cran.r-project.org/doc/manuals/R-admin.html#Essential-and-useful-othe
r-programs-under-Unix

--
Mark Dalphin
Dept Comp Biol, M/S AW2/D3262
Amgen, Inc.
1201 Amgen Court W
Seattle, WA 98119
Phone: +1-206-265-7951

[[alternative HTML version deleted]]

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

Re: [Rd] Regression test failed when building on an "older" Linux cluster

[Dalphin, Mark]

Thank you, Prof. Ripley.

In fact, I tend to agree somewhat with your arguments; our system 
administrators don't, however.

We do have Perl, though looking now I see its version is too old, 5.6.1, not 
the required > 5.8.0.

Your argument that the examples are essential for testing sways me. If that is 
how these tests are constructed, then we have failed the tests and can't trust 
the use of R on that old cluster. I intended my question to imply that we had 
failed on only one call to example(), hence I concluded (without evidence) that 
the test functions called example() only once where I had noted the failure. I 
probably should have grepped for "example(" before concluding that.

I'll see if we can install an upgraded Perl on a shared location and build R 
against that. I that solves the problem, I'll report back.

Thank you for your time.

Regards,
Mark Dalphin

-Original Message-
From: Prof Brian Ripley [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 24, 2007 12:37 AM
To: Dalphin, Mark
Cc: [EMAIL PROTECTED]
Subject: Re: [Rd] Regression test failed when building on an "older" Linux 
cluster

We don't offer the option of building R without documentation, so I presume you 
do not have Perl installed.

Without the examples, there is no check of large swathes of code, so 'make 
check' should not succeed (it would give a false sense of security to pass most 
tests by omitting them).  I've altered it so it will always fail without Perl.

I don't buy the disc space argument: you don't have to _install_ the 
documentation on each node, and 'make check' runs on the build and not the 
installed copy.  We don't offer the possibility of installing a cut-down 
version, but surely someone with such a specialized need will be able to script 
that?  And if disc space is tight, why have a copy on each node?
(We don't on our clusters, where space is not tight: it makes maintenance of 
packages so much easier to have a single shared copy.)

On Thu, 18 Oct 2007, Dalphin, Mark wrote:

> We have an aging Linux Cluster here, running Red Hat 7.3. We have some
> business reasons for not upgrading the OS version. I don't recall the
> exact hardware (dual Pentium III, 4 Gbyte RAM, 1 GHz clock?), but it
> was pretty good in 2001 or so.
>
> We recently tried to build and install R, ver 2.6.0, for this cluster.
> It built and apparently ran correctly, but it failed "make check".
> Earlier versions of R failed "make check" as well, not always for the
> same reason.
>
> I just located the failure in the tests.
> It is in the file: R-2.6.0/tests/reg-tests-1.R and fails in the code:
>
> ## related checks on eff.aovlist
> example(eff.aovlist) # helmert contrasts
> eff1 <- eff.aovlist(fit)
> fit <- aov(Yield ~ A * B * C + Error(Block), data = aovdat)
> eff2 <- eff.aovlist(fit)
> stopifnot(all.equal(eff1, eff2)) # will have rounding-error
> differences options(contrasts = old) ## Were different in earlier
> versions
>
> The failure occurred in the 'stopifnot()' call, but was preceded by a
> warning about a lack of documentation in "example(eff.aovlist)". I
> looked at "example" and found that it relies on available
> documentation to work, returning this warning when no documentation is found:
>
>file <- index.search(topic, INDICES, "AnIndex", "R-ex")
>if (file == "") {
>warning(gettextf("no help file found for '%s'", topic),
>domain = NA)
>return(invisible())
>
> Well, our old Linux cluster doesn't support building R documentation;
> why would it when we are very limited on disk space for each node? No
> one can log in there; it is all run via LSF. The lack of documentation
> makes "example()" fail to return anything and the "reg-tests-1.R"
> requires that a value for 'fit' be returned in the global environment
> for comparison. In short, in the absence of documentation, this
> regression test must fail. (I am assuming that my interpretation of
> the failure is correct; please feel free to let me know that I am 
> mis-interpreting the cause of failure!).
>
> If I comment out the above code, all the other tests run correctly. Of
> course, normally we would build on another, better equipped host, and
> then copy R to each host. That is not possible in this case as the
> glibc is so old that it is not compatible with the calls generated on newer 
> hosts.
>
> I am surprised that this problem with "example()" doesn't cause other
> failures in the "make check". It makes me think that the use of "example()"
> here is unusual (or that I am misinterpreting the fail

[Rd] Problem compiling R 3.6.1 on POWER 570 system

[Mark Komarinski]

I've for a RHEL 4 box on a P570 system.  My end user wants to have a 
64-bit version of R compiled due to the large amount of memory they 
require (this image has 16GB allocated to it).

I can compile R fine in 32-bit mode, but it can't use more than 2.4GB of 
RAM before it falls over and dies.

Compiling in 64-bit mode for POWER systems "should" be as easy as adding 
a CFLAGS="-m64" FFLAGS="-m64" ./configure --without-x .

It's not, and unfortunately I'm at a loss to what the problem is. 
Here's the last few lines of the above configure command:

checking for Fortran 77 libraries of g77...  -L/usr/local/lib64 
-L/usr/lib/gcc/ppc64-redhat-linux/3.4.6/64 
-L/usr/lib/gcc/ppc64-redhat-linux/3.4.6 
-L/usr/lib/gcc/ppc64-redhat-linux/3.4.6/../../../../lib64 
-L/usr/lib/gcc/ppc64-redhat-linux/3.4.6/../../.. -L/lib/../lib64 
-L/usr/lib/../lib64 -lfrtbegin -lg2c -lm -lgcc_s_64
checking how to get verbose linking output from gcc -std=gnu99... -v
checking for C libraries of gcc -std=gnu99...  -L/usr/local/lib64 
-L/usr/lib/gcc/ppc64-redhat-linux/3.4.6/64 
-L/usr/lib/gcc/ppc64-redhat-linux/3.4.6 
-L/usr/lib/gcc/ppc64-redhat-linux/3.4.6/../../../../lib64 
-L/usr/lib/gcc/ppc64-redhat-linux/3.4.6/../../.. -L/lib/../lib64 
-L/usr/lib/../lib64 -lgcc_s_64
checking for dummy main to link with Fortran 77 libraries... none
checking for Fortran 77 name-mangling scheme... lower case, underscore, 
extra underscore
checking whether g77 appends underscores to external names... yes
checking whether g77 appends extra underscores to external names... yes
checking whether mixed C/Fortran code can be run... configure: WARNING: 
cannot run mixed C/Fortran code
configure: error: Maybe check LDFLAGS for paths to Fortran libraries?

Here's what looks to be the relevant part from config.log:
configure:32383: checking whether mixed C/Fortran code can be run
/usr/bin/ld: skipping incompatible 
/usr/lib/gcc/ppc64-redhat-linux/3.4.6/libgcc_s_64.so when searching for 
-lgcc_s_64
/usr/bin/ld: skipping incompatible 
/usr/lib/gcc/ppc64-redhat-linux/3.4.6/libgcc_s_64.so when searching for 
-lgcc_s_64
/usr/bin/ld: cannot find -lgcc_s_64
collect2: ld returned 1 exit status
configure:32447: WARNING: cannot run mixed C/Fortran code
configure:32449: error: Maybe check LDFLAGS for paths to Fortran libraries?

This implies that configure is compiling the code in 32 bit mode (which 
is why it's skipping libgcc_s_64.o

I guess my questions are: has anyone compiled this for this system?  And 
if so, how did you do it?

-Mark

-- 
Mark Komarinski [EMAIL PROTECTED]
Sr. Research Systems Architect  http://ritg.med.harvard.edu
Research IT Group
Harvard Medical School

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

Re: [Rd] Problem compiling R 2.6.1 on POWER 570 system

[Mark Komarinski]

Cookies all around for the rapid and accurate help!

I wound up using a variation of the below (the non-quoted part is what I 
changed):

On 12/19/2007 04:15 PM, Andrew Ferris wrote:
> Hello Mark,
> 
> Here's the full configure that I used to get 2.4.1 to work on 64bit SLES on a 
> 570:
> 
> ./configure CC="gcc -m64" /
> CXX="gxx -m64" /
CXX="g++ -m64"
> F77="gfortran -m64" /
> FC="gfortran -m64" /
> CFLAGS="-mminimal-toc -fno-optimize-sibling-calls -g -O2" /
> FFLAGS="-mminimal-toc -fno-optimize-sibling-calls -g -O2" /
> LDFLAGS=-L/usr/lib64 /
> --without-x 

This did indeed create a 64-bit executable.

Alas, I won the battle but may still lose the war.  Red Hat did not 
include many PPC64 versions of their development libraries 
(libxml2-devel for example) that I need to install things like 
AnnBuilder.  It looks like RHEL 5 has these available, so I'll need to 
upgrade this partition and see if I can get this working.

Again, thanks for the help!

-Mark

-- 
Mark Komarinski [EMAIL PROTECTED]
Sr. Research Systems Architect  http://ritg.med.harvard.edu
Research IT Group
Harvard Medical School

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

[Rd] regexp with [:upper:] (PR#11032)

[mark . bravington]

Full_Name: Mark Bravington
Version: 2.6.2 patched
OS: Windows XP Pro
Submission from: (NULL) (140.79.22.104)


> grep( '[:upper:]', letters, val=T) # shurely shouldn't match anything ??
[1] "e" "p" "r" "u"

The converse ( '[:lower:]' and LETTERS) seems to work OK.

--please do not edit the information below--

Version:
 platform = i386-pc-mingw32
 arch = i386
 os = mingw32
 system = i386, mingw32
 status = Patched
 major = 2
 minor = 6.2
 year = 2008
 month = 03
 day = 21
 svn rev = 44836
 language = R
 version.string = R version 2.6.2 Patched (2008-03-21 r44836)

Windows XP (build 2600) Service Pack 2

Locale:
LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MONETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252

Search Path:
 .GlobalEnv, package:stats, package:graphics, package:grDevices, package:utils,
package:datasets, package:methods, Autoloads, pa

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

[Rd] error with R-patched (2008-05-02 r45591)

[Mark Kimpel]

Just installed the latest R-patched and get the error seen at the end of the
output below. Don't know what to make of this but thought I should report
it. In general, when installing the latest version of R, should one use
R-latest or R-patched? R-latest is stable, but one would assume that
R-patched includes the latest bug fixes.
Mark

mkimpel-m90 ~/R_HOME/R-patched/R-build/bin: ./R

R version 2.7.0 Patched (2008-05-02 r45591)
Copyright (C) 2008 The R Foundation for Statistical Computing
ISBN 3-900051-07-0

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

Loading required package: utils
[1] "packages do not need updated"
Error in source(source.files[i]) :
  invalid multibyte character in mbcs_get_next at line 17
[Previously saved workspace restored]

> sessionInfo()
R version 2.7.0 Patched (2008-05-02 r45591)
x86_64-unknown-linux-gnu

locale:
LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C

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


-- 
Mark W. Kimpel MD ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield, IN 46074

(317) 490-5129 Work, & Mobile & VoiceMail
(317) 663-0513 Home (no voice mail please)

**

[[alternative HTML version deleted]]

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

Re: [Rd] error with R-patched (2008-05-02 r45591)

[Mark Kimpel]

I have found the cause of the problem I am having with R-patched. In my
.Rprofile I have a function that loads a bunch of my own functions, one of
which contains the character "(R)". No other version of R I have used since
writing this function ~2 yrs. ago has had a problem reading in this
character, but apparently R-patched does (invalid multibyte character in
mbcs_get_next at line 17). Has something intentional or unintentional
occured to cause this? I suspect unintentional since this would seem to be a
loss of functionalilty unlikely to be introduced in a patch of a release.

Anyway, that's the issue, R-patched doesn't like "(R)".

Mark


On Sat, May 3, 2008 at 4:20 PM, Prof Brian Ripley <[EMAIL PROTECTED]>
wrote:

> On Sat, 3 May 2008, Mark Kimpel wrote:
>
>  Just installed the latest R-patched and get the error seen at the end of
> > the
> > output below. Don't know what to make of this but thought I should
> > report
> > it.
> >
>
> Nor do we.  You have something incorrect in your startup files, but we
> don't have those.
>
>  In general, when installing the latest version of R, should one use
> > R-latest or R-patched? R-latest is stable, but one would assume that
> > R-patched includes the latest bug fixes.
> >
>
> And you terminolgy is from where?  (Not e.g. the R FAQ.)
>
>  Mark
> >
> > mkimpel-m90 ~/R_HOME/R-patched/R-build/bin: ./R
> >
> > R version 2.7.0 Patched (2008-05-02 r45591)
> > Copyright (C) 2008 The R Foundation for Statistical Computing
> > ISBN 3-900051-07-0
> >
> > R is free software and comes with ABSOLUTELY NO WARRANTY.
> > You are welcome to redistribute it under certain conditions.
> > Type 'license()' or 'licence()' for distribution details.
> >
> >  Natural language support but running in an English locale
> >
> > R is a collaborative project with many contributors.
> > Type 'contributors()' for more information and
> > 'citation()' on how to cite R or R packages in publications.
> >
> > Type 'demo()' for some demos, 'help()' for on-line help, or
> > 'help.start()' for an HTML browser interface to help.
> > Type 'q()' to quit R.
> >
> > Loading required package: utils
> > [1] "packages do not need updated"
> > Error in source(source.files[i]) :
> >  invalid multibyte character in mbcs_get_next at line 17
> > [Previously saved workspace restored]
> >
> >  sessionInfo()
> > >
> > R version 2.7.0 Patched (2008-05-02 r45591)
> > x86_64-unknown-linux-gnu
> >
> > locale:
> >
> > LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C
> >
> > attached base packages:
> > [1] stats graphics  grDevices datasets  utils methods   base
> >
> >
> > --
> > Mark W. Kimpel MD ** Neuroinformatics ** Dept. of Psychiatry
> > Indiana University School of Medicine
> >
> > 15032 Hunter Court, Westfield, IN 46074
> >
> > (317) 490-5129 Work, & Mobile & VoiceMail
> > (317) 663-0513 Home (no voice mail please)
> >
> > **
> >
> >[[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> >
> --
> Brian D. Ripley,  [EMAIL PROTECTED]
> Professor of Applied Statistics,  
> http://www.stats.ox.ac.uk/~ripley/<http://www.stats.ox.ac.uk/%7Eripley/>
> University of Oxford, Tel:  +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UKFax:  +44 1865 272595
>



-- 
Mark W. Kimpel MD ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield, IN 46074

(317) 490-5129 Work, & Mobile & VoiceMail
(317) 663-0513 Home (no voice mail please)

**

[[alternative HTML version deleted]]

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

Re: [Rd] error with R-patched (2008-05-02 r45591)

[Mark Kimpel]

Thanks guys. For the benefit of anyone following up on this in the future, I
solved my problem in my offending file with:

iconv -f LATIN1 -t UTF-8 methods.output.func.R >> methods.output.func.R

Mark

On Sun, May 4, 2008 at 4:13 AM, Peter Dalgaard <[EMAIL PROTECTED]>
wrote:

> Prof Brian Ripley wrote:
>
> > From the NEWS file for R-patchd:
> > >
> >
> > BUG FIXES
> >
> >oThe parser sometimes accepted invalid quoted strings in a UTF-8
> >locale.
> >
> > This is likely to be the issue, but we still don't have a reproducible
> > example (see the posting guide).
> >
> >  As Brian probably already knows, the issue is likely to be that your
> source file is in a non-UTF-8 encoding. (Emacs has become a little too
> smooth in handling such files almost invisibly. The magic incantation is
>
> C-x RET f utf-8
>
> before saving.)
>
> It can be reproduces as follows:
>
> [EMAIL PROTECTED] ~]$ cat > xxx.R
> "æøå"
> [EMAIL PROTECTED] ~]$ iconv -t latin1 xxx.R > .R
>
> and then R-patched gives
>
> > source("~/.R")
> Error in source("~/.R") :
>  invalid multibyte character in mbcs_get_next at line 1
>
> whereas R-2.6.2 gives
>
> > source(".R")
> > .Last.value
> $value
> [1] "\xe6\xf8\xe5"
>
> $visible
> [1] TRUE
>
>
>
>
>
>
> > On Sat, 3 May 2008, Mark Kimpel wrote:
> >
> >  I have found the cause of the problem I am having with R-patched. In my
> > > .Rprofile I have a function that loads a bunch of my own functions,
> > > one
> > > of which contains the character "(R)". No other version of R I have used
> > > since writing this function ~2 yrs. ago has had a problem reading in
> > > this
> > > character, but apparently R-patched does (invalid multibyte character
> > > in
> > > mbcs_get_next at line 17).
> > >
> >
> > That is a parser error message.
> >
> >  Has something intentional or unintentional
> > > occured to cause this? I suspect unintentional since this would seem
> > > to
> > > be a loss of functionalilty unlikely to be introduced in a patch of a
> > > release.
> > >
> > > Anyway, that's the issue, R-patched doesn't like "(R)".
> > >
> >
> > I get
> >
> >  "(R)"
> > >
> > [1] "(R)"
> >
> > in R-patched in UTF-8.
> >
> >
> > > Mark
> > >
> > >
> > > On Sat, May 3, 2008 at 4:20 PM, Prof Brian Ripley <
> > > [EMAIL PROTECTED]>
> > > wrote:
> > >  On Sat, 3 May 2008, Mark Kimpel wrote:
> > >
> > >Just installed the latest R-patched and get the
> > >error seen at the end of the
> > >output below. Don't know what to make of this but
> > >thought I should report
> > >it.
> > >
> > >
> > > Nor do we.  You have something incorrect in your startup files, but
> > > we don't have those.
> > >
> > >  In general, when installing the latest version of R,
> > >  should one use
> > >  R-latest or R-patched? R-latest is stable, but one
> > >  would assume that
> > >  R-patched includes the latest bug fixes.
> > >
> > >
> > > And you terminolgy is from where?  (Not e.g. the R FAQ.)
> > >
> > > Mark
> > >
> > > mkimpel-m90 ~/R_HOME/R-patched/R-build/bin: ./R
> > >
> > > R version 2.7.0 Patched (2008-05-02 r45591)
> > > Copyright (C) 2008 The R Foundation for Statistical Computing
> > > ISBN 3-900051-07-0
> > >
> > > R is free software and comes with ABSOLUTELY NO WARRANTY.
> > > You are welcome to redistribute it under certain conditions.
> > > Type 'license()' or 'licence()' for distribution details.
> > >
> > >  Natural language support but running in an English locale
> > >
> > > R is a collaborative project with many contributors.
> > > Type 'contributors()' for more information and
> > > 'citation()' on how to cite R or R packages in publications.
> > >
> > > Type 'demo()' for some demos, 'help()' for on-line help, or
> > > 'help.start()' for an HTML browser

Re: [Rd] error with R-patched (2008-05-02 r45591)

[Mark Kimpel]

You're correct, bad form on my part. In reality, I did it in two steps as
you suggested, just condensed for purposes of a brief communication. mark

On Mon, May 5, 2008 at 1:52 AM, Peter Dalgaard <[EMAIL PROTECTED]>
wrote:

> Mark Kimpel wrote:
>
> > Thanks guys. For the benefit of anyone following up on this in the
> > future, I
> > solved my problem in my offending file with:
> >
> > iconv -f LATIN1 -t UTF-8 methods.output.func.R >> methods.output.func.R
> >
> > Mark
> >
> >
> That line triggers a knee-jerk reflex with me (possibly unfairly since it
> apparently did the job). I have always learned that using the same file for
> input and output is asking for trouble: if something goes wrong on the way,
> you end with neither of them. I'd do
>
> iconv -f LATIN1 -t UTF-8 methods.output.func.R > 
> mv  methods.output.func.R
>
>
>
>
> --
>  O__   Peter Dalgaard Øster Farimagsgade 5, Entr.B
>  c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
> (*) \(*) -- University of Copenhagen   Denmark  Ph:  (+45) 35327918
> ~~ - ([EMAIL PROTECTED])  FAX: (+45) 35327907
>
>
>


-- 
Mark W. Kimpel MD ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield, IN 46074

(317) 490-5129 Work, & Mobile & VoiceMail
(317) 663-0513 Home (no voice mail please)

**

[[alternative HTML version deleted]]

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

[Rd] problem building R packages on RHEL 4 Linux with Intel compilers

[Mark Kimpel]

I would like to build R and packages with the Intel 10.1 compilers in RHEL4.
Using the flags below, I can successfully build R using a vanilla
./configure, but when I install new packages they build with gcc. My
sysadmin suggested adding the flags to ./configure as illustrated below, but
then the R build blows up with the config tail output that follows far
below. It looks like gcc is still being searched for. I did read the R
install and admin manual but could not find an answer. Help?

CC=icc
CFLAGS="-fast -unroll"
F77=ifort
FLAGS="-fast -unroll"
CXX=icpc
CXXFLAGS="-fast -unroll"
FC=ifort
FCFLAGS="-fast -unroll"
LDFLAGS="-L$ICC_LIBS -L$IFC_LIBS -L/usr/local/lib64"
SHLIB_CXXLD=icpc
../configure --prefix=/N/u/mkimpel/Quarry/R_HOME/R-patched/R-build\
CC=icc CFLAGS="-fast -unroll -wd188" F77=ifort FFLAGS="-fast -unroll" \
CXX=icpc CXXFLAGS="-fast -unroll" FC=ifort FCFLAGS="-fast -unroll" \
ICC_LIBS=/N/soft/linux-rhel4-x86_64/intel/cce/10.1.013/lib \
IFC_LIBS=/N/soft/linux-rhel4-x86_64/intel/fce/10.1.013/lib \
LDFLAGS="-L$ICC_LIBS -L$IFC_LIBS -L/usr/local/lib64" \
SHLIB_CXXLD=icpc; gmake; gmake install
###

checking for gcc... gcc
checking for C compiler default output file name...
configure: error: C compiler cannot create executables
See `config.log' for more details.


-- 
Mark W. Kimpel MD ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield, IN 46074

(317) 490-5129 Work, & Mobile & VoiceMail
(317) 663-0513 Home (no voice mail please)

**

[[alternative HTML version deleted]]

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

Re: [Rd] problem building R packages on RHEL 4 Linux with Intel compilers

[Mark Kimpel]

I am installing within my home folder, see the ./configure options. I've
never had a permission problem before and, like I said, if I don't put all
the Intel-specific flags in the ./configure, everything works fine.

On Thu, May 29, 2008 at 4:41 PM, Esmail Bonakdarian <[EMAIL PROTECTED]>
wrote:

> Mark Kimpel wrote:
>
>>
>> checking for gcc... gcc
>> checking for C compiler default output file name...
>> configure: error: C compiler cannot create executables
>> See `config.log' for more details.
>>
>
> Are you running this as root? Or do you have the right
> privileges for the install?
>
> The "cannot create executables" looks like a permission problem
>
> Esmail
>



-- 
Mark W. Kimpel MD ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield, IN 46074

(317) 490-5129 Work, & Mobile & VoiceMail
(317) 663-0513 Home (no voice mail please)

**

[[alternative HTML version deleted]]

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

Re: [Rd] problem building R packages on RHEL 4 Linux with Intel compilers

[Mark Kimpel]

Simon, I scanned the config.log, which is too voluminous to insert below,
but it seems that gcc is still being looked for as the compiler. See the
lines from config.log below. Mark

Thread model: posix
gcc version 3.4.6 20060404 (Red Hat 3.4.6-9)
configure:4824: $? = 0
configure:4831: gcc -V >&5
gcc: `-V' option must have argument
configure:4834: $? = 1
configure:4857: checking for C compiler default output file name
configure:4884: gcc -fast -unroll -wd188 -I/usr/local/include -L -L
-L/usr/local/lib64 conftest.c  >&5
gcc: unrecognized option `-wd188'
cc1: error: unrecognized command line option "-fast"
configure:4887: $? = 1
configure:4925: result:
configure: failed program was:
| /* confdefs.h.  */

# Then the tail end of config.log

r_cc_lo_rules_frag=''
r_cc_rules_frag=''
r_cxx_rules_frag=''
r_objc_rules_frag=''

## --- ##
## confdefs.h. ##
## --- ##

#define PACKAGE_NAME "R"
#define PACKAGE_TARNAME "R"
#define PACKAGE_VERSION "2.7.0"
#define PACKAGE_STRING "R 2.7.0"
#define PACKAGE_BUGREPORT "[EMAIL PROTECTED]"
#define PACKAGE "R"
#define VERSION "2.7.0"
#define R_PLATFORM "x86_64-unknown-linux-gnu"
#define R_CPU "x86_64"
#define R_VENDOR "unknown"
#define R_OS "linux-gnu"
#define Unix 1
#define R_ARCH ""

configure: exit 77


On Thu, May 29, 2008 at 5:35 PM, Simon Urbanek <[EMAIL PROTECTED]>
wrote:

>
> On May 29, 2008, at 5:01 PM, Mark Kimpel wrote:
>
>  I am installing within my home folder, see the ./configure options. I've
>> never had a permission problem before and, like I said, if I don't put all
>> the Intel-specific flags in the ./configure, everything works fine.
>>
>>
> This has nothing to do with the executable bit and/or permissions - this is
> about the compiler rejecting your flags. Have a look in config.log that's
> where you'll find out what the compiler didn't like (and the error clearly
> tells you that ;)).
>
> Cheers,
> Simon
>
>
>  On Thu, May 29, 2008 at 4:41 PM, Esmail Bonakdarian <[EMAIL PROTECTED]>
>> wrote:
>>
>>  Mark Kimpel wrote:
>>>
>>>
>>>> checking for gcc... gcc
>>>> checking for C compiler default output file name...
>>>> configure: error: C compiler cannot create executables
>>>> See `config.log' for more details.
>>>>
>>>>
>>> Are you running this as root? Or do you have the right
>>> privileges for the install?
>>>
>>> The "cannot create executables" looks like a permission problem
>>>
>>> Esmail
>>>
>>>
>>
>>
>> --
>> Mark W. Kimpel MD ** Neuroinformatics ** Dept. of Psychiatry
>> Indiana University School of Medicine
>>
>> 15032 Hunter Court, Westfield, IN 46074
>>
>> (317) 490-5129 Work, & Mobile & VoiceMail
>> (317) 663-0513 Home (no voice mail please)
>>
>> **
>>
>>[[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>>
>


-- 
Mark W. Kimpel MD ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield, IN 46074

(317) 490-5129 Work, & Mobile & VoiceMail
(317) 663-0513 Home (no voice mail please)

**

[[alternative HTML version deleted]]

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

Re: [Rd] problem building R packages on RHEL 4 Linux with Intel compilers

[Mark Kimpel]

Esmail and Simon, I would direct you to the very first sentence of my
original post, "I would like to build R and packages with the Intel 10.1
compilers in RHEL4." I DO NOT want to build with gcc, that is the very point
of this thread. Does anyone have an answer to my original question? I need
to know what flags to put with configure so that packages will be compiled
with Intel 10.1 when I do "install.packages" from within R.

Mark

On Thu, May 29, 2008 at 5:54 PM, Simon Urbanek <[EMAIL PROTECTED]>
wrote:

>
> On May 29, 2008, at 5:45 PM, Mark Kimpel wrote:
>
>  Simon, I scanned the config.log, which is too voluminous to insert below,
>> but it seems that gcc is still being looked for as the compiler. See the
>> lines from config.log below. Mark
>>
>> Thread model: posix
>> gcc version 3.4.6 20060404 (Red Hat 3.4.6-9)
>> configure:4824: $? = 0
>> configure:4831: gcc -V >&5
>> gcc: `-V' option must have argument
>> configure:4834: $? = 1
>> configure:4857: checking for C compiler default output file name
>> configure:4884: gcc -fast -unroll -wd188 -I/usr/local/include -L -L
>> -L/usr/local/lib64 conftest.c  >&5
>> gcc: unrecognized option `-wd188'
>> cc1: error: unrecognized command line option "-fast"
>>
>
> ^^ there you go: "-fast" is not supported by your gcc and "-wd188" is
> ignored (whatever you're trying achieve with that) ... it's there in plain
> english ;).
>
> Cheers,
> Simon
>
>
>
>
>> configure:4887: $? = 1
>> configure:4925: result:
>> configure: failed program was:
>> | /* confdefs.h.  */
>>
>> # Then the tail end of config.log
>>
>> r_cc_lo_rules_frag=''
>> r_cc_rules_frag=''
>> r_cxx_rules_frag=''
>> r_objc_rules_frag=''
>>
>> ## --- ##
>> ## confdefs.h. ##
>> ## --- ##
>>
>> #define PACKAGE_NAME "R"
>> #define PACKAGE_TARNAME "R"
>> #define PACKAGE_VERSION "2.7.0"
>> #define PACKAGE_STRING "R 2.7.0"
>> #define PACKAGE_BUGREPORT "[EMAIL PROTECTED]"
>> #define PACKAGE "R"
>> #define VERSION "2.7.0"
>> #define R_PLATFORM "x86_64-unknown-linux-gnu"
>> #define R_CPU "x86_64"
>> #define R_VENDOR "unknown"
>> #define R_OS "linux-gnu"
>> #define Unix 1
>> #define R_ARCH ""
>>
>> configure: exit 77
>>
>>
>> On Thu, May 29, 2008 at 5:35 PM, Simon Urbanek <
>> [EMAIL PROTECTED]> wrote:
>>
>> On May 29, 2008, at 5:01 PM, Mark Kimpel wrote:
>>
>> I am installing within my home folder, see the ./configure options. I've
>> never had a permission problem before and, like I said, if I don't put all
>> the Intel-specific flags in the ./configure, everything works fine.
>>
>>
>> This has nothing to do with the executable bit and/or permissions - this
>> is about the compiler rejecting your flags. Have a look in config.log that's
>> where you'll find out what the compiler didn't like (and the error clearly
>> tells you that ;)).
>>
>> Cheers,
>> Simon
>>
>>
>> On Thu, May 29, 2008 at 4:41 PM, Esmail Bonakdarian <[EMAIL PROTECTED]>
>> wrote:
>>
>> Mark Kimpel wrote:
>>
>>
>> checking for gcc... gcc
>> checking for C compiler default output file name...
>> configure: error: C compiler cannot create executables
>> See `config.log' for more details.
>>
>>
>> Are you running this as root? Or do you have the right
>> privileges for the install?
>>
>> The "cannot create executables" looks like a permission problem
>>
>> Esmail
>>
>>
>>
>>
>> --
>> Mark W. Kimpel MD ** Neuroinformatics ** Dept. of Psychiatry
>> Indiana University School of Medicine
>>
>> 15032 Hunter Court, Westfield, IN 46074
>>
>> (317) 490-5129 Work, & Mobile & VoiceMail
>> (317) 663-0513 Home (no voice mail please)
>>
>> **
>>
>>   [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>>
>>
>>
>>
>> --
>> Mark W. Kimpel MD ** Neuroinformatics ** Dept. of Psychiatry
>> Indiana University School of Medicine
>>
>> 15032 Hunter Court, Westfield, IN 46074
>>
>> (317) 490-5129 Work, & Mobile & VoiceMail
>> (317) 663-0513 Home (no voice mail please)
>>
>> **
>>
>
>


-- 
Mark W. Kimpel MD ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield, IN 46074

(317) 490-5129 Work, & Mobile & VoiceMail
(317) 663-0513 Home (no voice mail please)

**

[[alternative HTML version deleted]]

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

Re: [Rd] Re quest: Documentation of formulae

[Mark Difford]

Hi Mike,

>> I was at a loss to understand the use of "/" until I looked in "An
>> Introduction [!] to R," 
>> where I found the explanation.

I am not with you on the [!], because the information is basically where you
are "complaining" that it isn't, viz in your face --- i.e. in the
introductory document ---, but the operator surely deserves a mention in
?formula.  So on that score I agree with you.

Best, Mark.


Mike Prager wrote:
> 
> In working through material on p.272 of MASS (4th ed.), I came
> across the following model formula:
> 
> pet1.lm <- lm(Y ~ No/EP - 1, Petrol)
> 
> I was at a loss to understand the use of "/" until I looked in
> "An Introduction [!] to R," where I found the explanation. 
> 
> My request is that more complete material on model formulae be
> lifted from "Introduction to R" (or elsewhere) and put into the
> main online help files. There are other useful notations that
> may not be well known. Since formulae are not limited to any
> particular function, perhaps an entry could be made under
> "Formula".
> 
> More justification:
> 
> The help for "lm" does not explain this notation, nor did I find
> a cross-reference to anything useful there. The R Reference
> Manual seems to explain functions only. The R Language
> Definition has no index entry for "formula" or "model formulae".
> 
> Looking to print, neither the section on "model formula" on p.56
> of MASS nor the section surrounding the above example explains
> the notation, nor could I find it in Dalgaard's book, nor in
> Maindonald and Braun.  
> 
> This seems too nice a feature to keep hidden in plain sight.
> 
> -- 
> Mike Prager, NOAA, Beaufort, NC
> * Opinions expressed are personal and not represented otherwise.
> * Any use of tradenames does not constitute a NOAA endorsement.
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Request%3A-Documentation-of-formulae-tp17567491p17568035.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

[Rd] benchmarking R installations

[Mark Kimpel]

Recently I posted to this list with a question about using the Intel 10.1
compilers in building R and one response was basically, "why in the heck
would you want to do that?" The answer is that my sysadmin believes that
there will be a performance boost with the Intel vs. Gnu compilers on our
Linux cluster, of which I am one of many users. Wanting to be a good citizen
and use my machine time wisely, I'd of course like to use right tool to
build the most efficient installation of R and associated packages. BTW, we
got R to compile nicely using the settings at the end of this post.

Looking back on previous posts, however, it seems that there is no consensus
as to how to benchmark R. I realize such a task is not trivial, nor
controversial, but does anyone have a set of time-consuming tasks that can
be used to compare R installations? It would seem logical that such a
benchmark would include sub-benchmarks on file access, interpreted intensive
tasks, C intensive tasks, BLAS intensive tasks, etc. You developers know
more about this than I do, but I know enough to realize that there won't be
one simple answer. Nevertheless, I'd like to make my usage decisions on
something rather than anedotal claims.

So, does anyone know of a good benchmarking script or would be willing to
contribute one?

And here are the settings we used to compile R with Intel 10.1 compilers:

../configure --prefix=/N/u/mkimpel/R_HOME/R-patched/R-build \
--with-system-zlib=/usr/lib64 --with-system-bzlib=/usr/lib64 \
--with-mpi=/N/soft/linux-rhel4-x86_64/openmpi/1.2.5/intel-64 --with-tcltk \
--with-tcl-config=/N/soft/linux-rhel4-x86_64/tcl8.4.16/lib64/tclConfig.sh \
--with-tk-config=/N/soft/linux-rhel4-x86_64/tk8.4.16/lib64/tkConfig.sh \
--without-x --without-readline --without-iconv \
CC="/N/soft/linux-rhel4-x86_64/intel/cce/10.1.013/bin/icc" \
CFLAGS="-O3 -no-prec-div -unroll" \
F77="/N/soft/linux-rhel4-x86_64/intel/fce/10.1.013/bin/ifort" \
FFLAGS="-O3 -no-prec-div -unroll" \
CXX="/N/soft/linux-rhel4-x86_64/intel/cce/10.1.013/bin/icpc" \
CXXFLAGS="-O3 -no-prec-div -unroll" \
FC="/N/soft/linux-rhel4-x86_64/intel/fce/10.1.013/bin/ifort" \
FCFLAGS="-O3 -no-prec-div -unroll" \
OBJC="/N/soft/linux-rhel4-x86_64/intel/cce/10.1.013/bin/icc" \
OBJCFLAGS="-O3 -no-prec-div -unroll" \
--disable-R-profiling --disable-memory-profiling
##
make all
make install

Mark

-- 
Mark W. Kimpel MD ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield, IN 46074

(317) 490-5129 Work, & Mobile & VoiceMail
(317) 663-0513 Home (no voice mail please)

**

[[alternative HTML version deleted]]

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

[Rd] configure.args from install.packages passed on to subsequent update.packages?

[Mark Kimpel]

>From the help pages I see that there is a configure.args argument to
install.packages, and I am using that successfully. I do not see anything
similar for update.packages(). Does each package keep track of the
configure.args used to build in initially and pass this on to subsequent
updates or I am missing an argument to update.packages?

Thanks,
Mark

-- 
Mark W. Kimpel MD ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield, IN 46074

(317) 490-5129 Work, & Mobile & VoiceMail
(317) 663-0513 Home (no voice mail please)

**

[[alternative HTML version deleted]]

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

Re: [Rd] benchmarking R installations

[Mark Kimpel]

Dirk,

At the moment, our emphasis is getting an installation that will run Rmpi in
batch mode. I imagine my sysadmin put that line in to minimize potential
problems. To be honest, I didn't catch it, I was just glad to get a compile
:)

As to the line that doesn't apply to the R install, I think you are
referring to the "with mpi", which I think he also slipped in not realizing
it should more properly go with the Rmpi install.

Mark

On Tue, Jun 3, 2008 at 12:18 AM, Dirk Eddelbuettel <[EMAIL PROTECTED]> wrote:

> On Mon, Jun 02, 2008 at 11:56:16PM -0400, Mark Kimpel wrote:
> > ../configure --prefix=/N/u/mkimpel/R_HOME/R-patched/R-build \
> > --with-system-zlib=/usr/lib64 --with-system-bzlib=/usr/lib64 \
> > --with-mpi=/N/soft/linux-rhel4-x86_64/openmpi/1.2.5/intel-64 --with-tcltk
> \
>
> There is no such option for R's configure.
>
> > --with-tcl-config=/N/soft/linux-rhel4-x86_64/tcl8.4.16/lib64/tclConfig.sh
> \
> > --with-tk-config=/N/soft/linux-rhel4-x86_64/tk8.4.16/lib64/tkConfig.sh \
> > --without-x --without-readline --without-iconv \
>
> So you never want your compute cluster to be able to do an interactive
> plot under x11 ?
>
> Dirk
>
> --
> Three out of two people have difficulties with fractions.
>



-- 
Mark W. Kimpel MD  ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield, IN  46074

(317) 490-5129 Work, & Mobile & VoiceMail
(317) 663-0513 Home (no voice mail please)

**

[[alternative HTML version deleted]]

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

Re: [Rd] benchmarking R installations

[Mark Kimpel]

Dirk,

Thanks for the helpful reply. I agree with the concept of testing an app
that is commonly used. I suppose someone who uses R to interface alot with a
database could have a very differnt experience that one who uses it mostly
for matrix manupulations.

Still, as a scientist I like to have some empirical evidence as to why I am
doing  something, especially when it entails the extra headache of using a
compiler wiith which I am not familiar. As a non-computer-scientist,
however, I I wasn't sure the best way about finding the answer.

Mark

On Tue, Jun 3, 2008 at 11:16 AM, Dirk Eddelbuettel <[EMAIL PROTECTED]> wrote:

> On Tue, Jun 03, 2008 at 11:09:28AM -0400, Mark Kimpel wrote:
> > Dirk,
> >
> > At the moment, our emphasis is getting an installation that will run Rmpi
> in
> > batch mode. I imagine my sysadmin put that line in to minimize potential
> > problems. To be honest, I didn't catch it, I was just glad to get a
> compile
> > :)
> >
> > As to the line that doesn't apply to the R install, I think you are
> > referring to the "with mpi", which I think he also slipped in not
> realizing
> > it should more properly go with the Rmpi install.
>
> Right. I wasn't implying it would do harm.
>
> As for the x11 choice: I prefer to keep the change vectors
> minimal. Otherwise you go nuts trying to debug things.
>
> But it's good to see that you now understand that you have to start
> 'at the top' with Intel icc, and once you have a working R with you
> can start working towards packages.  It's like a port to a different
> platform as you completely switch the toolchain.
>
> Good luck and keep us posted. I have looking at icc on the TODO list
> too (for my C++ code, though, given R's interactive nature I think
> there are lower hanging fruits elsewhere...)
>
> Lastly, as to the benchmarking: It's difficult. Ripley once snarled
> that it is probably the application you want to run the most so
> there you go ...
>
> Dirk
>
> >
> > Mark
> >
> > On Tue, Jun 3, 2008 at 12:18 AM, Dirk Eddelbuettel <[EMAIL PROTECTED]>
> wrote:
> >
> > > On Mon, Jun 02, 2008 at 11:56:16PM -0400, Mark Kimpel wrote:
> > > > ../configure --prefix=/N/u/mkimpel/R_HOME/R-patched/R-build \
> > > > --with-system-zlib=/usr/lib64 --with-system-bzlib=/usr/lib64 \
> > > > --with-mpi=/N/soft/linux-rhel4-x86_64/openmpi/1.2.5/intel-64
> --with-tcltk
> > > \
> > >
> > > There is no such option for R's configure.
> > >
> > > >
> --with-tcl-config=/N/soft/linux-rhel4-x86_64/tcl8.4.16/lib64/tclConfig.sh
> > > \
> > > >
> --with-tk-config=/N/soft/linux-rhel4-x86_64/tk8.4.16/lib64/tkConfig.sh \
> > > > --without-x --without-readline --without-iconv \
> > >
> > > So you never want your compute cluster to be able to do an interactive
> > > plot under x11 ?
> > >
> > > Dirk
> > >
> > > --
> > > Three out of two people have difficulties with fractions.
> > >
> >
> >
> >
> > --
> > Mark W. Kimpel MD  ** Neuroinformatics ** Dept. of Psychiatry
> > Indiana University School of Medicine
> >
> > 15032 Hunter Court, Westfield, IN  46074
> >
> > (317) 490-5129 Work, & Mobile & VoiceMail
> > (317) 663-0513 Home (no voice mail please)
> >
> > **
>
> --
> Three out of two people have difficulties with fractions.
>



-- 
Mark W. Kimpel MD ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield, IN 46074

(317) 490-5129 Work, & Mobile & VoiceMail
(317) 663-0513 Home (no voice mail please)

**

[[alternative HTML version deleted]]

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

Re: [Rd] benchmarking R installations

[Mark Kimpel]

Thanks, once I get my new Intel installation running in tandem with a
gcc one, I'll report back. mark

On Tue, Jun 3, 2008 at 7:04 PM, Martin Maechler
<[EMAIL PROTECTED]> wrote:
>>>>>> "SU" == Simon Urbanek <[EMAIL PROTECTED]>
>>>>>> on Tue, 3 Jun 2008 11:52:14 -0400 writes:
>
>SU> On Jun 3, 2008, at 3:58 AM, Ludo Pagie wrote:
>
>>> recently there was a post on R-help/Rd ?? with this link
>>> on benchmarking different 'number crunching
>>> packages'. They used a series of tests, although I didn't
>>> check they used all the types you mentioned. I couldn't
>>> find test code at first glance but myyebe it is available
>>> on request???
>>>
>>> http://www.sciviews.org/benchmark/
>>>
>
>SU> It's quite outdated and doesn't work with the current R versions,
>
> Yes, that was the topic of the recent R-help post mentioned
> above.  And because of that I did post an updated version back to the
> list.
> Here's the posting, as found on http://search.r-project.org :
>http://finzi.psych.upenn.edu/R/Rhelp02a/archive/130270.html
> and the R script here
>   
> https://stat.ethz.ch/pipermail/r-help/attachments/20080514/0ccea72b/attachment.pl
>
>SU> but I have an updated version that works. I have put some
>SU> benchmarks I'm aware of at
>
>SU> http://r.research.att.com/benchmarks/
>
> That's cool!  Thanks, Simon!
> Martin
>
>>> On Mon, 2 Jun 2008, Mark Kimpel wrote:
>>>
>>>> Recently I posted to this list with a question about
>>>> using the Intel 10.1 compilers in building R and one
>>>> response was basically, "why in the heck would you want
>>>> to do that?" The answer is that my sysadmin believes
>>>> that there will be a performance boost with the Intel
>>>> vs. Gnu compilers on our Linux cluster, of which I am
>>>> one of many users. Wanting to be a good citizen and use
>>>> my machine time wisely, I'd of course like to use right
>>>> tool to build the most efficient installation of R and
>>>> associated packages.  BTW, we got R to compile nicely
>>>> using the settings at the end of this post.
>>>>
>>>> Looking back on previous posts, however, it seems that
>>>> there is no consensus as to how to benchmark R. I
>>>> realize such a task is not trivial, nor controversial,
>>>> but does anyone have a set of time-consuming tasks that
>>>> can be used to compare R installations? It would seem
>>>> logical that such a benchmark would include
>>>> sub-benchmarks on file access, interpreted intensive
>>>> tasks, C intensive tasks, BLAS intensive tasks, etc. You
>>>> developers know more about this than I do, but I know
>>>> enough to realize that there won't be one simple
>>>> answer. Nevertheless, I'd like to make my usage
>>>> decisions on something rather than anedotal claims.
>>>>
>>>> So, does anyone know of a good benchmarking script or
>>>> would be willing to contribute one?
>>>>
>>>> And here are the settings we used to compile R with
>>>> Intel 10.1 compilers:
>>>>
>>>> ../configure
>>>> --prefix=/N/u/mkimpel/R_HOME/R-patched/R-build \
>>>> --with-system-zlib=/usr/lib64
>>>> --with-system-bzlib=/usr/lib64 \
>>>> --with-mpi=/N/soft/linux-rhel4-x86_64/openmpi/1.2.5/intel-64
>>>> --with- tcltk \
>>>> --with-tcl-config=/N/soft/linux-rhel4-x86_64/tcl8.4.16/lib64/
>>>> tclConfig.sh \
>>>> --with-tk-config=/N/soft/linux-rhel4-x86_64/tk8.4.16/lib64/
>>>> tkConfig.sh \ --without-x --without-readline
>>>> --without-iconv \
>>>> CC="/N/soft/linux-rhel4-x86_64/intel/cce/10.1.013/bin/icc"
>>>> \ CFLAGS="-O3 -no-prec-div -unroll" \
>>>> F77="/N/soft/linux-rhel4-x86_64/intel/fce/10.1.013/bin/ifort"
>>>> \ FFLAGS="-O3 -no-prec-div -unroll" \
>>>> CXX="/N/soft/linux-rhel4-x86_64/intel/cce/10.1.013/bin/icpc"
>>>> \ CXXFLAGS="-O3 -no-prec-div -unroll" \
>>>> 

[Rd] Rmpi segfault after install on Ubuntu Hardy Heron

[Mark Kimpel]

I just installed Rmpi on my 64-bit Ubuntu Hardy Heron OS and using the
following without errors:
"R CMD INSTALL Rmpi_0.5-5.tar.gz --configure-args=--with-mpi=/usr/lib64/openmpi"

Immediately at library(Rmpi) I get the segfault displayed in my
complete output below. My first thought is that perhaps I used the
wrong library for openmpi, but with my 64 bit install it seemed like a
logical choice and the install went without a hitch.

Two other general comments:
1. Am I addressing this to the correct list or should I use R-help? As
I read the posting guide, I'm not sure.
2. Has anyone considered an R-SIG-HPC list? Anyone besides me interested?

Mark


R version 2.7.0 Patched (2008-05-18 r45728)
Copyright (C) 2008 The R Foundation for Statistical Computing
ISBN 3-900051-07-0

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

Loading required package: datasets
Loading required package: utils
Loading required package: grDevices
Loading required package: graphics
Loading required package: stats
Loading required package: graph
[1] "packages do not need updated"
> options(STERM='iESS', editor='emacsclient')
> library("Rmpi")

 *** caught segfault ***
address 0x2104008, cause 'memory not mapped'

Traceback:
 1: .Call("mpi_initialize", PACKAGE = "Rmpi")
 2: f(libname, pkgname)
 3: firstlib(which.lib.loc, package)
 4: doTryCatch(return(expr), name, parentenv, handler)
 5: tryCatchOne(expr, names, parentenv, handlers[[1]])
 6: tryCatchList(expr, classes, parentenv, handlers)
 7: tryCatch(expr, error = function(e) {call <- conditionCall(e)
 if (!is.null(call)) {if (identical(call[[1]],
quote(doTryCatch))) call <- sys.call(-4)dcall <-
deparse(call)[1]prefix <- paste("Error in", dcall, ": ")
 LONG <- 75msg <- conditionMessage(e)sm <-
strsplit(msg, "\n")[[1]]if (14 + nchar(dcall, type = "w") +
nchar(sm[1], type = "w") > LONG) prefix <-
paste(prefix, "\n  ", sep = "")}else prefix <- "Error : "
msg <- paste(prefix, conditionMessage(e), "\n", sep = "")
.Internal(seterrmessage(msg[1]))if (!silent &&
identical(getOption("show.error.messages"), TRUE)) {
cat(msg, file = stderr()).Internal(printDeferredWarnings())
}invisible(structure(msg, class = "try-error"))})
 8: try(firstlib(which.lib.loc, package))
 9: library("Rmpi")

Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection:

-- 
Mark W. Kimpel MD ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield, IN 46074

(317) 490-5129 Work, & Mobile & VoiceMail
(317) 663-0513 Home (no voice mail please)

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

Re: [Rd] Rmpi segfault after install on Ubuntu Hardy Heron

[Mark Kimpel]

Dirk,

Configure concluded without errors. I am not running this on the HPC
cluster with icc, rather a separate local box used for testing and
learning. Its just an 64-bit Ubuntu 8.04 install on a 4-core machine.
LAM is not installed (I checked to make sure).

So, that leaves me with you last two options. Before I make my first
foray into using the R-debugger, I'd like to try you suggestion to
"Check ldd on Rmpi.so" but don't have a clue how to do so. Could you
instruct me?

Thanks to all for the helpful comments.
Mark

On Wed, Jun 11, 2008 at 8:22 AM, Dirk Eddelbuettel <[EMAIL PROTECTED]> wrote:
>
> On 11 June 2008 at 00:46, Mark Kimpel wrote:
> | I just installed Rmpi on my 64-bit Ubuntu Hardy Heron OS and using the
> | following without errors:
> | "R CMD INSTALL Rmpi_0.5-5.tar.gz 
> --configure-args=--with-mpi=/usr/lib64/openmpi"
>
> And it concluded without warnings or errors? Configure found all the right 
> files?
>
> As Paul suggested, make sure you're not getting it mixed with
> exisiting LAM headers or MPICH2 headers or, say, that you're getting your gcc
> and icc experiemenst mixed up or ...  ?
>
> I control this by locally re-building the Debian packages for Open MPI. That
> way I only keep one -dev package for MPI and can ensure that I do not get
> mixups with other MPI installation. But then I do buy into the Package
> Management mantra, but not everybody does...
>
> | Immediately at library(Rmpi) I get the segfault displayed in my
> | complete output below. My first thought is that perhaps I used the
> | wrong library for openmpi, but with my 64 bit install it seemed like a
> | logical choice and the install went without a hitch.
>
> Check ldd on Rmpi.so to ensure that you linked against what you thought you
> should link against.
>
> And if everything else fails, debug the compiled code and run R under the
> debuggger.  See the 'R Extensions' manual.
>
> | Two other general comments:
> | 1. Am I addressing this to the correct list or should I use R-help? As
> | I read the posting guide, I'm not sure.
> | 2. Has anyone considered an R-SIG-HPC list? Anyone besides me interested?
>
> I'd join.
>
> Dirk
>
> --
> Three out of two people have difficulties with fractions.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Mark W. Kimpel MD ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield, IN 46074

(317) 490-5129 Work, & Mobile & VoiceMail
(317) 663-0513 Home (no voice mail please)

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

Re: [Rd] Rmpi segfault after install on Ubuntu Hardy Heron

[Mark Kimpel]

Dirk,

Did R CMD ldd $R_HOME/library/Rmpi/libs/Rmpi.so as suggested and
things looked okay. Not really wanting to mess with the debugger I
decided to use your prepackaged version. I completely uninstalled all
openmpi packages on my system using Synaptic and deleted my compiled
from source Rmpi from my site-library. Then I executed "sudo apt-get
install r-cran-rmpi" and things seemed to go smoothly. I put a soft
link from the library aptitude installed Rmpi into to my
~/R_HOME/site-library. I get exactly the same error as before. Does
the minimal debugging info below "options(error = recover) provide any
insight?  Mark

> require(Rmpi)
Loading required package: Rmpi

 *** caught segfault ***
address 0x2224008, cause 'memory not mapped'

Traceback:
 1: .Call("mpi_initialize", PACKAGE = "Rmpi")
 2: f(libname, pkgname)
 3: firstlib(which.lib.loc, package)
 4: doTryCatch(return(expr), name, parentenv, handler)
 5: tryCatchOne(expr, names, parentenv, handlers[[1]])
 6: tryCatchList(expr, classes, parentenv, handlers)
 7: tryCatch(expr, error = function(e) {call <- conditionCall(e)
 if (!is.null(call)) {if (identical(call[[1]],
quote(doTryCatch))) call <- sys.call(-4)dcall <-
deparse(call)[1]prefix <- paste("Error in", dcall, ": ")
 LONG <- 75msg <- conditionMessage(e)sm <-
strsplit(msg, "\n")[[1]]if (14 + nchar(dcall, type = "w") +
nchar(sm[1], type = "w") > LONG) prefix <-
paste(prefix, "\n  ", sep = "")}else prefix <- "Error : "
msg <- paste(prefix, conditionMessage(e), "\n", sep = "")
.Internal(seterrmessage(msg[1]))if (!silent &&
identical(getOption("show.error.messages"), TRUE)) {
cat(msg, file = stderr()).Internal(printDeferredWarnings())
}invisible(structure(msg, class = "try-error"))})
 8: try(firstlib(which.lib.loc, package))
 9: library(package, lib.loc = lib.loc, character.only = TRUE,
logical.return = TRUE, warn.conflicts = warn.conflicts,
keep.source = keep.source, version = version)
10: require(Rmpi)

Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 2
Save workspace image? [y/n/c]: n
[EMAIL PROTECTED]:~/R_HOME/site-library-2.7.0/Rmpi$ R

R version 2.7.0 Patched (2008-05-18 r45728)

#stuff deleted for brevity
__

> sessionInfo()
R version 2.7.0 Patched (2008-05-18 r45728)
x86_64-unknown-linux-gnu

locale:
LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C

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

other attached packages:
[1] graph_1.18.1

loaded via a namespace (and not attached):
[1] cluster_1.11.10 tools_2.7.0



Mark W. Kimpel MD ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield, IN 46074

(317) 490-5129 Work, & Mobile & VoiceMail
(317) 663-0513 Home (no voice mail please)

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

[Rd] RBGL not compiling on Debian Lenny with c++ (Debian 4.3.1-2) 4.3.1

[Mark Kimpel]

I've just installed Debian Lenny and RBGL fails compilation with the
following errors (sessionInfo() follows).

* Installing *source* package 'RBGL' ...
untarring boost include tree...
** libs
g++ -I/home/mkimpel/R_HOME/R-patched/R-build/lib64/R/include
-I/usr/local/include   -IboostIncl  -fpic  -g -O2 -c bbc.cpp -o bbc.o
In file included from /usr/include/c++/4.3/ext/hash_set:64,
 from boostIncl/boost/graph/adjacency_list.hpp:22,
 from RBGL.hpp:26,
 from bbc.cpp:1:
/usr/include/c++/4.3/backward/backward_warning.h:32:2: warning:
#warning This file includes at least one deprecated or antiquated
header which may be removed without further notice at a future date.
Please use a non-deprecated interface with equivalent functionality
instead. For a listing of replacement headers and interfaces, consult
the file backward_warning.h. To disable this warning use
-Wno-deprecated.
In file included from boostIncl/boost/graph/dijkstra_shortest_paths.hpp:19,
 from boostIncl/boost/graph/betweenness_centrality.hpp:14,
 from bbc.cpp:2:
boostIncl/boost/pending/relaxed_heap.hpp: In member function 'size_t
boost::relaxed_heap::log_base_2(size_t)':
boostIncl/boost/pending/relaxed_heap.hpp:101: error: 'CHAR_BIT' was
not declared in this scope
make: *** [bbc.o] Error 1

> sessionInfo()
R version 2.7.1 Patched (2008-06-26 r45997)
x86_64-unknown-linux-gnu

locale:
LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C

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

other attached packages:
[1] graph_1.18.1

loaded via a namespace (and not attached):
[1] cluster_1.11.11 tcltk_2.7.1 tools_2.7.1

-- 
Mark W. Kimpel MD ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield, IN 46074

(317) 490-5129 Work, & Mobile & VoiceMail
(317) 663-0513 Home (no voice mail please)

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

Re: [Rd] matching predictors and dummies

[Mark Difford]

Hi Jeroen,

>> How could i use the model$terms to extract which coefficients belong to
>> which factor, 
>> the way anova() does it?

There may be a simpler ("canned") way to do it, but why don't you debug
anova.lm to see how it does it?

##
methods("anova")
anova.lm

HTH, Mark.


Jeroen Ooms wrote:
> 
> 
> Charles C. Berry wrote:
>> 
>> See
>>  ?terms
>>  ?terms.object
>> 
>> 
>> 
> 
> I am sorry but i cannot figure out how i can find out which coefficients
> belong to which predictors using the model$terms. If i do
> attributes(model$terms) i get a nice list which contains the orriginal
> factors and some more information, and from model$xlevels i can see the
> levels of these factors. However, it does not say anywhere which of the
> model$coefficients belong to which factor. The only thing i can imagine is
> assuming that the dummy names are simply the concatenation of the factor
> name and the level name, which seems to be the default behavior. But
> preferebly i would not want to make my program rely on this assumption.
> How could i use the model$terms to extract which coefficients belong to
> which factor, the way anova() does it?
> 
> 

-- 
View this message in context: 
http://www.nabble.com/matching-predictors-and-dummies-tp18405023p18416554.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

[Rd] Parameter names in nls()

[Mark Payne]

Dear R-dev,

I have been having some problems with regards to names in the parameter
vector being stripped when passed to the objective function when using
nls(). I was relieved to find that it wasn't me, and that this behaviour has
previously been reported in optim() also. See eg
https://stat.ethz.ch/pipermail/r-devel/2006-March/036710.html
The solution at that time was to make a change so that vector passed into
the objective function was named (eg see following two discussions).

The problem that I am having is virtually identical, but is occuring with
nls() instead of optim(). To illustrate the problem, I have put together the
following example code (see bottom). Basically, it is doing a linear least
squares by hand, but it also displays the names associated on the parameters
vector - if you run it, you will see that the names are there for the first
few function evaluations, but after the first "step", the names are dropped.

I was wondering if I could please ask for a similar fix as that applied to
optim() to be carried across to nls() also?

Many thanks,

Mark


#Setup environment
rm(list=ls())
counter <- 1

#Objective function for nls
fitting.fn <-function(x,params) {
  #The model - so that it works
  y <- params[1] + x*params[2]
  #Referring to the parameters this way stops working after the first "step"
#  y <- params["a"] + x*params["b"]

  #Display information about function eval and parameter names
  cat(paste("Evaluation # :",counter,"\t Names :"))
  print(names(params))
  counter <<- counter +1
  return(y)
}

#Synthetic data
data.x <- 1:50
data.y <- pi*data.x + rnorm(50,sd=20)

#Fit objective function
ips <-  c(a=0,b=0)
nls("data.y~fitting.fn(data.x,params)",data=data.frame(data.x,data.y),
  start=list(params=ips),trace=TRUE,control=nls.control(tol=1e-8))

[[alternative HTML version deleted]]

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

[Rd] error in help page of function interpSpline of package splines in R-devel

[Mark Kimpel]

Unless I am misreading something, I believe there is an error in the
help page of function interpSpline of package splines in R-devel.

The function prototype reads:
 interpSpline(obj1, obj2, bSpline = FALSE, period = NULL, na.action = na.fail)

whereas in the Arguments section, under na.action, the text reads "The
default action ('na.omit') is to omit any incomplete observations. "
Based on today's experience, I believe the function prototype is
correct and the text description should be amended.

Mark

--
Mark W. Kimpel MD ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield, IN 46074

(317) 490-5129 Work, & Mobile & VoiceMail
(317) 663-0513 Home (no voice mail please)

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

[Rd] specifying compiler path in configure

[Mark Kimpel]

I'm having trouble building some packages while running Debian Lenny
(testing) and suspect that the issues are related to the default use
of gcc-4.3.  With Lenny, build-essentials depends on 4.3, so I'd like
to leave it installed but have also installed 4.2.1. How do I tell
./configure the path to 4.2.1 ? I"m sure it's an option, but I don't
see it documented in the R-admin manual.

Mark

-- 
Mark W. Kimpel MD ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield, IN 46074

(317) 490-5129 Work, & Mobile & VoiceMail
(317) 663-0513 Home (no voice mail please)

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

Re: [Rd] specifying compiler path in configure

[Mark Kimpel]

After reading over the relevant sections of the manual more carefully,
I now see where the information is presented and I was able to get R
to compile with an alternate version of gcc. On thing, however,
remains unclear to me. If R is compiled with a non-default version of
a compiler, are subsequent add-on packages and updated automatically
directed to use the alternate or is it necessary to include this
information in 'install.packages' and 'update.packages'? If the
latter, then it is unclear to me how this is accomplished. Below is my
best attempt at putting this instruction into install.packages and it
failed to produce the intended result, with gcc-4.3 being used instead
of 4.2.

 install.packages("affxparser", repos=repos,configure.args =
c('CC=/usr/bin/gcc-4.2', 'CXX=/usr/bin/g++-4.2'))

Thanks, Mark

On Wed, Aug 27, 2008 at 4:38 PM, Prof Brian Ripley
<[EMAIL PROTECTED]> wrote:
> On Wed, 27 Aug 2008, Mark Kimpel wrote:
>
>> I'm having trouble building some packages while running Debian Lenny
>> (testing) and suspect that the issues are related to the default use
>> of gcc-4.3.
>
> You might want to compare your problems with the CRAN checks at
>
> http://cran.r-project.org/web/checks/check_summary.html
>
> as those are run with gcc 4.3.x on Debian testing.  From memory, the
> problems are confined to C++-(mis)using packages.
>
>> With Lenny, build-essentials depends on 4.3, so I'd like
>> to leave it installed but have also installed 4.2.1. How do I tell
>> ./configure the path to 4.2.1 ? I"m sure it's an option, but I don't
>> see it documented in the R-admin manual.
>
> From configure --help:
>
>  CC  C compiler command
>  CFLAGS  C compiler flags
>
> There are many examples of setting CC in the R-admin manual, and the first
> para of 'Essential Programs' seems to me to tell you that as well.
>
> --
> Brian D. Ripley,  [EMAIL PROTECTED]
> Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel:  +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UKFax:  +44 1865 272595
>



-- 
Mark W. Kimpel MD ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield, IN 46074

(317) 490-5129 Work, & Mobile & VoiceMail
(317) 663-0513 Home (no voice mail please)

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

[Rd] splitting strings efficiently

[Mark Kimpel]

I have a very long list of strings. Each string actually contains multiple
values separated by a semi-colon. I need to turn each string into a vector
of the values delimited by the semi-colons. I know I can do this very
laboriously by using loops, nchar, and substr, but it is terribly slow. Is
there a basic R function that handles this situation? If not, is there
perhaps a faster way to do it than I currently am, which is to lapply the
following function? Thanks, Mark

###
string.tokenizer.func<-function(string, separator){
  new.vec<- NULL
  newString<- ""
  if(is.null(string)) {new.vec<-""} else {
for(i in 1:(nchar(string) + 1)){
  if(substr(string, i, i) == separator){
new.vec<-c(new.vec,newString)
newString <- ""
  } else {
newString<-paste(newString, substr(string, i, i), sep="")
  }
}
new.vec<-c(new.vec,newString)
  }
  new.vec
}
----
Mark W. Kimpel MD ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield, IN 46074

(317) 490-5129 Work, & Mobile & VoiceMail
(317) 399-1219 Home
Skype: mkimpel

**

[[alternative HTML version deleted]]

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

Re: [Rd] splitting strings efficiently

[Mark Kimpel]

I knew there HAD to be a basic function, but 'help.search("split string")'
and 'help("string") did not find it. Thanks for the help on this elementary
question.
Mark
----
Mark W. Kimpel MD ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine

15032 Hunter Court, Westfield, IN 46074

(317) 490-5129 Work, & Mobile & VoiceMail
(317) 399-1219 Home
Skype: mkimpel

**


On Wed, Sep 24, 2008 at 12:17 PM, Erik Iverson <[EMAIL PROTECTED]>wrote:

> ?strsplit
>
> Mark Kimpel wrote:
>
>> I have a very long list of strings. Each string actually contains multiple
>> values separated by a semi-colon. I need to turn each string into a vector
>> of the values delimited by the semi-colons. I know I can do this very
>> laboriously by using loops, nchar, and substr, but it is terribly slow. Is
>> there a basic R function that handles this situation? If not, is there
>> perhaps a faster way to do it than I currently am, which is to lapply the
>> following function? Thanks, Mark
>>
>>
>> ###
>> string.tokenizer.func<-function(string, separator){
>>  new.vec<- NULL
>>  newString<- ""
>>  if(is.null(string)) {new.vec<-""} else {
>>for(i in 1:(nchar(string) + 1)){
>>  if(substr(string, i, i) == separator){
>>new.vec<-c(new.vec,newString)
>>newString <- ""
>>  } else {
>>newString<-paste(newString, substr(string, i, i), sep="")
>>  }
>>}
>>new.vec<-c(new.vec,newString)
>>  }
>>  new.vec
>> }
>> 
>> Mark W. Kimpel MD ** Neuroinformatics ** Dept. of Psychiatry
>> Indiana University School of Medicine
>>
>> 15032 Hunter Court, Westfield, IN 46074
>>
>> (317) 490-5129 Work, & Mobile & VoiceMail
>> (317) 399-1219 Home
>> Skype: mkimpel
>>
>> **
>>
>>[[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
>

[[alternative HTML version deleted]]

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

Re: [Rd] RFC: Kerning, postscript() and pdf()

[Mark Difford]

 A huge thank you from me, too. Greg has said what should be said.

Every day I look at my PS and PDF output, think through the chain of effort
involved, from building the blocks to the packages that coordinate them, and
say WOW! R graphics just got better, with some fine decision making.

Regards, Mark.


Bálint Czúcz-4 wrote:
> 
> Dear Prof Ripley,
> 
> FWIW, kerning problems seem to affect even European character sets, e.g.:
> 
>> pdf(); plot(0,main="árvíztűrő tükörfúrógép"); dev.off()
> 
> in a clean session produces some misaligned characters in the
> resulting Rplots.pdf. [--> note the misplacements after the characters
> ő and ű (Hungarian long umlaut): intToUtf8(c(337L,369L)) ]
> 
> Otherwise I completely concur with Greg Snow, huge Thank You for
> keeping on improving the marvellous capabilities of R!
> 
> Best regrads,
> Bálint
> 
> --
>> sessionInfo()
> R version 2.6.2 (2008-02-08)
> i386-pc-mingw32
> 
> locale:
> LC_COLLATE=Hungarian_Hungary.1250;LC_CTYPE=Hungarian_Hungary.1250;LC_MONETARY=Hungarian_Hungary.1250;LC_NUMERIC=C;LC_TIME=Hungarian_Hungary.1250
> 
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
> 
> [* sorry for not using the most recent R version, I hope this is still
> helpful -- otherwise please ignore my comment...]
> 
> -- 
> Bálint Czúcz
> Institute of Ecology and Botany of the Hungarian Academy of Sciences
> H-2163 Vácrátót, Alkotmány u. 2-4. HUNGARY
> Tel: +36 28 360122/157  +36 70 7034692
> 
> 
> On Thu, Oct 16, 2008 at 5:56 PM, Greg Snow <[EMAIL PROTECTED]> wrote:
>> Prof. Ripley,
>>
>> I am sure I speak for many others when I say Thank You for this and all
>> the other great work that you do.  R is already capable of producing high
>> quality graphics, this will just make them better.  Kerning is one of
>> those things that generally don't get noticed unless done wrong/poorly,
>> so I expect in the future people will look at their graphs and know that
>> they look great, but not understand why, or the work that you put into
>> giving them that extra quality.  So I just wanted to take this chance to
>> say thank you (I/we probably don't say it enough).
>>
>> Also Thank You to the rest of R core for all the great work.
>>
>> R: Come for the price, Stay for the Quality
>>
>> --
>> Gregory (Greg) L. Snow Ph.D.
>> Statistical Data Center
>> Intermountain Healthcare
>> [EMAIL PROTECTED]
>> 801.408.8111
>>
>>
>>> -Original Message-
>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>>> project.org] On Behalf Of Prof Brian Ripley
>>> Sent: Thursday, October 16, 2008 3:03 AM
>>> To: R-devel@r-project.org
>>> Subject: Re: [Rd] RFC: Kerning, postscript() and pdf()
>>>
>>> I've now implemented B and C in R-devel, with C as the default.
>>>
>>> On Sun, 12 Oct 2008, Prof Brian Ripley wrote:
>>>
>>> > Ei-ji Nakama has pointed out (from another Japanese user, I believe)
>>> that
>>> > postscript() and pdf() have not been handling kerning correctly, and
>>> this is
>>> > a request for opinions about how we should correct it.
>>> >
>>> > Kerning is the adjustment of the spacing between letters from their
>>> natural
>>> > width, so that for example 'Yo' is usually typeset with the o closer
>>> to the Y
>>> > than 'Yl' would be.  Kerning is not very well standardized, so that
>>> for
>>> > example R's default Helvetica and its URW clone (Nimbus Sans) have
>>> quite
>>> > different ideas of the amount of kerning corrections for 'Yo'. This
>>> matters,
>>> > because not many people actually see Helvetica when viewing R's
>>> PostScript or
>>> > PDF output, but rather a similar face like Nimbus Sans or Arial, or
>>> in the
>>> > case of Acrobat Reader, a not very similar face.  Kerning is only a
>>> feature
>>> > of some proportionally spaced fonts and so not of Courier nor CJK
>>> fonts.
>>> >
>>> > The current position (R <= 2.8.0) is that string widths have been
>>> computing
>>> > using kerning from the Adobe Font Metric files for the nominal font,
>>> but the
>>> > strings have been displayed without using kerning (at least in the
>>> viewers we
>>> > are aware of, and the PostScript and PDF reference manuals mandate
>>> that
>>> &g

[Rd] implementation of NULL in vectors

[Mark Rosen]

All,

I was wondering if someone could point me to the location of the code in R
that supports NULL values in vectors. I'm curious as to how you implemented
them.

The only possible solution to me seems that for a double [], you need to
keep a parallel bool [] that tells you whether the value is null or not. The
bool [] doesn't have to be a literal bool [] -- you can keep a bit array.
Things like summing up a vector become complicated -- you need to check if
something is null before you perform an operation on it.

For the purposes of vectors of numeric data types, why not represent NULL as
NaN (as long as you're happy with the standard semantics of NaN)

Thanks.

[[alternative HTML version deleted]]

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

Re: [Rd] [R] Semantics of sequences in R

[Mark Difford]

...
My earlier email requires too much reading between the lines. This one puts
the finger more closely on the issues: There are historical inconsistencies
and there are design flaws. Naturally, there often is an overlap, but there
is also a clear area of excellence. These are largely different things and
they should not be so easily confused.

Regards, Mark.


Mark Difford wrote:
> 
> Dimitris Rizopoulos wrote:
> 
>>> in my opinion the point of the whole discussion could be summarized by
>>> the question, what 
>>> is a design flaw? This is totally subjective, and it happens almost
>>> everywhere in life. 
> 
> This [what constitutes a design flaw, and the suggestion that all design
> flaws are subjective] needs to be more carefully defined, and cannot, or
> should not, be allowed to fly untested. People do die from time to time
> because of design flaws. In recent times, two well-known car companies had
> serious design flaws that led to several deaths.
> 
> Needless to say [perhaps], design flaws in software can have serious
> consequences. So-called "design flaws" in a language are unlikely to. So
> there are some fundamental, and important, differences between them.
> Usually, respondents on this list are very careful not to confuse apples
> with birds, or to try to compare them.
> 
> Regards, Mark.
> 
> 
> Berwin A Turlach wrote:
>> On Tue, 24 Feb 2009 09:39:51 +0100
>> Wacek Kusnierczyk  wrote:
>> 
>>> Berwin A Turlach wrote:
>> 
>> [...]
>>> why not read some fortunes?
>> I am well aware of those fortunes and maybe you missed the one:
>> 
>>> fortune("Watson")
>> 
>> Getting flamed for asking dumb questions on a public mailing list is
>> all part of growing up and being a man/woman.
>>-- Michael Watson (in a discussion on whether answers on R-help
>>   should be more polite)
>>   R-help (December 2004)
>> 
>> I am actually wondering where the corresponding fortunes from December
>> 2005, December 2006, December 2007 and December 2009 are since they
>> started of be produced on an annual basis.
>> 
>> [...]
>>>>> on the other hand, i have seen quite a few responses that were
>>>>> bashing a user for reporting a non-existent bug or submitting an
>>>>> annoying patch.
>>>>> 
>>>> In didactic terms those are "negative motivations/reinforcements";
>>>> opinion differ on how effective they are to reach certain learning
>>>> outcomes.   
>>>>   
>>> ah, so what's the difference between the way i pinpoint design flaws
>>> and the way r gurus respond to people, so that i am running with a
>>> chip on my shoulder, and they are being 'negatively
>>> motivating/reinforcing' in didactic terms?  [...]
>> 
>> Your goal is, presumably, that you want to have the design flaws
>> fixed/discussed/&c.  The goal of the R gurus is to avoid having to
>> waste their time on unproductive issues because people do not read
>> documentation/behave contrary to how they are asked to behave/&c.
>> 
>> To reach your goal, the controversial approach is counter productive.
>> To reach their goal, the controversial approach can be quite effective.
> 
> in my opinion the point of the whole discussion could be summarized by 
> the question, what is a design flaw? This is totally subjective, and it 
> happens almost everywhere in life. Take human languages as an example 
> and in particular, English. I do not know the history of the English 
> language but I can guess at some point some people decided that the past 
> tense for "give" should be "gave" and not "gived" according to the 
> standard rule, possibly because they thought it has better acoustic.
> 
> Is this a design flaw of English? Some might argue yes, maybe they would 
> think "gived" does not have a that bad acoustic or they could have come 
> up with another possibility than "gave". Does this confuse new users of 
> English? Of course it does -- I had to spent many hours learning the 
> past tense and past particle of the irregular verbs. Should it be 
> changed? Then almost all existing code (i.e., English texts) should be 
> rewritten, which I think demonstrates why some people are a bit 
> reluctant in design changes.
> 
> To close I'd like to share with you a Greek saying (maybe also a saying 
> in other parts of the world) that goes, for every rule there is an 
> exception. The important thing, in my opinion, is that these exceptions 
> are documented.
> 

Re: [Rd] [R] Semantics of sequences in R

[Mark Difford]

Dimitris Rizopoulos wrote:

>> in my opinion the point of the whole discussion could be summarized by
>> the question, what 
>> is a design flaw? This is totally subjective, and it happens almost
>> everywhere in life. 

This [what constitutes a design flaw, and the suggestion that all design
flaws are subjective] needs to be more carefully defined, and cannot, or
should not, be allowed to fly untested. People do die from time to time
because of design flaws. In recent times, two well-known car companies had
serious design flaws that led to several deaths.

Needless to say [perhaps], design flaws in software can have serious
consequences. So-called "design flaws" in a language are unlikely to. So
there are some fundamental, and important, differences between them.
Usually, respondents on this list are very careful not to confuse apples
with birds, or to try to compare them.

Regards, Mark.


Berwin A Turlach wrote:
> On Tue, 24 Feb 2009 09:39:51 +0100
> Wacek Kusnierczyk  wrote:
> 
>> Berwin A Turlach wrote:
> 
> [...]
>> why not read some fortunes?
> I am well aware of those fortunes and maybe you missed the one:
> 
>> fortune("Watson")
> 
> Getting flamed for asking dumb questions on a public mailing list is
> all part of growing up and being a man/woman.
>-- Michael Watson (in a discussion on whether answers on R-help
>   should be more polite)
>   R-help (December 2004)
> 
> I am actually wondering where the corresponding fortunes from December
> 2005, December 2006, December 2007 and December 2009 are since they
> started of be produced on an annual basis.
> 
> [...]
>>>> on the other hand, i have seen quite a few responses that were
>>>> bashing a user for reporting a non-existent bug or submitting an
>>>> annoying patch.
>>>> 
>>> In didactic terms those are "negative motivations/reinforcements";
>>> opinion differ on how effective they are to reach certain learning
>>> outcomes.   
>>>   
>> ah, so what's the difference between the way i pinpoint design flaws
>> and the way r gurus respond to people, so that i am running with a
>> chip on my shoulder, and they are being 'negatively
>> motivating/reinforcing' in didactic terms?  [...]
> 
> Your goal is, presumably, that you want to have the design flaws
> fixed/discussed/&c.  The goal of the R gurus is to avoid having to
> waste their time on unproductive issues because people do not read
> documentation/behave contrary to how they are asked to behave/&c.
> 
> To reach your goal, the controversial approach is counter productive.
> To reach their goal, the controversial approach can be quite effective.

in my opinion the point of the whole discussion could be summarized by 
the question, what is a design flaw? This is totally subjective, and it 
happens almost everywhere in life. Take human languages as an example 
and in particular, English. I do not know the history of the English 
language but I can guess at some point some people decided that the past 
tense for "give" should be "gave" and not "gived" according to the 
standard rule, possibly because they thought it has better acoustic.

Is this a design flaw of English? Some might argue yes, maybe they would 
think "gived" does not have a that bad acoustic or they could have come 
up with another possibility than "gave". Does this confuse new users of 
English? Of course it does -- I had to spent many hours learning the 
past tense and past particle of the irregular verbs. Should it be 
changed? Then almost all existing code (i.e., English texts) should be 
rewritten, which I think demonstrates why some people are a bit 
reluctant in design changes.

To close I'd like to share with you a Greek saying (maybe also a saying 
in other parts of the world) that goes, for every rule there is an 
exception. The important thing, in my opinion, is that these exceptions 
are documented.

Best,
Dimitris


> [...]
>>>> it has been fixed immediately by martin. 
>>>> 
>>> Yes, and, again, you could not help yourself telling the developers
>>> what you think they should do, could you?  
>> was this really running with a chip:
> 
> Look up what "running with a chip on your shoulder means" and reflect
> on the occasions in which I suggested to you that you give the
> impression of doing so.   On this occasion nobody said that you were
> running around with a chip on your shoulder.
> 
>> "shouldn't the tests have captured it? i think you should have a check
>> for every feature following from the docs."
>>
>> to which marting responded "y

Re: [Rd] bug (PR#13570)

[Mark Difford]

Hi Uwe,

This is not a problem under Vista, using "a" development version (mine now
somewhat outdated).

Regards, Mark.

sessionInfo()
R version 2.9.0 Under development (unstable) (2009-01-22 r47686) 
i386-pc-mingw32 

locale:
LC_COLLATE=English_South Africa.1252;LC_CTYPE=English_South
Africa.1252;LC_MONETARY=English_South
Africa.1252;LC_NUMERIC=C;LC_TIME=English_South Africa.1252

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

other attached packages:
[1] ade4_1.4-10 Design_2.1-2survival_2.34-1 Hmisc_3.5-2

loaded via a namespace (and not attached):
[1] cluster_1.11.12gamlss_1.9-4   grid_2.9.0 lattice_0.17-20   
latticeExtra_0.5-4
[6] MASS_7.2-45tools_2.9.0 


Uwe Ligges-3 wrote:
> 
> Berwin A Turlach wrote:
>> G'day Peter,
>> 
>> On Thu, 05 Mar 2009 09:09:27 +0100
>> Peter Dalgaard  wrote:
>> 
>>> rha...@stat.purdue.edu wrote:
>>>> <>
>>>>
>>>> This is a CRITICAL bug!!!  I have verified it in R 2.8.1 for mac
>>>> and for windows.  The problem is with loess degree=0 smoothing.
>>>> For example, try the following:
>>>>
>>>> x <- 1:100
>>>> y <- rnorm(100)
>>>> plot(x, y)
>>>> lines(predict(loess(y ~ x, degree=0, span=0.5)))
>>>>
>>>> This is obviously wrong.
>>> Obvious? How? I don't see anything particularly odd (on Linux).
>> 
>> Neither did I on linux; but the OP mentioned mac and windows. 
>> 
>> On windows, on running that code, the lines() command added a lot of
>> vertical lines; most spanning the complete window but some only part.  
>> 
>> Executing the code a second time (or in steps) gave sensible
>> results.  
>> 
>> My guess would be that some memory is not correctly allocated or
>> initialised.  Or is it something like an object with storage mode
>> "integer" being passed to a double?  But then, why doesn't it show on
>> linux?
>> 
>> Happy bug hunting.  If my guess is correct, then I have no idea how to
>> track down such things under windows.
>> 
>> Cheers,
>> 
>>  Berwin
>> 
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> 
> Please can you folks try under R-devel (to be R-2.9.0 in a couple of 
> weeks) and report if you still see it. I do not under R-devel (but do 
> under R-release), so my guess is that something called by loess() has 
> been fixed in the meantime.
> 
> Moreover it is not the plot stuff that was wrong under R-2.8.1 (release) 
> but the loess computations.
> 
> Uwe Ligges
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> 

-- 
View this message in context: 
http://www.nabble.com/bug-%28PR-13570%29-tp22346406p22350779.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

[Rd] installed.packages and package info cache buglet (PR#13592)

[Mark . Bravington]

Looks like there is a buglet in 'installed.packages', around line 17:

for (lib in lib.loc) {
dest <- file.path(tempdir(), paste("libloc_", URLencode(lib,=20
TRUE), paste(fields, collapse =3D ","), ".rds", sep =3D ""))
if (!noCache && file.exists(dest) && file.info(dest)$mtime >=20
file.info(lib.loc)$mtime) {

  ^^^
 =20
The 'lib.loc' should be 'lib', otherwise the comparison is always against t=
he first library in 'lib.loc', not against the one being checked. [Normally=
 the multiple test in '>' would flag a warning from 'if', but the &&s mean =
that only the first element is used.]

I can't provide a reproducible example for this, because it's so installati=
on-dependent.

Still present in R-devel from 8th March.

Mark Bravington
CSIRO
Hobart
Australia

--please do not edit the information below--

Version:
 platform =3D i386-pc-mingw32
 arch =3D i386
 os =3D mingw32
 system =3D i386, mingw32
 status =3D Patched
 major =3D 2
 minor =3D 8.1
 year =3D 2009
 month =3D 02
 day =3D 12
 svn rev =3D 47919
 language =3D R
 version.string =3D R version 2.8.1 Patched (2009-02-12 r47919)

Windows XP (build 2600) Service Pack 2

Locale:
LC_COLLATE=3DEnglish_Australia.1252;LC_CTYPE=3DEnglish_Australia.1252;LC_MO=
NETARY=3DEnglish_Australia.1252;LC_NUMERIC=3DC;LC_TIME=3DEnglish_Australia.=
1252

Search Path:
 .GlobalEnv, package:grDevices, package:ad, package:chstuff, package:handy2=
, package:tweedie, package:statmod, package:handy, package:debug, package:m=
vbutils, mvb.session.info, package:tools, package:tcltk, package:boot, pack=
age:stats, package:graphics, package:utils, package:methods, Autoloads, pac=
kage:base

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

[Rd] Using TCP/IP sockets in R

[Mark Schultz]

Hi All:
  I've examined the R documentation on sockets and while I can probably
figure it out with a bit of experimentation, I wondered if anyone has
some sample code they could send me. I'd like to use R
as a statistics server to python clients. Is ist possible to have a
multithreaded server in R?
Thanks a lot,
Mark Schultz

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

[Rd] rbind with auto-row-named data.frame + list (PR#9346)

[Mark . Bravington]

There's a problem new to R2.4.0 when rbinding an auto-row-named
data.frame to a list:

> rbind( data.frame( x=1), list( x=2))
Error in attr(value, "row.names") <- rlabs : 
row names must be 'character' or 'integer', not 'double'

Works OK with 2 data.frames or 2 lists.

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

--please do not edit the information below--

Version:
 platform = i386-pc-mingw32
 arch = i386
 os = mingw32
 system = i386, mingw32
 status = 
 major = 2
 minor = 4.0
 year = 2006
 month = 10
 day = 03
 svn rev = 39566
 language = R
 version.string = R version 2.4.0 (2006-10-03)

Windows XP Professional (build 2600) Service Pack 2.0

Locale:
LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MON
ETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252

Search Path:
 .GlobalEnv, package:methods, package:stats, package:graphics,
package:grDevices, package:utils, package:datasets, Autoloads,
package:base

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

[Rd] xlsReadWrite Pro and embedding objects and files in Excel worksheets

[Mark W Kimpel]

Hans-Peter and other R developers,

How are you? Have you made any progess with embedding Url's in Excel?

Well, I have been busy thinking of more things for you to do;)

My colleagues in the lab are not R literate, and some are barely 
computer literate, so I give them everything in Excel workbooks. I have 
gradually evolved a system such that these workbooks have become 
compendia of my data, output, and methods. That, in fact, is why I 
bought the Pro version of xlsReadWritePro. I have been saving graphics 
as PDF files, then inserting them as object in Excel sheets.

What I would like to be able to do is to embed objects (files) in sheets 
of a workbook directly from within R. I would also like to be able to 
save my current R workspace as an object embedded in a sheet so that in 
the future, if packages change, I could go back and recreate the 
analysis. I do not need to be able to manuipulate files that R has not 
created, like a PDF file from another user. I would, however, like to be 
able to save my graphics as PDF files inside a worksheet, even if it 
meant creating a  temp file or something.

Before people begin talking about how MySQL or some other database could 
handle all that archiving, let me say that that is not what my 
colleagues want. They want a nice Excel file that they can take home on 
there laptops. One thing I like about worksheets is that they themselves 
can contain many embedded files, so it keeps our virtual desks neater 
and less confusing.

Hans, if you could do this, it would be of tremendous benefit to me and 
hopefully a lot of people. R developers tend to think that all 
scientists are running Linux on 64-bit computers, but most biomedical 
researches still store date in Excel files. This won't solve everybody's 
needs, but it could be a start.

Well, let me know what you think. I am cc'ing R-devel to see if any of 
those guys have ideas as well.

Thanks,
Mark



-- 
Mark W. Kimpel MD
Neuroinformatics
Department of Psychiatry
Indiana University School of Medicine

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

Re: [Rd] xlsReadWrite Pro and embedding objects and files in Excel worksheets

[Mark W Kimpel]

Thanks for the useful suggestions. I am not as CS savvy as some of you, 
so maybe Hans-Peter could reply? I haven't checked into it, but does his 
  package write to files that are OpenOffice compliant? Would that 
satisfy more users?

Mark

Hin-Tak Leung wrote:
> James W. MacDonald wrote:
>> Have you looked at RDCOMClient? I would imagine you could do what you 
>> want with this package.
>>
>> http://www.omegahat.org/RDCOMClient/
> 
> Interesting point. But the dcom client would be windows-specific?
> (those I mentioned - the perl mondules, openoffice, run on windows,
> as well as unix boxes - not sure about gnumeric :-).
> 
> In fact there is a very perverse way of doing it - ActiveState provides
> a PerlCom product for hooking up dcom with activestate perl. i.e. you 
> can go via R -> RDComClient -> PerlCom -> ActiveState Perl -> 
> SpreadSheet::* . Just so that it does not require Excel installed
> or an MS Office license...
> 
> In that sense, probably technology based on bridging over odbc
> is also acceptable?
> 
> HTL
> 
>> Hin-Tak Leung wrote:
>>> I don't know of any native xls read/write facility in R, either
>>> in core or as add-ons (I could be wrong), but if you want some source 
>>> code to scavenge on to build some R package out of it, there are two
>>> perl modules, Spreadsheet::ParseExcel and Spreadsheet::WriteExcel
>>> which are small enough to "read from front cover to back cover",
>>> so to speak, might be useful for reference and steal code from.
>>>
>>> The other open-source packages which can read/write excel files
>>> are gnumeric and openoffice and probably too big to find one's way 
>>> around the source code to steal there :-).
>>>
>>> Good luck.
>>>
>>> HTL
>>>
>>> Mark W Kimpel wrote:
>>>
>>>> Hans-Peter and other R developers,
>>>>
>>>> How are you? Have you made any progess with embedding Url's in Excel?
>>>>
>>>> Well, I have been busy thinking of more things for you to do;)
>>>>
>>>> My colleagues in the lab are not R literate, and some are barely 
>>>> computer literate, so I give them everything in Excel workbooks. I 
>>>> have gradually evolved a system such that these workbooks have 
>>>> become compendia of my data, output, and methods. That, in fact, is 
>>>> why I bought the Pro version of xlsReadWritePro. I have been saving 
>>>> graphics as PDF files, then inserting them as object in Excel sheets.
>>>>
>>>> What I would like to be able to do is to embed objects (files) in 
>>>> sheets of a workbook directly from within R. I would also like to be 
>>>> able to save my current R workspace as an object embedded in a sheet 
>>>> so that in the future, if packages change, I could go back and 
>>>> recreate the analysis. I do not need to be able to manuipulate files 
>>>> that R has not created, like a PDF file from another user. I would, 
>>>> however, like to be able to save my graphics as PDF files inside a 
>>>> worksheet, even if it meant creating a  temp file or something.
>>>>
>>>> Before people begin talking about how MySQL or some other database 
>>>> could handle all that archiving, let me say that that is not what my 
>>>> colleagues want. They want a nice Excel file that they can take home 
>>>> on there laptops. One thing I like about worksheets is that they 
>>>> themselves can contain many embedded files, so it keeps our virtual 
>>>> desks neater and less confusing.
>>>>
>>>> Hans, if you could do this, it would be of tremendous benefit to me 
>>>> and hopefully a lot of people. R developers tend to think that all 
>>>> scientists are running Linux on 64-bit computers, but most 
>>>> biomedical researches still store date in Excel files. This won't 
>>>> solve everybody's needs, but it could be a start.
>>>>
>>>> Well, let me know what you think. I am cc'ing R-devel to see if any 
>>>> of those guys have ideas as well.
>>>>
>>>> Thanks,
>>>> Mark
>>>>
>>>>
>>>>
>>>
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
> 
> 

-- 
Mark W. Kimpel MD
Neuroinformatics
Department of Psychiatry
Indiana University School of Medicine

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

Re: [Rd] xlsReadWrite Pro and embedding objects and files in Excel worksheets

[Mark W Kimpel]

Gabor,

What I want is a bit more than hyperlinks, although I did ask the 
package developer about that to. My idea is, from within R, place things 
like pdf files and .Rdata directly into an Excel spreadsheet. As a 
practical matter, if I can create a report with some data that someone 
else can manipulate as a "regular" spreadsheet (ex. sort gene lists) and 
then have other sheets that contain pdf output files of graphs I do 
within R. I would also like to archive my R workspace at time of 
analysis so that I could, if I had to, the analysis again. As I and 
others are constantly tweaking what functions do, it is sometimes 
impossible for me to go back and figure out what versions of what 
functions I was using. sessionInfo won't do what I want.

Since Hans-Peter came up with his really nice package, I thought I would 
throw this out as an idea. I have been doing this manually for some time 
  and my boss likes it because he only has to get one file from me, not 
10. I include worksheets with the values of parameters passed to 
functions, abbreviations, etc. Then 5 months from now and he wants me to 
explain the sheet to him, everything is in one place.

In a way, I want to treat an Excel spreadsheet as a list (the workbook) 
that can contain different kinds of objects (spreadsheets, pdfs, Rdata, 
ex.). The Excel file acts as a binder for these different files. My boss 
doesn't even want to deal with zipped files because when they are 
unzipped he ends up with tons of files.

I know this might not make a lot of sense to UNIX users who mostly 
interact with other programmers, but for those of us who deal with the 
computer-barely-literate biologists who run Windows, it could be a nice 
way of keeping things together.

BTW, I only mention Excel and Windows because that is what I use. I 
think it would be great to come up with a common format that Linux, Mac, 
and UNIX users could use. Could openOffice serve that purpose?

Thanks for your input.

Mark

Gabor Grothendieck wrote:
> Its not entirely clear to me what it is that you are looking
> for.  Maybe you want to create an Excel spreadsheet with a hyperlink
> to a web page?  This R code will do that.  It requires a Windows machine 
> that
> has Excel running on it.
> 
> 
> library(RDCOMClient)
> xl <- COMCreate("Excel.Application")
> xl[["Visible"]] <- TRUE
> wkbk <- xl$Workbooks()$Add()
> 
> sh <- xl$ActiveSheet()
> 
> B2R <- sh$Range("B3")
> B2R[["Formula"]] <- '=HYPERLINK("http://www.r-project.org";)'
> 
> wkbk$SaveAs("\\test-url.xls")
> xl$Quit()
> 
> 
> 
> 
> On 2/8/07, Mark W Kimpel <[EMAIL PROTECTED]> wrote:
>> Hans-Peter and other R developers,
>>
>> How are you? Have you made any progess with embedding Url's in Excel?
>>
>> Well, I have been busy thinking of more things for you to do;)
>>
>> My colleagues in the lab are not R literate, and some are barely
>> computer literate, so I give them everything in Excel workbooks. I have
>> gradually evolved a system such that these workbooks have become
>> compendia of my data, output, and methods. That, in fact, is why I
>> bought the Pro version of xlsReadWritePro. I have been saving graphics
>> as PDF files, then inserting them as object in Excel sheets.
>>
>> What I would like to be able to do is to embed objects (files) in sheets
>> of a workbook directly from within R. I would also like to be able to
>> save my current R workspace as an object embedded in a sheet so that in
>> the future, if packages change, I could go back and recreate the
>> analysis. I do not need to be able to manuipulate files that R has not
>> created, like a PDF file from another user. I would, however, like to be
>> able to save my graphics as PDF files inside a worksheet, even if it
>> meant creating a  temp file or something.
>>
>> Before people begin talking about how MySQL or some other database could
>> handle all that archiving, let me say that that is not what my
>> colleagues want. They want a nice Excel file that they can take home on
>> there laptops. One thing I like about worksheets is that they themselves
>> can contain many embedded files, so it keeps our virtual desks neater
>> and less confusing.
>>
>> Hans, if you could do this, it would be of tremendous benefit to me and
>> hopefully a lot of people. R developers tend to think that all
>> scientists are running Linux on 64-bit computers, but most biomedical
>> researches still store date in Excel files. This won't solve everybody's
>> needs, but it could be a start.
>>
>> Well, let me know what you think. I am cc'ing R-devel to see if any of

[Rd] append within worksheet in write.xls

[Mark W Kimpel]

I can currently append an entire worksheet with write.xls, but would 
also like to be able to append within the same worksheet. Is this 
possible? It doesn't seem to work if I use append = T

Thanks,
Mark


-- 
Mark W. Kimpel MD
Neuroinformatics
Department of Psychiatry
Indiana University School of Medicine

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

[Rd] newline with cell of Excel worksheet created with write.xls

[Mark W Kimpel]

As part of my project to put different types of results into worksheets, 
I would like to be able to put an auto-generated methods section. If I 
compose in RWinEdt, read into R, and use write.table with a .txt file 
extension, what I get out has line-breaks that correspond to those I put 
in in the first place.

If I do the same thing but write.xls with .xls extention, I get an Excel 
  worksheet with the entire paragraph on one line (row). It seems to me 
that Excel uses a special character for new-lines (new-rows). Is there a 
way that write.xls could convert \n to this special character?

I'm  writing lots of posts on this, but trying to break up the subjects 
to create better threads.

Mark

-- 
Mark W. Kimpel MD
Neuroinformatics
Department of Psychiatry
Indiana University School of Medicine

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