gmane.comp.lang.r.devel

Re: Cannot Install Custom Package On Windows7 64-bit

Steve Pederson — 2012-05-18T08:25:03

Thank you for the look with fresh eyes Uwe.

It was just the simple solution of opening a new command shell window. I
thought I'd tried that along with the multiple reboots, but it must have
been before I figured out the correct PATH settings.

And thanks for the CYGWIN reminder too. :)

All the best,

Steve

-----Original Message-----
From: Uwe Ligges [mailto:ligges< at >statistik.tu-dortmund.de] 
Sent: Friday, 18 May 2012 5:27 PM
To: stephen.pederson< at >adelaide.edu.au
Cc: r-devel< at >r-project.org
Subject: Re: [Rd] Cannot Install Custom Package On Windows7 64-bit



On 18.05.2012 08:55, Steve Pederson wrote:


1. Do what it says and

set CYGWIN=nodosfilewarning

to avoid lots of warnings.




2. So far your PATH look good, but it may be messed up later on, hence tell
us what

echo %PATH%

returns and be sure you started a new Windows command shell after changing
the PATH environment variable.

Best,
Uwe Ligges

Re: Cannot Install Custom Package On Windows7 64-bit

Uwe Ligges — 2012-05-18T07:57:19


On 18.05.2012 08:55, Steve Pederson wrote:


1. Do what it says and

set CYGWIN=nodosfilewarning

to avoid lots of warnings.




2. So far your PATH look good, but it may be messed up later on, hence 
tell us what

echo %PATH%

returns and be sure you started a new Windows command shell after 
changing the PATH environment variable.

Best,
Uwe Ligges

Cannot Install Custom Package On Windows7 64-bit

Steve Pederson — 2012-05-18T06:55:26

Hi,

 

After uninstalling Rtools 2.14.0, I have installed the latest version of
Rtools 2.15.0 which gives the two folders

C:\Rtools\bin

C:\Rtools\gcc-4.6.3

 

R is installed in the directory

C:\R\R-2.15.0

 

I have set the Environment Variable

PATH=c:\Rtools\bin;c:\Rtools\gcc-4.6.3\bin;c:\R\R-2.15.0\bin;<others>

 

I am trying to install a custom package (BMEA_0.2.1) which is exactly as
written & built successfully on R-2.14.0

 

When I use R CMD INSTALL BMEA_0.2.1.tar.gz, I get the following output

* installing to library 'C:/R/R-2.15.0/library'

* installing *source* package 'BMEA' ...

** libs

cygwin warning:

  MS-DOS style path detected: C:/R/R-2.15.0/etc/x64/Makeconf

  Preferred POSIX equivalent is: /cygdrive/c/R/R-2.15.0/etc/x64/Makeconf

  CYGWIN environment variable option "nodosfilewarning" turns off this
warning

  Consult the user's guide for more details about POSIX paths:

     http://cygwin.com/cygwin-ug-net/using.html#using-pathnames

gcc -m64 -I"C:/R/R-2.15.0/include" -DNDEBUG
-I

Re: r-devel fails tests for parallel

Simon Urbanek — 2012-05-17T22:14:24

On May 17, 2012, at 6:08 PM, Murray Stokely wrote:


The problem is that unfortunately clang is too incomplete for that -- it lacks Fortran and OpenMP support - both are quite important for R so migrating to clang is not realistic so far.

Cheers,
Simon

Re: r-devel fails tests for parallel

Murray Stokely — 2012-05-17T22:08:20

On Thu, May 17, 2012 at 8:09 AM, Prof Brian Ripley
<ripley< at >stats.ox.ac.uk> wrote:

I would also point out that clang has significantly better error
detection and diagnostics compared to current GCC.  Installations
stuck with old GCC releases for GPL3 reasons should really migrate to
clang / llvm.

                - Murray

Re: r-devel fails tests for parallel

Kasper Daniel Hansen — 2012-05-17T21:48:11

I am happy to report that R-devel (r59358) passes make check on my platform.

And sorry for the complete mixup today el4/el5 and 4.1.2 vs 4.2.1

Thanks,
Kasper

On Thu, May 17, 2012 at 11:09 AM, Prof Brian Ripley
<ripley< at >stats.ox.ac.uk> wrote:

Re: test suites for packages

Uwe Ligges — 2012-05-17T16:08:47


On 17.05.2012 17:56, Matthew Dowle wrote:

R always reports the whole diffs of the tests.

Uwe

Re: test suites for packages

Matthew Dowle — 2012-05-17T15:56:11

Not sure, but could it be that in some cases the output of test failures is 
there, but chopped off since CRAN displays the 13 line tail? At least that's 
what I've experienced, and reported, and asked to be increased in the past. 
Often the first error causes a cascade, so it's the head you need to see, not 
the tail. If I've got that right, how about a much larger limit than 13, say 
1000. Or the first 50 and last 50 lines of output.

Matthew

Re: r-devel fails tests for parallel

Prof Brian Ripley — 2012-05-17T15:09:16

But yours is 4.1.2 (Feb 2007).  Apple seems to have stuck at 4.2.1 for 
the GPL reason.


This is getting increasingly difficult.  GCC 4.6.x and 4.7.x detect a 
lot of errors (especially C++ errors) that earlier versions did not -- 
and that means CRAN gets a fair number of submissions that we cannot 
compile.  And there have been a lot of optimization advances since 4.1.x.

Re: test suites for packages

Uwe Ligges — 2012-05-17T14:59:13


On 17.05.2012 16:52, Brian G. Peterson wrote:


I am talking about the problem that relevant output of test failures 
that may help to identify the problem is frequently not shown in the 
output of R CMD check when such frameworks are used - that is a major 
nuisance for CRAN automatisms.

If additional configuration steps are required, fine, but then package 
maintainers seem to forget about that step. We do not have the time to 
tell hundreds of package maintainers how to configure their preferred 
test framework (whatever it is).

Best,
Uwe

Re: test suites for packages

Brian G. Peterson — 2012-05-17T14:52:53

Uwe:  I don't think that's completely fair.  RUnit and testthat tests
can be configured to be called from the R package tests directory, so
that they are run during R CMD check.

They don't *need* to be configured that way, so perhaps that's what
you're talking about.

Re: r-devel fails tests for parallel

Kasper Daniel Hansen — 2012-05-17T14:48:04

On Thu, May 17, 2012 at 9:04 AM, Prof Brian Ripley
<ripley< at >stats.ox.ac.uk> wrote:

Thanks a lot.

And I apologize for mixing up the red hat version.  I am using EL 5.4.

FInally, while GCC 4.2 is pretty old, it is still the newest release
under GPL 2.  And (more importantly to me), it is the system compiler
on our cluster.

Kasper

Re: test suites for packages

Uwe Ligges — 2012-05-17T14:32:34


On 17.05.2012 16:10, Whit Armstrong wrote:

Yes: R CMD check does the trick. See Writing R Extension and read about 
a package's test directory. I prefer frameworks that do not obfuscate 
failing test results on the CRAN check farm (as most other frameworks I 
have seen).

Best,
Uwe Ligges

test suites for packages

Whit Armstrong — 2012-05-17T14:10:34

Can anyone share some opinions on test suites for R packages?

I'm looking at testthat and RUnit. Does anyone have strong opinions on
either of those.

Any additional packages I should consider?

Thanks,
Whit

Re: r-devel fails tests for parallel

Prof Brian Ripley — 2012-05-17T13:04:08

Seems your ancient OS (that compiler has a 6-year-old copyright date) 
has a broken implementation of affinity with CPU_ZERO but not CPU_COUNT.

I've added some checks which should catch this.

On 17/05/2012 13:52, Kasper Daniel Hansen wrote:

Hmm, it says .el5: RHEL5 is ancient but RHEL4 is pre-historic!

r-devel fails tests for parallel

Kasper Daniel Hansen — 2012-05-17T12:52:10

I have been building R-devel daily for years.  In the last week or so,
R-devel has failed make check with the error in
  tests/Examples/parallel-Ex.R

The specific error is
Error in dyn.load(file, DLLpath = DLLpath, ...) :
  unable to load shared object
'/hpscc/usr/local/gcc-4.1.2/build/R/R-devel-build/library/parallel/libs/parallel.so':
  /hpscc/usr/local/gcc-4.1.2/build/R/R-devel-build/library/parallel/libs/parallel.so:
undefined symbol: CPU_COUNT
Error: package/namespace load failed for ‘parallel’
Execution halted

I am building on Red Hat Enterprise Linux version 4, using
# gcc --version
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

The specifics of the distro is
# cat /proc/version
Linux version 2.6.18-274.12.1.el5
(mockbuild< at >x86-001.build.bos.redhat.com) (gcc version 4.1.2 20080704
(Red Hat 4.1.2-51))

Re: Package does not have a NAMESPACE and should bere-installed

Uwe Ligges — 2012-05-17T12:42:51


On 16.05.2012 23:29, walcotteric wrote:

So easiest solution:
Upgrade to R-2.15.0 and install the package from its source version.

Uwe Ligges

Re: Passing externalptr to .C()

Prof Brian Ripley — 2012-05-17T12:37:25

Actually, 'Writing R Extensions' says:

  .. external pointers should only be used as part of an object with 
normal semantics, for example an attribute or an element of a list.

so that *is* the 'correct semantics' ....




As has been said here many times recently, .C is an old (some say 
obselete) interface, and pre-dates objects such as external pointers. 
It was chance that this ever worked: it was never designed to.

If you find yourself with C[++] code which uses Rinternals.h it should 
use the .Call/.External interfaces, and there is no guarantee that using 
.C for such things will continue to work (as it is all too easy to break 
R's copying semantics and corrupt loaded R code).

Re: Evaluation without the parent frame

Terry Therneau — 2012-05-17T12:27:55

Duncan,
   I agree completely with "don't use attach"; if I could get all the 
users of the survival package to agree as well the problem in question 
would go away :-)  I'm thinking about ways to add more effective error 
surveillance.
   Your suggestion was not horribly complex and I'll look into it 
further.  My first foray failed because what I want (I think) is the 
environment that they had when the first ">" came up.  I tried baseenv 
in a spot, but then my code couldn't find the model.frame function.

Terry T.



On 05/17/2012 05:00 AM, Duncan wrote:

Re: Passing externalptr to .C()

Rick Sayre — 2012-05-16T22:30:37

Thanks very much for the quick reply.

I'd like to avoid static state in the .so, which is why I'm using
the opaque pointer.  It is indeed possible to convert everything to
.Call(), but the work seems unnecessary given that it used to work
just fine and I am going out of my way to pass things with correct
type conversion and semantics.  Again, this seems like exactly the
usage externalptr was designed for, doesn't it?

It seems I can avoid the warnings by putting the externalptr in
a list:

getDeviceInfo<- function(handle) {
     .C("groovyDevice_getDeviceInfo", PACKAGE="groovyDevice",
list(handle),# Avoid pedantic warnings via encapsulation
status = as.integer(0))[-1] # skip handle
}

void
groovyDevice_getDeviceInfo(SEXP *handle, int *status)
{
     groovyHandle *gh = R_ExternalPtrAddr(*handle);
     *status = GroovyStatus(gh);
}

Perhaps this will help others in the same boat in which I find myself.

Cheers

--Rick

On 05/11/2012 03:34 PM, Duncan Murdoch wrote:

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

Prof Brian Ripley — 2012-05-17T11:12:06

I think you missed the following on the help page:

   loglik: the maximized log-likelihood.  Note that as all these models
           are non-stationary this includes a diffuse prior for some
           observations and hence is not comparable with ‘arima’ nor
           different types of structural models.

It is explicitly not valid for almost all model comparisons, and those 
few that are valid will use the differences of the quoted values.

Yes, it was an error, but the constant in log-likelihoods is always 
arbitrary and here there is even more indeterminancy.