Hi, I was reading about cppyy and I could not find a mention of what it does with out arguments. I also read through the unit tests, but I couldn't find any examples. Are they supported? I also found the section header "CPython" a little confusing on this page as the section doesn't seem to talk about cpython: pypy.readthedocs.org/en/latest/cppyy.html#cpython Martin
Hi Martin, On 30 July 2014 21:13, Martin Matusiak <numerodix@gmail.com> wrote:
A C++ "reference" type like "int &" is implemented like a C++ pointer type "int *" by most C++ compilers, as far as I know. My guess is that you simply have to pretend that "int &" is just "int *".
It's about the difference between cppyy and PyCintex, which is an older CPython-only equivalent to cppyy. A bientôt, Armin.
Hi,
wish that were true. Currently, I have no good int&, although int* will work through an array of size 1. One of them things that need integrating with cffi. (I tried once with CPython's ctypes, but the types are not in the public interface.)
It's about the difference between cppyy and PyCintex, which is an older CPython-only equivalent to cppyy.
Yes, and although the documentation is not wrong, it is out of date. There is a 'cppyy.py' module in recent versions of ROOT. Still suffers from the same dependency issues, but recent repositories (scientific software section of linux distro's, and certainly MacPorts) should have it, so although not nice, it's also not the end of the world to install. (Also means that yes, there is a cppyy on llvm these days, but for CPython, available through ROOT6. MacPorts definitely has it, not sure about others. There are some p3 issues, though, as llvm itself uses p2, but those can be worked around.) I've started rewriting all unit tests on the CPython side to be based on pytest and cppyy, and to synchronize them between the two implementations. Is a lot more work than I expected. :P Best regards, Wim -- WLavrijsen@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net
Hi Wim, Thanks for answering the original question. On 31 July 2014 19:05, <wlavrijsen@lbl.gov> wrote:
...I wish I could make sense of what you said, but I'm probably just too tired at the moment. I don't understand what the low-level difference between "int*" and "int&" is. More importantly I don't understand why you would mention cffi/ctypes, given that these two are not about C++ at all. There is certainly no plan to support "int&" or any non-C type in cffi. As far as I know these types are not in ctypes either (public interface or not) for the same reason. They are not in libffi either. A bientôt, Armin.
Hi Armin,
at low-level, sure. But to first order, I deal with wrappers (even in cling, as it could be an inline function, which, although having external linkage, is usually removed from the code section).
More importantly I don't understand why you would mention cffi/ctypes, given that these two are not about C++ at all.
No, but they actually do have ints. Right now, to get an int*, one would have to do: import array flag = array.array('i', [0]) set_flag(flag) But here's what I'd like code to look like: flag = c_int(0) set_flag(flag) and I can cook up a c_int myself, or re-use a data type representing a c_int, either from ctypes or cffi, that is already available. Re-using seems a better idea. For that to work, though, I need to be able to take the address of the actual payload of the c_int. This is not in the public interface of ctypes on CPython. Best regards, Wim -- WLavrijsen@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net
Hello, First of all, directly supporting UTF8 in CFFI has been discussed before. I'm bringing the same subject again because now PyPy aims to convert to using UTF8 internally by default. So the question is, will CFFI take advantage of that? Right now cffi_backend's "b_string" works with ASCII and widechar strings as input. This means that for UTF-8 input we need to first parse (via ffi.string) the char* as str (1st copy), and then convert it to UTF-8 (doing a 2nd copy?). Wouldn't it be faster to have a ffi.stringUTF8 for the case where we know the input is in UTF8? Ideally we could also have a ffi.stringUTF8const, which knowing that the char* is const (won't be changed by the C side), won't do a copy at all? Kind regards, l.
Hi, On 31 July 2014 16:47, Eleytherios Stamatogiannakis <estama@gmail.com> wrote:
Wouldn't it be faster to have a ffi.stringUTF8 for the case where we know the input is in UTF8?
It seems the truth is the opposite of what you expect. Right now, `ffi.string(p).decode('utf-8')` does two copies, whereas in the proposed UTF8 future of PyPy the same expression might possibly be done with only one copy (because `s` and `s.decode('utf-8')` could share the same byte string). It doesn't mean the idea of `ffi.stringUTF8()` is necessarily bad, but it should be a CFFI discussion instead of a PyPy one. I'm "-0" on the idea as adding more complexity to the API for just a minor performance gain (particularly one that disappears in the UTF8 future of PyPy).
Ideally we could also have a ffi.stringUTF8const, which knowing that the char* is const (won't be changed by the C side), won't do a copy at all?
That's not possible: a PyPy string object cannot point directly to raw memory, but must contain its own data, just like a CPython (byte)string object. A bientôt, Armin.
Hi Martin, On 30 July 2014 21:13, Martin Matusiak <numerodix@gmail.com> wrote:
A C++ "reference" type like "int &" is implemented like a C++ pointer type "int *" by most C++ compilers, as far as I know. My guess is that you simply have to pretend that "int &" is just "int *".
It's about the difference between cppyy and PyCintex, which is an older CPython-only equivalent to cppyy. A bientôt, Armin.
Hi,
wish that were true. Currently, I have no good int&, although int* will work through an array of size 1. One of them things that need integrating with cffi. (I tried once with CPython's ctypes, but the types are not in the public interface.)
It's about the difference between cppyy and PyCintex, which is an older CPython-only equivalent to cppyy.
Yes, and although the documentation is not wrong, it is out of date. There is a 'cppyy.py' module in recent versions of ROOT. Still suffers from the same dependency issues, but recent repositories (scientific software section of linux distro's, and certainly MacPorts) should have it, so although not nice, it's also not the end of the world to install. (Also means that yes, there is a cppyy on llvm these days, but for CPython, available through ROOT6. MacPorts definitely has it, not sure about others. There are some p3 issues, though, as llvm itself uses p2, but those can be worked around.) I've started rewriting all unit tests on the CPython side to be based on pytest and cppyy, and to synchronize them between the two implementations. Is a lot more work than I expected. :P Best regards, Wim -- WLavrijsen@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net
Hi Wim, Thanks for answering the original question. On 31 July 2014 19:05, <wlavrijsen@lbl.gov> wrote:
...I wish I could make sense of what you said, but I'm probably just too tired at the moment. I don't understand what the low-level difference between "int*" and "int&" is. More importantly I don't understand why you would mention cffi/ctypes, given that these two are not about C++ at all. There is certainly no plan to support "int&" or any non-C type in cffi. As far as I know these types are not in ctypes either (public interface or not) for the same reason. They are not in libffi either. A bientôt, Armin.
Hi Armin,
at low-level, sure. But to first order, I deal with wrappers (even in cling, as it could be an inline function, which, although having external linkage, is usually removed from the code section).
More importantly I don't understand why you would mention cffi/ctypes, given that these two are not about C++ at all.
No, but they actually do have ints. Right now, to get an int*, one would have to do: import array flag = array.array('i', [0]) set_flag(flag) But here's what I'd like code to look like: flag = c_int(0) set_flag(flag) and I can cook up a c_int myself, or re-use a data type representing a c_int, either from ctypes or cffi, that is already available. Re-using seems a better idea. For that to work, though, I need to be able to take the address of the actual payload of the c_int. This is not in the public interface of ctypes on CPython. Best regards, Wim -- WLavrijsen@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net
Hello, First of all, directly supporting UTF8 in CFFI has been discussed before. I'm bringing the same subject again because now PyPy aims to convert to using UTF8 internally by default. So the question is, will CFFI take advantage of that? Right now cffi_backend's "b_string" works with ASCII and widechar strings as input. This means that for UTF-8 input we need to first parse (via ffi.string) the char* as str (1st copy), and then convert it to UTF-8 (doing a 2nd copy?). Wouldn't it be faster to have a ffi.stringUTF8 for the case where we know the input is in UTF8? Ideally we could also have a ffi.stringUTF8const, which knowing that the char* is const (won't be changed by the C side), won't do a copy at all? Kind regards, l.
Hi, On 31 July 2014 16:47, Eleytherios Stamatogiannakis <estama@gmail.com> wrote:
Wouldn't it be faster to have a ffi.stringUTF8 for the case where we know the input is in UTF8?
It seems the truth is the opposite of what you expect. Right now, `ffi.string(p).decode('utf-8')` does two copies, whereas in the proposed UTF8 future of PyPy the same expression might possibly be done with only one copy (because `s` and `s.decode('utf-8')` could share the same byte string). It doesn't mean the idea of `ffi.stringUTF8()` is necessarily bad, but it should be a CFFI discussion instead of a PyPy one. I'm "-0" on the idea as adding more complexity to the API for just a minor performance gain (particularly one that disappears in the UTF8 future of PyPy).
Ideally we could also have a ffi.stringUTF8const, which knowing that the char* is const (won't be changed by the C side), won't do a copy at all?
That's not possible: a PyPy string object cannot point directly to raw memory, but must contain its own data, just like a CPython (byte)string object. A bientôt, Armin.
participants (4)
-
Armin Rigo -
Eleytherios Stamatogiannakis -
Martin Matusiak -
wlavrijsen＠lbl.gov