[Rd] multiple defines of diag

[Terry Therneau]

The current coxme code has functions that depend on bdsmatrix and others
that depend on Matrix, both those pacakges define S4 methods for diag.
When loaded, the message appears:
   replacing previous import ‘diag’ when loading ‘Matrix’ 

Questions:
  1. Do I need to worry about this?  If so, what can I do about it?
I suppose I could add an importFrom directive, but it will be a pain
unless there is an "allbut(diag)" option I'm not aware of.  (I assume
that methods and classes can be listed in importFrom, i.e., there are no
importMethodsFrom or importClassesFrom functions).

  2. If I don't need to worry, is there a way to turn the message off?
I as a developer need to see it, but users don't and it may worry them
unnecessarily.  Updating all 17 of my test/*.Rout.save files is a
nuisance as well, but only a nuisance.

I'd like to upload this to CRAN soon as I have users asking for the
updated lmekin function (which uses Matrix).  In the long term all the
bdsmatrix functions will be replaced by Matrix, but that requires major
changes to C code so "long" is the operative word. 

Thanks,
  Terry T.

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

Re: [Rd] Question about Rweb

[Jay Emerson]

Ted,

Simon may be biased, but I am not.  I'm barely a few days into
Rserve/FastRWeb and am blown away (and frustrated that I didn't have a
good excuse to give it a try sooner).  I'm still in the process of
refining my setup (including a fresh installation of Apache2 on my
Ubuntu box), and have documented the steps, which attempt to
synthesize information from Simon's various docs and from my own
communications with him.

I will make these available, but if you drop me an email I'll send you
my current draft.  I can't wait to get beyond the obvious usage cases
into some of the more advanced functionality.

Jay

-- 
John W. Emerson (Jay)
Associate Professor of Statistics
Department of Statistics
Yale University
http://www.stat.yale.edu/~jay

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

Re: [Rd] multiple defines of diag

[Kasper Daniel Hansen]

Terry,

if you're using two packages that both define a diag function/method
you absolutely _have_ to resolve this using your NAMESPACE.  [Update:
I see both are methods.  I actually don't know what happens when you
have the same generic in both packages]

And yes, there is both an importClassesFrom and importMethodsFrom.

Since import() grabs everything you need to selectively import
functions/methods/classes from at least one of the two packages.  I
have been in the same situation, and it is painful to figure out all
the stuff you need from the package you selectively import.  A while
ago I suggested having something like
  importExcept
to selectively exclude specific functions when you have a name clash,
but I don't think anyone took up my suggestion.

Kasper

On Thu, Oct 6, 2011 at 8:06 AM, Terry Therneau  wrote:
> The current coxme code has functions that depend on bdsmatrix and others
> that depend on Matrix, both those pacakges define S4 methods for diag.
> When loaded, the message appears:
>   replacing previous import ‘diag’ when loading ‘Matrix’
>
> Questions:
>  1. Do I need to worry about this?  If so, what can I do about it?
> I suppose I could add an importFrom directive, but it will be a pain
> unless there is an "allbut(diag)" option I'm not aware of.  (I assume
> that methods and classes can be listed in importFrom, i.e., there are no
> importMethodsFrom or importClassesFrom functions).
>
>  2. If I don't need to worry, is there a way to turn the message off?
> I as a developer need to see it, but users don't and it may worry them
> unnecessarily.  Updating all 17 of my test/*.Rout.save files is a
> nuisance as well, but only a nuisance.
>
> I'd like to upload this to CRAN soon as I have users asking for the
> updated lmekin function (which uses Matrix).  In the long term all the
> bdsmatrix functions will be replaced by Matrix, but that requires major
> changes to C code so "long" is the operative word.
>
> Thanks,
>  Terry T.
>
> __
> 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] Question about Rweb

[Dirk Eddelbuettel]

On 6 October 2011 at 09:37, Jay Emerson wrote:
| Ted,
| 
| Simon may be biased, but I am not.  I'm barely a few days into
| Rserve/FastRWeb and am blown away (and frustrated that I didn't have a
| good excuse to give it a try sooner).  I'm still in the process of
| refining my setup (including a fresh installation of Apache2 on my
| Ubuntu box), and have documented the steps, which attempt to
| synthesize information from Simon's various docs and from my own
| communications with him.
| 
| I will make these available, but if you drop me an email I'll send you
| my current draft.  I can't wait to get beyond the obvious usage cases
| into some of the more advanced functionality.

I bite.  Given that I already package Rserve for Debian (and hence Ubuntu)
and may need something like FastRWeb (or Rapache) I should have a look.

Can you send me your stuff?  In a nutshell, why this and not Rapache (for
which Jeff Horner has a ppa on launchpad so it also works out of the box).

Dirk

-- 
New Rcpp master class for R and C++ integration is scheduled for 
San Francisco (Oct 8), more details / reg.info available at
http://www.revolutionanalytics.com/products/training/public/rcpp-master-class.php

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

Re: [Rd] Question about Rweb

[Dirk Eddelbuettel]

On 5 October 2011 at 21:54, Simon Urbanek wrote:
| Ubuntu is currently the most popular and works out of the box on most 
machines. Personally, I prefer Debian on servers, but there is not a big 
difference.


  Ubuntu also comes in at least four flavours: ubuntu (Gnome look), kubuntu
  (KDE), xubuntu (XFCE) and 'server'.  So it is easy to overlook the server
  product which is also excellent. If you install it, it start with just six
  or seven processes running -- perfect for customization on top of something
  truly barebones.

  And the end of the day it depends on what update cycle you want to
  subscribe too. The bi-annual Ubuntu releases are nice.  I also _really_
  like Debian testing which is like a rolling 'current/fresh/yet stable'
  release.  CRAN uses that for a few machines, and I can never remember if
  rforge and r-forge, respectively, are on stable or testing.

  I often use Ubuntu and just re-build whatever I need never versions of by
  rebuilding the packages locally in 'package building chroot' on
  Ubuntu. Best of both worlds for me.

  If there are follow-ups, they should probably go to r-sig-debian.


Best, Dirk

-- 
New Rcpp master class for R and C++ integration is scheduled for 
San Francisco (Oct 8), more details / reg.info available at
http://www.revolutionanalytics.com/products/training/public/rcpp-master-class.php

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

Re: [Rd] Question about Rweb

[Jay Emerson]

Simon or Jeff had best answer your latter query on
strengths/weaknesses of each model.  I could hazard a guess, but would
probably be wrong.  !-)  I can't send attachments here, so decided to
put the draft on my blog and will revise as needed.  Feedback welcome,
and I need to make it friendlier and provide more detail in places.
Apologies in advance for errors/omissions, etc... that are my own
fault, not Simon's.

http://jayemerson.blogspot.com/2011/10/setting-up-fastrwebrserve-on-ubuntu.html

On Thu, Oct 6, 2011 at 12:20 PM, Dirk Eddelbuettel  wrote:
>
> On 6 October 2011 at 09:37, Jay Emerson wrote:
> | Ted,
> |
> | Simon may be biased, but I am not.  I'm barely a few days into
> | Rserve/FastRWeb and am blown away (and frustrated that I didn't have a
> | good excuse to give it a try sooner).  I'm still in the process of
> | refining my setup (including a fresh installation of Apache2 on my
> | Ubuntu box), and have documented the steps, which attempt to
> | synthesize information from Simon's various docs and from my own
> | communications with him.
> |
> | I will make these available, but if you drop me an email I'll send you
> | my current draft.  I can't wait to get beyond the obvious usage cases
> | into some of the more advanced functionality.
>
> I bite.  Given that I already package Rserve for Debian (and hence Ubuntu)
> and may need something like FastRWeb (or Rapache) I should have a look.
>
> Can you send me your stuff?  In a nutshell, why this and not Rapache (for
> which Jeff Horner has a ppa on launchpad so it also works out of the box).
>
> Dirk
>
> --
> New Rcpp master class for R and C++ integration is scheduled for
> San Francisco (Oct 8), more details / reg.info available at
> http://www.revolutionanalytics.com/products/training/public/rcpp-master-class.php
>



-- 
John W. Emerson (Jay)
Associate Professor of Statistics
Department of Statistics
Yale University
http://www.stat.yale.edu/~jay

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

Re: [Rd] cbind() crashes on raw vectors

[Hervé Pagès]

On 11-09-25 01:06 PM, Simon Urbanek wrote:

Thanks, now fixed.


Thanks Simon,
H.


Simon


On Sep 23, 2011, at 4:46 PM, Hervé Pagès wrote:


Hi,

cbind() doesn't seem to like raw vectors:


df<- cbind(a=integer(4000), b=raw(4000))
df

*** glibc detected *** /home/hpages/R-2.13.1/bin/exec/R: malloc(): memory 
corruption: 0x02d73ca0 ***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x79d7a)[0x7f3592b91d7a]
/lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x6e)[0x7f3592b9431e]
/lib/libreadline.so.5(xmalloc+0x6)[0x7f3592620ab6]
/lib/libreadline.so.5(add_history+0xbe)[0x7f359262136e]
/home/hpages/R-2.13.1/lib/libR.so(+0x1b6538)[0x7f35936bd538]
/lib/libreadline.so.5(rl_callback_read_char+0x8c)[0x7f359261cb1c]
/home/hpages/R-2.13.1/lib/libR.so(+0x1b6f74)[0x7f35936bdf74]
/home/hpages/R-2.13.1/lib/libR.so(Rf_ReplIteration+0xe7)[0x7f3593610eb7]
/home/hpages/R-2.13.1/lib/libR.so(+0x10a260)[0x7f3593611260]
/home/hpages/R-2.13.1/lib/libR.so(run_Rmainloop+0x50)[0x7f3593611780]
/home/hpages/R-2.13.1/bin/exec/R(main+0x1b)[0x40085b]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xff)[0x7f3592b36eff]
/home/hpages/R-2.13.1/bin/exec/R[0x400779]
=== Memory map: 
0040-00401000 r-xp  08:01 3811201  /home/hpages/R-2.13.1/bin/exec/R
0060-00601000 r--p  08:01 3811201  /home/hpages/R-2.13.1/bin/exec/R
00601000-00602000 rw-p 1000 08:01 3811201  /home/hpages/R-2.13.1/bin/exec/R
02583000-03b16000 rw-p  00:00 0  [heap]
7f358c00-7f358c021000 rw-p  00:00 0
7f358c021000-7f359000 ---p  00:00 0
7f3590342000-7f3590357000 r-xp  08:06 8155  
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f3590357000-7f3590556000 ---p 00015000 08:06 8155  
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f3590556000-7f3590557000 r--p 00014000 08:06 8155  
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f3590557000-7f3590558000 rw-p 00015000 08:06 8155  
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f3590558000-7f35905c4000 r-xp  08:01 3818237  
/home/hpages/R-2.13.1/library/stats/libs/stats.so
7f35905c4000-7f35907c3000 ---p 0006c000 08:01 3818237  
/home/hpages/R-2.13.1/library/stats/libs/stats.so
7f35907c3000-7f35907c5000 r--p 0006b000 08:01 3818237  
/home/hpages/R-2.13.1/library/stats/libs/stats.so
7f35907c5000-7f35907c7000 rw-p 0006d000 08:01 3818237  
/home/hpages/R-2.13.1/library/stats/libs/stats.so
7f35907c7000-7f359083a000 rw-p  00:00 0
7f359083a000-7f359085c000 r-xp  08:01 3817784  
/home/hpages/R-2.13.1/library/grDevices/libs/grDevices.so
7f359085c000-7f3590a5b000 ---p 00022000 08:01 3817784  
/home/hpages/R-2.13.1/library/grDevices/libs/grDevices.so
7f3590a5b000-7f3590a5c000 r--p 00021000 08:01 3817784  
/home/hpages/R-2.13.1/library/grDevices/libs/grDevices.so
7f3590a5c000-7f3590a5d000 rw-p 00022000 08:01 3817784  
/home/hpages/R-2.13.1/library/grDevices/libs/grDevices.so
7f3590b61000-7f3590b63000 r-xp  08:07 671027  
/usr/lib/x86_64-linux-gnu/gconv/ISO8859-1.so
7f3590b63000-7f3590d62000 ---p 2000 08:07 671027  
/usr/lib/x86_64-linux-gnu/gconv/ISO8859-1.so
7f3590d62000-7f3590d63000 r--p 1000 08:07 671027  
/usr/lib/x86_64-linux-gnu/gconv/ISO8859-1.so
7f3590d63000-7f3590d64000 rw-p 2000 08:07 671027  
/usr/lib/x86_64-linux-gnu/gconv/ISO8859-1.so
7f3590d64000-7f3590de6000 rw-p  00:00 0
7f3590de6000-7f3590ded000 r-xp  08:01 3818288  
/home/hpages/R-2.13.1/library/methods/libs/methods.so
7f3590ded000-7f3590fec000 ---p 7000 08:01 3818288  
/home/hpages/R-2.13.1/library/methods/libs/methods.so
7f3590fec000-7f3590fed000 r--p 6000 08:01 3818288  
/home/hpages/R-2.13.1/library/methods/libs/methods.so
7f3590fed000-7f3590fee000 rw-p 7000 08:01 3818288  
/home/hpages/R-2.13.1/library/methods/libs/methods.so
7f3590fee000-7f3590ffa000 r-xp  08:06 8319  
/lib/x86_64-linux-gnu/libnss_files-2.13.so
7f3590ffa000-7f35911f9000 ---p c000 08:06 8319  
/lib/x86_64-linux-gnu/libnss_files-2.13.so
7f35911f9000-7f35911fa000 r--p b000 08:06 8319  
/lib/x86_64-linux-gnu/libnss_files-2.13.so
7f35911fa000-7f35911fb000 rw-p c000 08:06 8319  
/lib/x86_64-linux-gnu/libnss_files-2.13.so
7f35911fb000-7f3591206000 r-xp  08:06 8321  
/lib/x86_64-linux-gnu/libnss_nis-2.13.so
7f3591206000-7f3591405000 ---p b000 08:06 8321  
/lib/x86_64-linux-gnu/libnss_nis-2.13.so
7f3591405000-7f3591406000 r--p a000 08:06 8321  
/lib/x86_64-linux-gnu/libnss_nis-2.13.so
7f3591406000-7f3591407000 rw-p b000 08:06 8321  
/lib/x86_64-linux-gnu/libnss_nis-2.13.so
7f3591407000-7f359141e000 r-xp  08:06 8316  
/lib/x86_64-linux-gnu/libnsl-2.13.so
7f359141e000-7f359161d000 ---p 00017000 08:06 8316  
/lib/x86_64-linux-gnu/libnsl-2.13.so
7f359161d000-7f359161e000 r--p 00016000 08:06 8316  
/lib/x86_64-linux-gnu/libnsl-2.13.so
7f359161e000-7f359161f000 rw-p 00017000 08:06 8316  
/lib/x86_64-linux-gnu/libnsl-2.13.so
7f359161f000-7f3591621000 rw-p  00:00 0
7f3591621000-7f3591629000 r-xp  08:06 8317  
/lib/x86_64-linux-gnu/l

Re: [Rd] multiple defines of diag

[Terry Therneau]

On Thu, 2011-10-06 at 10:00 -0400, Kasper Daniel Hansen wrote:
> if you're using two packages that both define a diag function/method
> you absolutely _have_ to resolve this using your NAMESPACE.  [Update:
> I see both are methods.  I actually don't know what happens when you
> have the same generic in both packages]
> 

Your response made me look further, with some surprising results.

1. Sequential loading
tmt226% R --vanilla
R version 2.13.0 (2011-04-13)

> library(bdsmatrix)
> tmat <- bdsmatrix(c(3,2,2,4),
c(22,1,2,21,3,20,19,4,18,17,5,16,15,6,7, 8,14,9,10,13,11,12),
matrix(c(1,0,1,1,0,0,1,1,0,1,0,10,0, 
   0,1,1,0,1,1,0,1,1,0,1,0,10), ncol=2))
> tmat[1:7,1:7] [,1] [,2] [,3] [,4] [,5] [,6] [,7]
[1,]   22120000
[2,]1   2130000
[3,]23   200000
[4,]000   19400
[5,]0004   1800
[6,]00000   175> 

> diag(tmat)
 [1] 22 21 20 19 18 17 16 15 14 13 12 10 10

> library(Matrix)
Loading required package: lattice

Attaching package: 'Matrix'

The following object(s) are masked from 'package:base':

det

> diag(tmat)
 [1] 22 21 20 19 18 17 16 15 14 13 12 10 10

  Things to note: 
 in this case I did not get a message about overwriting the diag
method, 
 it works.  

This was not my experience with ranef(), an S3 generic that coxme, nlme,
and lme4 all define; there whichever library loaded last did not
discover existing methods.  That is, if one loaded nlme after coxme,
then ranef(a coxme object) would not dispatch ranef.coxme.  Our solution
(Doug Bates and I) was to have both coxme and lme4 import ranef and
fixef from the nlme library.
  However, per above it appears to work with S4 generics.
  Can I count on it though?

-

Case 2:

tmt229% R --vanilla
R version 2.13.0 (2011-04-13)

> library(coxme)
Loading required package: survival
Loading required package: splines
Loading required package: bdsmatrix
Loading required package: nlme
Loading required package: Matrix
Loading required package: lattice

Attaching package: 'Matrix'

The following object(s) are masked from 'package:base':

det

Warning message:
replacing previous import ‘diag’ when loading ‘Matrix’ 

> tmat <- bdsmatrix(c(3,2,2,4), 
  c(22,1,2,21,3,20,19,4,18,17,5,16,15,6,7,
8,14,9,10,13,11,12),
  matrix(c(1,0,1,1,0,0,1,1,0,1,0,10,0,
   0,1,1,0,1,1,0,1,1,0,1,0,10), ncol=2))
>diag(tmat)
 [1] 22 21 20 19 18 17 16 15 14 13 12 10 10


 Things to note:
 I now get a warning message about diag. Why only here?
 Per the earlier comment I'm not importing all of nlme, just the two
generics
 It still works

(This example isn't reproducable for others: the coxme library on CRAN
does not yet have a Matrix dependency.)

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

Re: [Rd] Question about Rweb

[Simon Urbanek]

On Oct 6, 2011, at 12:20 PM, Dirk Eddelbuettel wrote:

> 
> On 6 October 2011 at 09:37, Jay Emerson wrote:
> | Ted,
> | 
> | Simon may be biased, but I am not.  I'm barely a few days into
> | Rserve/FastRWeb and am blown away (and frustrated that I didn't have a
> | good excuse to give it a try sooner).  I'm still in the process of
> | refining my setup (including a fresh installation of Apache2 on my
> | Ubuntu box), and have documented the steps, which attempt to
> | synthesize information from Simon's various docs and from my own
> | communications with him.
> | 
> | I will make these available, but if you drop me an email I'll send you
> | my current draft.  I can't wait to get beyond the obvious usage cases
> | into some of the more advanced functionality.
> 
> I bite.  Given that I already package Rserve for Debian (and hence Ubuntu)
> and may need something like FastRWeb (or Rapache) I should have a look.
> 
> Can you send me your stuff?  In a nutshell, why this and not Rapache (for
> which Jeff Horner has a ppa on launchpad so it also works out of the box).
> 

FastRWeb is server-independent, easier to deploy on machines you have limited 
rights (i.e., you don't need to compile against apache or edit its 
configuration) and cleaner to debug because the client layer is so thin (the 
front-end doesn't die if R crashes). Also since Rserve is the back-end you can 
use its features such as updating data in the instance (control commands) or 
connect into the live instance from R itself to work interactively. Also you 
can technically separate web server and R server machines if you want to (or do 
load balancing etc.).

It is also a little more than just infrastructure, e.g. it does query parsing 
for you and takes care of things like graphics etc. Clearly, that is something 
you can do equally well do with a layer on top RApache, so that's not a 
technical issue. That said, I don't know RApache well enough to provide a 
comprehensive comparison, because I don't have control over the machines that 
my stuff will be deployed on, so RApache is not an option for my particular use.

Cheers,
Simon

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

Re: [Rd] multiple defines of diag

[Kasper Daniel Hansen]

On Thu, Oct 6, 2011 at 1:19 PM, Terry Therneau  wrote:
>
> On Thu, 2011-10-06 at 10:00 -0400, Kasper Daniel Hansen wrote:
>> if you're using two packages that both define a diag function/method
>> you absolutely _have_ to resolve this using your NAMESPACE.  [Update:
>> I see both are methods.  I actually don't know what happens when you
>> have the same generic in both packages]
>>
>
> Your response made me look further, with some surprising results.
>
> 1. Sequential loading
> tmt226% R --vanilla
> R version 2.13.0 (2011-04-13)
>
>> library(bdsmatrix)
>> tmat <- bdsmatrix(c(3,2,2,4),
>    c(22,1,2,21,3,20,19,4,18,17,5,16,15,6,7, 8,14,9,10,13,11,12),
>    matrix(c(1,0,1,1,0,0,1,1,0,1,0,10,0,
>           0,1,1,0,1,1,0,1,1,0,1,0,10), ncol=2))
>> tmat[1:7,1:7]     [,1] [,2] [,3] [,4] [,5] [,6] [,7]
> [1,]   22    1    2    0    0    0    0
> [2,]    1   21    3    0    0    0    0
> [3,]    2    3   20    0    0    0    0
> [4,]    0    0    0   19    4    0    0
> [5,]    0    0    0    4   18    0    0
> [6,]    0    0    0    0    0   17    5>
>
>> diag(tmat)
>  [1] 22 21 20 19 18 17 16 15 14 13 12 10 10
>
>> library(Matrix)
> Loading required package: lattice
>
> Attaching package: 'Matrix'
>
> The following object(s) are masked from 'package:base':
>
>    det
>
>> diag(tmat)
>  [1] 22 21 20 19 18 17 16 15 14 13 12 10 10
>
>  Things to note:
>         in this case I did not get a message about overwriting the diag
> method,
>         it works.
>
> This was not my experience with ranef(), an S3 generic that coxme, nlme,
> and lme4 all define; there whichever library loaded last did not
> discover existing methods.  That is, if one loaded nlme after coxme,
> then ranef(a coxme object) would not dispatch ranef.coxme.  Our solution
> (Doug Bates and I) was to have both coxme and lme4 import ranef and
> fixef from the nlme library.
>  However, per above it appears to work with S4 generics.
>  Can I count on it though?

My _guess_ is that you cannot depend on this in general.  What if the
two generics have different signatures, say one uses x,y and the other
uses x,y,z?

Kasper


>
> -
>
> Case 2:
>
> tmt229% R --vanilla
> R version 2.13.0 (2011-04-13)
>
>> library(coxme)
> Loading required package: survival
> Loading required package: splines
> Loading required package: bdsmatrix
> Loading required package: nlme
> Loading required package: Matrix
> Loading required package: lattice
>
> Attaching package: 'Matrix'
>
> The following object(s) are masked from 'package:base':
>
>    det
>
> Warning message:
> replacing previous import ‘diag’ when loading ‘Matrix’
>
>> tmat <- bdsmatrix(c(3,2,2,4),
>              c(22,1,2,21,3,20,19,4,18,17,5,16,15,6,7,
>                8,14,9,10,13,11,12),
>              matrix(c(1,0,1,1,0,0,1,1,0,1,0,10,0,
>                       0,1,1,0,1,1,0,1,1,0,1,0,10), ncol=2))
>>diag(tmat)
>  [1] 22 21 20 19 18 17 16 15 14 13 12 10 10
>
>
>  Things to note:
>     I now get a warning message about diag. Why only here?
>     Per the earlier comment I'm not importing all of nlme, just the two
> generics
>     It still works
>
> (This example isn't reproducable for others: the coxme library on CRAN
> does not yet have a Matrix dependency.)
>
>
>
>
>
>

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

[Rd] parallel::mclapply() dummy function on Windows?

[Tim Triche, Jr.]

Hi all,

Would it be possible to have the new 'parallel' library export a dummy
function, something akin to

if(Windows) mclapply <- lapply

to paper over the lack of fork() support on said platform?  This may not be
the world's greatest idea, but it would make it easier for me to maintain my
package and still offer most users good parallel support.  Plus, I can't
really see where it would cause problems, but then I don't develop R,
myself.

Thanks for any thoughts on the matter.


-- 
If people do not believe that mathematics is simple,
it is only because they do not realize how complicated life is. John von
Neumann

[[alternative HTML version deleted]]

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

Re: [Rd] parallel::mclapply() dummy function on Windows?

[Prof Brian Ripley]

On Thu, 6 Oct 2011, Tim Triche, Jr. wrote:


Hi all,

Would it be possible to have the new 'parallel' library export a dummy
function, something akin to

if(Windows) mclapply <- lapply

to paper over the lack of fork() support on said platform?  This may not be
the world's greatest idea, but it would make it easier for me to maintain my
package and still offer most users good parallel support.  Plus, I can't


Why would it make it easier?  And how could using a dummy for 'most 
users' (who are on Windows) offer them 'good parallel support'?



really see where it would cause problems, but then I don't develop R,
myself.


Take a look at e.g. package 'boot' to see how to offer alternatives. 
(A version that uses 'parallel' is pending on CRAN, or see 
http://www.stats.ox.ac.uk/pub/R/boot_1.3-3.tar.gz .) Package 
'parallel' may in future offer a higher-level abstraction layer that 
makes offers such a choice, but as the 'boot' code shows, deciding 
what to send to the workers in a snow-style cluster is not simple.


Note that it is not just Windows that lacks fork support: some 
front-ends (notably Rstudio) do not work with forking at present. And 
some parts of parallel (and multicore/snow) do not work reliably on 
some OSes (e.g. Solaris).



Thanks for any thoughts on the matter.

[[alternative HTML version deleted]]


Please do follow the posting guide: no HTML and use the signature 
block for your real name and credentials.




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



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

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