Open mw66 opened 2 years ago
A related question: is it possible to make a round trip, e.g.
// in D:
Dtype genDObj() {...}
void foo(Dtype dObj) {
// round trip, get back the D object here!
}
# in Python
dObj = libDll.genDobj() // wrap D object
...
libDll.foo(dObj); // unwrap D object?
Thanks.
libDdll ~main: building configuration "python39"... ERROR! Autowrap could not wrap aggregate `pyd.pydobject.PydObject` for Python ERROR! Autowrap could not wrap aggregate `deimos.python.object.PyTypeObject` for Python ERROR! Autowrap could not wrap aggregate `deimos.python.methodobject.PyMethodDef` for Python ERROR! Autowrap could not wrap aggregate `deimos.python.structmember.PyMemberDef` for Python ERROR! Autowrap could not wrap aggregate `deimos.python.descrobject.PyGetSetDef` for Python Linking... To force a rebuild of up-to-date targets, run again with --force.
I'm wondering if these ERROR messages are actually error, since the .so can be built, and the running result seems fine.
If they are not actually real errors, can we either change them to warnings, or even completely remove them? This only cause some confusion to the user.
Encounter a related issue:
https://github.com/symmetryinvestments/autowrap/issues/120#issuecomment-1166375061
Looks like this kind error only affect the single reported aggregate cannot be wrapped and used on the Python side, other types still can work. So I'd suggest change this to a warning message instead of error.
pyd lets you do this with PydObject if I'm not mistaken.
https://forum.dlang.org/post/amisorwzyfhsxocdnqdu@forum.dlang.org
Hi,
I know with PyD, D can call Python, and with autowrap, Python can call a D .dll, I'm just wondering if someone can show an example that Python <==> d can call both ways? esp. show passing D objects to Python and then call its member function there, and vice versa.
I tried a simple example:
The result seem working; but the dub build issues error message, even though the .so was able to be built.
I'm wondering if these ERROR messages are actually error, since the .so can be built, and the running result seems fine.
If they are not actually real errors, can we either change them to warnings, or even completely remove them? This only cause some confusion to the user.
And we can document this usage: i.e passing Python object to D, and call its Python method on the D side.
Thanks.