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
Hi Martin,
On 30 July 2014 21:13, Martin Matusiak wrote:
> 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?
A C++ "reference" type like "int &" is implemented
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 ASCI
Hi,
On 26 July 2014 11:19, Antonio Cuni wrote:
> this looks interesting, but from a quick look it seems they are only
> offering a C++ API?
> In that case, it might be better/easier to wrap it through cppyy than cffi.
One or the other, yes.
> Also, did Travis told you what are the plans for sci
Hi,
On 31 July 2014 16:47, Eleytherios Stamatogiannakis 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
pr
Hi,
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 *".
wish that were true. Currently, I have no good int&, although int* will
work through an arr
Hi Wim,
Thanks for answering the original question.
On 31 July 2014 19:05, wrote:
> 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
Hi Armin,
...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.
at low-level, sure. But to first order, I deal with wrappers (even in
cling, as it could be an inline function
Did Travis seem to indicate they would accept contributions from outside
toward making a new ndarray implementation a reality? Until we can find
a wagon to hitch our minimal efforts to, I will keep working slowly on
micronumpy. It seems useful for some tasks, and will be even more so
once linal
