I'm trying to compile the sitmo prng under C++11 within an R package. The problematic code has been packaged and is available here. The objective of this R package is to make available the sitmo header file so that other packages are able to use the LinkTo field within description. As an added bonus, the package is scheduled to ship with an Armadillo + OpenMP example. There is one other package, mvnfast, that uses sitmo, but only under c++98 and boost headers.
I believe that the error which I am receiving is specific to OS X and clang. I haven't been able to replicate it on Windows via win-build. With that being said, the error is:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/random:3641:44: error: non-type template argument is not a constant expression
const size_t __logR = __log2<uint64_t, _URNG::max() - _URNG::min() + uint64_t(1)>::value;
The error has only popped up on the Rcpp dev list. The resolution in this case was to compile under C++98 and use boost.
The above error is followed by the following notes:
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/random:3773:18: note: in instantiation of function template specialization 'std::__1::generate_canonical<double, 53, sitmo::prng_engine>' requested here
* _VSTD::generate_canonical<_RealType, numeric_limits<_RealType>::digits>(__g)
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/random:3737:17: note: in instantiation of function template specialization 'std::__1::uniform_real_distribution<double>::operator()<sitmo::prng_engine>' requested here
{return (*this)(__g, __p_);}
^
sitmo_test.cpp:77:26: note: in instantiation of function template specialization 'std::__1::uniform_real_distribution<double>::operator()<sitmo::prng_engine>' requested here
double u = distunif(engine);
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/random:3641:44: note: non-constexpr function 'max' cannot be used in a constant expression
const size_t __logR = __log2<uint64_t, _URNG::max() - _URNG::min() + uint64_t(1)>::value;
^
../inst/include/prng_engine.hpp:100:23: note: declared here
static result_type (max)() { return 0xFFFFFFFF; }
The version of clang being used is:
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin15.3.0
Thread model: posix
Looking into the code, there is a bug in the sitmo prng_engine.h. min() and max() were declared as
static result_type (min)() { return 0; }
static result_type (max)() { return 0xFFFFFFFF; }
If you take a look at, say, standard LCG max from here, you could see that it is declared constexpr, ditto for min.
As soon as you make those methods constexpr in the sitmo header file, I believe you could use them in template expression.
UPDATE
I've looked into GCC 5 headers, methods indeed are declared constexpr
Related
I get the below error when i try to open and download .realm file in /tmp directory of serverless framework.
{"errorType":"Runtime.UnhandledPromiseRejection","errorMessage":"Error: posix_fallocate() failed: Operation not permitted" }
Below is the code:
let realm = new Realm({path: '/tmp/custom.realm', schema: [schema1, schema2]});
realm.write(() => {
console.log('completed==');
});
EDIT: this might soon be finally fixed in Realm-Core: see issue 4957.
In case you'll run into this problem elsewhere, here's a workaround.
This caused by AWS Lambda not supporting the fallocate and fallocate64 system calls. Instead of returning the correct error code in this case, which would be EINVAL for not supported on this file system, Amazon has blocked the system call so that it returns EPERM. Realm-Core has code that handles EINVAL return value correctly but will be bewildered by the unexpected EPERM returned from the system call.
The solution is to add a small shared library as a layer to the lambda: compile the following C file on Linux machine or inside lambda-ci Docker image:
#include <errno.h>
#include <fcntl.h>
int posix_fallocate(int __fd, off_t __offset, off_t __len) {
return EINVAL;
}
int posix_fallocate64(int __fd, off_t __offset, off_t __len) {
return EINVAL;
}
Now, compile this to a shared object with something like
gcc -shared fix.c -o fix.so
Then add it to a root of a ZIP file:
zip layer.zip fix.so
Create a new lambda layer from this zip
Add the lambda layer to your lambda function
Finally make the shared object be loaded by configuring the environment value LD_PRELOAD with value /opt/fix.so to your Lambda.
Enjoy.
to ccall a custom made library, I need to write down the library full path on the system:
j = ccall((:add3, "[FULL_PATH]/libmylib.so"), Float32, (Float32,), 2)
I am trying to use instead a relative path with:
j = ccall((:add3, "$(pwd())/libmylib.so"), Float32, (Float32,), 2)
but, while "$(pwd())/libmylib.so" returns the right path for the library, ccall with pwd returns a TypeError: in ccall: first argument not a pointer or valid constant expression, expected Ptr, got Tuple{Symbol,String}.
So, how to ccall a library that is in the same folder than the Julia script/current working directory ?
I am puzzled, as according to this thread in Windows seems to work, even if the doc for ccall specify:
Note that the argument type tuple must be a literal tuple, and not a tuple-valued variable or expression.
For info, I'm in Ubuntu 18.04 and the library has been implemented with
mylib.c:
float add3 (float i){
return i+3;
}
mylib.h:
#ifndef _MYLIB_H_
#define _MYLIB_H_
extern float get2 ();
extern float add3 (float i);
Compilation (gcc):
gcc -o mylib.o -c mylib.c
gcc -shared -o libmylib.so mylib.o -lm -fPIC
As far as I know this is the most used pattern:
const mylib = joinpath(pwd(), "libmylib.so")
j = ccall((:add3, mylib), Cfloat, (Cfloat,), 2)
Note that pwd can be a bit more in "flux" than you want for a library path, it is probably better to relate it to the file, e.g.
const mylib = joinpath(#__DIR__, "libmylib.so")
where #__DIR__ expands to the directory of the file itself.
As often, I found the solution only after posting on SO.. it seems setting the question helps defining better the problem..
Any how, the solution is to first get the function pointer with cglobal - where I can use pwd() - and then use the ccall method with the function pointer:
f = cglobal((:add3, "$(pwd())/libmylib.so"))
j = ccall(f, Float32, (Float32,), i)
When I submit my package to cran I get the error as
Found no calls to: 'R_registerRoutines', 'R_useDynamicSymbols'
It is good practice to register native routines and to disable symbol
search.
My package was tested in this version of R by CRAN:
R version 3.4.0 alpha (2017-03-28 r72427)
Note that there is a solution for this error here
R CMD check note: Found no calls to: ‘R_registerRoutines’, ‘R_useDynamicSymbols’
but my external codes are in Fortran and tried the procedure described there but does not fix the issue for me. What can I do to overcome the issue?
Thanks
Update:
Following the procedure described https://www.r-bloggers.com/1-easy-package-registration/ I could pass the
Error:Found no calls to: ‘R_useDynamicSymbols’
But Found no call to: 'R_registerRoutines' still remains.
I solved the problem and you may find it useful for your own case.
Let's assume you have a subroutine called myf.f90 in src directory with following content:
SUBROUTINE cf(r,cd,loci)
INTEGER::r,cd
DOUBLE PRECISION::loci
....
....
....
END SUBROUTINE cf
To register this you need to do the following :
A) Run tools::package_native_routine_registration_skeleton("package directory")
B) Edit the output; for the example above would be:
#include <R.h>
#include <Rinternals.h>
#include <stdlib.h> // for NULL
#include <R_ext/Rdynload.h>
/* FIXME:
Check these declarations against the C/Fortran source code.
*/
/* .Fortran calls */
extern void F77_NAME(cf)(int *r, int *cd, double *loci);
static const R_FortranMethodDef FortranEntries[] = {
{"cf", (DL_FUNC) &F77_NAME(cf), 3},
{NULL, NULL, 0}
};
void R_init_packagename(DllInfo *dll)
{
R_registerRoutines(dll, NULL, NULL, FortranEntries, NULL);
R_useDynamicSymbols(dll, FALSE);
}
C) Copy and paste the full output in a packagename_init.c file to be put in src/
D) Update NAMESPACE, verifying that useDynLib(packagename, .registration = TRUE)
I know that g++ support constexpr math function. I want to do that on clang++. So I write a simple code.
#include<iostream>
#include<cmath>
int main()
{
constexpr auto a(std::floor(4.3));
std::cout<<a<<std::endl;
}
and then use clang++-libc++ -std=c++1y to compile it and the get the following error:
error: constexpr variable 'a' must be initialized by a constant expression
constexpr auto a(std::floor(4.3));
^ ~~~~~~~~~~~~~~~
note: non-constexpr function 'floor' cannot be used in a constant expression
constexpr auto a(std::floor(4.3));
^
/usr/include/x86_64-linux-gnu/bits/mathcalls.h:184:14: note: declared here
__MATHCALLX (floor,, (_Mdouble_ __x), (__const__));
^
/usr/include/math.h:58:26: note: expanded from macro '__MATHCALLX'
__MATHDECLX (_Mdouble_,function,suffix, args, attrib)
^
/usr/include/math.h:60:22: note: expanded from macro '__MATHDECLX'
__MATHDECL_1(type, function,suffix, args) __attribute__ (attrib); \
^
/usr/include/math.h:63:31: note: expanded from macro '__MATHDECL_1'
extern type __MATH_PRECNAME(function,suffix) args __THROW
^
/usr/include/math.h:66:42: note: expanded from macro '__MATH_PRECNAME'
#define __MATH_PRECNAME(name,r) __CONCAT(name,r)
^
/usr/include/x86_64-linux-gnu/sys/cdefs.h:88:23: note: expanded from macro '__CONCAT'
#define __CONCAT(x,y) x ## y
I use clang-3.5. So I want to ask whether clang++ support constexpr math function. If so, what compiler flag I need to pass to clang?
cppreference doesn't declare std::floor as constexpr. Not sure whether any standard does. I guess compilers might want to avoid implementing this unless it's in some standard, to avoid incompatible behavior. According to the manual, clang aims for support of C++11 and C++1y (likely C++14), with no extensions of C++ features mentioned.
Currently I have some code like (condensed and removed a bunch of error checking):
dp = readdir(dir);
if (dp->d_type == DT_DIR) {
}
This works swimmingly on my Linux machine. However on another machine (looks like SunOS, sparc):
SunOS HOST 5.10 Generic_127127-11 sun4u sparc SUNW,Ultra-5_10
I get the following error at compile time:
error: structure has no member named `d_type'
error: `DT_DIR' undeclared (first use in this function)
I thought the dirent.h header was crossplatform (for POSIX machines). Any suggestions.
Ref http://www.nexenta.org/os/Porting_Codefixes:
The struct dirent definition in solaris does not contain the d_type field. You would need to make the changes as follows
if (de->d_type == DT_DIR)
{
return 0;
}
changes to
struct stat s; /*include sys/stat.h if necessary */
..
..
stat(de->d_name, &s);
if (s.st_mode & S_IFDIR)
{
return 0;
}
Since stat is also POSIX standard it should be more cross-platform. But you may want to use if ((s.st_mode & S_IFMT) == S_IFDIR) to follow the standard.