You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sometimes I start batch-wrapping a bunch of library functions to get a C++ wrapper more feature complete, but I overlook that some types have been used that have not been wrapped themselves yet. At the moment, one only gets a (to me) rather cryptic error message such as
C++ exception while wrapping module OpenFHE: No appropriate factory for type St3mapIjSt10shared_ptrIN8lbcrypto11EvalKeyImplINS1_12DCRTPolyImplIN9bigintdyn9mubintvecINS4_5ubintImEEEEEEEEESt4lessIjESaISt4pairIKjSB_EEE
ERROR: LoadError: No appropriate factory for type St3mapIjSt10shared_ptrIN8lbcrypto11EvalKeyImplINS1_12DCRTPolyImplIN9bigintdyn9mubintvecINS4_5ubintImEEEEEEEEESt4lessIjESaISt4pairIKjSB_EEE
Stacktrace:
[1] register_julia_module
@ CxxWrap.CxxWrapCore ~/.julia/packages/CxxWrap/5IZvn/src/CxxWrap.jl:393 [inlined]
[2] readmodule(so_path_cb::OpenFHE.var"#1#2", funcname::Symbol, m::Module, flags::Nothing)
@ CxxWrap.CxxWrapCore ~/.julia/packages/CxxWrap/5IZvn/src/CxxWrap.jl:751
[3] wrapmodule(so_path_cb::Function, funcname::Symbol, m::Module, flags::Nothing)
@ CxxWrap.CxxWrapCore ~/.julia/packages/CxxWrap/5IZvn/src/CxxWrap.jl:761
[4] top-level scope
@ /mnt/ssd/home/mschlott/hackathon/fhe/OpenFHE.jl/src/OpenFHE.jl:11
[5] include
@ Base ./Base.jl:495 [inlined]
[6] include_package_for_output(pkg::Base.PkgId, input::String, depot_path::Vector{String}, dl_load_path::Vector{String}, load_path::Vector{String}, concrete_deps::Vector{Pair{Base.PkgId, UInt128}}, source::Nothing)
@ Base ./loading.jl:2216
[7] top-level scope
@ stdin:3
While I am usually able to decipher which type is the offending one (in this case, St3mapIjSt10shared_ptrIN8lbcrypto11EvalKeyImplINS1_12DCRTPolyImplIN9bigintdyn9mubintvecINS4_5ubintImEEEEEEEEESt4lessIjESaISt4pairIKjSB_EEE probably refers to something starting with std::map<std::shared_ptr<lbcrypto..., it's usually rather cumbersume.
Thus, it would be great if there were a demangle function (or if such names were demangled automatically). Furthermore, it would be great - if possible - if the offending location in the wrapper library could be shown as well.
The latter probably requires passing the source location in C++ as something like <filename>:<lineno> with each call to add_type, method etc. Since this is C++, it would probably require an explicit argument (maybe using an appropriate LOC__ preproc macro) that would have to be explicitly given as an argument, but it would certainly make debugging much easier.
The text was updated successfully, but these errors were encountered:
Sometimes I start batch-wrapping a bunch of library functions to get a C++ wrapper more feature complete, but I overlook that some types have been used that have not been wrapped themselves yet. At the moment, one only gets a (to me) rather cryptic error message such as
While I am usually able to decipher which type is the offending one (in this case,
St3mapIjSt10shared_ptrIN8lbcrypto11EvalKeyImplINS1_12DCRTPolyImplIN9bigintdyn9mubintvecINS4_5ubintImEEEEEEEEESt4lessIjESaISt4pairIKjSB_EEE
probably refers to something starting withstd::map<std::shared_ptr<lbcrypto...
, it's usually rather cumbersume.Thus, it would be great if there were a
demangle
function (or if such names were demangled automatically). Furthermore, it would be great - if possible - if the offending location in the wrapper library could be shown as well.The latter probably requires passing the source location in C++ as something like
<filename>:<lineno>
with each call toadd_type
,method
etc. Since this is C++, it would probably require an explicit argument (maybe using an appropriateLOC__
preproc macro) that would have to be explicitly given as an argument, but it would certainly make debugging much easier.The text was updated successfully, but these errors were encountered: