Re: [Rd] 32 vs 64 bit difference?

[Terry Therneau]

Thank you both for the nice explanation.  I added "digits=4" to my
print statements to shorten the display.  
 Mixed effects Cox models can have difficult numerical issues, as it
turns out; I've added this to my collection of things to watch for.

Terry Therneau



On Sat, 2011-11-26 at 11:37 +, Prof Brian Ripley wrote:
> On 26/11/2011 09:23, peter dalgaard wrote:
> >
> > On Nov 26, 2011, at 05:20 , Terry Therneau wrote:
> >
> >> I've spent the last few hours baffled by a test suite inconsistency.
> >>
> >> The exact same library code gives slightly different answers on the home
> >> and work machines  - found in my R CMD check run.  I've recopied the entire
> >> directory to make sure it's really identical code.
> >>   The data set and fit in question has a pretty flat "top" to the 
> >> likelihood.
> >> I put print statements in to the "f()" function called by optim, and the
> >> two parameters and the likelihood track perfectly for 48 iterations, then
> >> start to drift ever so slightly:
> >> <  theta= -3.254176 -6.201119 ilik= -16.64806
> >>> theta= -3.254176 -6.201118 ilik= -16.64806
> >>
> >> And at the end of the iteration:
> >> <  theta= -3.207488 -8.583329 ilik= -16.70139
> >>> theta= -3.207488 -8.58 ilik= -16.70139
> >>
> >> As you can see, they get to the same max, but with just a slightly
> >> different path.
> >>
> >>   The work machine is running 64 bit Unix (CentOS) and the home one 32 bit
> >> Ubuntu.
> >> Could this be enough to cause the difference?  Most of my tests are
> >> based on all.equal, but I also print out 1 or 2 full solutions; perhaps
> >> I'll have to modify that?
> >
> > We do see quite a lot of that, yes; even running 32 and 64 bit builds on 
> > the same machine, an sometimes to the extent that an algorithm diverges on 
> > one architecture and diverges on the other (just peek over on R-sig-ME). 
> > The comparisons by "make check" on R itself also give off quite a bit of 
> > "last decimal chatter" when the architecture is switched. For some reason, 
> > OSX builds seem more consistent than Windows and Linux, although I have 
> > only anecdotal evidence of that.
> >
> > However, the basic point is that compilers don't define the sequence of FPU 
> > operations down to the last detail, an internal extended-precision register 
> > may or may not be used, the order of terms in a sum may be changed, etc. 
> > Since 64 bit code has different performance characteristics from 32 bit 
> > code (since you shift more data around for pointers), the FPU instructions 
> > may be differently optimized too.
> 
> However, the main difference is that all x86_64 chips have SSE2 
> registers, and so gcc makes use of them.  Not all i686 chips do, so 
> 32-bit builds on Linux and Windows only use the FPU registers.
> 
> This matters at ABI level: arguments get passed and values returned in 
> SSE registers: so we can't decide to only support later i686 cpus and 
> make use of SSE2 without re-compiling all the system libraries (but a 
> Linux distributor could).
> 
> And the FPU registers are 80-bit and use extended precision (the way we 
> set up Windows and on every Linux system I have seen): the SSE* 
> registers are 2x64-bit.
> 
> I believe that all Intel Macs are 'Core' or later and so do have SSE2, 
> although I don't know how much Apple relies on that.
> 
> (The reason I know that this is the 'main difference' is that you can 
> often turn off the use of SSE2 on x86_64 and reproduce the i686 results. 
>   But because of the ABI differences, you may get crashes: in R this 
> matters most often for complex numbers which are 128-bit C99 double 
> complex and passed around in an SSE register.)
> 
> >>
> >> Terry Therneau
> >>
> >> __
> >> R-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> 
>

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

[Rd] Avoid package in build process when not supported on OS

[Rau, Roland]

Dear all,

I am currently working on a package which involves some simulation where no 
current simulation run depends on a previous simulation run.
That is why I decided to parallelize the computation using the doMC package 
(which exists only for unix-like OS).

I can create a package without any R CMD check and R CMD build errors on my 
computers (Ubuntu Linux 32bit & 64 bit).

The problem that I have is: I would like to make the package 
platform-independent. In this case, this should not be difficult. A simple: 

if (!(.Platform$OS.type=="unix")) {
  
}

allows me to specify a different execution path on non unix-like operating 
systems (i.e. not using doMC-code, resulting in running the code not in 
parallel).

I just tried it out and uploaded the source package to 
http://win-builder.r-project.org/

Unfortunately, I get the following result:
[...]
* checking package dependencies ... ERROR
Package required but not available: 'doMC'
[...]

I interpret it as such: Even if the package will never be required (for a 
particular OS) the build process nevertheless checks whether the packages 
exists for the respective platform.
What would you suggest? Create two packages (mypackage vs. mypackageNONUNIX)? 
Release only for unix-like systems? ...?

Thank you in advance,
Roland



--
This mail has been sent through the MPI for Demographic ...{{dropped:10}}

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

Re: [Rd] Avoid package in build process when not supported on OS

[Henrik Bengtsson]

Move doMC from Requests: to Suggests: and load it in the code when
needed, e.g. library("doMC").

BTW, make sure you are aware of the new 'parallel' package that comes
with R v2.14.0.

/H

On Mon, Nov 28, 2011 at 7:39 AM, Rau, Roland  wrote:
> Dear all,
>
> I am currently working on a package which involves some simulation where no 
> current simulation run depends on a previous simulation run.
> That is why I decided to parallelize the computation using the doMC package 
> (which exists only for unix-like OS).
>
> I can create a package without any R CMD check and R CMD build errors on my 
> computers (Ubuntu Linux 32bit & 64 bit).
>
> The problem that I have is: I would like to make the package 
> platform-independent. In this case, this should not be difficult. A simple:
>
> if (!(.Platform$OS.type=="unix")) {
>  
> }
>
> allows me to specify a different execution path on non unix-like operating 
> systems (i.e. not using doMC-code, resulting in running the code not in 
> parallel).
>
> I just tried it out and uploaded the source package to 
> http://win-builder.r-project.org/
>
> Unfortunately, I get the following result:
> [...]
> * checking package dependencies ... ERROR
> Package required but not available: 'doMC'
> [...]
>
> I interpret it as such: Even if the package will never be required (for a 
> particular OS) the build process nevertheless checks whether the packages 
> exists for the respective platform.
> What would you suggest? Create two packages (mypackage vs. mypackageNONUNIX)? 
> Release only for unix-like systems? ...?
>
> Thank you in advance,
> Roland
>
>
>
> --
> This mail has been sent through the MPI for Demographic ...{{dropped:10}}
>
> __
> 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] Avoid package in build process when not supported on OS

[Rau, Roland]

Dear Henrik,
dear all,

thank you very much!

What you recommended works, see here: :-D

=
The files will be removed after roughly 72 hours.
Installation time in seconds: 9
Check time in seconds: 22
Check result: OK
R version 2.14.0 (2011-10-31)
=


And also thank you for pointing out the new package 'parallel'. Just started 
reading the vignette.

Thanks,
Roland



-Original Message-
From: henrik.bengts...@gmail.com on behalf of Henrik Bengtsson
Sent: Mon 11/28/2011 18:10
To: Rau, Roland
Cc: r-devel@r-project.org
Subject: Re: [Rd] Avoid package in build process when not supported on OS
 
Move doMC from Requests: to Suggests: and load it in the code when
needed, e.g. library("doMC").

BTW, make sure you are aware of the new 'parallel' package that comes
with R v2.14.0.

/H

On Mon, Nov 28, 2011 at 7:39 AM, Rau, Roland  wrote:
> Dear all,
>
> I am currently working on a package which involves some simulation where no 
> current simulation run depends on a previous simulation run.
> That is why I decided to parallelize the computation using the doMC package 
> (which exists only for unix-like OS).
>
> I can create a package without any R CMD check and R CMD build errors on my 
> computers (Ubuntu Linux 32bit & 64 bit).
>
> The problem that I have is: I would like to make the package 
> platform-independent. In this case, this should not be difficult. A simple:
>
> if (!(.Platform$OS.type=="unix")) {
>  
> }
>
> allows me to specify a different execution path on non unix-like operating 
> systems (i.e. not using doMC-code, resulting in running the code not in 
> parallel).
>
> I just tried it out and uploaded the source package to 
> http://win-builder.r-project.org/
>
> Unfortunately, I get the following result:
> [...]
> * checking package dependencies ... ERROR
> Package required but not available: 'doMC'
> [...]
>
> I interpret it as such: Even if the package will never be required (for a 
> particular OS) the build process nevertheless checks whether the packages 
> exists for the respective platform.
> What would you suggest? Create two packages (mypackage vs. mypackageNONUNIX)? 
> Release only for unix-like systems? ...?
>
> Thank you in advance,
> Roland
>
>
>
> --
> This mail has been sent through the MPI for Demographic ...{{dropped:10}}
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>


--
This mail has been sent through the MPI for Demographic ...{{dropped:10}}

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

[Rd] R CMD ?

[Henrik Bengtsson]

Hi,

is it possible to add a custom script such that it is called via R CMD
?  Is R CMD searching for it elsewhere than R_HOME/bin/?  I'm
looking for an non-admin alternative, so copying the script to
R_HOME/bin/ will not do (in case the user don't have enough permission
to write there).

/Henrik

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

Re: [Rd] R CMD ?

[Hadley Wickham]

It'd be cool if R CMD was user extensible through packages, so that (e.g.)

R CMD mypackage::mycommand

would do something like:

path <- system.file("cmd", paste(command, ".r"), package = package)
if (!file.exists(path)) {
  stop("Command ", command, " in ", package, " does not exist")
} else {
  source(path)
}

And maybe `R CMD mypackage` would look in mypackcage/cmd/default.r.

Hadley

On Mon, Nov 28, 2011 at 1:16 PM, Henrik Bengtsson  wrote:
> Hi,
>
> is it possible to add a custom script such that it is called via R CMD
> ?  Is R CMD searching for it elsewhere than R_HOME/bin/?  I'm
> looking for an non-admin alternative, so copying the script to
> R_HOME/bin/ will not do (in case the user don't have enough permission
> to write there).
>
> /Henrik
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



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

Re: [Rd] R CMD ?

[Yihui Xie]

I strongly support this proposal. This will be a fantastic feature!

Regards,
Yihui
--
Yihui Xie 
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA



On Mon, Nov 28, 2011 at 1:48 PM, Hadley Wickham  wrote:
> It'd be cool if R CMD was user extensible through packages, so that (e.g.)
>
> R CMD mypackage::mycommand
>
> would do something like:
>
> path <- system.file("cmd", paste(command, ".r"), package = package)
> if (!file.exists(path)) {
>  stop("Command ", command, " in ", package, " does not exist")
> } else {
>  source(path)
> }
>
> And maybe `R CMD mypackage` would look in mypackcage/cmd/default.r.
>
> Hadley
>
> On Mon, Nov 28, 2011 at 1:16 PM, Henrik Bengtsson  
> wrote:
>> Hi,
>>
>> is it possible to add a custom script such that it is called via R CMD
>> ?  Is R CMD searching for it elsewhere than R_HOME/bin/?  I'm
>> looking for an non-admin alternative, so copying the script to
>> R_HOME/bin/ will not do (in case the user don't have enough permission
>> to write there).
>>
>> /Henrik
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>
>
> --
> 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] R CMD ?

[Duncan Murdoch]

On 28/11/2011 2:16 PM, Henrik Bengtsson wrote:

Hi,

is it possible to add a custom script such that it is called via R CMD
?  Is R CMD searching for it elsewhere than R_HOME/bin/?  I'm
looking for an non-admin alternative, so copying the script to
R_HOME/bin/ will not do (in case the user don't have enough permission
to write there).


I don't remember if this is platform independent,  but

R CMD foo

on Windows will set up standard environment variables then try to 
execute "foo".  If "foo" isn't one of the internal commands listed by


R CMD --help

then it will just go looking for it like any other command in the path.  
(This is why "R CMD install" gives a funny error message:  the internal 
command is "INSTALL", so "R CMD install" just tries to execute "install".)


Duncan Murdoch

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

Re: [Rd] R CMD ?

[Duncan Murdoch]

On 28/11/2011 2:48 PM, Hadley Wickham wrote:

It'd be cool if R CMD was user extensible through packages, so that (e.g.)

R CMD mypackage::mycommand

would do something like:

path<- system.file("cmd", paste(command, ".r"), package = package)
if (!file.exists(path)) {
   stop("Command ", command, " in ", package, " does not exist")
} else {
   source(path)
}

And maybe `R CMD mypackage` would look in mypackcage/cmd/default.r.



That does seem to mix up namespaces quite a bit.  But what does it get 
you that "Rscript -e" doesn't already give you?  You can set up your 
package so that


R CMD mypackage::mycommand

executes a function, using delayedAssign or some of the more exotic 
features (like external pointers and finalizers).


Duncan Murdoch

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

Re: [Rd] R CMD ?

[Hadley Wickham]

> That does seem to mix up namespaces quite a bit.

That was just a proposal - equally

R CMD mypackage::mycommand

could just run

mypackage::mycommand()

but then passing argument might get a bit confusing.

> But what does it get you
> that "Rscript -e" doesn't already give you?  You can set up your package so
> that
>
> R CMD mypackage::mycommand
>
> executes a function, using delayedAssign or some of the more exotic features
> (like external pointers and finalizers).

Because you have to specify the path to that package?  R CMD roxygen2
is much easier to type, remember and is portable, compared to
~/R/roxygen2/something.r.  It also makes R CMD scripts extensible by
packages in a consistent manner.

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

Re: [Rd] R CMD ?

[William Dunlap]

The shell command
  R CMD something
currently acts as though it puts R_HOME/bin on the front
of PATH, looks for an executable file called 'something'
in PATH, and then executes it.  The executable may call R
or it may not.

I think that running an R script file is sufficiently different
from running an executable file that the operation should
not also be called 'CMD'.

Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com 

> -Original Message-
> From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On 
> Behalf Of Hadley Wickham
> Sent: Monday, November 28, 2011 11:49 AM
> To: Henrik Bengtsson
> Cc: R-devel
> Subject: Re: [Rd] R CMD ?
> 
> It'd be cool if R CMD was user extensible through packages, so that (e.g.)
> 
> R CMD mypackage::mycommand
> 
> would do something like:
> 
> path <- system.file("cmd", paste(command, ".r"), package = package)
> if (!file.exists(path)) {
>   stop("Command ", command, " in ", package, " does not exist")
> } else {
>   source(path)
> }
> 
> And maybe `R CMD mypackage` would look in mypackcage/cmd/default.r.
> 
> Hadley
> 
> On Mon, Nov 28, 2011 at 1:16 PM, Henrik Bengtsson  
> wrote:
> > Hi,
> >
> > is it possible to add a custom script such that it is called via R CMD
> > ?  Is R CMD searching for it elsewhere than R_HOME/bin/?  I'm
> > looking for an non-admin alternative, so copying the script to
> > R_HOME/bin/ will not do (in case the user don't have enough permission
> > to write there).
> >
> > /Henrik
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> 
> 
> 
> --
> 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] R CMD ?

[Hadley Wickham]

> The shell command
>  R CMD something
> currently acts as though it puts R_HOME/bin on the front
> of PATH, looks for an executable file called 'something'
> in PATH, and then executes it.  The executable may call R
> or it may not.
>
> I think that running an R script file is sufficiently different
> from running an executable file that the operation should
> not also be called 'CMD'.

Fair enough. But it would still be extremely useful to have an R
"command" which did run R scripts (which naively you would expect R
CMD to do do).  Maybe R SCRIPT ?

Or R CMD package::script could look for an arbitrary script and
execute it - I suspect this would be trickier cross-platform though.

One could also consider eliminating R CMD and the bin directory, given
that most of the scripts there now just call an R function.  Perhaps a
general syntax for calling R scripts in an package could subsume these
important scripts in a consistent and package-extensible manner.

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

Re: [Rd] R CMD ?

[Henrik Bengtsson]

On Mon, Nov 28, 2011 at 12:19 PM, Hadley Wickham  wrote:
>> That does seem to mix up namespaces quite a bit.
>
> That was just a proposal - equally
>
> R CMD mypackage::mycommand
>
> could just run
>
> mypackage::mycommand()
>
> but then passing argument might get a bit confusing.
>
>> But what does it get you
>> that "Rscript -e" doesn't already give you?  You can set up your package so
>> that
>>
>> R CMD mypackage::mycommand
>>
>> executes a function, using delayedAssign or some of the more exotic features
>> (like external pointers and finalizers).
>
> Because you have to specify the path to that package?  R CMD roxygen2
> is much easier to type, remember and is portable, compared to
> ~/R/roxygen2/something.r.  It also makes R CMD scripts extensible by
> packages in a consistent manner.

When people run R CMD build, R CMD INSTALL, R CMD check etc, they are
in a well defined working directory.  It can be assumed that R CMD
roxygen2 will be executed in the same directory.  As so as you enter
the R prompt, you cannot assume this working directory, and you have
to document/specify which directory the command should be executed on.
 Because of this, I favor an 'R CMD roxygen2' solution.

My use case/wish is to be able to provide 'R CMD Rdoc' (similar to 'R
CMD roxygen2') and 'R CMD rsp' (similar to 'R CMD Sweave').

/Henrik

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

[Rd] extend validObject to validate any object (shallow and deep validation)

[Hervé Pagès]

Hi,

It would be nice if there was a tool for checking the validity of any
object. validObject() is of course the natural candidate for this but
right now it doesn't work on S3 objects:

  df <- data.frame(aa=1:4, bb=letters[4:1])
  attributes(df)$row.names <- c("A", "B", "C", "A")

'df' is an invalid data frame instance:

  > df
  Error in data.frame(aa = c("1", "2", "3", "4"), bb = c("d", "c", "b",  :
duplicate row.names: A

However:

  > validObject(df)
  [1] TRUE
  > validObject(df, complete=TRUE)
  [1] TRUE

Also, here is another (typical) situation where it would be nice to be
able to (recursively) check the validity of the object:

  setClass("Collection", representation(things="list"))
  mycollection <- new("Collection", things=list(object1, object2, object3))

The problem is that 'validObject(mycollection, complete=TRUE)'
will return TRUE, even if one of the 3 objects stored in 'mycollection'
is invalid. I could implement my own validity method for Collection
objects but that's not a satisfactory solution because it would always
do a deep check (validity methods don't handle the 'complete' argument).

Would it make sense to modify validObject() so that, when called with
'complete=TRUE', it recursively validates the components of a list or
environment?

Thanks,
H.

--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fhcrc.org
Phone:  (206) 667-5791
Fax:(206) 667-1319

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

[Rd] Bug in Sys.which()?

[Dan Tenenbaum]

At a Windows command prompt:
C:\>which ls
/cygdrive/c/Rtools215/bin/ls

C:\>which perl
/cygdrive/c/perl/bin/perl

In R:
> Sys.which(c("ls", "perl"))
 lsperl
"c:\\RTOOLS~3\\bin\\ls.exe"  ""

Is this expected behavior?

> sessionInfo()
R Under development (unstable) (2011-10-28 r57459)
Platform: i386-pc-mingw32/i386 (32-bit)

locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

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

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


Thanks,
Dan

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

Re: [Rd] R CMD ?

[Duncan Murdoch]

On 11-11-28 3:19 PM, Hadley Wickham wrote:

That does seem to mix up namespaces quite a bit.


That was just a proposal - equally

R CMD mypackage::mycommand

could just run

mypackage::mycommand()

but then passing argument might get a bit confusing.


But what does it get you
that "Rscript -e" doesn't already give you?  You can set up your package so
that

R CMD mypackage::mycommand

executes a function, using delayedAssign or some of the more exotic features
(like external pointers and finalizers).


Because you have to specify the path to that package?


Sorry, I was in a rush and typed the wrong thing.  I meant to type

Rscript -e mypackage::mycommand

which needs no path.

R CMD roxygen2

is much easier to type, remember and is portable, compared to
~/R/roxygen2/something.r.  It also makes R CMD scripts extensible by
packages in a consistent manner.


"Easier to type" is not a good argument, since any reasonable command 
line shell would allow you to abbreviate whatever you wanted.  "rox" is 
easier to type than R CMD roxygen2, and is easy enough to make happen.


Duncan Murdoch





Hadley



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

Re: [Rd] Bug in Sys.which()?

[Duncan Murdoch]

On 11-11-28 5:20 PM, Dan Tenenbaum wrote:

At a Windows command prompt:
C:\>which ls
/cygdrive/c/Rtools215/bin/ls

C:\>which perl
/cygdrive/c/perl/bin/perl

In R:

Sys.which(c("ls", "perl"))

  lsperl
"c:\\RTOOLS~3\\bin\\ls.exe"  ""

Is this expected behavior?


R doesn't necessarily have the same search path as your command prompt. 
 (Look at PATH in your command line, and Sys.getenv("PATH") in R, to 
compare.) When I try Sys.which() that with two things known to be on the 
path that R uses, it finds both.


Duncan Murdoch




sessionInfo()

R Under development (unstable) (2011-10-28 r57459)
Platform: i386-pc-mingw32/i386 (32-bit)

locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

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

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


Thanks,
Dan

__
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] Bug in Sys.which()?

[Dan Tenenbaum]

On Mon, Nov 28, 2011 at 2:34 PM, Duncan Murdoch
 wrote:
> On 11-11-28 5:20 PM, Dan Tenenbaum wrote:
>>
>> At a Windows command prompt:
>> C:\>which ls
>> /cygdrive/c/Rtools215/bin/ls
>>
>> C:\>which perl
>> /cygdrive/c/perl/bin/perl
>>
>> In R:
>>>
>>> Sys.which(c("ls", "perl"))
>>
>>                          ls                        perl
>> "c:\\RTOOLS~3\\bin\\ls.exe"                          ""
>>
>> Is this expected behavior?
>
> R doesn't necessarily have the same search path as your command prompt.
>  (Look at PATH in your command line, and Sys.getenv("PATH") in R, to
> compare.) When I try Sys.which() that with two things known to be on the
> path that R uses, it finds both.

Thanks.
PEBKAC.

Dan

>
> Duncan Murdoch
>
>>
>>> sessionInfo()
>>
>> R Under development (unstable) (2011-10-28 r57459)
>> Platform: i386-pc-mingw32/i386 (32-bit)
>>
>> locale:
>> [1] LC_COLLATE=English_United States.1252
>> [2] LC_CTYPE=English_United States.1252
>> [3] LC_MONETARY=English_United States.1252
>> [4] LC_NUMERIC=C
>> [5] LC_TIME=English_United States.1252
>>
>> attached base packages:
>> [1] stats     graphics  grDevices utils     datasets  methods   base
>>
>> loaded via a namespace (and not attached):
>> [1] tools_2.15.0
>>
>>
>> Thanks,
>> Dan
>>
>> __
>> 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] Holding back on source code

[Dominick Samperi]

On Mon, Nov 28, 2011 at 2:17 AM, Prof Brian Ripley
 wrote:
> On 27/11/2011 23:07, Sachinthaka Abeywardana wrote:
>>
>> Hi All,
>>
>> A few years back when I was a CSIRO (an Australian research centre) intern
>> I developed a BLAS package for R that uses the GPU. I believe that there
>> is
>> something similar right now, except it uses a few CuBLAS (Nvidia BLAS)
>> routines, but doesnt replace them.
>
> We haven't much idea what 'something similar' refers to.
>
>> My question is, is it technically illegal to hold back on source code?
>
> It depends entirely on the licenses involved.  Nothing prevents Adobe
> distributing Acrobat without source code, for example.
>
> This is the R development list: questions not specific to R are best asked
> elsewhere (and, to take a recent example, that includes questions about
> licenses of packages on R-forge or CRAN).  'Elsewhere' may mean an IP
> lawyer.

One side-effect of R's GPL-based license is that there are many
Copyright holders
if you include members of the R core, R Foundation, R package
contributors, etc., and
any discussion (with an IP lawyer, say) about possible violation of
license terms would
require input from each of these groups.

Perhaps a new mailing list R-license-policy would be helpful...

Dominick

>> Thanks,
>> Sachin
>>
>>        [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
> --
> Brian D. Ripley,                  rip...@stats.ox.ac.uk
> Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
> University of Oxford,             Tel:  +44 1865 272861 (self)
> 1 South Parks Road,                     +44 1865 272866 (PA)
> Oxford OX1 3TG, UK                Fax:  +44 1865 272595
>
> __
> 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] Holding back on source code

[Sachinthaka Abeywardana]

I was referring specifically to gputools package:
http://cran.r-project.org/web/packages/gputools/index.html which has some
of Nvidias CuBLAS implemented.

What I want to do is release the code and implement the package, and not
get in trouble considering I was with CSIRO when I did it. I guess from all
this what I gather is if I recode it in a different way I should be able to
release it. From memory there were certainly GPL code elements within it.

Thanks for all the help.
Sachin

On Mon, Nov 28, 2011 at 6:17 PM, Prof Brian Ripley wrote:

> On 27/11/2011 23:07, Sachinthaka Abeywardana wrote:
>
>> Hi All,
>>
>> A few years back when I was a CSIRO (an Australian research centre) intern
>> I developed a BLAS package for R that uses the GPU. I believe that there
>> is
>> something similar right now, except it uses a few CuBLAS (Nvidia BLAS)
>> routines, but doesnt replace them.
>>
>
> We haven't much idea what 'something similar' refers to.
>
>
>  My question is, is it technically illegal to hold back on source code?
>>
>
> It depends entirely on the licenses involved.  Nothing prevents Adobe
> distributing Acrobat without source code, for example.
>
> This is the R development list: questions not specific to R are best asked
> elsewhere (and, to take a recent example, that includes questions about
> licenses of packages on R-forge or CRAN).  'Elsewhere' may mean an IP
> lawyer.
>
>
>  Thanks,
>> Sachin
>>
>>[[alternative HTML version deleted]]
>>
>> __**
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/**listinfo/r-devel
>>
>
>
> --
> Brian D. Ripley,  rip...@stats.ox.ac.uk
> Professor of Applied Statistics,  
> http://www.stats.ox.ac.uk/~**ripley/
> University of Oxford, Tel:  +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UKFax:  +44 1865 272595
>

[[alternative HTML version deleted]]

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

[Rd] Updated Windows toolchain

[Prof Brian Ripley]

An updated toolchain is now being used for Windows' builds of R-devel: 
details are in the R-admin manual and at

http://www.murdoch-sutherland.com/Rtools/ and
http://www.stats.ox.ac.uk/pub/Rtools/

Both 32- and 64-bit parts of the toolchain use v2.0.1 of the Mingw-w64 
project's runtime and a beta of gcc 4.5.4: the Mingw.org project's 
builds are no longer used.  This should mean that code which compiles 
for 64-bit Windows also compiles for 32-bit Windows, and v.v. unless 
code makes (incorrect but common) assumptions that pointers fit into 
longs.


A very few packages will need modifications because they contain 
declarations which clash with the headers in this toolchain: where we 
are aware of problems the maintainers have been informed.


At DLL level different Windows' toolchains should be compatible: at C 
level they mostly are but at C++ level they are pretty much 
incompatible (so that for example GDAL has to be re-compiled for every 
toolchain: and Rcpp users need to be careful to use only one toolchain 
for Rcpp and their packages).  All the external software previously 
made available (and more) is made available at 
http://www.stats.ox.ac.uk/pub/Rtools .


The toolchain has support for OpenMP and pthreads: however OpenMP 
support is not enabled by default in R (it is too slow to be much 
use).  If you do make use of it in your packages, be aware that you 
will need to ship the appropriate pthreads DLL(s).


It is expected that there will be several further minor updates prior 
to the release of 2.15.0 in ca 4 months, but this step is the major 
one.


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

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