Re: [Rd] nested parallel workers

2015-03-25 Thread Simon Urbanek
On Mar 25, 2015, at 3:46 PM, Valerie Obenchain wrote: > Hi Simon, > > I'm having trouble with nested parallel workers, specifically, forking inside > socket connections. > You simply can't by definition - when you fork *all* the workers share the same connection inherited from the parent, so

Re: [Rd] vignette checking woes

2015-03-25 Thread Thierry Onkelinx
I think that you need to check how MatrixModels imports sparse.model.matrix(). If MatrixModels depends on Matrix, then you are probably forced to depend on MatrixModels. ir. Thierry Onkelinx Instituut voor natuur- en bosonderzoek / Research Institute for Nature and Forest team Biometrie & Kwalitei

Re: [Rd] vignette checking woes

2015-03-25 Thread Roger Koenker
Thierry, I have this: if (require(MatrixModels) && require(Matrix)) { X <- model.Matrix(Terms, m, contrasts, sparse = TRUE) in my function rqss() I've tried variants of requireNamespace too without success. If I understand properly model.Matrix is from MatrixModels but it calls sparse.m

Re: [Rd] vignette checking woes

2015-03-25 Thread Thierry Onkelinx
Dear Roger, How is Matrix loaded? If you use sparse.model.matrix() inside a function from your package you need to declare it as Matrix::sparse.model.matrix() Best regards, ir. Thierry Onkelinx Instituut voor natuur- en bosonderzoek / Research Institute for Nature and Forest team Biometrie & Kw

[Rd] nested parallel workers

2015-03-25 Thread Valerie Obenchain
Hi Simon, I'm having trouble with nested parallel workers, specifically, forking inside socket connections. When mclapply is called inside a SOCK, PSOCK or FORK worker I get an error in unserialize(). cl <- makeCluster(1, "SOCK") fun = function(i) { library(parallel) mclapply(1:2, sqrt) }

Re: [Rd] vignette checking woes

2015-03-25 Thread Duncan Murdoch
On 25/03/2015 2:59 PM, Roger Koenker wrote: I'm having trouble with R CMD check of my quantreg package. All is well until I get to: checking running R code from vignettes ... ‘rq.Rnw’ ... failed ERROR Errors in running code in vignettes: when running code in ‘rq.Rnw’ when I see a snippet

[Rd] vignette checking woes

2015-03-25 Thread Roger Koenker
I'm having trouble with R CMD check of my quantreg package. All is well until I get to: checking running R code from vignettes ... ‘rq.Rnw’ ... failed ERROR Errors in running code in vignettes: when running code in ‘rq.Rnw’ when I see a snippet from the vignette code and then: Loading req

Re: [Rd] F77_CALL/NAME problem

2015-03-25 Thread William Dunlap
You said you changed F77_NAME(DGESV) to dgesv_ to make it work and inferred that F77_NAME was the the problem. I suspect that things got better because you changed the capitalization and that F77_NAME(dgesv) would have worked as well. Adding #include to your code would declare these things as

Re: [Rd] F77_CALL/NAME problem

2015-03-25 Thread John McKown
On Wed, Mar 25, 2015 at 4:44 AM, bstr wrote: > Dear R-devel, > > I am trying to use Fortran DGESV subroutine into C. Here it is the relevant > part of the C file I am currently writing > > #include > #include > #include > #include > > void F77_NAME(DGESV)( int*, int*, double*, int*, int*, double*,

[Rd] F77_CALL/NAME problem

2015-03-25 Thread bstr
Dear R-devel, I am trying to use Fortran DGESV subroutine into C. Here it is the relevant part of the C file I am currently writing #include #include #include #include void F77_NAME(DGESV)( int*, int*, double*, int*, int*, double*, int*, int*); void solve( int *p, double *A, double *Ainv) {

Re: [Rd] F77_CALL/NAME problem

2015-03-25 Thread bstr
I was not able to find why my old way to do things did not work. However, I "discovered" that dgesv is also in the header Lapack.h. So I just dropped form the C code the declarations F77_NAME/CALL and used directly function dgesv_ as declared in Lapack.h. Of course I had to compile with the -llapac