wlav / cppyy Goto Github PK
View Code? Open in Web Editor NEWLicense: Other
cppyy's People
Contributors
Stargazers
Watchers
Forkers
etejedor saidctb fchen7i myxinxin-code toolframework mfkiwl xayjin sudo-panda python-repository-hub jeepee-liu mphschmitt keceli snserhello scauligi vgvassilev cloudbee7 yssource mohammadzainabbas finsberg durbar2003 nikeyigun compiler-research amr-atif imamul5641 ro4i7 aaronj0 msaini28r quillpusher agoose77 pitkajuh m-fila guitargeek strogo chococandy63 devajithvscppyy's Issues
Read char16_t* String in user defined struct
According to that SO-Question:
C++ Code:
#define MLPI_MOTION_MAX_AXIS_NAME_LEN (80)
typedef unsigned int ULONG;
typedef char16_t WCHAR16;
typedef enum MlpiAxisType
{<snipp>
}MlpiAxisType;
typedef struct MlpiAxisInformation
{
MlpiAxisRef axis; //!< Logical axis address.
ULONG deviceAddress; //!< (SERCOS) device address.
MlpiAxisType axisType; //!< Type of axis (virtual, real, etc...).
WCHAR16 name[MLPI_MOTION_MAX_AXIS_NAME_LEN]; //!< The axis name.
}MlpiAxisInformation;
MLPI_API MLPIRESULT mlpiMotionGetConfiguredAxes(const MLPIHANDLE connection, MlpiAxisInformation* configAxes, const ULONG numElements, ULONG *numElementsRet);
Python-Code (working more or less):
class MlpiAxisRef(ctypes.Structure):
_fields_ = [
("controlNo",ctypes.c_int16),
("axisNo",ctypes.c_int16) ]
class MlpiAxisInformation(ctypes.Structure):
_fields_ = [
("axis", MlpiAxisRef),
("deviceAddress",ctypes.c_ulong),
("axisType", ctypes.c_int16),
("name", ctypes.c_uint16*79) ]
def MLPIGetConfiguredAxes(self) -> List[MlpiAxisInformation]:
length = ctypes.c_ulong(99)
length_ret = ctypes.c_ulong(0)
self._mlpi.mlpiMotionGetConfiguredAxes.argtypes = (ctypes.c_ulonglong, ctypes.POINTER(MlpiAxisInformation), ctypes.c_ulong, ctypes.POINTER(ctypes.c_ulong))
self._mlpi.mlpiMotionGetConfiguredAxes.restype = ctypes.c_long
val = (MlpiAxisInformation*100)()
ret = self._mlpi.mlpiMotionGetConfiguredAxes(self.con, val, length, length_ret)
<some code to covert int-array to string>
It works, but it's not fully correctly assigned. So not each byte is on the right position. Tried various datatypes and with _pack_=1 and without. It changes, but somewhere there is always anything wrong. Therefore my idea was to use cppyy to get it running.
- Is cppyy a better tool for that than ctypes?
- Is there a possibility to use the Types from the C++ Code and cast them in Python later? So tried to get a
cppyy.ll.array_new[cppyy.gbl.MlpiAxisInformation](length.value), but array_new just supports standard types? - Or generate a wrapper function and return clean results to python?
Edit: To be clear: I'm sure this could be solved with ctypes, but it is a pain to guess the right byte-size in this structs. And even if you guess right, on another platform it could be compiled differently.
I'm asking if there is a way to achieve that in cppyy more convenient, with some sort of mechanism taking the Types from C++ and get the transfer to python code type safe.
[Question] Problems while testing with ns-3
Sorry, typed enter without writing the text...
Hi, I've been testing the runtime bindings with the ns-3 simulator as we are thinking of dropping pybindgen and would be good to have an alternative.
While setting up cppyy runtime bindings was incredibly easy (90 lines), I'm having some issues.
First is due to a custom operator being overwritten/ignored. It is quite hacky, so I don't mind using a workaround, but wanted to inform you.
ipv4Address = interfaces.GetAddress(1)
address = ns.addressFromIpv4Address(ipv4Address)
# In the entire codebase, operator Address converts Ipv4Address to Address automatically
echoClient = ns.applications.UdpEchoClientHelper(address, 9)
Second issue object lifetime management. I have no idea of the internals, but things like the following fail with a segmentation violation:
networkNode = ns.Node()
nodeContainer = ns.NodeContainer()
nodeContainer.Add(networkNode)
while instantiating the Node in the c++ side works correctly:
nodeContainer = ns.NodeContainer(1)
nodeContainer2 = ns.NodeContainer(nodeContainer.Get(0))
Same issue here and with CommandLine here.
Not sure if that is a problem on our side, or just template shenanigans.
Third issue: some methods seem to map to the wrong classes. I don't quite understand why either. With this example:
mobility = ns.mobility.ConstantPositionMobilityModel()
mobility.SetPosition(ns.core.Vector(xi*DISTANCE, yi*DISTANCE, 0))
node.AggregateObject(mobility)
I get
msg="Object::AggregateObject(): Multiple aggregation of objects of type ns3::Object on objects of type ns3::Object", +0.000000000s -1 file=/mnt/dev/tools/source/ns-3-dev/src/core/model/object.cc, line=279
terminate called without an active exception
The typeId of the aggregated object isn't ns3::Object, but ns3::ConstantPositionMobilityModel.
Fourth issue, which I believe has something to do with the third. In example, I get the following:
remoteAddr = appSink.GetObject(ns.Ipv4.GetTypeId()).GetAddress(1,0).GetLocal()
TypeError: Template method resolution failed:
Failed to instantiate "GetObject(ns3::TypeId&)"
Failed to instantiate "GetObject(ns3::TypeId*)"
Failed to instantiate "GetObject(ns3::TypeId)"
GetObject searches for aggregated objects based on the typeId.
If you have the free time and want to give it a try, cloning this branch, then configuring the project with ./ns3 configure --enable-examples && ./ns3 build, then you should be able to run ./ns3 run example.py --no-build to run a python example.
I'm not really sure of what we can do to make it work.
cppyy with context switches (aka coroutines)
In a recent tryout to use cppyy with context swtich libraries (e.g. SystemC, which are using QuickThread) some random failures happen. One run could report segmentation fault, the next run could report cannot find a proper function for the give parameters, which in the segmentation fault case was successfully found.
Before I try to create a minimal example that reproduce the issue, just want to check quickly if cppyy need any special handling to work with those libraries? or maybe this is even a known issue? Thanks.
__repr__ Returning std::string Not Valid
In cppyy 2.3.0 you can no longer have a __str__ or __repr__ that return a std::string. I'm not sure when this changed. Returning a const char* works.
import cppyy
cppyy.cppdef('''
struct Test
{
// Works
//const char* __repr__() const { return "Test()"; }
// Doesn't Work
std::string __repr__() const { return "Test()"; }
};
''')
from cppyy.gbl import Test
print(repr(Test()))
Tag for 2.2.0
cppyy 2.2.0 is on PyPI but there is not tag/release in this repository. Was that intentional @wlav?
Operations on std::filesystem cause segmentation violation
Hi!
I just started using cppyy and I need to use a C++ library using some functions of std::filesystem. However, calling some of these functions cause a *** Break *** segmentation violation.
I think that it finally boils down to the following code (identical to the following resolved issue: https://bitbucket.org/wlav/cppyy/issues/265/destruction-of-std-filesystem-path-causes):
import cppyy
if __name__ == '__main__':
# Allocating a path works
cppyy.cppdef("""
#include <filesystem>
void leak_std_path()
{
std::filesystem::path* p = new std::filesystem::path("/usr");
std::cout << *p << std::endl;
}
""")
cppyy.gbl.leak_std_path()
# prints "/usr"
# However, when it is destructed, a segfault occurs (on execution of the function).
cppyy.cppdef("""
#include <filesystem>
void destruct_std_path()
{
std::filesystem::path p = "/usr";
std::cout << p << std::endl;
}
""")
# prints "/usr", then segfaults.
cppyy.gbl.destruct_std_path()
I tested the code:
- in a virtual environment using Python3.7 or Python3.9 with g++ 8.4.0 (I tried the installation via pip and the installation from source),
- in a conda environment (installation via conda-forge).
I am using the following versions:
cppyy==2.2.0
cppyy-backend==1.14.7
cppyy-cling==6.25.2
CPyCppyy==1.12.8
and the command cppyy.cppexec("std::cerr << __cplusplus << std::endl;") returns 201703.
I obtain the following error message in all cases:
*** Break *** segmentation violation
#0 0x00007fbff8716457 in __GI___waitpid (pid=915, stat_loc=stat_loc
entry=0x7ffe631ac478, options=options
entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:30
#1 0x00007fbff8681177 in do_system (line=<optimized out>) at ../sysdeps/posix/system.c:149
#2 0x00007fbff7a109c0 in CppyyLegacy::TUnixSystem::Exec (shellcmd=<optimized out>, this=0x55e1de090a00) at /tmp/pip-install-aas9inhn/cppyy-cling_52668ffc4cc34678ace6e48cae8c9f88/src/core/unix/src/TUnixSystem.cxx:1814
#3 CppyyLegacy::TUnixSystem::StackTrace (this=0x55e1de090a00) at /tmp/pip-install-aas9inhn/cppyy-cling_52668ffc4cc34678ace6e48cae8c9f88/src/core/unix/src/TUnixSystem.cxx:2104
#4 0x00007fbff21533f5 in (anonymous namespace)::do_trace (sig=1) at src/clingwrapper.cxx:199
#5 (anonymous namespace)::TExceptionHandlerImp::HandleException (this=<optimized out>, sig=1) at src/clingwrapper.cxx:212
#6 0x00007fbff7a12229 in CppyyLegacy::TUnixSystem::DispatchSignals (this=0x55e1de090a00, sig=CppyyLegacy::kSigSegmentationViolation) at /tmp/pip-install-aas9inhn/cppyy-cling_52668ffc4cc34678ace6e48cae8c9f88/src/core/unix/src/TUnixSystem.cxx:2744
#7 <signal handler called>
#8 0x00007fbff987a33b in ?? ()
#9 0x00007fbff98780a0 in ?? ()
#10 0x6232313131787863 in ?? ()
#11 0x00007fbff987a330 in ?? ()
#12 0x00007fbff754f9c0 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#13 0x000055e1dfe6b580 in ?? ()
#14 0x0000000000000002 in ?? ()
#15 0x00007fbff752bf20 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#16 0x00007fbff987a386 in ?? ()
#17 0x00007fbff98780a0 in ?? ()
#18 0x000055e1dfe6b560 in ?? ()
#19 0x0000000000000000 in ?? ()
*** Break *** segmentation violation
#0 0x00007fbff8716457 in __GI___waitpid (pid=1054, stat_loc=stat_loc
entry=0x7ffe631ac478, options=options
entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:30
#1 0x00007fbff8681177 in do_system (line=<optimized out>) at ../sysdeps/posix/system.c:149
#2 0x00007fbff7a109c0 in CppyyLegacy::TUnixSystem::Exec (shellcmd=<optimized out>, this=0x55e1de090a00) at /tmp/pip-install-aas9inhn/cppyy-cling_52668ffc4cc34678ace6e48cae8c9f88/src/core/unix/src/TUnixSystem.cxx:1814
#3 CppyyLegacy::TUnixSystem::StackTrace (this=0x55e1de090a00) at /tmp/pip-install-aas9inhn/cppyy-cling_52668ffc4cc34678ace6e48cae8c9f88/src/core/unix/src/TUnixSystem.cxx:2104
#4 0x00007fbff21532b8 in (anonymous namespace)::do_trace (sig=1) at src/clingwrapper.cxx:199
#5 (anonymous namespace)::TExceptionHandlerImp::HandleException (this=<optimized out>, sig=1) at src/clingwrapper.cxx:218
#6 0x00007fbff7a12229 in CppyyLegacy::TUnixSystem::DispatchSignals (this=0x55e1de090a00, sig=CppyyLegacy::kSigSegmentationViolation) at /tmp/pip-install-aas9inhn/cppyy-cling_52668ffc4cc34678ace6e48cae8c9f88/src/core/unix/src/TUnixSystem.cxx:2744
#7 <signal handler called>
#8 0x00007fbff987a33b in ?? ()
#9 0x00007fbff98780a0 in ?? ()
#10 0x6232313131787863 in ?? ()
#11 0x00007fbff987a330 in ?? ()
#12 0x00007fbff754f9c0 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#13 0x000055e1dfe6b580 in ?? ()
#14 0x0000000000000002 in ?? ()
#15 0x00007fbff752bf20 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#16 0x00007fbff987a386 in ?? ()
#17 0x00007fbff98780a0 in ?? ()
#18 0x000055e1dfe6b560 in ?? ()
#19 0x0000000000000000 in ?? ()
Do you have any idea what may cause the error, and how I could solve it? I would really appreciate any help! :)
[Question] Why does the automatic overloading fails here?
I have an object of type <cppyy.gbl.BLArrayView<BLPoint> object at 0x000002C9302F2440>.
The following call with the object as the argument fails to my surprise (see below), since the fourth signature should work.
It does work when I choose it manually via 'const BLArrayView<BLPoint>& poly, BLGeometryDirection dir = BL_GEOMETRY_DIRECTION_CW'. Casting the obj does not, it seems to be a non-op (as expected). Any hints?
>>> p.addPolyline(obj)
TypeError: none of the 8 overloaded methods succeeded. Full details:
unsigned int BLPath::addPolyline(const BLArrayView<BLPoint>& poly, const BLMatrix2D& m, BLGeometryDirection dir) =>
TypeError: takes at least 3 arguments (2 given)
unsigned int BLPath::addPolyline(const BLArrayView<BLPointI>& poly, BLGeometryDirection dir = BL_GEOMETRY_DIRECTION_CW) =>
TypeError: could not convert argument 1
unsigned int BLPath::addPolyline(const BLArrayView<BLPointI>& poly, const BLMatrix2D& m, BLGeometryDirection dir = BL_GEOMETRY_DIRECTION_CW) =>
TypeError: could not convert argument 1
unsigned int BLPath::addPolyline(const BLArrayView<BLPoint>& poly, BLGeometryDirection dir = BL_GEOMETRY_DIRECTION_CW) =>
TypeError: could not convert argument 1
unsigned int BLPath::addPolyline(const BLPoint* poly, size_t n, const BLMatrix2D& m, BLGeometryDirection dir) =>
TypeError: takes at least 4 arguments (2 given)
unsigned int BLPath::addPolyline(const BLPointI* poly, size_t n, BLGeometryDirection dir = BL_GEOMETRY_DIRECTION_CW) =>
TypeError: could not convert argument 1
unsigned int BLPath::addPolyline(const BLPointI* poly, size_t n, const BLMatrix2D& m, BLGeometryDirection dir = BL_GEOMETRY_DIRECTION_CW) =>
TypeError: takes at least 3 arguments (2 given)
unsigned int BLPath::addPolyline(const BLPoint* poly, size_t n, BLGeometryDirection dir = BL_GEOMETRY_DIRECTION_CW) =>
TypeError: could not convert argument 1
JIT template instantiation with templates loaded by genreflex
I would like to be able to instantiate templates loaded/precompiled with genreflex in cppyy similar to how they work with cppyy.cppdef
https://cppyy.readthedocs.io/en/latest/stl.html
I'm not sure what changes would need to be made to genreflex to export template definitions. But, it seems like that project is largely uninterested in JIT template instantiation: https://root-forum.cern.ch/t/genreflex-warning-unused-class-rule/24680
Issue when assigning pointers to structure's variable
Hi Wim, again me :)
I've run into another issue with 2.1.0.
It showed up first when assigning pointers-to-pointers (e.g. int**) to a structure's variable.
E.g. take the following:
struct Foo {
int** bar;
};foo = gbl.Foo()
foo.bar = valueThe latter would assign the wrong value incurring then into a seg fault.
When trying to achieve a reproducible, things became even weirder... (see Explanation after)
Reproducible
from cppyy import ll, cppdef, gbl
cppdef("""
template<typename T>
struct Foo {
T* bar;
Foo() {}
Foo(T* other) : bar(other) { }
bool eq(T* other) { return bar == other; }
void print_check(char* msg, T* other) {
printf("%s: %p, other: %p\\n", msg, bar, other);
}
};
template<typename T>
auto create(T* other) {
return Foo<T>(other);
}
""")
for dtype in ["int", "int*", "int**",]:
print("\nType\n", dtype+"*")
bar = ll.malloc[dtype](4)
# Variable assignment
foo = gbl.Foo[dtype]()
foo.bar = bar
foo.print_check("foo.bar", bar)
# Pointer passed to the constructor
foo2 = gbl.Foo[dtype](bar)
foo2.print_check("foo2.bar", bar)
# Pointer passed to a function
foo3 = gbl.create[dtype](bar)
foo3.print_check("foo3.bar", bar)
# These checks can be used for tests
#assert foo.eq(bar)
#assert foo2.eq(bar)
#assert foo3.eq(bar)
ll.free(bar)Explanation
I have tried three different approaches to initialize the structure:
foo: as in the example above, first allocates the structure and then assigns via pythonfoo2: assigns via a constructorfoo3: assigns via a function
For a structure containing int* everything looks fine having an output:
Type int*
foo.bar: 0x55a1e2e30eb0, other: 0x55a1e2e30eb0
foo2.bar: 0x55a1e2e30eb0, other: 0x55a1e2e30eb0
foo3.bar: 0x55a1e2e30eb0, other: 0x55a1e2e30eb0
where all pointers, stored and original (other), are the same.
For a structure containing int** things look very odd, having all pointers different
Type int**
foo.bar: 0x55a1e2e85cb0, other: 0x7ffdaf0f9f30
foo2.bar: 0x7ffdaf0f9ea0, other: 0x7ffdaf0f9f30
foo3.bar: 0x7ffdaf0f9d50, other: 0x7ffdaf0f9f30
Finally, for a structure containing int***, I run into the following error...
Type int***
Traceback (most recent call last):
File "tmp.py", line 35, in <module>
foo.bar = bar
RuntimeError: property type mismatch or assignment not allowed
NotImplementedError with enum namespace
It looks like cppyy might not correctly handle the enum namespace.
This code:
import cppyy
cppyy.cppdef('''
enum foo { FOO };
void foo() {}
void bar( enum foo f) {}
''')
cppyy.gbl.bar( cppyy.gbl.FOO)
- results in:
NotImplementedError: void ::bar(enum foo f) =>
NotImplementedError: could not convert argument 1 (this method cannot (yet) be called)
Removing the void foo() {} function makes things work, so is cppyy/cling being confused by the difference between enum foo and foo?
[Unfortunately the code i'm attempting to wrap with cppyy has exactly this pattern where a function has the same name as an enum.]
Thanks for any help. And for cppyy.
Failed to import CPPYY on PyPy on Windows
I'm on windows 10 64-bit, using PyPy.
Python 3.7.10 (77787b8f4c49, May 15 2021, 11:51:36)
[PyPy 7.3.5 with MSC v.1927 64 bit (AMD64)]
I did a pip install cppyy just now wwhich worked, but actually importing cppyy caused an error:
C:\py>pypy3
Python 3.7.10 (77787b8f4c49, May 15 2021, 11:51:36)
[PyPy 7.3.5 with MSC v.1927 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
import cppyy
Traceback (most recent call last):
File "", line 1, in
File "C:\pypy\site-packages\cppyy_init_.py", line 72, in
from ._pypy_cppyy import *
File "C:\pypy\site-packages\cppyy_pypy_cppyy.py", line 33, in
import _cppyy as _backend # built-in module
ModuleNotFoundError: No module named '_cppyy'
inspect.getmembers() on cppyy.gbl not detecting enums and functions
inspect.getmembers() does not seem to see C++ functions and enums inside
cppyy.gbl. But it does see functions and enums inside a C++ namespace
within cppyy.gbl.
The same behaviour occurs with dir().
This is with cppyy.__version__ = 2.3.0
I understand that cppyy is generally lazy about creating things, but given that
it seems to be able to enumerate functions and enums in a C++ namespace within
cppyy.gbl, i was hoping it would be able to do so for cppyy.gbl itself.
So, is this expected behaviour? Can anything be done to allow detection of
enums and functions within cppyy.gbl?
Python code that demonstrates the problem:
import cppyy
import inspect
def show( namespace):
'''
Show items in <namespace> whose names do not start with an
underscore.
'''
print( f'{namespace}:')
for n, v in inspect.getmembers( namespace):
if not n.startswith( '_'):
print( f' {n}={v}')
# Create some C++ functions, enums and a namespace:
cppyy.cppdef('''
enum { FOO };
void foo() {}
namespace N
{
enum { BAR };
void bar() {}
}
''')
show( cppyy.gbl) # Does not show FOO or foo().
show( cppyy.gbl.N) # Shows BAR and bar().
# foo() and FOO do exist if we ask for them explicitly:
print( f'cppyy.__version__={cppyy.__version__}')
print( f'cppyy.gbl.foo={cppyy.gbl.FOO}')
print( f'cppyy.gbl.foo={cppyy.gbl.foo}')
print( f'cppyy.gbl.N.bar={cppyy.gbl.N.BAR}')
print( f'cppyy.gbl.N.bar={cppyy.gbl.N.bar}')
show( cppyy.gbl) # Now shows FOO and foo().
Output:
<namespace cppyy.gbl at 0x176b020>:
CppyyLegacy=<namespace cppyy.gbl.CppyyLegacy at 0x2466320>
N=<namespace cppyy.gbl.N at 0x2ba5960>
std=<namespace cppyy.gbl.std at 0x176c000>
<namespace cppyy.gbl.N at 0x2ba5960>:
BAR=0
bar=<C++ overload "bar" at 0x7f19213164c0>
cppyy.__version__=2.3.0
cppyy.gbl.foo=0
cppyy.gbl.foo=<C++ overload "foo" at 0x7f1921316900>
cppyy.gbl.N.bar=0
cppyy.gbl.N.bar=<C++ overload "bar" at 0x7f1921706740>
<namespace cppyy.gbl at 0x176b020>:
CppyyLegacy=<namespace cppyy.gbl.CppyyLegacy at 0x2466320>
FOO=0
N=<namespace cppyy.gbl.N at 0x2ba5960>
foo=<C++ overload "foo" at 0x7f1921316680>
std=<namespace cppyy.gbl.std at 0x176c000>
Thanks in advance for any help here.
Segmentation Fault when trying to access an object's property
I am working with the MikePopoloski/slang library. I am trying to walk an AST generated after compiling some code with it. If I call the built-in functions, it is able to walk the tree completely, so I know all the data is there and able to be referenced. When I attempt to walk the tree manually, I get a couple layers deep before hitting a segfault when attempting to check a simple string_view attached to an object. Unfortunately, creating a standalone reproducer of this would be challenging.
This is the object I eventually crash on. The hierarchy would be:
Compilation > DesignTree > Instances[0] > InstanceSymbol > InstancyBodySymbol
Then, when I try to call str(body.name), I get a stack trace. Most of the information looks pretty generic to me, but here it is anyway:
segmentation fault
*** Break *** segmentation violation
#0 0x00007fd0116dc437 in __GI___waitpid (pid=11716, stat_loc=stat_loc
entry=0x7ffdaa45d158, options=options
entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:30
#1 0x00007fd01165a5df in do_system (line=<optimized out>) at ../sysdeps/posix/system.c:149
#2 0x00007fd010e3b355 in CppyyLegacy::TUnixSystem::StackTrace() () from /home/dillan/git_projects/svls/env_dbg/lib/python3.9/site-packages/cppyy_backend/lib/libCoreLegacy.so
#3 0x00007fd00c5a6d08 in (anonymous namespace)::do_trace (sig=1) at src/clingwrapper.cxx:199
#4 (anonymous namespace)::TExceptionHandlerImp::HandleException (this=<optimized out>, sig=1) at src/clingwrapper.cxx:212
#5 0x00007fd010e39e61 in CppyyLegacy::TUnixSystem::DispatchSignals(CppyyLegacy::ESignals) () from /home/dillan/git_projects/svls/env_dbg/lib/python3.9/site-packages/cppyy_backend/lib/libCoreLegacy.so
#6 <signal handler called>
#7 0x00007fd009025a7e in ska::fibonacci_hash_policy::index_for_hash (this=0xffffffff0000032e, hash=94329315036496) at /home/dillan/git_projects/svls/external/slang/source/../external/flat_hash_map.hpp:1274
#8 ska::detailv3::sherwood_v3_table<std::pair<void const*, nonstd::span_lite::span<slang::AttributeSymbol const* const, 18446744073709551615ul> >, void const*, std::hash<void const*>, ska::detailv3::KeyOrValueHasher<void const*, std::pair<void const*, nonstd::span_lite::span<slang::AttributeSymbol const* const, 18446744073709551615ul> >, std::hash<void const*> >, std::equal_to<void const*>, ska::detailv3::KeyOrValueEquality<void const*, std::pair<void const*, nonstd::span_lite::span<slang::AttributeSymbol const* const, 18446744073709551615ul> >, std::equal_to<void const*> >, std::allocator<std::pair<void const*, nonstd::span_lite::span<slang::AttributeSymbol const* const, 18446744073709551615ul> > >, std::allocator<ska::detailv3::sherwood_v3_entry<std::pair<void const*, nonstd::span_lite::span<slang::AttributeSymbol const* const, 18446744073709551615ul> > > > >::find (this=0xffffffff0000031e, key=<optimized out>) at /home/dillan/git_projects/svls/external/slang/source/../external/flat_hash_map.hpp:542
#9 ska::detailv3::sherwood_v3_table<std::pair<void const*, nonstd::span_lite::span<slang::AttributeSymbol const* const, 18446744073709551615ul> >, void const*, std::hash<void const*>, ska::detailv3::KeyOrValueHasher<void const*, std::pair<void const*, nonstd::span_lite::span<slang::AttributeSymbol const* const, 18446744073709551615ul> >, std::hash<void const*> >, std::equal_to<void const*>, ska::detailv3::KeyOrValueEquality<void const*, std::pair<void const*, nonstd::span_lite::span<slang::AttributeSymbol const* const, 18446744073709551615ul> >, std::equal_to<void const*> >, std::allocator<std::pair<void const*, nonstd::span_lite::span<slang::AttributeSymbol const* const, 18446744073709551615ul> > >, std::allocator<ska::detailv3::sherwood_v3_entry<std::pair<void const*, nonstd::span_lite::span<slang::AttributeSymbol const* const, 18446744073709551615ul> > > > >::find (this=0xffffffff0000031e, key=<optimized out>) at /home/dillan/git_projects/svls/external/slang/source/../external/flat_hash_map.hpp:553
#10 slang::Compilation::getAttributes (this=0xffffffff00000006, ptr=<optimized out>) at /home/dillan/git_projects/svls/external/slang/source/compilation/Compilation.cpp:617
#11 slang::Compilation::getAttributes (this=0xffffffff00000006, symbol=...) at /home/dillan/git_projects/svls/external/slang/source/compilation/Compilation.cpp:605
#12 0x00007fd0099fd013 in ?? ()
#13 0x00007ffdaa45fc80 in ?? ()
#14 0x00007fd00c5a68de in WrapperCall (method=94329305792864, nargs=1, args_=0x55cac1c305a0, self=0xffffffff00000006, result=0x55cac1c305a0) at src/clingwrapper.cxx:848
#15 0x00007fd00c5a7646 in Cppyy::CallO (method=method
entry=94329305792864, self=self
entry=0xffffffff00000006, nargs=1, args=0x7ffdaa45fc80, result_type=result_type
entry=89) at src/clingwrapper.cxx:957
#16 0x00007fd00a409110 in GILCallO (klass=89, ctxt=0x7ffdaa45fc60, self=0xffffffff00000006, method=94329305792864) at src/CallContext.h:100
#17 GILCallO (klass=89, ctxt=0x7ffdaa45fc60, self=0xffffffff00000006, method=94329305792864) at src/Executors.cxx:80
#18 CPyCppyy::(anonymous namespace)::InstanceExecutor::Execute (this=0x55cac1c49af0, method=94329305792864, self=0xffffffff00000006, ctxt=0x7ffdaa45fc60) at src/Executors.cxx:592
#19 0x00007fd00a3dcc79 in CPyCppyy::CPPMethod::ExecuteFast (ctxt=<optimized out>, offset=<optimized out>, self=<optimized out>, this=0x55cac0c38370) at src/CPPMethod.cxx:853
#20 CPyCppyy::CPPMethod::Execute (this=0x55cac0c38370, self=<optimized out>, offset=<optimized out>, ctxt=<optimized out>) at src/CPPMethod.cxx:853
#21 0x00007fd00a3dcf96 in CPyCppyy::CPPMethod::Call (this=0x55cac0c38370, self=
0x7fd009bd3990: 0x7fd009a9a600, args=<optimized out>, nargsf=<optimized out>, kwds=<optimized out>, ctxt=0x7ffdaa45fc60) at src/CPPMethod.cxx:913
#22 0x00007fd00a3e15c0 in CPyCppyy::(anonymous namespace)::mp_vectorcall (pymeth=0x7fd009bd3980, args=0x7fd011243970, nargsf=9223372036854775810, kwds=0x0) at src/CPPOverload.cxx:708
#23 0x000055cab73c4141 in _PyObject_VectorcallTstate (kwnames=0x0, nargsf=<optimized out>, args=0x7fd011243970, callable=0x7fd009bd3980, tstate=0x55cab9289250) at ./Include/cpython/abstract.h:118
#24 PyObject_Vectorcall (kwnames=0x0, nargsf=<optimized out>, args=0x7fd011243970, callable=0x7fd009bd3980) at ./Include/cpython/abstract.h:127
#25 call_function (kwnames=0x0, oparg=<optimized out>, pp_stack=<synthetic pointer>, tstate=<optimized out>) at Python/ceval.c:5075
#26 _PyEval_EvalFrameDefault (tstate=<optimized out>, f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:3504
#27 0x000055cab748a055 in _PyEval_EvalFrame (throwflag=0, f=0x7fd011243800, tstate=0x55cab9289250) at ./Include/internal/pycore_ceval.h:40
#28 _PyEval_EvalCode (tstate=0x55cab9289250, _co=_co
entry=0x7fd009a99500, globals=globals
entry=0x7fd011261340, locals=locals
entry=0x7fd011261340, args=args
entry=0x0, argcount=argcount
entry=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0) at Python/ceval.c:4327
#29 0x000055cab748a386 in _PyEval_EvalCodeWithName (qualname=0x0, name=0x0, closure=0x0, kwdefs=0x0, defcount=0, defs=0x0, kwstep=2, kwcount=0, kwargs=0x0, kwnames=0x0, argcount=0, args=0x0, locals=0x7fd011261340, globals=0x7fd011261340, _co=0x7fd009a99500) at Python/ceval.c:4359
#30 PyEval_EvalCodeEx (closure=0x0, kwdefs=0x0, defcount=0, defs=0x0, kwcount=0, kws=0x0, argcount=0, args=0x0, locals=0x7fd011261340, globals=0x7fd011261340, _co=0x7fd009a99500) at Python/ceval.c:4375
#31 PyEval_EvalCode (co=co
entry=0x7fd009a99500, globals=globals
entry=0x7fd011261340, locals=locals
entry=0x7fd011261340) at Python/ceval.c:826
#32 0x000055cab74c7937 in run_eval_code_obj (locals=0x7fd011261340, globals=0x7fd011261340, co=0x7fd009a99500, tstate=0x55cab9289250) at Python/pythonrun.c:1219
#33 run_mod (mod=mod
entry=0x55cab93c0028, filename=filename
entry=0x7fd0111ecaf0, globals=0x7fd011261340, locals=0x7fd011261340, flags=flags
entry=0x7ffdaa460168, arena=arena
entry=0x7fd0111fcbb0) at Python/pythonrun.c:1240
#34 0x000055cab74c90c0 in PyRun_InteractiveOneObjectEx (fp=fp
entry=0x7fd0117d1a00 <_IO_2_1_stdin_>, filename=filename
entry=0x7fd0111ecaf0, flags=flags
entry=0x7ffdaa460168) at Python/pythonrun.c:273
#35 0x000055cab74c9366 in PyRun_InteractiveLoopFlags (fp=fp
entry=0x7fd0117d1a00 <_IO_2_1_stdin_>, filename_str=filename_str
entry=0x55cab75cf132 "<stdin>", flags=flags
entry=0x7ffdaa460168) at Python/pythonrun.c:126
#36 0x000055cab74c9cbe in PyRun_AnyFileExFlags (fp=0x7fd0117d1a00 <_IO_2_1_stdin_>, filename=filename
entry=0x55cab75cf132 "<stdin>", closeit=closeit
entry=0, flags=flags
entry=0x7ffdaa460168) at Python/pythonrun.c:85
#37 0x000055cab73cbc59 in pymain_run_stdin (cf=0x7ffdaa460168, config=0x55cab9287b40) at Modules/main.c:512
#38 pymain_run_python (exitcode=exitcode
entry=0x7ffdaa460290) at Modules/main.c:601
#39 0x000055cab73cc038 in Py_RunMain () at Modules/main.c:677
#40 pymain_main (args=0x7ffdaa460250) at Modules/main.c:707
#41 Py_BytesMain (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:731
#42 0x00007fd01163a09b in __libc_start_main (main=0x55cab73bf6d0 <main>, argc=1, argv=0x7ffdaa460398, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffdaa460388) at ../csu/libc-start.c:308
#43 0x000055cab73cacfa in _start () at Python/ceval.c:5185
*** Break *** segmentation violation
#0 0x00007fd0116dc437 in __GI___waitpid (pid=11980, stat_loc=stat_loc
entry=0x7ffdaa45d158, options=options
entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:30
#1 0x00007fd01165a5df in do_system (line=<optimized out>) at ../sysdeps/posix/system.c:149
#2 0x00007fd010e3b355 in CppyyLegacy::TUnixSystem::StackTrace() () from /home/dillan/git_projects/svls/env_dbg/lib/python3.9/site-packages/cppyy_backend/lib/libCoreLegacy.so
#3 0x00007fd00c5a6b78 in (anonymous namespace)::do_trace (sig=1) at src/clingwrapper.cxx:199
#4 (anonymous namespace)::TExceptionHandlerImp::HandleException (this=<optimized out>, sig=1) at src/clingwrapper.cxx:218
#5 0x00007fd010e39e61 in CppyyLegacy::TUnixSystem::DispatchSignals(CppyyLegacy::ESignals) () from /home/dillan/git_projects/svls/env_dbg/lib/python3.9/site-packages/cppyy_backend/lib/libCoreLegacy.so
#6 <signal handler called>
#7 0x00007fd009025a7e in ska::fibonacci_hash_policy::index_for_hash (this=0xffffffff0000032e, hash=94329315036496) at /home/dillan/git_projects/svls/external/slang/source/../external/flat_hash_map.hpp:1274
#8 ska::detailv3::sherwood_v3_table<std::pair<void const*, nonstd::span_lite::span<slang::AttributeSymbol const* const, 18446744073709551615ul> >, void const*, std::hash<void const*>, ska::detailv3::KeyOrValueHasher<void const*, std::pair<void const*, nonstd::span_lite::span<slang::AttributeSymbol const* const, 18446744073709551615ul> >, std::hash<void const*> >, std::equal_to<void const*>, ska::detailv3::KeyOrValueEquality<void const*, std::pair<void const*, nonstd::span_lite::span<slang::AttributeSymbol const* const, 18446744073709551615ul> >, std::equal_to<void const*> >, std::allocator<std::pair<void const*, nonstd::span_lite::span<slang::AttributeSymbol const* const, 18446744073709551615ul> > >, std::allocator<ska::detailv3::sherwood_v3_entry<std::pair<void const*, nonstd::span_lite::span<slang::AttributeSymbol const* const, 18446744073709551615ul> > > > >::find (this=0xffffffff0000031e, key=<optimized out>) at /home/dillan/git_projects/svls/external/slang/source/../external/flat_hash_map.hpp:542
#9 ska::detailv3::sherwood_v3_table<std::pair<void const*, nonstd::span_lite::span<slang::AttributeSymbol const* const, 18446744073709551615ul> >, void const*, std::hash<void const*>, ska::detailv3::KeyOrValueHasher<void const*, std::pair<void const*, nonstd::span_lite::span<slang::AttributeSymbol const* const, 18446744073709551615ul> >, std::hash<void const*> >, std::equal_to<void const*>, ska::detailv3::KeyOrValueEquality<void const*, std::pair<void const*, nonstd::span_lite::span<slang::AttributeSymbol const* const, 18446744073709551615ul> >, std::equal_to<void const*> >, std::allocator<std::pair<void const*, nonstd::span_lite::span<slang::AttributeSymbol const* const, 18446744073709551615ul> > >, std::allocator<ska::detailv3::sherwood_v3_entry<std::pair<void const*, nonstd::span_lite::span<slang::AttributeSymbol const* const, 18446744073709551615ul> > > > >::find (this=0xffffffff0000031e, key=<optimized out>) at /home/dillan/git_projects/svls/external/slang/source/../external/flat_hash_map.hpp:553
#10 slang::Compilation::getAttributes (this=0xffffffff00000006, ptr=<optimized out>) at /home/dillan/git_projects/svls/external/slang/source/compilation/Compilation.cpp:617
#11 slang::Compilation::getAttributes (this=0xffffffff00000006, symbol=...) at /home/dillan/git_projects/svls/external/slang/source/compilation/Compilation.cpp:605
#12 0x00007fd0099fd013 in ?? ()
#13 0x00007ffdaa45fc80 in ?? ()
#14 0x00007fd00c5a68de in WrapperCall (method=94329305792864, nargs=1, args_=0x55cac1c305a0, self=0xffffffff00000006, result=0x55cac1c305a0) at src/clingwrapper.cxx:848
#15 0x00007fd00c5a7646 in Cppyy::CallO (method=method
entry=94329305792864, self=self
entry=0xffffffff00000006, nargs=1, args=0x7ffdaa45fc80, result_type=result_type
entry=89) at src/clingwrapper.cxx:957
#16 0x00007fd00a409110 in GILCallO (klass=89, ctxt=0x7ffdaa45fc60, self=0xffffffff00000006, method=94329305792864) at src/CallContext.h:100
#17 GILCallO (klass=89, ctxt=0x7ffdaa45fc60, self=0xffffffff00000006, method=94329305792864) at src/Executors.cxx:80
#18 CPyCppyy::(anonymous namespace)::InstanceExecutor::Execute (this=0x55cac1c49af0, method=94329305792864, self=0xffffffff00000006, ctxt=0x7ffdaa45fc60) at src/Executors.cxx:592
#19 0x00007fd00a3dcc79 in CPyCppyy::CPPMethod::ExecuteFast (ctxt=<optimized out>, offset=<optimized out>, self=<optimized out>, this=0x55cac0c38370) at src/CPPMethod.cxx:853
#20 CPyCppyy::CPPMethod::Execute (this=0x55cac0c38370, self=<optimized out>, offset=<optimized out>, ctxt=<optimized out>) at src/CPPMethod.cxx:853
#21 0x00007fd00a3dcf96 in CPyCppyy::CPPMethod::Call (this=0x55cac0c38370, self=
0x7fd009bd3990: 0x7fd009a9a600, args=<optimized out>, nargsf=<optimized out>, kwds=<optimized out>, ctxt=0x7ffdaa45fc60) at src/CPPMethod.cxx:913
#22 0x00007fd00a3e15c0 in CPyCppyy::(anonymous namespace)::mp_vectorcall (pymeth=0x7fd009bd3980, args=0x7fd011243970, nargsf=9223372036854775810, kwds=0x0) at src/CPPOverload.cxx:708
#23 0x000055cab73c4141 in _PyObject_VectorcallTstate (kwnames=0x0, nargsf=<optimized out>, args=0x7fd011243970, callable=0x7fd009bd3980, tstate=0x55cab9289250) at ./Include/cpython/abstract.h:118
#24 PyObject_Vectorcall (kwnames=0x0, nargsf=<optimized out>, args=0x7fd011243970, callable=0x7fd009bd3980) at ./Include/cpython/abstract.h:127
#25 call_function (kwnames=0x0, oparg=<optimized out>, pp_stack=<synthetic pointer>, tstate=<optimized out>) at Python/ceval.c:5075
#26 _PyEval_EvalFrameDefault (tstate=<optimized out>, f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:3504
#27 0x000055cab748a055 in _PyEval_EvalFrame (throwflag=0, f=0x7fd011243800, tstate=0x55cab9289250) at ./Include/internal/pycore_ceval.h:40
#28 _PyEval_EvalCode (tstate=0x55cab9289250, _co=_co
entry=0x7fd009a99500, globals=globals
entry=0x7fd011261340, locals=locals
entry=0x7fd011261340, args=args
entry=0x0, argcount=argcount
entry=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0) at Python/ceval.c:4327
#29 0x000055cab748a386 in _PyEval_EvalCodeWithName (qualname=0x0, name=0x0, closure=0x0, kwdefs=0x0, defcount=0, defs=0x0, kwstep=2, kwcount=0, kwargs=0x0, kwnames=0x0, argcount=0, args=0x0, locals=0x7fd011261340, globals=0x7fd011261340, _co=0x7fd009a99500) at Python/ceval.c:4359
#30 PyEval_EvalCodeEx (closure=0x0, kwdefs=0x0, defcount=0, defs=0x0, kwcount=0, kws=0x0, argcount=0, args=0x0, locals=0x7fd011261340, globals=0x7fd011261340, _co=0x7fd009a99500) at Python/ceval.c:4375
#31 PyEval_EvalCode (co=co
entry=0x7fd009a99500, globals=globals
entry=0x7fd011261340, locals=locals
entry=0x7fd011261340) at Python/ceval.c:826
#32 0x000055cab74c7937 in run_eval_code_obj (locals=0x7fd011261340, globals=0x7fd011261340, co=0x7fd009a99500, tstate=0x55cab9289250) at Python/pythonrun.c:1219
#33 run_mod (mod=mod
entry=0x55cab93c0028, filename=filename
entry=0x7fd0111ecaf0, globals=0x7fd011261340, locals=0x7fd011261340, flags=flags
entry=0x7ffdaa460168, arena=arena
entry=0x7fd0111fcbb0) at Python/pythonrun.c:1240
#34 0x000055cab74c90c0 in PyRun_InteractiveOneObjectEx (fp=fp
entry=0x7fd0117d1a00 <_IO_2_1_stdin_>, filename=filename
entry=0x7fd0111ecaf0, flags=flags
entry=0x7ffdaa460168) at Python/pythonrun.c:273
#35 0x000055cab74c9366 in PyRun_InteractiveLoopFlags (fp=fp
entry=0x7fd0117d1a00 <_IO_2_1_stdin_>, filename_str=filename_str
entry=0x55cab75cf132 "<stdin>", flags=flags
entry=0x7ffdaa460168) at Python/pythonrun.c:126
#36 0x000055cab74c9cbe in PyRun_AnyFileExFlags (fp=0x7fd0117d1a00 <_IO_2_1_stdin_>, filename=filename
entry=0x55cab75cf132 "<stdin>", closeit=closeit
entry=0, flags=flags
entry=0x7ffdaa460168) at Python/pythonrun.c:85
#37 0x000055cab73cbc59 in pymain_run_stdin (cf=0x7ffdaa460168, config=0x55cab9287b40) at Modules/main.c:512
#38 pymain_run_python (exitcode=exitcode
entry=0x7ffdaa460290) at Modules/main.c:601
#39 0x000055cab73cc038 in Py_RunMain () at Modules/main.c:677
#40 pymain_main (args=0x7ffdaa460250) at Modules/main.c:707
#41 Py_BytesMain (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:731
#42 0x00007fd01163a09b in __libc_start_main (main=0x55cab73bf6d0 <main>, argc=1, argv=0x7ffdaa460398, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffdaa460388) at ../csu/libc-start.c:308
#43 0x000055cab73cacfa in _start () at Python/ceval.c:5185
Debian 10, python 3.9.7 with debug options installed, cppyy 2.1.0
If you are feeling up to installing slang, I would be happy to assist and provide a reproducer. Otherwise, any help would be appreciated.
cpycppyy api not found
With cppyy 2.1.0 (installed by pip) i get the warning
/usr/local/lib/python3.8/dist-packages/cppyy/__init__.py:318: UserWarning: CPyCppyy API not found (tried: /usr/local/lib/python3.8/dist-packages/../../../include/python3.8); set CPPYY_API_PATH envar to the 'CPyCppyy' API directory to fix
warnings.warn("CPyCppyy API not found (tried: %s); set CPPYY_API_PATH envar to the 'CPyCppyy' API directory to fix" % apipath_extra)
same in venv (installed by pipenv):
/home/gateway/.local/share/virtualenvs/cmmlpipy-EDRQn1Yr/lib/python3.8/site-packages/cppyy/__init__.py:318: UserWarning: CPyCppyy API not found (tried: /home/gateway/.local/share/virtualenvs/cmmlpipy-EDRQn1Yr/lib/python3.8/site-packages/../../../include/site/python3.8); set CPPYY_API_PATH envar to the 'CPyCppyy' API directory to fix
warnings.warn("CPyCppyy API not found (tried: %s); set CPPYY_API_PATH envar to the 'CPyCppyy' API directory to fix" % apipath_extra)
According to pipenv it is installed:
cppyy==2.1.0
- cppyy-backend [required: ==1.14.6, installed: 1.14.6]
- cppyy-cling [required: >=6.25.1, installed: 6.25.1]
- cppyy-cling [required: ==6.25.1, installed: 6.25.1]
- CPyCppyy [required: ==1.12.7, installed: 1.12.7]
- cppyy-backend [required: >=1.14.6, installed: 1.14.6]
- cppyy-cling [required: >=6.25.1, installed: 6.25.1]
- cppyy-cling [required: >=6.25.1, installed: 6.25.1]
Should find that in a regular installation by himself?
Due to the truncated path, i don't know where exactly to look at..
Docker Ubuntu 20.04 CPython 3.8.10 GCC 9.4.0
WSL2 Ubuntu 20.04 CPython 3.8.5 GCC 9.3.0 (venv)
After that I get a segmentation violation, don't know if it is due to this warning (just on Docker, not on WSL2, there it just does not work anymore. Worked with cppyy 1.7.1 on both environments):
0x00007f755a8e97ae in <unknown> from /usr/local/lib/python3.8/dist-packages/cppyy_backend/lib/libcppyy_backend.so
0x00007f755a8e9ef6 in Cppyy::CallI(long, void*, unsigned long, void*) at /tmp/pip-install-w15h9p76/cppyy-backend/src/clingwrapper.cxx:887 from /usr/local/lib/python3.8/dist-packages/cppyy_backend/lib/libcppyy_backend.so
0x00007f755865a8b4 in <unknown> from /usr/local/lib/python3.8/dist-packages/libcppyy.cpython-38-x86_64-linux-gnu.so
0x00007f75586688c6 in CPyCppyy::CPPMethod::ExecuteFast(void*, long, CPyCppyy::CallContext*) at /tmp/pip-install-w15h9p76/cpycppyy/src/CPPMethod.cxx:182 from /usr/local/lib/python3.8/dist-packages/libcppyy.cpython-38-x86_64-linux-gnu.so
0x00007f75586671e5 in CPyCppyy::CPPMethod::Execute(void*, long, CPyCppyy::CallContext*) at /tmp/pip-install-w15h9p76/cpycppyy/src/CPPMethod.cxx:853 from /usr/local/lib/python3.8/dist-packages/libcppyy.cpython-38-x86_64-linux-gnu.so
0x00007f75586657df in CPyCppyy::CPPFunction::Call(CPyCppyy::CPPInstance*&, _object* const*, unsigned long, _object*, CPyCppyy::CallContext*) at /tmp/pip-install-w15h9p76/cpycppyy/src/CPPFunction.cxx:89 from /usr/local/lib/python3.8/dist-packages/libcppyy.cpython-38-x86_64-linux-gnu.so
0x00007f755867ea3f in <unknown> from /usr/local/lib/python3.8/dist-packages/libcppyy.cpython-38-x86_64-linux-gnu.so
0x000000000056fb87 in _PyEval_EvalFrameDefault + 0x57d7 from python3
No stack trace: cannot find (functions in) dbghelp.dll
Hi,
I'm trying to make sil-cling work on Windows, but whenever there's an error I get
No stack trace: cannot find (functions in) dbghelp.dll!, so I'm not able to see the stack trace. I've googled this error message and it seems that it comes from here, but I've checked and I have both dbghelp.dll and imagehlp.dll in PATH.
Any ideas what could go wrong?
[Question] Include <windows.h> on Linux
I just want to get all the types information from Windows.h.
I tried copy the whole include directory from my windows machine then manually call add_include_path but doesn't work (gave lots off syntax error).
Any compiler/environment setup do I need to get this to work and what API I need to call to do that ? Thanks in advance.
Building from source produces an error when importing: "Error: Problems loading PCH"
I followed the instructions in https://cppyy.readthedocs.io/en/latest/repositories.html#building-from-source without any issues, everything built fine. When attempting to import, I get the following:
> python
Python 3.8.5 (default, Jul 26 2020, 02:44:08)
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import cppyy
error: Problems loading PCH: './env/lib/python3.8/site-packages/cppyy/allDict.cxx.pch.6.25.1'.
There is no other output. If I attempt to use the package, it crashes with a stacktrace. I assume there must be some incompatibility with my build environment. I am running on Debian 10. I have clang++-11 installed but I am not sure if it is getting picked up or not.
cppyy fails to find template type with template type as final parameter
If the final parameter of a templated typedef is a template type, then cppyy fails to find the type (unless the template type is the only parameter).
import cppyy
cppyy.cppdef('''
template<class T>
class F;
template<class T>
class V;
using i = F<void (int)>;
using v = F<void (V<int>)>;
using ii = F<void (int,int)>;
using iv = F<void (int,V<int>)>;
using vi = F<void (V<int>,int)>;
using vv = F<void (V<int>,V<int>)>;
using iii = F<void (int,int,int)>;
using ivi = F<void (int,V<int>,int)>;
using vii = F<void (V<int>,int,int)>;
using vvi = F<void (V<int>,V<int>,int)>;
using iiv = F<void (int,int,V<int>)>;
using ivv = F<void (int,V<int>,V<int>)>;
using viv = F<void (V<int>,int,V<int>)>;
using vvv = F<void (V<int>,V<int>,V<int>)>;
''')
if __name__ == '__main__':
for t in ['i','v',
'ii', 'iv', 'vi', 'vv',
'iii', 'ivi', 'vii', 'vvi',
'iiv', 'ivv', 'viv', 'vvv']:
try:
cpp = getattr(cppyy.gbl,t)
print(f'{t:5} ok')
except AttributeError as e:
print(f'{t:5} not found')results in
i ok
v ok
ii ok
iv not found
vi ok
vv not found
iii ok
ivi ok
vii ok
vvi ok
iiv not found
ivv not found
viv not found
vvv not found
Real-world use of this was using std::function for F and std::vector for V, and various different types instead of int.
Error in CMake interface due to tentative of calling non-existing default constructor
Hi, I have been trying to wrap a lib of mine using the CMake interface and I am getting an error about calling non-existing default constructor.
I was able to reduce the issue and reproduce the error in the demo application https://github.com/jclay/cppyy-knearestneighbors-example.
To make the error arise, one simply goes to https://github.com/jclay/cppyy-knearestneighbors-example/blob/master/nearest_neighbors.h#L8 and deletes the default constructor of Point (which is not necessary in the remaining code).
It seems that the error is somehow related to the fact that std::vector<Point> is being used on some code.
I'm happy to provide further info if the error is not reproducible.
Compiling with -fvisibilty=hidden on macOS breaks hashing
When building a shared library on macOS with -g -fvisibility=hidden and the conda-forge compilers, the symbol table contains some unresolved symbols. I guess this is the expected behaviour somehow but I don't understand how macOS works here:
000000000002e1a0 lw F __TEXT,__text std::__1::hash<exactreal::Element<exactreal::RationalField> >::operator()(exactreal::Element<exactreal::RationalField> const&) const
000000000002e1a0 l d *UND* std::__1::hash<exactreal::Element<exactreal::RationalField> >::operator()(exactreal::Element<exactreal::RationalField> const&) const
Invoking this hash function from cppyy prints a warning and produces the wrong result:
>>> from pyexactreal import ExactReals
>>> x = ExactReals().random_element()
>>> import cppyy
>>> cppyy.gbl.std.hash[type(x._backend)]()(x._backend)
IncrementalExecutor::executeFunction: symbol '_ZNKSt3__14hashIN9exactreal7ElementINS1_13RationalFieldEEEEclERKS4_' unresolved while linking symbol '__cf_27'!
You are probably missing the definition of std::__1::hash<exactreal::Element<exactreal::RationalField> >::operator()(exactreal::Element<exactreal::RationalField> const&) const
Maybe you need to load the corresponding shared library?
18446744073709551615
When I invoke this method indirectly through Python's hash(), I get:
>>> hash(x._backend)
SystemError: <built-in function hash> returned NULL without setting an error
As soon as I drop -fvisibility=hidden from my CXXFLAGS when building the shared library, everything works.
I originally reported that this was caused by -g. I got myself confused by looking at too many CI runs here. I can reproduce this locally with -fvisibility=hidden in macOS.
Segfault with std::forward invocation
A segfault showed up for me when upgrading flatsurf from cppyy 1.9.* to 2.1.0.
The problem seems to be related to move semantics and std::forward.
import cppyy
cppyy.include('gmpxx.h')
cppyy.load_library('gmp')
cppyy.load_library('gmpxx')
cppyy.cppdef(r'''
struct V {
V(mpq_class&& x, mpq_class&& y): x(std::move(x)), y(std::move(y)) {}
template <typename X, typename Y, std::enable_if_t<!std::is_convertible_v<X, mpq_class> || !std::is_convertible_v<Y, mpq_class>, int> = 0>
V(X&& x, Y&& y): V(static_cast<mpq_class>(std::forward<X>(x)), static_cast<mpq_class>(std::forward<Y>(y))) {}
mpq_class x,y;
};
''')
cppyy.cppdef(r'''
V f() {
return V(0, mpq_class{});
}
''')
print(cppyy.gbl.f()) # works
def f():
return cppyy.gbl.V(0, cppyy.gbl.mpq_class())
print(f()) # prints, then segfaults.I might be doing something wrong here somehow but this used to work with older versions of cppyy.
I am seeing the segfault with the latest version of cppyy from conda-forge on Linux.
Is it possible to generate bindings on Windows?
Given a header file, is it possible to generate bindings on Windows and create an extension module without requiring Cling at runtime. There's something like this in the docs but it's only for CMake I think.
build fails with CPython2.7
Hi again.
Trying to build with python 2.7 this time for older setups. The readthedocs page says
so it seems it should be supported, but following the same steps as for python3 building from sources, I get
$ git clone https://github.com/wlav/cppyy-backend.git
Cloning into 'cppyy-backend'...
$ cd cppyy-backend
$ git checkout cppyy-cling-6.25.2
$ cd cling
$ python setup.py egg_info
Traceback (most recent call last):
File "setup.py", line 395, in <module>
packages=find_packages('python', include=['cppyy_backend']),
TypeError: find_packages() got an unexpected keyword argument 'include'
No module named '_cppyy' on PyPy windows
I am using windows 10 64bit with PyPy, I installed cppyy using pip, when I try to import cppyy I get this error
>>>> import cppyy
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "D:\pypy\lib\site-packages\cppyy\__init__.py", line 78, in <module>
from ._pypy_cppyy import *
File "D:\pypy\lib\site-packages\cppyy\_pypy_cppyy.py", line 33, in <module>
import _cppyy as _backend # built-in module
ModuleNotFoundError: No module named '_cppyy'
This happens with all versions of PyPy (3.9, 3.8...), when I tried to use wsl it worked, but I don't think that's ideal.
I know there is #1 but that is a year old issue and I don't know if it was fixed and it's just me having problems or it's still doing this.
Thanks for any answer
Update 1.7.1 -> 2.1.0: typedefed enums as argument not longer working
With cppyy version 1.7.1 i wrapped many functions with pointer (=output) arguments and typedefed stuff. For example C++ function:
MLPI_API MLPIRESULT mlpiLogicGetTypeOfSymbol(const MLPIHANDLE connection, const WCHAR16 *symbol, MlpiLogicType *type, MlpiLogicType *subtype=0);
typedef enum MlpiLogicType
{
MLPI_LOGIC_TYPE_BOOL = 0, //!< 1 Byte (BOOL8)
MLPI_LOGIC_TYPE_BIT = 1, //!< Symbolic access unsupported (1 Bit)
<snipp>
MLPI_LOGIC_TYPE_UNSUPPORTED = 255 //!< Symbolic access unsupported
} MlpiLogicType;
In 1.7.1 it was running like that:
def MLPIGetSymbolType(self, symbol:str, layer:int) -> int:
varType = ctypes.c_uint(0)
subtype = ctypes.c_uint(0)
ret = cppyy.gbl.mlpiLogicGetTypeOfSymbol(self.con.value, symbol, ctypes.pointer(varType), ctypes.pointer(subtype))
if ret != 0x360000:
raise Exception("MLPI Error: " + str(ret))
if layer == 0:
return varType.value
else:
return subtype.value
Pretty straight forward. But with 2.1.0 it drops:
TypeError: int ::mlpiLogicGetTypeOfSymbol(const MLPIHANDLE connection, const WCHAR16* symbol, MlpiLogicType* type, MlpiLogicType* subtype = 0) =>
TypeError: could not convert argument 3 (could not convert argument to buffer or nullptr)
What do you mean by that? Am I not longer allowed to send arguments to a buffer? Sorry, I don't get it.
extern C function in a namespace cannot be accessed
I am new to cppyy, not sure if this is an issue or simply I didn't get the right way to use it.
It seems that if a function is declared as extern "C" then it is not accessible from cppyy.
Here is a quick way to test it:
$ cat test.h
namespace test {
extern "C" int test_extern_c(void);
int test_normal(void);
}
$ python3
Python 3.10.0+ (heads/v3.10-dirty:099a94fba3, Nov 5 2021, 13:02:25) [GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import cppyy
>>> cppyy.include("test.h")
True
>>> cppyy.gbl.test.test_normal
<cppyy.CPPOverload object at 0x7f1dfb343340>
>>> cppyy.gbl.test.test_extern_c
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: <namespace cppyy.gbl.test at 0x561e5d770300> has no attribute 'test_extern_c'. Full details:
type object 'test' has no attribute 'test_extern_c'
'test::test_extern_c' is not a known C++ class
'test_extern_c' is not a known C++ template
'test_extern_c' is not a known C++ enum
>>>
>>> cppyy.gbl.test_extern_c
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: <namespace cppyy.gbl at 0x561e5bf3e580> has no attribute 'test_extern_c'. Full details:
type object '' has no attribute 'test_extern_c'
'test_extern_c' is not a known C++ class
'test_extern_c' is not a known C++ template
'test_extern_c' is not a known C++ enum
>>>
Did I miss anything?
Thanks a lot.
C-array's shape deduced wrongly for certain types
Hi,
the shape of c-style arrays is deduced wrongly for various types.
This happens for instance for char, enum, void* and probably others.
Here a way to reproduce the issue:
import cppyy
cppyy.cppdef("""
enum Enum{One, Two, Three};
template<typename T>
struct Foo {
T a[5];
T aa[5][4];
T aaa[5][4][3];
};
""")
for dtype in ["int", "double", "long", "bool", "char", "void*", "Enum"]:
foo = cppyy.gbl.Foo[dtype]()
print(dtype, foo.a.shape, foo.aa.shape, foo.aaa.shape)And the output with cppyy==2.1.0 is
int (5,) (5, 4) (5, 4, 3)
double (5,) (5, 4) (5, 4, 3)
long (5,) (5, 4) (5, 4, 3)
bool (5,) (5, 4) (5, 4, 3)
char (1,) (268435455,) (268435455,)
void* (5,) (268435455,) (268435455,)
Enum (5,) (268435455,) (268435455,)
Clearly one would expect for any datatype the shapes (5,) (5, 4) (5, 4, 3). As you can see, though, for enum and void* it fails to deduce the shape of array of array, while for char already the shape of a single array is wrong being (1,) and not (5,).
Thanks a lot in advance!
CppyLegacy errors
Building topologicPy on Windows 10 used to work fine, but when I just tried to re-build it today (using Visual Studio 2019), it gave me these errors.
The steps are:
Create a topologicbim working folder
cd C:/Users/homefolder/topologicbim
git clone https://github.com/wassimj/topologicPy.git
cd C:/Users/homefolder/topologicbim/topologicPy/cpython
python setup.py build
python setup.py install
C:\Users\wassi\topologicbim>cd topologicPy/cpython
C:\Users\wassi\topologicbim\topologicPy\cpython>python setup.py build
running build
running build_py
creating build
creating build\lib
creating build\lib\topologic
copying .\topologic\__init__.py -> build\lib\topologic
C:\Users\wassi\topologicbim\topologicPy\cpython>python setup.py install
running install
running bdist_egg
running egg_info
creating topologic.egg-info
writing topologic.egg-info\PKG-INFO
writing dependency_links to topologic.egg-info\dependency_links.txt
writing requirements to topologic.egg-info\requires.txt
writing top-level names to topologic.egg-info\top_level.txt
writing manifest file 'topologic.egg-info\SOURCES.txt'
reading manifest file 'topologic.egg-info\SOURCES.txt'
writing manifest file 'topologic.egg-info\SOURCES.txt'
installing library code to build\bdist.win-amd64\egg
running install_lib
running build_py
creating build\bdist.win-amd64
creating build\bdist.win-amd64\egg
creating build\bdist.win-amd64\egg\topologic
copying build\lib\topologic\__init__.py -> build\bdist.win-amd64\egg\topologic
byte-compiling build\bdist.win-amd64\egg\topologic\__init__.py to __init__.cpython-38.pyc
creating build\bdist.win-amd64\egg\EGG-INFO
copying topologic.egg-info\PKG-INFO -> build\bdist.win-amd64\egg\EGG-INFO
copying topologic.egg-info\SOURCES.txt -> build\bdist.win-amd64\egg\EGG-INFO
copying topologic.egg-info\dependency_links.txt -> build\bdist.win-amd64\egg\EGG-INFO
copying topologic.egg-info\requires.txt -> build\bdist.win-amd64\egg\EGG-INFO
copying topologic.egg-info\top_level.txt -> build\bdist.win-amd64\egg\EGG-INFO
zip_safe flag not set; analyzing archive contents...
topologic.__pycache__.__init__.cpython-38: module references __file__
creating dist
creating 'dist\topologic-0.5-py3.8.egg' and adding 'build\bdist.win-amd64\egg' to it
removing 'build\bdist.win-amd64\egg' (and everything under it)
Processing topologic-0.5-py3.8.egg
creating c:\users\wassi\anaconda3\lib\site-packages\topologic-0.5-py3.8.egg
Extracting topologic-0.5-py3.8.egg to c:\users\wassi\anaconda3\lib\site-packages
Removing topologic 0.2 from easy-install.pth file
Adding topologic 0.5 to easy-install.pth file
Installed c:\users\wassi\anaconda3\lib\site-packages\topologic-0.5-py3.8.egg
Processing dependencies for topologic==0.5
Searching for cppyy>=1.9.4
Reading https://pypi.org/simple/cppyy/
Downloading https://files.pythonhosted.org/packages/e8/24/3f956ffa96ae33e0ce8ac27ffa19b4467755115b6701315efb55508fc7c5/cppyy-2.1.0.tar.gz#sha256=e5feb67fe6af2314da8ced934b2966ec3dd55a4649462b21607a2f51de1d0b27
Best match: cppyy 2.1.0
Processing cppyy-2.1.0.tar.gz
Writing C:\Users\wassi\AppData\Local\Temp\easy_install-3swie2ai\cppyy-2.1.0\setup.cfg
Running cppyy-2.1.0\setup.py -q bdist_egg --dist-dir C:\Users\wassi\AppData\Local\Temp\easy_install-3swie2ai\cppyy-2.1.0\egg-dist-tmp-5r45c506
no previously-included directories found matching 'test'
no previously-included directories found matching 'doc'
creating c:\users\wassi\anaconda3\lib\site-packages\cppyy-2.1.0-py3.8.egg
Extracting cppyy-2.1.0-py3.8.egg to c:\users\wassi\anaconda3\lib\site-packages
Adding cppyy 2.1.0 to easy-install.pth file
Installed c:\users\wassi\anaconda3\lib\site-packages\cppyy-2.1.0-py3.8.egg
Searching for cppyy-cling==6.25.1
Reading https://pypi.org/simple/cppyy-cling/
Downloading https://files.pythonhosted.org/packages/85/74/44734dc6163e97736beb29aa71d39ccf1b90969d3a722f5ad17b37a4a19a/cppyy_cling-6.25.1-py2.py3-none-win_amd64.whl#sha256=da5fd43598bf643fbfed9bbc2f8b044058c30517e556eabf418159deb86c8884
Best match: cppyy-cling 6.25.1
Processing cppyy_cling-6.25.1-py2.py3-none-win_amd64.whl
Installing cppyy_cling-6.25.1-py2.py3-none-win_amd64.whl to c:\users\wassi\anaconda3\lib\site-packages
Adding cppyy-cling 6.25.1 to easy-install.pth file
Installing cling-config-script.py script to C:\Users\wassi\anaconda3\Scripts
Installing cling-config.exe script to C:\Users\wassi\anaconda3\Scripts
Installing cppyy-generator-script.py script to C:\Users\wassi\anaconda3\Scripts
Installing cppyy-generator.exe script to C:\Users\wassi\anaconda3\Scripts
Installing genreflex-script.py script to C:\Users\wassi\anaconda3\Scripts
Installing genreflex.exe script to C:\Users\wassi\anaconda3\Scripts
Installing rootcling-script.py script to C:\Users\wassi\anaconda3\Scripts
Installing rootcling.exe script to C:\Users\wassi\anaconda3\Scripts
Installed c:\users\wassi\anaconda3\lib\site-packages\cppyy_cling-6.25.1-py3.8-win-amd64.egg
Searching for cppyy-backend==1.14.6
Reading https://pypi.org/simple/cppyy-backend/
Downloading https://files.pythonhosted.org/packages/c6/81/fda1986538c6c9135fb528abacccab717fab988c010f1d9edf7aab613ed2/cppyy-backend-1.14.6.tar.gz#sha256=42598fc1f578ccd389a8c5a5410f57809726dce758185585c3a2ab1d72bd4ed3
Best match: cppyy-backend 1.14.6
Processing cppyy-backend-1.14.6.tar.gz
Writing C:\Users\wassi\AppData\Local\Temp\easy_install-qwb7m9uq\cppyy-backend-1.14.6\setup.cfg
Running cppyy-backend-1.14.6\setup.py -q bdist_egg --dist-dir C:\Users\wassi\AppData\Local\Temp\easy_install-qwb7m9uq\cppyy-backend-1.14.6\egg-dist-tmp-_j_5hpfq
cl : Command line warning D9025 : overriding '/EHc' with '/EHc-'
clingwrapper.cxx
C:\Users\wassi\anaconda3\lib\site-packages\cppyy_backend\include\ROOT\libcpp_string_view.h(193): warning C4068: unknown pragma
src\clingwrapper.cxx(362): error C2660: 'CppyyLegacy::TInterpreter::Declare': function does not take 2 arguments
C:\Users\wassi\anaconda3\lib\site-packages\cppyy_backend\include\TInterpreter.h(149): note: see declaration of 'CppyyLegacy::TInterpreter::Declare'
src\clingwrapper.cxx(786): error C2660: 'CppyyLegacy::TInterpreter::CallFunc_IFacePtr': function does not take 2 arguments
C:\Users\wassi\anaconda3\lib\site-packages\cppyy_backend\include\TInterpreter.h(302): note: see declaration of 'CppyyLegacy::TInterpreter::CallFunc_IFacePtr'
src\clingwrapper.cxx(825): error C2039: 'fDirect': is not a member of 'CppyyLegacy::TInterpreter::CallFuncIFacePtr_t'
C:\Users\wassi\anaconda3\lib\site-packages\cppyy_backend\include\TInterpreter.h(82): note: see declaration of 'CppyyLegacy::TInterpreter::CallFuncIFacePtr_t'
src\clingwrapper.cxx(844): error C2039: 'fDirect': is not a member of 'CppyyLegacy::TInterpreter::CallFuncIFacePtr_t'
C:\Users\wassi\anaconda3\lib\site-packages\cppyy_backend\include\TInterpreter.h(82): note: see declaration of 'CppyyLegacy::TInterpreter::CallFuncIFacePtr_t'
src\clingwrapper.cxx(844): error C2530: 'fgen': references must be initialized
src\clingwrapper.cxx(848): error C3536: 'fgen': cannot be used before it is initialized
src\clingwrapper.cxx(848): error C2064: term does not evaluate to a function taking 4 arguments
src\clingwrapper.cxx(852): error C2064: term does not evaluate to a function taking 4 arguments
src\clingwrapper.cxx(1431): error C2660: 'CppyyLegacy::TInterpreter::Declare': function does not take 2 arguments
C:\Users\wassi\anaconda3\lib\site-packages\cppyy_backend\include\TInterpreter.h(149): note: see declaration of 'CppyyLegacy::TInterpreter::Declare'
error: Setup script exited with error: command 'C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Community\\VC\\Tools\\MSVC\\14.26.28801\\bin\\HostX86\\x64\\cl.exe' failed with exit status 2
Different results when checking value in c++ vs. python
Hi, I am working with a C++ library called slang. I have a simple example here that is causing me some trouble:
import cppyy
############################################################################
# Set up cppyy (runs from root directory)
############################################################################
# cppyy.ll.set_signals_as_exception(True)
cppyy.add_include_path('include')
cppyy.add_include_path('external')
cppyy.add_include_path('build/source')
cppyy.include('slang/syntax/SyntaxTree.h')
cppyy.load_library('build/lib/libslangcore')
cppyy.load_library('build/lib/libslangparser')
cppyy.load_library('build/lib/libslangruntime')
cppyy.load_library('build/lib/libslangcompiler')
############################################################################
slang = cppyy.gbl.slang
t1 = slang.SyntaxTree.fromText('always_ff')
t2 = slang.SyntaxTree.fromText(' always_ff')
kind1 = t1.root().childToken(1).kind
kind2 = t2.root().childToken(1).kind
cppyy.cppdef('''
namespace slang {
#include "slang/syntax/SyntaxTree.h"
auto t1 = SyntaxTree::fromText("always_ff");
auto t2 = SyntaxTree::fromText(" always_ff");
auto kind1 = t1->root().childToken(1).kind;
auto kind2 = t2->root().childToken(1).kind;
}
''')
print('python kind1: %d, kind2: %d' % (kind1, kind2))
print('c++ kind1: %d, kind2: %d' % (slang.kind1, slang.kind2))
print('combo kind1: %d, kind2: %d' % (slang.t1.root().childToken(1).kind, slang.t2.root().childToken(1).kind))
# Results:
# python kind1: 98, kind2: 131170
# c++ kind1: 6422626, kind2: 98
# combo kind1: 98, kind2: 131170All 4 of the kind values should be 98. Essentially, kind is an enum value based on the text passed through a lexer. When additional characters are attached (a space, for example), they are saved in a separate list attached to the token. So in either case, always_ff should be getting passed to the lexer and the kind should be getting set to 98. The high values shown (131170, 6422626) are not valid enum values, so I am not sure where they came from. I am sure this is not a simple task to debug, so let me know what additional information I can provide. My first thought is maybe somehow the value is getting replaced with a pointer to the value instead, although I am not sure if that makes sense. My C++ knowledge is not massive.
cppyy fails to find template type with template _template_ type as final parameter
Further to Issue #37, (now fixed, thanks!) I see further failures when the final parameter is a template template type (as opposed to a plain template type in #37).
Interestingly, the VA template in the reproducer above is intended to match the signature of std::vector, and indeed std::vector also fails on MacOS (clang 12), but not on CentOS g++ v10 devtoolset-10). Both Python 10.
On MacOS std::vector fails in the same way as VA, unless f is inside a namespace, when it fails on different tests... all very confusing.
Our real-world case is using std::vector and std::function on CentOS and failing, so some more digging needed to find what is causing that, as this test case does not fail for that combination!
[Question] Package always trying to load original header files
I am building a python package using the CMake function cppyy_add_bindings. If I install the package and use the package on the machine where I built the python package everything works fine. But if I deploy the package to a different machine where I don't have the original header Files, then I get the following error:
import mypackage
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
Missing FileEntry for /home/user/myrepo/src/MyClass.hpp
requested to autoload type MyClass
Where the path is the path of the original header file. I am rather new to cppyy, so I don't know if I just did something stupid. But my understanding was that the bindings can also be loaded from the mypackage.map file which is distributed with the python package.
manual installation segfaults
Trying to install cppyy from sources on centos7 segfaults immediately on import. I've tried to follow the instructions as closely as possible, and have a hopefully reproducible version based on a singularity container here:
/// get the centos7 latest docker image
$ sudo singularity build centos7.sif docker://cern/cc7-base:latest
/// make an overlay for storing changes to the container
$ mkdir -p -m 777 overlay/upper overlay/work
$ dd if=/dev/zero of=overlay.img bs=1M count=3000 && mkfs.ext3 -d overlay overlay.img
/// start it up as root user and install dependencies
$ sudo singularity shell --overlay overlay.img --cleanenv --no-home centos7.sif
> # yum install gcc-c++ gcc make cmake git python36 python36-libs python36-devel python36-pip patch
> # python3 -m pip install --upgrade pip
> // N.B. without upgrading pip, `--no-use-pep517` is not recognised.
> # python3 --version
> Python 3.6.8
> # python3 -m pip -V
> pip 21.3.1 from /usr/local/lib/python3.6/site-packages/pip (python 3.6)
> # g++ --version
> g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)
> # cmake --version
> cmake version 2.8.12.2
> # mkdir /home/user
> # chown -R 1000 /home/user
> # exit
/// start it up again as non-root user
$ singularity shell --overlay overlay.img --cleanenv --no-home centos7.sif
/// cppyy installation:
> $ cd /home/user
> $ export STDCXX=11
> # N.B. without the above, building cppyy-cling returns: `gcc: error: unrecognized command line option '-std=c++1z'`
> $ export EXTRA_CLING_ARGS='-nocudainc'
> # N.B. without the above, importing cppyy returns CUDA libraries not found, and many compiler errors.
> $ export PATH=/home/user/.local/bin:$PATH
> # as recommended in the install guide
> $ export LD_LIBRARY_PATH=/home/user/.local/lib/python3.6/site-packages/cppyy_backend/lib:$LD_LIBRARY_PATH
> # also noted in the install guide
> $
> $ git clone https://github.com/wlav/cppyy-backend.git
> $ cd cppyy-backend/cling
> $ python3 setup.py egg_info
> $ python3 create_src_directory.py
> $ python3 -m pip install . --upgrade
> $
> $ cd ../clingwrapper
> $ python3 -m pip install . --upgrade --no-use-pep517 --no-deps
> $
> $ cd ../../
> $ git clone https://github.com/wlav/CPyCppyy.git
> $ cd CPyCppyy
> $ python3 -m pip install . --upgrade --no-use-pep517 --no-deps
> $
> $ cd ../
> $ git clone https://github.com/wlav/cppyy.git
> $ cd cppyy
> $ python3 -m pip install . --upgrade --no-deps --verbose
/// no errors during installation at this point, but cppyy immediately segfaults on import:
> $ python3
> >>> import cppyy
/home/user/.local/lib/python3.6/site-packages/cppyy_backend/loader.py:134: UserWarning: No precompiled header available (local variable 'cling_args' referenced before assignment); this may impact performance.
warnings.warn('No precompiled header available (%s); this may impact performance.' % msg)
> Segmentation fault
Any suggestions? I'm building from source as centos7 contains g++4.8.5 (as shown) and the guide says that this should sufficient, but only for manual installation.
I would like to avoid conda etc as I've had a lot of issues integrating them with other installations and packaging systems in the past.
How to pass array such as uint8_t *[8] to python
import cppyy
cppyy.cppdef('void test(int *arr[8]) { }')
# how to pass a valid parameter to cppyy.gbl.test ?
# I cannot get any help from documentation, I trys many ways to construct the parameter, but it always cause crash when execute cppyy.gbl.test(xxxx)
cppyy.gbl.test(xxxx)Issue with template member whose parameters depend on the class template parameters
Hello,
I am using Python 3.8.10 with cppyy 2.2.0, and I have an issue about the size of the std::array member, declared as std::array<T, (1<<X)+1> from a Lut<T,X,Y> class:
when instantiating a Lut with lut = cppyy.gbl.Lut [ int, 14, 14 ](), the type of the data member is said to be cppyy.gbl.std.array<int,1> instead of cppyy.gbl.std.array<int,16385>.
I could make it work in Lut2 class by adding a template parameter with default value.
import cppyy
cppyy.cppdef("""
#include <array>
#include <cstdint>
template<class T, uint8_t X, uint8_t Y> struct Lut {
// Constructors
Lut() { }
// Capacity
constexpr size_t size() const noexcept { return (1<<X)+1; }
public:
std::array<T, 3> data1 ; // OK
std::array<T, X> data2 ; // OK
std::array<T, 2*X> data3 ; // OK
std::array<T, 16385> data4 ; // OK
std::array<T, (1UL<<(std::size_t)3)+1UL> data5 ; // not OK
std::array<T, ((1<<3)+1)> data6 ; // not OK
std::array<T, ((1<<X)+1)> data7 ; // not OK
static int constexpr array_size = X<<2;
std::array<T, array_size> data8 ; // not OK
};
template<class T, uint8_t X, uint8_t Y, uint32_t asize=((1<<X)+1)> struct Lut2 {
// Constructors
Lut2() { }
// Capacity
constexpr size_t size() const noexcept { return (1<<X)+1; }
public:
std::array<T, asize> data;
};
""")
lut = cppyy.gbl.Lut[int, 14, 14]()
print(lut)
# <cppyy.gbl.Lut<int,'\x0E','\x0E'> object at 0x3e47eb0>
print(lut.size())
# 16385
print(lut.data1)
# <cppyy.gbl.std.array<int,3> object at 0x3e47eb0>
print(lut.data2)
# <cppyy.gbl.std.array<int,14> object at 0x3e47ebc>
print(lut.data3)
# <cppyy.gbl.std.array<int,28> object at 0x3e47ef4>
print(lut.data4)
# <cppyy.gbl.std.array<int,16385> object at 0x3e47f64>
print(lut.data5)
# <cppyy.gbl.std.array<int,1> object at 0x3e57f68>
print(lut.data6)
# TypeError: C++ type cannot be converted from memory
print(lut.data7)
# TypeError: C++ type cannot be converted from memory
print(lut.data8)
# TypeError: C++ type cannot be converted from memory
lut2 = cppyy.gbl.Lut2[int, 14, 14]()
print(lut2)
# <cppyy.gbl.Lut2<int,'\x0E','\x0E',16385> object at 0x418e520>
print(lut2.size())
# 16385
print(lut2.data)
# <cppyy.gbl.std.array<int,16385> object at 0x418e520>
Failure to install: Python 3.6, Ubuntu 18
I was setting up a new system and tried installing the latest cppyy (2.3.0), resulting in multiple “Failed to build” errors and complete failure to install. Version 2.2.0 also failed. Version 2.1.0 did display one or two of those errors (in particular, cppyy_backend) but the installation completed and is working. In each case, the install was attempted into a fresh virtual environment.
Ubuntu 18.04LTS, Python 3.6.9. The environment does not include clang, just gcc 7.5.0.
Installation capture (stdout only) is attached.
cppyy23_install.log
Exceptions sometimes lead to "terminate called"
When running the following code snippet, a C++ exception is correctly reported in an interactive Python session:
>>> from pyintervalxt import IntervalExchangeTransformation
>>> iet = IntervalExchangeTransformation((18, 3), (1, 0))
>>> iet
[a: 18] [b: 3] / [b] [a]
>>> from pyeantic import eantic
>>> L = eantic.renf("a^3 - a^2 - a - 1", "a", "[1.84 +/- 0.01]")
>>> lengths = [L.gen(), eantic.renf_elem(L, "-3*a^2 + 2*a - 1")]
>>> IntervalExchangeTransformation(lengths, [1, 0])
---------------------------------------------------------------------------
TypeError: none of the 4 overloaded methods succeeded. Full details:
Lengths<std::vector<eantic::renf_elem_class> >::Lengths<std::vector<eantic::renf_elem_class> >(intervalxt::cppyy::Lengths<std::vector<eantic::renf_elem_class> >&&) =>
ValueError: could not convert argument 1 (object is not an rvalue)
Lengths<std::vector<eantic::renf_elem_class> >::Lengths<std::vector<eantic::renf_elem_class> >(const intervalxt::cppyy::Lengths<std::vector<eantic::renf_elem_class> >&) =>
TypeError: could not convert argument 1
Lengths<std::vector<eantic::renf_elem_class> >::Lengths<std::vector<eantic::renf_elem_class> >(const std::vector<eantic::renf_elem_class>&) =>
invalid_argument: all lengths must be non-negative
Lengths<std::vector<eantic::renf_elem_class> >::Lengths<std::vector<eantic::renf_elem_class> >() =>
TypeError: takes at most 0 arguments (1 given)However, later in the same session, the same invocation causes a crash:
>>> iet = IntervalExchangeTransformation((18, 3), (1, 0))
>>> from pickle import loads, dumps
>>> loads(dumps(iet))
[a: 18] [b: 3] / [b] [a]
>>> lengths = [L.gen(), eantic.renf_elem(L, "-3*a^2 + 2*a - 1")]
>>> IntervalExchangeTransformation(lengths, [1, 0])
terminate called after throwing an instance of 'std::invalid_argument'
what(): all lengths must be non-negativeSince the same exception was apparently thrown, I don't understand why the loads and dumps on an unrelated object, made it so that this time the exception could not be caught and handed over to Python.
Unfortunately, I could not find a short reproducer for this yet. I can reproduce the above on Linux in the following conda environment:
conda create -n terminate -c flatsurf pyintervalxt pyeantic
conda activate terminate
pythonSum of bigints improperly cast to a big-rational
I have a Debian 11 system on a PC. I created a miniconda environment with
Python 3.8.12, CGAL 5.0.1, cppyy 2.2.0, and gmp 6.2.1.
"CGAL" is The Computational Geometry Algorithms Library. It is written in C++. It contains wrappers for the Gnu multi-precision library. Class Gmpz does bigints and class Gmpq does big-rationals.
When I add two Gmpz objects, I get a Gmpq object. Assuming that I am not experienced with cppyy, how do I find out exactly what is happening?
#! /usr/bin/env python
import cppyy
cppyy.load_library('libgmp')
cppyy.include('/home/xxxxxxxx/miniconda3/envs/CPPYY/include/CGAL/Gmpz.h')
# Add two bigints, get a big rational:
three = cppyy.gbl.CGAL.Gmpz(3)
print(three, type(three))
seven = cppyy.gbl.CGAL.Gmpz(7)
print(seven, type(seven))
s = three + seven
print(s, type(s))
# "+=" behaves correctly.
sum = cppyy.gbl.CGAL.Gmpz(0)
sum += three
sum += seven
print(sum, type(sum))
111
Different behavior on cpython and pypy interpreter.
The following code works on cpython (I only test it on 3.7). However, it doesn't work on pypy 3:
from cppyy.gbl.std import vector as Vector
import numpy as np
from array import array
x = Vector['int'](range(10))
x = Vector['int'](np.arange(10))
x = Vector['int'](array('i', range(10)))Can bindings be saved permanently and not just in temporary memory?
All the uses I'm seeing for cppyy define the bindings as they need to be used (e.g. I want to use C++ MyClass in python, so in a single python script I will generate the python binding and use it).
Is it possible to generate more "permanent" bindings that can be used later?
For example, let's say I have a project containing classes A, B, and C. Is it possible to generate the bindings when my project is built, so that anyone using the project later can just do from cppyy.gbl import A and use the binding?
Mocking cppyy code / Reloading newer versions of shared libs
I have a function that produces a random output roll_dice() and I want to mock that function so I can test dependent functions. (replacing the equivalent of return rand()%(stop+1-start)+start; with f"return {x};"
I haven't been able to find a way to do this in cppyy. I have tried to reload the module using importlib and repeating the load_libary commands with new versions of my .so file to no avail.
Is there a way to reload cppyy? My mocking system works for the first tests, but everything after this fails.
Python int unexpected cast to C++ double
I have a Debian 11 system on a PC. I created a miniconda environment with Python 3.9.10, CGAL 5.0.1, cppyy 2.2.0, and gmp 6.2.1.
"CGAL" is The Computational Geometry Algorithms Library. It is written in C++. It contains wrappers for the Gnu multi-precision library (gmp). Class Gmpz does bigints and class Gmpq does big-rationals.
This program:
#! /usr/bin/env python
import cppyy
cppyy.load_library('libgmp')
cppyy.include('/home/xxxxxxxx/miniconda3/envs/CPPYY/include/CGAL/Gmpz.h')
Gmpz = cppyy.gbl.CGAL.Gmpz
big = 10**30
print(Gmpz(big))
print(Gmpz(float(big)))
print(str(big))
print(Gmpz(str(big)))
outputs:
1000000000000000019884624838656
1000000000000000019884624838656
1000000000000000000000000000000
1000000000000000000000000000000
A Python-oriented user might unconsciously assume that Gmpz(10**30) would convert a Python int into a gmp bigint. I didn't notice for a very long time that this was not happening. Fortunately, all the numbers I input into my program are small. The correct thing to do is Gmpz(str(10**30)). cppyy cannot possibly be expected to do this conversion. Among the various constructors for Gmpz, cppyy chooses double which is reasonable.
Good documentation might have prevented my confusion. cppyy needs to have a reference manual. It should contain details about how basic Python objects (int, list, etc) and C++ constructs (ints, vector, etc.) map into each other. At the other extreme of depth, perhaps fork some of the ROOT documentation.
I have been frustrated many times with cppyy's opaqueness. It seems as if there are several layers of magic between Python and CGAL.
retrieving a string is causing an access to null pointer error
Hi,
I distributed Topologic along with cppyy to three people and they all had VS 2019 installed and it worked fine, but they have encountered the following error which I do not see on my installation. Any hints on why this may be happening on their machines, but not mine? Is there something I can fix in my C++ code to avoid all this? This happens when they try to get a string value back from a dictionary. Thanks
2021-09-07 15:16:56,481 [WARNING] py.warnings: C:\Users\FILIPE\AppData\Roaming\Blender Foundation\Blender\2.93\scripts\addons\topologicsverchok\topologicPy\site-packages\cppyy\__init__.py:318: UserWarning: CPyCppyy API not found (tried: C:\Program Files\Blender Foundation\Blender 2.93\2.93\python\site\python3.9); set CPPYY_API_PATH envar to the 'CPyCppyy' API directory to fix
warnings.warn("CPyCppyy API not found (tried: %s); set CPPYY_API_PATH envar to the 'CPyCppyy' API directory to fix" % apipath_extra)
IncrementalExecutor::executeFunction: symbol '?Value@StringAttribute@TopologicCore@@UEAAPEAXXZ' unresolved while linking symbol '__cf_28'!
You are probably missing the definition of public: virtual void * __ptr64 __cdecl TopologicCore::StringAttribute::Value(void) __ptr64
Maybe you need to load the corresponding shared library?
2021-09-07 15:19:19,473 [INFO] root: Initializing Sverchok logging. Blender version 2.93.4, Sverchok version 1.0.0
2021-09-07 15:19:19,473 [ERROR] topologicsverchok.nodes.Topologic.DictionaryValues:31 : attempt to access a null-pointer
cppexec terminates process
Some invalid code terminates the Python process when running through cppyy.cppexec. I guess the following should just produce an exception but not actually crash?
>>> import cppyy
>>> cppyy.cppexec('a + 1')
terminate called after throwing an instance of 'cling::CompilationException'
what(): Error evaluating expression (a + 1)
Generating stack trace...
/tmp/ruth/micromamba/envs/arbxx-build/bin/addr2line: DWARF error: section .debug_info is larger than its filesize! (0x9bd663 vs 0x526480)
0x00007fc95ca3b535 in abort + 0x121 from /lib/x86_64-linux-gnu/libc.so.6
0x00007fc95c0ebfac in __gnu_cxx::__verbose_terminate_handler() at /home/conda/feedstock_root/build_artifacts/gcc_compilers_1634095553113/work/build/x86_64-conda-linux-gnu/libstdc++-v3/libsupc++/../../../../libstdc++-v3/libsupc++/vterminate.cc:95 from /tmp/ruth/micromamba/envs/arbxx-build/lib/python3.10/lib-dynload/../../libstdc++.so
0x00007fc95c0ea56c in <unknown> from /tmp/ruth/micromamba/envs/arbxx-build/lib/python3.10/lib-dynload/../../libstdc++.so
0x00007fc95c0ea5be in <unknown> from /tmp/ruth/micromamba/envs/arbxx-build/lib/python3.10/lib-dynload/../../libstdc++.so
0x00007fc95c0ea7b3 in __cxa_rethrow at /home/conda/feedstock_root/build_artifacts/gcc_compilers_1634095553113/work/build/x86_64-conda-linux-gnu/libstdc++-v3/libsupc++/../../../../libstdc++-v3/libsupc++/eh_throw.cc:100 from /tmp/ruth/micromamba/envs/arbxx-build/lib/python3.10/lib-dynload/../../libstdc++.so
0x00007fc95983d3e9 in <unknown> from /tmp/ruth/micromamba/envs/arbxx-build/lib/python3.10/site-packages/cppyy_backend/lib/libCling.so
0x00007fc9599f8b30 in cling::runtime::internal::EvaluateDynamicExpression(cling::Interpreter*, cling::runtime::internal::DynamicExprInfo*, clang::DeclContext*) + 0x1d0 from /tmp/ruth/micromamba/envs/arbxx-build/lib/python3.10/site-packages/cppyy_backend/lib/libCling.so
0x00007fc95c2720a9 in <unknown function>
0x00007fc959a7ca77 in <unknown> from /tmp/ruth/micromamba/envs/arbxx-build/lib/python3.10/site-packages/cppyy_backend/lib/libCling.so
Generating stack trace...
/tmp/ruth/micromamba/envs/arbxx-build/bin/addr2line: DWARF error: section .debug_info is larger than its filesize! (0x9bd663 vs 0x526480)
0x00007fc95ca3b535 in abort + 0x121 from /lib/x86_64-linux-gnu/libc.so.6
0x00007fc95c0ebfac in __gnu_cxx::__verbose_terminate_handler() at /home/conda/feedstock_root/build_artifacts/gcc_compilers_1634095553113/work/build/x86_64-conda-linux-gnu/libstdc++-v3/libsupc++/../../../../libstdc++-v3/libsupc++/vterminate.cc:95 from /tmp/ruth/micromamba/envs/arbxx-build/lib/python3.10/lib-dynload/../../libstdc++.so
0x00007fc95c0ea56c in <unknown> from /tmp/ruth/micromamba/envs/arbxx-build/lib/python3.10/lib-dynload/../../libstdc++.so
0x00007fc95c0ea5be in <unknown> from /tmp/ruth/micromamba/envs/arbxx-build/lib/python3.10/lib-dynload/../../libstdc++.so
0x00007fc95c0ea7b3 in __cxa_rethrow at /home/conda/feedstock_root/build_artifacts/gcc_compilers_1634095553113/work/build/x86_64-conda-linux-gnu/libstdc++-v3/libsupc++/../../../../libstdc++-v3/libsupc++/eh_throw.cc:100 from /tmp/ruth/micromamba/envs/arbxx-build/lib/python3.10/lib-dynload/../../libstdc++.so
0x00007fc95983d3e9 in <unknown> from /tmp/ruth/micromamba/envs/arbxx-build/lib/python3.10/site-packages/cppyy_backend/lib/libCling.so
0x00007fc9599f8b30 in cling::runtime::internal::EvaluateDynamicExpression(cling::Interpreter*, cling::runtime::internal::DynamicExprInfo*, clang::DeclContext*) + 0x1d0 from /tmp/ruth/micromamba/envs/arbxx-build/lib/python3.10/site-packages/cppyy_backend/lib/libCling.so
0x00007fc95c2720a9 in <unknown function>
0x00007fc959a7ca77 in <unknown> from /tmp/ruth/micromamba/envs/arbxx-build/lib/python3.10/site-packages/cppyy_backend/lib/libCling.soThis is the latest cppyy 2.2.0 as distributed on conda-forge for linux-64.
Program crashes when trying to wrap Miniaudio
I tried writing a simple program that uses CPPYY to use Miniaudio from Python. However, at some point it crashes and I have no idea why.
I'm using Windows 10 64-bit, CPython 3.9.5 and here is a ZIP file containg my Python code, my copy of Miniaudio (up-to-date) and miniaudio_dll.dll (to rebuild "cl miniaudio_dll.c")
problem.zip
I don't just JIT compile miniaudio.h because it causes a compilation error. Sorry if I forgot something, but nearly empty laptop batteries wait for no one.
Support Concepts
More of a long term thing, but would it be possible to support concepts? I think this would only require an update to Clang 10, though updating to the latest version would be nice.
Stack overflow when calling private constructor
Consider the following code snippet:
import cppyy
cppyy.cppdef(r"""
#include <boost/operators.hpp>
#include <atomic>
class X : boost::equality_comparable<X> {
X();
mutable std::atomic<size_t> x;
};
""")
cppyy.gbl.X()This crashes for me with:
Fatal Python error: Cannot recover from stack overflow.
Current thread 0x00007faa59ead740 (most recent call first):
File "../e-antic/crash.py", line 11 in <module>
Program received signal SIGABRT, Aborted.
Debugging with GDB shows the following infinite recursion:
#29 0x0000557ed94d1d25 in PyObject_Call (callable=<X_meta(__module__='__main__', __doc__=None) at remote 0x557edd549990>, args=(), kwargs=0x0)
at /home/conda/feedstock_root/build_artifacts/python_1635226063427/work/Objects/call.c:245
#30 0x00007faa501535a7 in CPyCppyy::CPPConstructor::Call(CPyCppyy::CPPInstance*&, _object*, unsigned long, _object*, CPyCppyy::CallContext*) ()
from /tmp/ruth/micromamba/envs/e-antic-build/lib/python3.7/site-packages/libcppyy.cpython-37m-x86_64-linux-gnu.so
#31 0x00007faa501314e6 in CPyCppyy::(anonymous namespace)::mp_call(CPyCppyy::CPPOverload*, _object*, _object*) ()
from /tmp/ruth/micromamba/envs/e-antic-build/lib/python3.7/site-packages/libcppyy.cpython-37m-x86_64-linux-gnu.so
#32 0x0000557ed94d1d25 in PyObject_Call (callable=<cppyy.CPPOverload at remote 0x7faa4f608af0>, args=(), kwargs=0x0) at /home/conda/feedstock_root/build_artifacts/python_1635226063427/work/Objects/call.c:245
#33 0x0000557ed95eafee in slot_tp_init (self=<X at remote 0x7faa4f608aa0>, args=(), kwds=0x0) at /home/conda/feedstock_root/build_artifacts/python_1635226063427/work/Objects/typeobject.c:6639
#34 0x0000557ed956d2ea in type_call (type=<optimized out>, args=(), kwds=0x0) at /home/conda/feedstock_root/build_artifacts/python_1635226063427/work/Objects/typeobject.c:971
#35 0x0000557ed94d1d25 in PyObject_Call (callable=<X_meta(__module__='__main__', __doc__=None) at remote 0x557edd549990>, args=(), kwargs=0x0)
at /home/conda/feedstock_root/build_artifacts/python_1635226063427/work/Objects/call.c:245
I don’t except calling a private constructor to actually yield an instance of the object so this should be an error. However, this problem shows up when cppyy attempts to convert arguments, i.e., when invoking an overloaded function with some argument that is not X:
void f(const X&);
void f(something else);
Conversion to X is apparently attempted when invoking say f([]) which then leads to the above crash.
This happened on Linux with the latest cppyy from conda-forge:
cppyy 2.2.0 py37ha1a9abc_1 conda-forge
cppyy-backend 1.14.7 py37h2527ec5_0 conda-forge
cppyy-cling 6.25.2 py37hfa6fd77_1 conda-forge
cpycppyy 1.12.8 py37h2527ec5_1 conda-forge
Single Byte Enums are Always Characters
First off, thanks for all your work with cppyy. In cppyy 2.3.0 it appears that single byte enums are always backed by a character. This isn't necessarily ideal. But, a negative value enum will not be able to be used in any manner AFAIK because it always gets converted to an empty string.
import cppyy
cppyy.cppdef('''
enum class TestEnum { E0 = 0, E1 = 1, EN1 = -1, EN2 = -2 };
enum class TestInt8Enum : int8_t { E0 = 0, E1 = 1, EN1 = -1, EN2 = -2 };
enum class TestInt16Enum : int16_t { E0 = 0, E1 = 1, EN1 = -1, EN2 = -2 };
''')
from cppyy.gbl import TestEnum, TestInt8Enum, TestInt16Enum
# Works
assert TestEnum.EN1 == -1
assert TestInt16Enum.EN1 == -1
assert ord(TestInt8Enum.E1) == 1
# Shouldn't be equal, but it is
assert TestInt8Enum.EN1 != TestInt8Enum.EN2
# Doesn't work
assert ord(TestInt8Enum.EN1) == -1
assert TestInt8Enum.EN1 == -1
Would it be possible to preserve the underlying type of the enum?
Error when installing cppyy on Windows 10 with VS 2022
I try to install cppyy on Windows 10 and the following error happened.
I have installed Visual Studio 2022 on my machine.
Is there any clue to solve this issue?
(playground) PS C:\Users\yangyue> pip install --no-cache-dir cppyy
Collecting cppyy
Downloading cppyy-2.3.0.tar.gz (19 kB)
Installing build dependencies ... done
Getting requirements to build wheel ... done
Installing backend dependencies ... done
Preparing metadata (pyproject.toml) ... done
Collecting cppyy-cling==6.25.3
Downloading cppyy_cling-6.25.3-py2.py3-none-win_amd64.whl (18.4 MB)
---------------------------------------- 18.4/18.4 MB 6.2 MB/s eta 0:00:00
Collecting cppyy-backend==1.14.8
Downloading cppyy-backend-1.14.8.tar.gz (33 kB)
Installing build dependencies ... done
Getting requirements to build wheel ... done
Preparing metadata (pyproject.toml) ... done
Collecting CPyCppyy==1.12.9
Downloading CPyCppyy-1.12.9.tar.gz (199 kB)
---------------------------------------- 199.1/199.1 KB 12.6 MB/s eta 0:00:00
Installing build dependencies ... done
Getting requirements to build wheel ... done
Preparing metadata (pyproject.toml) ... done
Building wheels for collected packages: cppyy, cppyy-backend, CPyCppyy
Building wheel for cppyy (pyproject.toml) ... done
Created wheel for cppyy: filename=cppyy-2.3.0-py3-none-any.whl size=20035 sha256=132cd4c97ce652804c08fc0627965f0b48e19932c4e63474829d481dcf76541f
Stored in directory: C:\Users\yangyue\AppData\Local\Temp\pip-ephem-wheel-cache-z8xiphov\wheels\f3\ae\84\b99113a0a70ec5e622e58065ab1481b284b610fd33f176b267
Building wheel for cppyy-backend (pyproject.toml) ... done
Created wheel for cppyy-backend: filename=cppyy_backend-1.14.8-py2.py3-none-win_amd64.whl size=85356 sha256=578725e6caf5808584b606fd1c09c6ec521f403a7c31172b3a6aa9e55f036eb0
Stored in directory: C:\Users\yangyue\AppData\Local\Temp\pip-ephem-wheel-cache-z8xiphov\wheels\d9\79\54\b8c2878b4e8c97247ef50b93d3b1c8be0583a70bd0552d5397
Building wheel for CPyCppyy (pyproject.toml) ... error
error: subprocess-exited-with-error
× Building wheel for CPyCppyy (pyproject.toml) did not run successfully.
│ exit code: 1
╰─> [13 lines of output]
running bdist_wheel
running build
running build_ext
building 'libcppyy' extension
creating build
creating build\temp.win-amd64-3.10
creating build\temp.win-amd64-3.10\Release
creating build\temp.win-amd64-3.10\Release\src
"D:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.31.31103\bin\HostX86\x64\cl.exe" /c /nologo /O2 /W3 /GL /DNDEBUG /MD -Iinclude -ID:\miniforge3\envs\playground\include -ID:\miniforge3\envs\playground\Include "-ID:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.31.31103\include" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\ucrt" "-IC:\Program Files (x86)\Windows Kits\10\\include\10.0.19041.0\\shared" "-IC:\Program Files (x86)\Windows Kits\10\\include\10.0.19041.0\\um" "-IC:\Program Files (x86)\Windows Kits\10\\include\10.0.19041.0\\winrt" "-IC:\Program Files (x86)\Windows Kits\10\\include\10.0.19041.0\\cppwinrt" -IC:\xpressmp\include /EHsc /Tpsrc\API.cxx /Fobuild\temp.win-amd64-3.10\Release\src\API.obj -O2 -Zc:__cplusplus /std:c++17 /GR /EHsc- /MD
cl: 命令行 warning D9025 :正在重写“/EHc”(用“/EHc-”)
API.cxx
C:\Users\yangyue\AppData\Local\Temp\pip-install-zrabrnpi\cpycppyy_a99affbe1670424fa1d8ebafa772bc6e\src\CPPInstance.h(82): error C2061: 语法错误: 标识符“ssize_t”
error: command 'D:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.31.31103\\bin\\HostX86\\x64\\cl.exe' failed with exit code 2
[end of output]
note: This error originates from a subprocess, and is likely not a problem with pip.
ERROR: Failed building wheel for CPyCppyy
Successfully built cppyy cppyy-backend
Failed to build CPyCppyy
ERROR: Could not build wheels for CPyCppyy, which is required to install pyproject.toml-based projects
*** Break *** segmentation violation after import
On a brand new docker image based on debian:bullseye-slim after installing cppyy with pip I get this error right after importing cppyy. It was fine a couple of days ago so I guess it could be related to some changes in cppyy-cling
>>> import cppyy
*** Break *** segmentation violation
Generating stack trace...
0x00007fc1c2d6484f in Cppyy::IsEnum(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) at /tmp/pip-install-m9mzikn_/cppyy-backend_e2a0d0c0e3d440bea44e6d18e5f7c223/src/clingwrapper.cxx:1020 (discriminator 1) from /opt/venv/lib/python3.9/site-packages/cppyy_backend/lib/libcppyy_backend.so
0x00007fc1c2d6efa8 in Cppyy::ResolveName(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) at /tmp/pip-install-m9mzikn_/cppyy-backend_e2a0d0c0e3d440bea44e6d18e5f7c223/src/clingwrapper.cxx:403 from /opt/venv/lib/python3.9/site-packages/cppyy_backend/lib/libcppyy_backend.so
0x00007fc1c2d6f7be in Cppyy::GetScope(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) at /usr/include/c++/10/bits/basic_string.h:6239 from /opt/venv/lib/python3.9/site-packages/cppyy_backend/lib/libcppyy_backend.so
0x00007fc1c09d09f7 in CPyCppyy::CreateScopeProxy(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, _object*, unsigned int) at /tmp/pip-install-2hd9bd5e/cpycppyy_b2a99bb0d2704d20a070e1b9fdd8839e/src/ProxyWrappers.cxx:564 (discriminator 10) from /opt/venv/lib/python3.9/site-packages/libcppyy.cpython-39-x86_64-linux-gnu.so
0x00007fc1c09997fb in <unknown> from /opt/venv/lib/python3.9/site-packages/libcppyy.cpython-39-x86_64-linux-gnu.so
0x0000000000511ed1 in _PyEval_EvalFrameDefault + 0x441 from python
0x0000000000528b63 in _PyFunction_Vectorcall + 0x1a3 from python
0x0000000000511fb5 in _PyEval_EvalFrameDefault + 0x525 from python
0x00000000005106ed in <unknown> from python
0x0000000000510497 in _PyEval_EvalCodeWithName + 0x47 from python
0x00000000005f5be3 in PyEval_EvalCode + 0x23 from python
0x00000000005fa670 in <unknown> from python
0x00000000005298c4 in <unknown> from python
0x0000000000517b9b in _PyEval_EvalFrameDefault + 0x610b from python
0x00000000005106ed in <unknown> from python
0x0000000000528d21 in _PyFunction_Vectorcall + 0x361 from python
0x0000000000516e76 in _PyEval_EvalFrameDefault + 0x53e6 from python
0x0000000000528b63 in _PyFunction_Vectorcall + 0x1a3 from python
0x0000000000512192 in _PyEval_EvalFrameDefault + 0x702 from python
0x0000000000528b63 in _PyFunction_Vectorcall + 0x1a3 from python
0x0000000000511fb5 in _PyEval_EvalFrameDefault + 0x525 from python
0x0000000000528b63 in _PyFunction_Vectorcall + 0x1a3 from python
0x0000000000511fb5 in _PyEval_EvalFrameDefault + 0x525 from python
0x0000000000528b63 in _PyFunction_Vectorcall + 0x1a3 from python
0x000000000052842e in <unknown> from python
0x000000000053f559 in _PyObject_CallMethodIdObjArgs + 0xf9 from python
0x000000000053e786 in PyImport_ImportModuleLevelObject + 0x916 from python
0x00000000005144bd in _PyEval_EvalFrameDefault + 0x2a2d from python
0x00000000005106ed in <unknown> from python
0x0000000000510497 in _PyEval_EvalCodeWithName + 0x47 from python
0x00000000005f5be3 in PyEval_EvalCode + 0x23 from python
0x00000000005fa670 in <unknown> from python
0x00000000005298c4 in <unknown> from python
0x0000000000517b9b in _PyEval_EvalFrameDefault + 0x610b from python
0x00000000005106ed in <unknown> from python
0x0000000000528d21 in _PyFunction_Vectorcall + 0x361 from python
0x0000000000516e76 in _PyEval_EvalFrameDefault + 0x53e6 from python
0x0000000000528b63 in _PyFunction_Vectorcall + 0x1a3 from python
0x0000000000512192 in _PyEval_EvalFrameDefault + 0x702 from python
0x0000000000528b63 in _PyFunction_Vectorcall + 0x1a3 from python
0x0000000000511fb5 in _PyEval_EvalFrameDefault + 0x525 from python
0x0000000000528b63 in _PyFunction_Vectorcall + 0x1a3 from python
0x0000000000511fb5 in _PyEval_EvalFrameDefault + 0x525 from python
0x0000000000528b63 in _PyFunction_Vectorcall + 0x1a3 from python
0x000000000052842e in <unknown> from python
0x000000000053f559 in _PyObject_CallMethodIdObjArgs + 0xf9 from python
0x000000000053e786 in PyImport_ImportModuleLevelObject + 0x916 from python
0x00000000005144bd in _PyEval_EvalFrameDefault + 0x2a2d from python
0x00000000005106ed in <unknown> from python
0x0000000000510497 in _PyEval_EvalCodeWithName + 0x47 from python
0x00000000005f5be3 in PyEval_EvalCode + 0x23 from python
0x0000000000619de7 in <unknown> from python
0x0000000000615610 in <unknown> from python
0x0000000000459cb3 in <unknown> from python
0x0000000000459911 in PyRun_InteractiveLoopFlags + 0xd5 from python
0x00000000006194f5 in PyRun_AnyFileExFlags + 0x55 from python
0x000000000044bca9 in <unknown> from python
0x00000000005ea6e9 in Py_BytesMain + 0x29 from python
0x00007fc1c7b20d0a in __libc_start_main + 0xea from /lib/x86_64-linux-gnu/libc.so.6
0x00000000005ea5ea in _start + 0x2a from python
*** Break *** segmentation violation
Generating stack trace...
0x00007fc1c2d6484f in Cppyy::IsEnum(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) at /tmp/pip-install-m9mzikn_/cppyy-backend_e2a0d0c0e3d440bea44e6d18e5f7c223/src/clingwrapper.cxx:1020 (discriminator 1) from /opt/venv/lib/python3.9/site-packages/cppyy_backend/lib/libcppyy_backend.so
0x00007fc1c2d6efa8 in Cppyy::ResolveName(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) at /tmp/pip-install-m9mzikn_/cppyy-backend_e2a0d0c0e3d440bea44e6d18e5f7c223/src/clingwrapper.cxx:403 from /opt/venv/lib/python3.9/site-packages/cppyy_backend/lib/libcppyy_backend.so
0x00007fc1c2d6f7be in Cppyy::GetScope(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) at /usr/include/c++/10/bits/basic_string.h:6239 from /opt/venv/lib/python3.9/site-packages/cppyy_backend/lib/libcppyy_backend.so
0x00007fc1c09d09f7 in CPyCppyy::CreateScopeProxy(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, _object*, unsigned int) at /tmp/pip-install-2hd9bd5e/cpycppyy_b2a99bb0d2704d20a070e1b9fdd8839e/src/ProxyWrappers.cxx:564 (discriminator 10) from /opt/venv/lib/python3.9/site-packages/libcppyy.cpython-39-x86_64-linux-gnu.so
0x00007fc1c09997fb in <unknown> from /opt/venv/lib/python3.9/site-packages/libcppyy.cpython-39-x86_64-linux-gnu.so
0x0000000000511ed1 in _PyEval_EvalFrameDefault + 0x441 from python
0x0000000000528b63 in _PyFunction_Vectorcall + 0x1a3 from python
0x0000000000511fb5 in _PyEval_EvalFrameDefault + 0x525 from python
0x00000000005106ed in <unknown> from python
0x0000000000510497 in _PyEval_EvalCodeWithName + 0x47 from python
0x00000000005f5be3 in PyEval_EvalCode + 0x23 from python
0x00000000005fa670 in <unknown> from python
0x00000000005298c4 in <unknown> from python
0x0000000000517b9b in _PyEval_EvalFrameDefault + 0x610b from python
0x00000000005106ed in <unknown> from python
0x0000000000528d21 in _PyFunction_Vectorcall + 0x361 from python
0x0000000000516e76 in _PyEval_EvalFrameDefault + 0x53e6 from python
0x0000000000528b63 in _PyFunction_Vectorcall + 0x1a3 from python
0x0000000000512192 in _PyEval_EvalFrameDefault + 0x702 from python
0x0000000000528b63 in _PyFunction_Vectorcall + 0x1a3 from python
0x0000000000511fb5 in _PyEval_EvalFrameDefault + 0x525 from python
0x0000000000528b63 in _PyFunction_Vectorcall + 0x1a3 from python
0x0000000000511fb5 in _PyEval_EvalFrameDefault + 0x525 from python
0x0000000000528b63 in _PyFunction_Vectorcall + 0x1a3 from python
0x000000000052842e in <unknown> from python
0x000000000053f559 in _PyObject_CallMethodIdObjArgs + 0xf9 from python
0x000000000053e786 in PyImport_ImportModuleLevelObject + 0x916 from python
0x00000000005144bd in _PyEval_EvalFrameDefault + 0x2a2d from python
0x00000000005106ed in <unknown> from python
0x0000000000510497 in _PyEval_EvalCodeWithName + 0x47 from python
0x00000000005f5be3 in PyEval_EvalCode + 0x23 from python
0x00000000005fa670 in <unknown> from python
0x00000000005298c4 in <unknown> from python
0x0000000000517b9b in _PyEval_EvalFrameDefault + 0x610b from python
0x00000000005106ed in <unknown> from python
0x0000000000528d21 in _PyFunction_Vectorcall + 0x361 from python
0x0000000000516e76 in _PyEval_EvalFrameDefault + 0x53e6 from python
0x0000000000528b63 in _PyFunction_Vectorcall + 0x1a3 from python
0x0000000000512192 in _PyEval_EvalFrameDefault + 0x702 from python
0x0000000000528b63 in _PyFunction_Vectorcall + 0x1a3 from python
0x0000000000511fb5 in _PyEval_EvalFrameDefault + 0x525 from python
0x0000000000528b63 in _PyFunction_Vectorcall + 0x1a3 from python
0x0000000000511fb5 in _PyEval_EvalFrameDefault + 0x525 from python
0x0000000000528b63 in _PyFunction_Vectorcall + 0x1a3 from python
0x000000000052842e in <unknown> from python
0x000000000053f559 in _PyObject_CallMethodIdObjArgs + 0xf9 from python
0x000000000053e786 in PyImport_ImportModuleLevelObject + 0x916 from python
0x00000000005144bd in _PyEval_EvalFrameDefault + 0x2a2d from python
0x00000000005106ed in <unknown> from python
0x0000000000510497 in _PyEval_EvalCodeWithName + 0x47 from python
0x00000000005f5be3 in PyEval_EvalCode + 0x23 from python
0x0000000000619de7 in <unknown> from python
0x0000000000615610 in <unknown> from python
0x0000000000459cb3 in <unknown> from python
0x0000000000459911 in PyRun_InteractiveLoopFlags + 0xd5 from python
0x00000000006194f5 in PyRun_AnyFileExFlags + 0x55 from python
0x000000000044bca9 in <unknown> from python
0x00000000005ea6e9 in Py_BytesMain + 0x29 from python
0x00007fc1c7b20d0a in __libc_start_main + 0xea from /lib/x86_64-linux-gnu/libc.so.6
0x00000000005ea5ea in _start + 0x2a from python
Possible memory issue with string_view
Hi again,
I have been making good progress with cppyy. I have run into the following situation though:
text = cppyy.gbl.string_view('''
The standard Lorem Ipsum passage, used since the 1500s
"Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum."
Section 1.10.32 of "de Finibus Bonorum et Malorum", written by Cicero in 45 BC
"Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur?"
1914 translation by H. Rackham
"But I must explain to you how all this mistaken idea of denouncing pleasure and praising pain was born and I will give you a complete account of the system, and expound the actual teachings of the great explorer of the truth, the master-builder of human happiness. No one rejects, dislikes, or avoids pleasure itself, because it is pleasure, but because those who do not know how to pursue pleasure rationally encounter consequences that are extremely painful. Nor again is there anyone who loves or pursues or desires to obtain pain of itself, because it is pain, but because occasionally circumstances occur in which toil and pain can procure him some great pleasure. To take a trivial example, which of us ever undertakes laborious physical exercise, except to obtain some advantage from it? But who has any right to find fault with a man who chooses to enjoy a pleasure that has no annoying consequences, or one who avoids a pain that produces no resultant pleasure?"
Section 1.10.33 of "de Finibus Bonorum et Malorum", written by Cicero in 45 BC
"At vero eos et accusamus et iusto odio dignissimos ducimus qui blanditiis praesentium voluptatum deleniti atque corrupti quos dolores et quas molestias excepturi sint occaecati cupiditate non provident, similique sunt in culpa qui officia deserunt mollitia animi, id est laborum et dolorum fuga. Et harum quidem rerum facilis est et expedita distinctio. Nam libero tempore, cum soluta nobis est eligendi optio cumque nihil impedit quo minus id quod maxime placeat facere possimus, omnis voluptas assumenda est, omnis dolor repellendus. Temporibus autem quibusdam et aut officiis debitis aut rerum necessitatibus saepe eveniet ut et voluptates repudiandae sint et molestiae non recusandae. Itaque earum rerum hic tenetur a sapiente delectus, ut aut reiciendis voluptatibus maiores alias consequatur aut perferendis doloribus asperiores repellat."
1914 translation by H. Rackham
"On the other hand, we denounce with righteous indignation and dislike men who are so beguiled and demoralized by the charms of pleasure of the moment, so blinded by desire, that they cannot foresee the pain and trouble that are bound to ensue; and equal blame belongs to those who fail in their duty through weakness of will, which is the same as saying through shrinking from toil and pain. These cases are perfectly simple and easy to distinguish. In a free hour, when our power of choice is untrammelled and when nothing prevents our being able to do what we like best, every pleasure is to be welcomed and every pain avoided. But in certain circumstances and owing to the claims of duty or the obligations of business it will frequently occur that pleasures have to be repudiated and annoyances accepted. The wise man therefore always holds in these matters to this principle of selection: he rejects pleasures to secure other greater pleasures, or else he endures pains to avoid worse pains."
''')
print(text)When I attempt to load a fairly large amount of text into a string_view (think a source code file), weird stuff happens. I can load it in just fine, and if I call text.size(), it gives me the correct number, but attempting to access the data either through printing it or using it in a different function on the C++ side fail. Sometimes it gives an error about failing to decode utf-8 characters. Sometimes it just prints out an empty string (or a handful of invisible characters, hard to tell).
When I was playing around with it, if I started with a smaller amount of text and kept increasing the amount and printing the new variable each time, I could occasionally get one created that properly printed the entire string. That is what makes me think there is something weird going on with the memory storage. The exact length where it fails varies, but it is usually around 3000 characters.
I have not attempted to use a different string type, the compiler library uses string_view internally so I doubt it would make a difference. But maybe having a stable C string which gets converted to a string_view might work as a workaround. I would need to test it.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.