Hi Leonardo,
On 14 May 2015 at 21:51, Leonardo Santagada wrote:
> I'm thinking that maybe the JIT is trying to compile some trace and then
> throw it away, by using cprofile it is not even trying... that's why it is
> actually slower than cpython to begin with. Can this be the case Armin?
That's
I'm thinking that maybe the JIT is trying to compile some trace and then
throw it away, by using cprofile it is not even trying... that's why it is
actually slower than cpython to begin with. Can this be the case Armin? It
is a variation of what you said, but a more problematic one I think. Maybe
t
Hi Yicong,
On 14 May 2015 at 11:33, Yicong Huang wrote:
> To my understanding, "ALL_RESULTS" is used to prevent pypy GC the pointing
> buffer.
> And thus, it is the C callback function's responsibility to free the buffer.
> Am I right?
No. In my example I just keep storing ffi.new("char[]") obj
Thanks, the method did work.
To my understanding, "ALL_RESULTS" is used to prevent pypy GC the pointing
buffer.
And thus, it is the C callback function's responsibility to free the buffer.
Am I right?
On Thursday, May 14, 2015 at 4:14:07 PM UTC+8, Armin Rigo wrote:
>
> Hi Yicong,
>
> (CC to th
Thanks, the method did work.
To my understanding, "ALL_RESULTS" is used to prevent pypy GC the pointing
buffer.
And thus, it is the C callback function's responsibility to free the buffer.
Am I right?
On Thu, May 14, 2015 at 4:13 PM, Armin Rigo wrote:
> Hi Yicong,
>
> (CC to the cffi mailing l
Hi Stanislav,
On 14 May 2015 at 08:37, Stanislav Bohm wrote:
> I have tried some standard benchmarks and my other python programs, and
> cProfile makes things slower.
> Hence, Aislinn is the only program where I can reproduce the weird behavior.
Then it looks likely to be a "randomness" issue: d
Sorry, I found that's a bug of the code.
In some cases, char* buffer was free by accident before passing to
pypy_execute_source().
On Thu, May 14, 2015 at 4:21 PM, Armin Rigo wrote:
> Hi Yicong,
>
> On 12 May 2015 at 11:48, Yicong Huang wrote:
> > The program I wrote is simple: it read python c
Hi Michael,
On 11 May 2015 at 19:10, Michael Kennedy wrote:
> Hi guys, does that time work?
Just so you know, your mails are being sent to the general pypy-dev
mailing list too. We can't tell when "that time" is, probably because
you have used a different channel to set it up privately. Fijal
Hi Yicong,
On 13 May 2015 at 11:10, Amaury Forgeot d'Arc wrote:
>> Does pypy have similar API?
>
> But don't you have it already? the func(3) above should return the integer 6!
I would guess so too. The point of the PyPy "API" is that it is
completely minimal. You have to do everything with CF
Hi Yicong,
On 12 May 2015 at 11:48, Yicong Huang wrote:
> The program I wrote is simple: it read python code from a local file to
> char*, and pass char* to pypy_execute_source().
It works for us, so please give a complete example: ideally, a C
program that can show the problem when executed (in
Hi Yicong,
(CC to the cffi mailing list)
On 14 May 2015 at 05:02, Yicong Huang wrote:
> We had a python function that return a string value. The function will
> callback in C code.
> The below is an example of the code:
>
> @ffi.callback("char *(char *, char *)")
> def strconcat(x, y):
> x1
11 matches
Mail list logo
