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
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
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
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
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)
}
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
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
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
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*,
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)
{
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
11 matches
Mail list logo