I'm trying to use protobuf with PyPy and I've been quite successful doing so with cppyy. I generated the protobuf in C++ and used reflex to generate the bindings. I've encountered some problems that I don't know how to deal with and the documentation doesn't describe what you can do to resolve them. I discovered that If you don't specify --deep when generating the reflex bindings and you try to pass a string to the C++ side you get a segfault. I'm guessing that's a bug. I can't catch exceptions that are being raised from C++ (it's also undocumented). I ensured that protobuf's FatalException has reflex bindings but the process crashes on an exception. e.SerializeAsString() [libprotobuf FATAL google/protobuf/message_lite.cc:273] CHECK failed: IsInitialized(): Can't serialize message of type "MyProtobufType" because it is missing required fields: header terminate called after throwing an instance of 'google::protobuf::FatalException' what(): CHECK failed: IsInitialized(): Can't serialize message of type "MyProtobufType" because it is missing required fields: header Aborted (core dumped) How can I catch that exception? The documentation is unclear how you can pass a pointer to a Python variable e.g.: str = "" e.SerializeToString(str) --------------------------------------------------------------------------- TypeError Traceback (most recent call last) <ipython-input-7-993880892d74> in <module>() ----> 1 e.SerializeToString(str) TypeError: none of the 5 overloaded methods succeeded. Full details: bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char> bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char> bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char> bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char> bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char> Best Regards, Omer Katz.
Hi, 2015-01-20 14:14 GMT+01:00 Omer Katz <omer.drow@gmail.com>:
The documentation is unclear how you can pass a pointer to a Python variable e.g.: str = ""
e.SerializeToString(str)
Message::SerializeToString() updates its argument in-place, but Python strings are not mutable. You should allocate a std::string from Python code, and pass it to the function. Maybe something like: s = cppyy.gbl.std.string() e.SerializeToString(s) print s
--------------------------------------------------------------------------- TypeError Traceback (most recent call last) <ipython-input-7-993880892d74> in <module>() ----> 1 e.SerializeToString(str)
TypeError: none of the 5 overloaded methods succeeded. Full details: bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char> bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char> bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char> bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char> bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char>
Best Regards, Omer Katz.
_______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
-- Amaury Forgeot d'Arc
That's correct but can't we handle those cases in cppyy? We should provide a native Python interface whenever it's possible. 2015-01-20 15:40 GMT+02:00 Amaury Forgeot d'Arc <amauryfa@gmail.com>:
Hi,
2015-01-20 14:14 GMT+01:00 Omer Katz <omer.drow@gmail.com>:
The documentation is unclear how you can pass a pointer to a Python variable e.g.: str = ""
e.SerializeToString(str)
Message::SerializeToString() updates its argument in-place, but Python strings are not mutable. You should allocate a std::string from Python code, and pass it to the function. Maybe something like:
s = cppyy.gbl.std.string() e.SerializeToString(s) print s
--------------------------------------------------------------------------- TypeError Traceback (most recent call last) <ipython-input-7-993880892d74> in <module>() ----> 1 e.SerializeToString(str)
TypeError: none of the 5 overloaded methods succeeded. Full details: bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char> bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char> bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char> bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char> bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char>
Best Regards, Omer Katz.
_______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
-- Amaury Forgeot d'Arc
2015-01-20 16:07 GMT+01:00 Omer Katz <omer.drow@gmail.com>:
That's correct but can't we handle those cases in cppyy? We should provide a native Python interface whenever it's possible.
It's not possible to take a Python string as mutable reference. Here are some options that cppyy could implement: - Use bytearray, which is mutable. a = bytearray() e.SerializeToString(a) s = str(a) - Pass a list, and expect the function to append a (python) string l = [] e.SerializeToString(s) s = l[0] - Change the signature of the function so that it *returns* the string (like swig's OUTPUT <http://www.swig.org/Doc3.0/Arguments.html#Arguments_nn5>) result, s = e.SerializeToString() I don't know which method is the most convenient with cppyy.
2015-01-20 15:40 GMT+02:00 Amaury Forgeot d'Arc <amauryfa@gmail.com>:
Hi,
2015-01-20 14:14 GMT+01:00 Omer Katz <omer.drow@gmail.com>:
The documentation is unclear how you can pass a pointer to a Python variable e.g.: str = ""
e.SerializeToString(str)
Message::SerializeToString() updates its argument in-place, but Python strings are not mutable. You should allocate a std::string from Python code, and pass it to the function. Maybe something like:
s = cppyy.gbl.std.string() e.SerializeToString(s) print s
--------------------------------------------------------------------------- TypeError Traceback (most recent call last) <ipython-input-7-993880892d74> in <module>() ----> 1 e.SerializeToString(str)
TypeError: none of the 5 overloaded methods succeeded. Full details: bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char> bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char> bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char> bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char> bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char>
Best Regards, Omer Katz.
_______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
-- Amaury Forgeot d'Arc
-- Amaury Forgeot d'Arc
I tried to pass a bytearray and that's also not currently supported. Any clue about what should I do with the exception? It definitely shouldn't crash the process. I need it to raise a python exception instead. בתאריך 20 בינו 2015 17:49, "Amaury Forgeot d'Arc" <amauryfa@gmail.com> כתב:
2015-01-20 16:07 GMT+01:00 Omer Katz <omer.drow@gmail.com>:
That's correct but can't we handle those cases in cppyy? We should provide a native Python interface whenever it's possible.
It's not possible to take a Python string as mutable reference.
Here are some options that cppyy could implement:
- Use bytearray, which is mutable. a = bytearray() e.SerializeToString(a) s = str(a)
- Pass a list, and expect the function to append a (python) string l = [] e.SerializeToString(s) s = l[0]
- Change the signature of the function so that it *returns* the string (like swig's OUTPUT <http://www.swig.org/Doc3.0/Arguments.html#Arguments_nn5>) result, s = e.SerializeToString()
I don't know which method is the most convenient with cppyy.
2015-01-20 15:40 GMT+02:00 Amaury Forgeot d'Arc <amauryfa@gmail.com>:
Hi,
2015-01-20 14:14 GMT+01:00 Omer Katz <omer.drow@gmail.com>:
The documentation is unclear how you can pass a pointer to a Python variable e.g.: str = ""
e.SerializeToString(str)
Message::SerializeToString() updates its argument in-place, but Python strings are not mutable. You should allocate a std::string from Python code, and pass it to the function. Maybe something like:
s = cppyy.gbl.std.string() e.SerializeToString(s) print s
--------------------------------------------------------------------------- TypeError Traceback (most recent call last) <ipython-input-7-993880892d74> in <module>() ----> 1 e.SerializeToString(str)
TypeError: none of the 5 overloaded methods succeeded. Full details: bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char> bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char> bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char> bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char> bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char>
Best Regards, Omer Katz.
_______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
-- Amaury Forgeot d'Arc
-- Amaury Forgeot d'Arc
2015-01-20 17:00 GMT+01:00 Omer Katz <omer.drow@gmail.com>:
I tried to pass a bytearray and that's also not currently supported. Any clue about what should I do with the exception? It definitely shouldn't crash the process. I need it to raise a python exception instead.
The only way to prevent a crash is to add a "catch" block somehow in C++, and I don't see anything like this in cppyy. This said, it's probably a bad idea to continue something after what the library calls a "FatalError"... Better add a check like "if e.IsInitialized()" before calling SerializeToString.
בתאריך 20 בינו 2015 17:49, "Amaury Forgeot d'Arc" <amauryfa@gmail.com> כתב:
2015-01-20 16:07 GMT+01:00 Omer Katz <omer.drow@gmail.com>:
That's correct but can't we handle those cases in cppyy? We should provide a native Python interface whenever it's possible.
It's not possible to take a Python string as mutable reference.
Here are some options that cppyy could implement:
- Use bytearray, which is mutable. a = bytearray() e.SerializeToString(a) s = str(a)
- Pass a list, and expect the function to append a (python) string l = [] e.SerializeToString(s) s = l[0]
- Change the signature of the function so that it *returns* the string (like swig's OUTPUT <http://www.swig.org/Doc3.0/Arguments.html#Arguments_nn5>) result, s = e.SerializeToString()
I don't know which method is the most convenient with cppyy.
2015-01-20 15:40 GMT+02:00 Amaury Forgeot d'Arc <amauryfa@gmail.com>:
Hi,
2015-01-20 14:14 GMT+01:00 Omer Katz <omer.drow@gmail.com>:
The documentation is unclear how you can pass a pointer to a Python variable e.g.: str = ""
e.SerializeToString(str)
Message::SerializeToString() updates its argument in-place, but Python strings are not mutable. You should allocate a std::string from Python code, and pass it to the function. Maybe something like:
s = cppyy.gbl.std.string() e.SerializeToString(s) print s
--------------------------------------------------------------------------- TypeError Traceback (most recent call last) <ipython-input-7-993880892d74> in <module>() ----> 1 e.SerializeToString(str)
TypeError: none of the 5 overloaded methods succeeded. Full details: bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char> bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char> bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char> bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char> bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char>
Best Regards, Omer Katz.
_______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
-- Amaury Forgeot d'Arc
-- Amaury Forgeot d'Arc
-- Amaury Forgeot d'Arc
The fatal exception is not really that fatal. It just means that it can't serialize the protobuf object to a string. The normal protobuf Python bindings just raise Python exceptions. See https://github.com/google/protobuf/search?l=python&q=Exception&utf8=%E2%9C%93 The problem with IsInitialized() is that it doesn't report what's wrong exactly. I can get that information from e.InitializationErrorString() and raise a Python exception but it would be preferable that if reflex has a binding to the exception object it will catch it and reraise a Python version of that exception. 2015-01-20 18:18 GMT+02:00 Amaury Forgeot d'Arc <amauryfa@gmail.com>:
2015-01-20 17:00 GMT+01:00 Omer Katz <omer.drow@gmail.com>:
I tried to pass a bytearray and that's also not currently supported. Any clue about what should I do with the exception? It definitely shouldn't crash the process. I need it to raise a python exception instead.
The only way to prevent a crash is to add a "catch" block somehow in C++, and I don't see anything like this in cppyy. This said, it's probably a bad idea to continue something after what the library calls a "FatalError"... Better add a check like "if e.IsInitialized()" before calling SerializeToString.
בתאריך 20 בינו 2015 17:49, "Amaury Forgeot d'Arc" <amauryfa@gmail.com> כתב:
2015-01-20 16:07 GMT+01:00 Omer Katz <omer.drow@gmail.com>:
That's correct but can't we handle those cases in cppyy? We should provide a native Python interface whenever it's possible.
It's not possible to take a Python string as mutable reference.
Here are some options that cppyy could implement:
- Use bytearray, which is mutable. a = bytearray() e.SerializeToString(a) s = str(a)
- Pass a list, and expect the function to append a (python) string l = [] e.SerializeToString(s) s = l[0]
- Change the signature of the function so that it *returns* the string (like swig's OUTPUT <http://www.swig.org/Doc3.0/Arguments.html#Arguments_nn5>) result, s = e.SerializeToString()
I don't know which method is the most convenient with cppyy.
2015-01-20 15:40 GMT+02:00 Amaury Forgeot d'Arc <amauryfa@gmail.com>:
Hi,
2015-01-20 14:14 GMT+01:00 Omer Katz <omer.drow@gmail.com>:
The documentation is unclear how you can pass a pointer to a Python variable e.g.: str = ""
e.SerializeToString(str)
Message::SerializeToString() updates its argument in-place, but Python strings are not mutable. You should allocate a std::string from Python code, and pass it to the function. Maybe something like:
s = cppyy.gbl.std.string() e.SerializeToString(s) print s
--------------------------------------------------------------------------- TypeError Traceback (most recent call last) <ipython-input-7-993880892d74> in <module>() ----> 1 e.SerializeToString(str)
TypeError: none of the 5 overloaded methods succeeded. Full details: bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char> bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char> bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char> bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char> bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char>
Best Regards, Omer Katz.
_______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
-- Amaury Forgeot d'Arc
-- Amaury Forgeot d'Arc
-- Amaury Forgeot d'Arc
e.ParseFromString('') [libprotobuf ERROR google/protobuf/message_lite.cc:123] Can't parse message of type "MyProtobufType" because it is missing required fields:
Also how do I catch exceptions that are caused when parsing an event? header
False
2015-01-20 18:18 GMT+02:00 Amaury Forgeot d'Arc <amauryfa@gmail.com>:
2015-01-20 17:00 GMT+01:00 Omer Katz <omer.drow@gmail.com>:
I tried to pass a bytearray and that's also not currently supported. Any clue about what should I do with the exception? It definitely shouldn't crash the process. I need it to raise a python exception instead.
The only way to prevent a crash is to add a "catch" block somehow in C++, and I don't see anything like this in cppyy. This said, it's probably a bad idea to continue something after what the library calls a "FatalError"... Better add a check like "if e.IsInitialized()" before calling SerializeToString.
בתאריך 20 בינו 2015 17:49, "Amaury Forgeot d'Arc" <amauryfa@gmail.com> כתב:
2015-01-20 16:07 GMT+01:00 Omer Katz <omer.drow@gmail.com>:
That's correct but can't we handle those cases in cppyy? We should provide a native Python interface whenever it's possible.
It's not possible to take a Python string as mutable reference.
Here are some options that cppyy could implement:
- Use bytearray, which is mutable. a = bytearray() e.SerializeToString(a) s = str(a)
- Pass a list, and expect the function to append a (python) string l = [] e.SerializeToString(s) s = l[0]
- Change the signature of the function so that it *returns* the string (like swig's OUTPUT <http://www.swig.org/Doc3.0/Arguments.html#Arguments_nn5>) result, s = e.SerializeToString()
I don't know which method is the most convenient with cppyy.
2015-01-20 15:40 GMT+02:00 Amaury Forgeot d'Arc <amauryfa@gmail.com>:
Hi,
2015-01-20 14:14 GMT+01:00 Omer Katz <omer.drow@gmail.com>:
The documentation is unclear how you can pass a pointer to a Python variable e.g.: str = ""
e.SerializeToString(str)
Message::SerializeToString() updates its argument in-place, but Python strings are not mutable. You should allocate a std::string from Python code, and pass it to the function. Maybe something like:
s = cppyy.gbl.std.string() e.SerializeToString(s) print s
--------------------------------------------------------------------------- TypeError Traceback (most recent call last) <ipython-input-7-993880892d74> in <module>() ----> 1 e.SerializeToString(str)
TypeError: none of the 5 overloaded methods succeeded. Full details: bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char> bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char> bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char> bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char> bool google::protobuf::MessageLite::SerializeToString(std::string*) => TypeError: cannot pass str as basic_string<char>
Best Regards, Omer Katz.
_______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
-- Amaury Forgeot d'Arc
-- Amaury Forgeot d'Arc
-- Amaury Forgeot d'Arc
Hi,
I tried to pass a bytearray and that's also not currently supported.
no, it really expects an std::string object to be passed through an std::string*, as Amaury advised. Any other type would require the creation of a temporary. (A C++ string is not a byte array. Typically, it carries a length data member and a pointer to what is a byte array. Further, for short strings, those data members can be used as the actual payload.)
Any clue about what should I do with the exception? It definitely shouldn't crash the process. I need it to raise a python exception instead.
Right, which is done on the CPython side. Haven't gotten around to implement the same on the PyPy side. Isn't hard, but takes time. (There's a separate issue for the cling backend, where we have yet to move to MCJit, which is needed to support C++ exceptions through LLVM JIT-ted code.) Likewise, returning out-parameters in a tuple is a nice pythonization that is on the TODO-list (which is long). Lacking time, again. Of course, this can be fixed on the python side also, by replacing the bound function with one that creates a temporary s = std.string(), calls the original function, then returns an str(s). Best regards, Wim -- WLavrijsen@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net
So cppyy isn't production ready yet? If C++ exceptions can cause the process to crash that's very dangerous in production systems. Can we warn about this in the documentation. I think that people should know about this before investing time with it. 2015-01-20 19:03 GMT+02:00 <wlavrijsen@lbl.gov>:
Hi,
I tried to pass a bytearray and that's also not currently supported.
no, it really expects an std::string object to be passed through an std::string*, as Amaury advised. Any other type would require the creation of a temporary. (A C++ string is not a byte array. Typically, it carries a length data member and a pointer to what is a byte array. Further, for short strings, those data members can be used as the actual payload.)
Any clue about what should I do with the exception? It definitely
shouldn't crash the process. I need it to raise a python exception instead.
Right, which is done on the CPython side. Haven't gotten around to implement the same on the PyPy side. Isn't hard, but takes time. (There's a separate issue for the cling backend, where we have yet to move to MCJit, which is needed to support C++ exceptions through LLVM JIT-ted code.)
Likewise, returning out-parameters in a tuple is a nice pythonization that is on the TODO-list (which is long). Lacking time, again.
Of course, this can be fixed on the python side also, by replacing the bound function with one that creates a temporary s = std.string(), calls the original function, then returns an str(s).
Best regards, Wim -- WLavrijsen@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net
Omar,
So cppyy isn't production ready yet?
that will always be in the eye of the beholder. :)
If C++ exceptions can cause the process to crash that's very dangerous in production systems.
Yes, C++ exceptions do that in C++ as well. :) Which is why we forbid them.
Can we warn about this in the documentation. I think that people should know about this before investing time with it.
Adding support is probably less work then updating the docs. :P But at the moment, I'm falling from one "world-ending" emergency to another. :P Best regards, Wim -- WLavrijsen@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net
One last thing, The documentation doesn't specify where should I place the rootmap file. Is it where $REFLEX_HOME is set? 2015-01-20 19:16 GMT+02:00 <wlavrijsen@lbl.gov>:
Omar,
So cppyy isn't production ready yet?
that will always be in the eye of the beholder. :)
If C++ exceptions can cause the process to crash that's very dangerous in
production systems.
Yes, C++ exceptions do that in C++ as well. :) Which is why we forbid them.
Can we warn about this in the documentation. I think that people should
know about this before investing time with it.
Adding support is probably less work then updating the docs. :P But at the moment, I'm falling from one "world-ending" emergency to another. :P
Best regards, Wim -- WLavrijsen@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net
Omar,
The documentation doesn't specify where should I place the rootmap file.
yes it does. :) "By convention, the rootmap files should be located next to the reflection info libraries, so that they can be found through the normal shared library search path." i.e. they are found through the LD_LIBRARY_PATH envar. Standard problem when writing documentation: either tutorial style, as was chosen, which is nice for people new to it, but makes it hard to find info afterwards. Or index-style, which has the opposite as result. :P Best regards, Wim -- WLavrijsen@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net
My name is Omer which is the same as Omar (which is in Arabic) only in Hebrew. It's a common mistake. Don't worry. Is there a good guide for compiling C++ code when running setup.py? I think we should link to it in the documentation. What happens if I install a cppyy extension using setup.py? Will the rootmap be loaded from site-packages? בתאריך 21 בינו 2015 19:59, <wlavrijsen@lbl.gov> כתב:
Omar,
The documentation doesn't specify where should I place the rootmap file.
yes it does. :)
"By convention, the rootmap files should be located next to the reflection info libraries, so that they can be found through the normal shared library search path."
i.e. they are found through the LD_LIBRARY_PATH envar.
Standard problem when writing documentation: either tutorial style, as was chosen, which is nice for people new to it, but makes it hard to find info afterwards. Or index-style, which has the opposite as result. :P
Best regards, Wim -- WLavrijsen@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net
Omer,
My name is Omer which is the same as Omar (which is in Arabic) only in Hebrew. It's a common mistake. Don't worry.
whoops ... :} Sorry! Time for new glasses (or a larger font size).
Is there a good guide for compiling C++ code when running setup.py? I think we should link to it in the documentation.
Yes, that's a good idea. I've not spend any time thinking about that, though.
What happens if I install a cppyy extension using setup.py? Will the rootmap be loaded from site-packages?
No, as that is not part of LD_LIBRARY_PATH. I'd have to try and see whether it can be added dynamically (i.e. whether the path envar is cached or not) through an os.environ update. I can try later (am in a workshop atm.). Best regards, Wim -- WLavrijsen@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net
participants (3)
-
Amaury Forgeot d'Arc -
Omer Katz -
wlavrijsen＠lbl.gov