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
Hi,
Ok. In that case, to reproduce, you'll need the "STL" file from Frans. And
his ".skeinforge_pypy" folder from C:\documents and settings/[USER]/ (this
contains all the configuration settings, cross platform compatible, needs
to be in $HOME) And the SkeinPyPy release from github.
If I encounter
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
On Tue, Feb 14, 2012 at 5:35 PM, Serhat Sevki Dincer wrote:
> I will take the liberty to forward this topic on "scientific python"
> to pypy list, since numpy work on pypy has progressed a lot,
> apparently, and it does concern pypy too, i guess..
Note - I know I'm replying to pypy-dev instead of
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 (
I will take the liberty to forward this topic on "scientific python"
to pypy list, since numpy work on pypy has progressed a lot,
apparently, and it does concern pypy too, i guess..
Date: Mon, 13 Feb 2012 13:55:45 -0800
From: Fernando Perez
Subject: [Matplotlib-users] Discussion with Guido van Ro
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,
Frans answered with more details but in a private mail to me. I
copied it to the following bug report:
https://bugs.pypy.org/issue1045
This is really a pypy bug, because it should not be possible to get a
"RPython error: AssertionError". It shows that an assert in the PyPy
source code
You don't check you email for a few days and this happens...
For the pypy-dev people. This is about SkeinPyPy, a pre-packaged Python
software package I made, which comes with PyPy.
https://github.com/daid/SkeinPyPy
The packaged version was 1.7 for the Alpha2 and Alpha3. And pypy-1.8 for
Alpha4. I
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
On Tue, Feb 14, 2012 at 12:42 AM, Dale Hubler wrote:
> Hello,
>
> I was requested to install pypy but our computers appear to be too new to
> run it, having libssl.so.0.9.8e among other newer items. This confuses me
> because the web page for pypy shows a 2011 date and blog entries from 2012.
>
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
44 matches
Mail list logo
