I have read (here) that PyPy has support for CPython extension modules via cpyext.
I haven't found any cpyext documentation. Is there any?
How do I use it?
From the source code (e.g. here), I figured out that to load my leveldb.so module, I probably have to do this:
import cpyext
cpyext.load_module("leveldb.so","leveldb")
However, this crashes with this error:
Fatal Python error: PyThreadState_Get: no current thread
I noticed in the backtrace that it calls the functions from my CPython, not from PyPy:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff8b3e4d46 __kill + 10
1 libsystem_c.dylib 0x00007fff927a9df0 abort + 177
2 org.python.python 0x0000000104692eaa Py_FatalError + 49
3 org.python.python 0x0000000104691370 PyThreadState_Get + 28
4 org.python.python 0x000000010468cf16 Py_InitModule4_64 + 58
5 leveldb.so 0x00000001027e0881 initleveldb + 49 (leveldb_ext.cc:59)
6 pypy 0x0000000100f59bb3 PyLong_CheckExact + 55379
7 pypy 0x0000000100f6e7c7 PyLong_CheckExact + 140391
....
I figured it out.
It is necessary to recompile the module. I must use the header files from PyPy. For linking, I must not link against libpython. I must just tell the linker to ignore about unresolved symbols.
This where my commands to build py-leveldb on MacOSX:
cc -I /usr/local/Cellar/pypy/1.9/include -g -c leveldb_ext.cc leveldb_object.cc
libtool -dynamic -o leveldb.so leveldb_ext.o leveldb_object.o -lleveldb -lsnappy -lc -lstdc++ -undefined dynamic_lookup
That worked. I just did cpyext.load_module("leveldb.so","leveldb").
I also found some more notes about CPyExt in their wiki here.
Plyvel, a fast and feature-rich Python interface to LevelDB, also passes almost all of its many unit tests when running under PyPy with cpyext. (The one exception is related to threading.) Installation is as simple as "pip install plyvel"; no need to fiddle with compiler flags.
See https://github.com/wbolster/plyvel and https://plyvel.readthedocs.org/ for more information.
(Disclaimer: I wrote Plyvel.)
Related
I am trying to build GROMACS with icc compiler but it is throwing error I have provided the error below.
": internal error: 0_76
compilation aborted for /global/scratch/groups/hpcperf/2022_Refresh/gromacs/api/nblib/topology.cpp (code 4)
make[2]: *** [api/nblib/CMakeFiles/nblib.dir/build.make:216: api/nblib/CMakeFiles/nblib.dir/topology.cpp.o] Error 4
Any help appreciated!
A sample reproducer would help us resolve your issue from our end. However, GROMACS no longer supports Intel classic compilers (icc/icpc). It supports only the Intel LLVM compilers (icx/icpx).
I had the same issue and can confirm that it is resolved when switching from the classic compilers to the LLVM compilers. Note that if you use MPI, you also need to change the compiler for these wrappers, either via the I_MPI_CC(X) environment variable or the -cc / -cxx option.
I bought an M1 Silicon with Monterey back in January and --- after a three+ month pause -- am trying again to get Rcpp running so I can install RStan. Following these instructions in response to (I'd like to just comment on this other issue, but being new to posting on Stack Overflow it tells me that I cannot and what I am about to post is certainly NOT an answer):
Configuring compilers on Mac M1 (Big Sur, Monterey) for Rcpp and other tools
While step 3 (installing gfortran) looks to go well, when I ask about gfortran things seem less hopeful:
-bash: gfortran: command not found
Or maybe this is not how to ask if all went well with the installation?
No matter, I charge on to step 4 installing from openmp-13.0.0-darwin21-Release.tar.gz based on:
Apple clang version 13.1.6 (clang-1316.0.21.2.3)
Target: arm64-apple-darwin21.4.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
I confirm that I have the files where expected, then create the .R directory and the Makevars file (in nano) then try to run the R and get ....
+ #endif
+ }
+ ')
/Users/lizzie/.R/Makevars:6: *** missing separator. Stop.
Error in Rcpp::sourceCpp(code = "\n#include <RcppArmadillo.h>\n#ifdef _OPENMP\n# include <omp.h>\n#endif\n\n// [[Rcpp::depends(RcppArmadillo)]]\n// [[Rcpp::export]]\nvoid omp_test()\n{\n#ifdef _OPENMP\n Rprintf(\"OpenMP threads available: %d\\n\", omp_get_max_threads());\n#else\n Rprintf(\"OpenMP not supported\\n\");\n#endif\n}\n") :
Error 1 occurred building shared library.
WARNING: The tools required to build C++ code for R were not found.
Please install Command Line Tools for XCode (or equivalent).
Any thoughts or ideas much appreciated. Again, I am new to posting to StackOverflow so apologize as I am sure I am doing this wrong.
I'm trying to make a Ocaml graphics program in Windows, but I cannot generate it without the console window.
The correct command should be:
ocamlopt -o test.exe -ccopt "-subsystem console" graphics.cmxa test.ml
However I receive the following error :
ld: cannot find -lcomdlg32
** Fatal error: Error during linking
Im' working on windows 10, 64 bits, having installed 32 bit ocaml
ocpwin32-20160113-4.02.1+ocp1-mingw32
(Just to be able to use also ocaml-top, that comes only in 32 bit version).
Any suggestion ?
Does anyone know if it is possible to have binary code from IR generated with llvmlite? in llvm, we can simply clang -emit-llvm -o foo.bc -c foo.c. What if I am using llvmlite?
As far as I can tell, llvmlite doesn't include a linker. You can write object code with, for example,
target = llvm.Target.from_default_triple()
machine = target.create_target_machine()
with llvm.create_mcjit_compiler(module, target) as mcjit:
def on_compiled(module, objbytes):
open('mymodule.o', 'w').write(objbytes)
mcjit.set_object_cache(on_compiled, lambda m: None)
mcjit.finalize_object()
And then use your standard linker ld, which usually you would have via gcc or clang to link the object file. LLVM 4 seems to ship with its own linker lld which is an option to use manually but llvmlite isn't on version 4 and wouldn't be able to expose that functionality.
On my machine for example, I can run from bash
$ gcc -o llvmapp mymodule.o
$ ./llvmapp
It appears the easiest solution thus far is directly write all your code in python, but it comes at the cost of run time, which I know some people don't care about.
Unfortunately, I would have to agree with #Jimmy. I haven't seen anything yet and it is 2019 which is 2 years later and still nothing.
I'm trying to apply frama-c/jessie on a module of a proprietary safety critical system from our customer. The function under analysis is pretty big (image 700 uncommented lines count) with a lot of conditional statements as well as complex (&&, ||, etc).
I got this error message when I ran it on Ubuntu VM 64 bit machine. It appears Error 137 is related to memory size, etc. But I'm not quite sure.
Any suggestion for how to approach this error is greatly appreciated.
[
formal_verification]$ frama-c -jessie test.c
[kernel] preprocessing with "gcc -C -E -I. -dD test.c"
[jessie] Starting Jessie translation
[jessie] Producing Jessie files in subdir test.jessie
[jessie] File test.jessie/test.jc written.
[jessie] File test.jessie/test.cloc written.
[jessie] Calling Jessie tool in subdir tests.jessie
Generating Why function testFun
[jessie] Calling VCs generator.
gwhy-bin [...] why/test.why
Computation of VCs...
Killed
make: *** [test.stat] Error 137
with a lot of conditional statements as well as complex (&&, ||, etc).
You should use the so-called “fast WP” option when analyzing functions with lots of nested conditionals. Otherwise, the target does not even need to be very large to cause a blowup.
It happens to be the example in Jessie's manual for passing options to Why (it is really a Why option):
-jessie-why-opt=<s>
give an option to Why (e.g., -fast-wp)
You would therefore use -jessie-why-opt=-fast-wp.