On Tue, Feb 14, 2012 at 8:13 PM, Stefan Behnel wrote:
> Maciej Fijalkowski, 14.02.2012 19:00:
>> On Tue, Feb 14, 2012 at 7:56 PM, Stefan Behnel wrote:
>>> Amaury Forgeot d'Arc, 14.02.2012 18:45:
2012/2/14 Stefan Behnel
> if PyPy can't come up with a fast way to
> interface with C code
Stefan Behnel, 14.02.2012 19:13:
> Simple questions:
>
> Is rffi usable in this context or is it not? Does it require RPython code
> to be generated or does it also work with Python code? How do callbacks
> work in rffi? Does rffi provide access to PyPy objects? And how so?
>
> I don't know all t
On 14 February 2012 18:10, Antonio Cuni wrote:
> On 02/14/2012 06:56 PM, Stefan Behnel wrote:
>>
>> Ok, then I take it that this would be the preferred Python+FFI approach
>> for
>> interfacing, right? ctypes is out of the loop?
>
>
> note that there are at least two different levels to interface
Maciej Fijalkowski, 14.02.2012 19:00:
> On Tue, Feb 14, 2012 at 7:56 PM, Stefan Behnel wrote:
>> Amaury Forgeot d'Arc, 14.02.2012 18:45:
>>> 2012/2/14 Stefan Behnel
if PyPy can't come up with a fast way to
interface with C code, it's bound to die.
>>>
>>> But it certainly can! For example
On 02/14/2012 06:56 PM, Stefan Behnel wrote:
Ok, then I take it that this would be the preferred Python+FFI approach for
interfacing, right? ctypes is out of the loop?
note that there are at least two different levels to interface with C code.
The first is using rffi, which lets you to call C
On 14 February 2012 18:00, Maciej Fijalkowski wrote:
> On Tue, Feb 14, 2012 at 7:56 PM, Stefan Behnel wrote:
>> Amaury Forgeot d'Arc, 14.02.2012 18:45:
>>> 2012/2/14 Stefan Behnel
if PyPy can't come up with a fast way to
interface with C code, it's bound to die.
>>>
>>> But it certainly
On Tue, Feb 14, 2012 at 7:56 PM, Stefan Behnel wrote:
> Amaury Forgeot d'Arc, 14.02.2012 18:45:
>> 2012/2/14 Stefan Behnel
>>> if PyPy can't come up with a fast way to
>>> interface with C code, it's bound to die.
>>
>> But it certainly can! For example PyPy implements the _ssl and pyexpat
>> modu
Amaury Forgeot d'Arc, 14.02.2012 18:45:
> 2012/2/14 Stefan Behnel
>> if PyPy can't come up with a fast way to
>> interface with C code, it's bound to die.
>
> But it certainly can! For example PyPy implements the _ssl and pyexpat
> modules,
> which are interfaces to the openssl and expat libraries
Hi Stefan,
On Tue, Feb 14, 2012 at 18:24, Stefan Behnel wrote:
> My personal take on this is: if PyPy can't come up with a fast way to
> interface with C code, it's bound to die. (...)
I think you are seeing the world through the pin's hole of what would
be needed for Cython's C files to compile
2012/2/14 Stefan Behnel
> if PyPy can't come up with a fast way to
> interface with C code, it's bound to die.
>
But it certainly can! For example PyPy implements the _ssl and pyexpat
modules,
which are interfaces to the openssl and expat libraries.
And it does that by generating C code that cal
On Tue, Feb 14, 2012 at 7:24 PM, Stefan Behnel wrote:
> Armin Rigo, 14.02.2012 16:12:
>> On Tue, Feb 14, 2012 at 14:12, Stefan Behnel wrote:
>>> Hmm, if that is so, how would you ever want to make PyPy bidirectionally
>>> interface with anything at all? How does ctypes even work in PyPy?
>>
>> I b
Hi everyone
Having work on the Python backend for Cython I can give you what I think
are the main hassles.
First, ctypes semantics don't match Cython semantics (which is way
closer, in a good way, to C)
Second, if you work with the AST, you should reimplement stuff that
don't change between Cyth
Armin Rigo, 14.02.2012 16:12:
> On Tue, Feb 14, 2012 at 14:12, Stefan Behnel wrote:
>> Hmm, if that is so, how would you ever want to make PyPy bidirectionally
>> interface with anything at all? How does ctypes even work in PyPy?
>
> I believe you are not understanding my point. Obviously ctypes
Hey,
On Tue, Feb 14, 2012 at 4:28 PM, mark florisson
wrote:
[snip]
>> There is no way to map that to Python unless you use something like
>> ctypes (but ctypes is not considered to be right for this purpose).
>
> Why is ctypes not right? Cython could actually generate a C function
> with a known
Hi Mark,
On Tue, Feb 14, 2012 at 16:22, mark florisson wrote:
> (...) Going the python + ctypes way through to the end,
> and supporting all the features, will be a lot of work. (...)
I think that your points are valid and need to be carefully
considered. I was taking a bit of an extreme opposi
Hi,
On Tue, 14 Feb 2012, mark florisson wrote:
1) C++ support
(http://docs.cython.org/src/userguide/wrapping_CPlusPlus.html)
[.. snip ..]
Under this model I think the first three points are particularly
though. Could RPython in any way alleviate the countless problems with
this approach (
On 14 February 2012 15:25, Martijn Faassen wrote:
> On Tue, Feb 14, 2012 at 4:19 PM, Armin Rigo wrote:
>> Hi Martijn,
>>
>> On Tue, Feb 14, 2012 at 14:47, Martijn Faassen
>> wrote:
>>> But Cython-based code does talk to C APIs, so there is a problem.
>>> Python code in PyPy needs to be able to
On 14 February 2012 15:12, Armin Rigo wrote:
> Hi Stefan,
>
> On Tue, Feb 14, 2012 at 14:12, Stefan Behnel wrote:
>> Hmm, if that is so, how would you ever want to make PyPy bidirectionally
>> interface with anything at all? How does ctypes even work in PyPy?
>
> I believe you are not understandi
On Tue, Feb 14, 2012 at 4:19 PM, Armin Rigo wrote:
> Hi Martijn,
>
> On Tue, Feb 14, 2012 at 14:47, Martijn Faassen wrote:
>> But Cython-based code does talk to C APIs, so there is a problem.
>> Python code in PyPy needs to be able to interface with C APIs first in
>> order to generate the right
On 14 February 2012 13:21, Maciej Fijalkowski wrote:
> On Tue, Feb 14, 2012 at 3:12 PM, Stefan Behnel wrote:
>> Armin Rigo, 14.02.2012 13:13:
>>> the main problem is that the RPython-to-C translation that we
>>> do is not just a one-format traduction. We need to tweak the
>>> intermediate code i
Hi Martijn,
On Tue, Feb 14, 2012 at 14:47, Martijn Faassen wrote:
> But Cython-based code does talk to C APIs, so there is a problem.
> Python code in PyPy needs to be able to interface with C APIs first in
> order to generate the right stuff from Cython.
That's not necessarily hard. I believe
Hi Stefan,
On Tue, Feb 14, 2012 at 14:12, Stefan Behnel wrote:
> Hmm, if that is so, how would you ever want to make PyPy bidirectionally
> interface with anything at all? How does ctypes even work in PyPy?
I believe you are not understanding my point. Obviously ctypes works
in PyPy, and not, I
Hi Antonio,
On Tue, Feb 14, 2012 at 13:23, Antonio Cuni wrote:
> this approach would work for all C extensions then, not just Cython's one,
> right?
No. Or maybe yes, but with much more work. I'm suggesting to take
specifically the Cython-produced C files, with all macros redefined to
strange
Hi there,
So if I understand the direction of this discussion correctly, it is
suggested that to interface PyPy with Cython in a non-hackish way the
best strategy might be to modify Cython to generate Python code. This
way, there's no need to expose all sorts of PyPy internals on a C API
level, an
On 02/14/2012 02:21 PM, Maciej Fijalkowski wrote:
I think CPython C API is a serious part of it's success because it's
"good enough for a lot of cases" not because it's necessary for it's
success. In my opinion a decent FFI (not ctypes, I mean a decent one)
and better performance would eliminate
On Tue, Feb 14, 2012 at 3:12 PM, Stefan Behnel wrote:
> Armin Rigo, 14.02.2012 13:13:
>> the main problem is that the RPython-to-C translation that we
>> do is not just a one-format traduction. We need to tweak the
>> intermediate code in various ways depending on various settings. The
>> way it
Armin Rigo, 14.02.2012 13:13:
> the main problem is that the RPython-to-C translation that we
> do is not just a one-format traduction. We need to tweak the
> intermediate code in various ways depending on various settings. The
> way it is tweaked really depends on these settings in a way that
>
Armin Rigo, 14.02.2012 13:18:
> On Tue, Feb 14, 2012 at 13:13, Armin Rigo wrote:
>> For this reason, I remain convinced that the best approach for Cython
>> on PyPy is instead to have Cython generate pure Python code that would
>> use some API in the form of a built-in Python module.
>
> For what
2012/2/14 Armin Rigo
> As a rather extreme solution: I wonder how useful it would be to use
> gcc to cross-compile the C intermediate sources to MIPS assembler, and
> write a MIPS interpreter in RPython... (MIPS because it's apparently
> a very simple instruction set)
>
Are you suggesting somet
On 02/14/2012 01:18 PM, Armin Rigo wrote:
As a rather extreme solution: I wonder how useful it would be to use
gcc to cross-compile the C intermediate sources to MIPS assembler, and
write a MIPS interpreter in RPython... (MIPS because it's apparently
a very simple instruction set)
this approac
Re-Hi,
On Tue, Feb 14, 2012 at 13:13, Armin Rigo wrote:
> For this reason, I remain convinced that the best approach for Cython
> on PyPy is instead to have Cython generate pure Python code that would
> use some API in the form of a built-in Python module.
For what it's worth, it would work if t
Hi Fijal,
On Tue, Feb 14, 2012 at 10:50, Maciej Fijalkowski wrote:
> The thing is noone seriously works on the cython's pypy backend, so
> the dirty hacks seem like a very good solution short-to-mid term.
Someone feel free to try them out. However I'm generally negative
about the outcome and it
On Tue, Feb 14, 2012 at 11:48 AM, Antonio Cuni wrote:
> On 02/14/2012 10:41 AM, Amaury Forgeot d'Arc wrote:
>>
>>
>> Seriously - we control the code on both sides. I think the
>> possibilities
>> are endless.
>>
>>
>> Why only think in terms of C code then? The best API pypy offers so far
>>
On 02/14/2012 10:41 AM, Amaury Forgeot d'Arc wrote:
Seriously - we control the code on both sides. I think the possibilities
are endless.
Why only think in terms of C code then? The best API pypy offers so far
is written in RPython - space operations, type definitions, and external C
2012/2/14 Stefan Behnel
> Antonio Cuni, 14.02.2012 09:35:
> > On 02/14/2012 09:17 AM, Stefan Behnel wrote:
> >>
> >> Stuffing the code for both CPython and PyPy into the same C source file
> may
> >> result in a noticeable increase in C code size at some point, but as
> long
> >> as the C preproc
Antonio Cuni, 14.02.2012 09:35:
> On 02/14/2012 09:17 AM, Stefan Behnel wrote:
>>
>> Stuffing the code for both CPython and PyPy into the same C source file may
>> result in a noticeable increase in C code size at some point, but as long
>> as the C preprocessor can filter it back out, at least the
On 02/14/2012 09:17 AM, Stefan Behnel wrote:
Stuffing the code for both CPython and PyPy into the same C source file may
result in a noticeable increase in C code size at some point, but as long
as the C preprocessor can filter it back out, at least the build times
won't go up all that much, and
Stefan Behnel, 14.02.2012 08:46:
> Antonio Cuni, 14.02.2012 00:04:
>> On 02/13/2012 11:26 PM, Stefan Behnel wrote:
> Last time I looked, Cython still generates code that PyPy cannot handle:
> for example, it explicitly messes with tstate->curexc_type&co,
> Couldn't PyErr_Fetch() and
Antonio Cuni, 14.02.2012 00:04:
> On 02/13/2012 11:26 PM, Stefan Behnel wrote:
>>> > Last time I looked, Cython still generates code that PyPy cannot handle:
>>> > for example, it explicitly messes with tstate->curexc_type&co,
>>> > Couldn't PyErr_Fetch() and PyErr_Restore() be used instead?
>>
On 13 February 2012 23:04, Antonio Cuni wrote:
> On 02/13/2012 11:26 PM, Stefan Behnel wrote:
>>>
>>> > Last time I looked, Cython still generates code that PyPy cannot
>>> > handle:
>>> > for example, it explicitly messes with tstate->curexc_type&co,
>>> > Couldn't PyErr_Fetch() and PyErr_Rest
On 02/13/2012 11:26 PM, Stefan Behnel wrote:
> Last time I looked, Cython still generates code that PyPy cannot handle:
> for example, it explicitly messes with tstate->curexc_type&co,
> Couldn't PyErr_Fetch() and PyErr_Restore() be used instead?
Just two general comments on this, because the
Amaury Forgeot d'Arc, 13.02.2012 22:06:
> 2012/2/13 Stefan Behnel
>
>> Given how important Cython has become for the Python ecosystem in
>> many regards, it's sad that PyPy still doesn't have it available
>
> Last time I looked, Cython still generates code that PyPy cannot handle:
> for example,
Hey,
Thanks guys for bringing the discussion back on track!
Regards,
Martijn
___
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
Maciej Fijalkowski, 13.02.2012 21:41:
> On Mon, Feb 13, 2012 at 9:37 PM, Stefan Behnel wrote:
>> What are
>> you using for comparison? speed.pypy.org? Have you noticed that amongst all
>> those benchmarks there that PyPy was specifically tuned for, there is not a
>> single benchmark that was select
2012/2/13 Stefan Behnel
> Given how important Cython has become for the Python ecosystem in
> many regards, it's sad that PyPy still doesn't have it available
>
Last time I looked, Cython still generates code that PyPy cannot handle:
for example, it explicitly messes with tstate->curexc_type &co
On Mon, Feb 13, 2012 at 9:37 PM, Stefan Behnel wrote:
> Maciej Fijalkowski, 13.02.2012 19:44:
>> On Mon, Feb 13, 2012 at 4:29 PM, Stefan Behnel wrote:
>>> Sébastien Volle, 13.02.2012 13:33:
My team is working on a project of fast packet sniffers and I'm comparing
performance between diff
Hi Stefan, others,
I've recommended to Maciej to take this discussion off-list with
Stefan. I think a few mailing list etiquette mistakes were made in
this discussion so far. I don't think this is worth a flame war and
it's in my interest if you both work it out - Stefan's contributions
added to M
Maciej Fijalkowski, 13.02.2012 19:44:
> On Mon, Feb 13, 2012 at 4:29 PM, Stefan Behnel wrote:
>> Sébastien Volle, 13.02.2012 13:33:
>>> My team is working on a project of fast packet sniffers and I'm comparing
>>> performance between different languages.
>>> So, we came up with a simple ARP sniffer
48 matches
Mail list logo
