Okay,
i see the issue now. Basically i was under an impression that FFI was somehow
a more elaborate thing... Sorry for the bother, the actual thing i need is
more like cppyy, but working =) Anyways, might be actually interesting to see
it work with SWIG, since it uses C-like functions to wrap
Hi Alex,
On Sun, Jun 3, 2012 at 10:16 AM, Alex Pyattaev wrote:
> So, when would users be able to test it? I'd like to compare the overhead
> with ctypes and cppyy for instance.
The first version is ready for testing at https://github.com/arigo/ffi
. Note that the goal is not to interface with C
So, when would users be able to test it? I'd like to compare the overhead with
ctypes and cppyy for instance. I also wonder if I'd be able to send Python
objects to the c++ domain for storage in a container (e.g. a vector).
BR,
Alex
keskiviikko 30 toukokuu 2012 18:00:16 Robert Zaremba kirjoitti:
Thanks for clarification. I've been wondering why to dobule the work.
I'm also really fascinated about this idea, and that i don't need to use
separate tool.
It looks really great! Thanks!
--
Robert
___
pypy-dev mailing list
pypy-dev@python.org
h
Hi,
On Wed, 30 May 2012, Armin Rigo wrote:
On Tue, May 29, 2012 at 3:49 PM, Robert Zaremba wrote:
Whats the problem with cppyy?
Why don't extend it rather than build new solution based on pycparser?
Once again the design goals are different.
right; to Robert: think (conceptually) of cppyy a
Hi Robert,
On Tue, May 29, 2012 at 3:49 PM, Robert Zaremba wrote:
> Whats the problem with cppyy?
> Why don't extend it rather than build new solution based on pycparser?
Once again the design goals are different. Note that the first mail
in this thread was 15 days ago. During this time we go
Whats the problem with cppyy?
Why don't extend it rather than build new solution based on pycparser?
___
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
I think that what laura meant was that pypy people should talk to
luajit people, because if someone came to talk to pypy about ctypes
(the other big ffi for a dynamic language) pypy devs would have said
"don't copy us because in pratictice this design is bad.". As you said
that you talked to luajit
Hi Laura,
On Wed, May 23, 2012 at 6:29 AM, Laura Creighton wrote:
> tons of things that I agree with more or less wholesale, though I think
> that there is a slightly larger market for Cython in the immediate
> future ...
Sure, I never meant to give any market size estimate.
> Sounds great to m
>Sounds great to me. Except that Mike Pell (LuaJit's author) hasn't
>been cc'd on this note. And so what I would like to know before
Ooops, it's Mike Pall. No disrespect intended (and indeed I spelt the name
correctly the second time it was used in my reply). That was a typo.
I apologise.
In a message of Tue, 15 May 2012 16:23:14 +0200, Armin Rigo writes:
tons of things that I agree with more or less wholesale, though I think
that there is a slightly larger market for Cython in the immediate
future ...
Then comes this:
>The simplest FFI we know of for a high-level language is Lu
Hi all,
We started working on it a few days ago and it's already progressed well:
http://github.com/arigo/ffi
A bientôt,
Armin.
___
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
Hi Stefan,
Hmm, are you sure? Pyrex is pretty old, too. Cython's C++ support certainly
is a lot younger, though. Well, anyway...
we've been parsing C++ since C++ itself was a spring chicken. I don't know
when Pyrex started (and it doesn't seem to parse headers AFAICS?), but unless
you tell me
wlavrij...@lbl.gov, 16.05.2012 17:39:
>> Then take a look at some of the tools that Cython users have written to
>> generate .pxd files from header files. I heard of at least two that use
>> gccxml and clang respectively. Seems like Wim Lavrijsen has also started
>> doing the same thing all over ag
Hi David,
I think the trick here is automating the tedious description of the C API in
ctypes (note, the above doesn't need to be done in ctypes, but can be thought
of a pythonic interface to low-level C). AFAIK LLVM provides python binding
for the language and (with clang) could possibly pro
Hi Stefan,
Then take a look at some of the tools that Cython users have written to
generate .pxd files from header files. I heard of at least two that use
gccxml and clang respectively. Seems like Wim Lavrijsen has also started
doing the same thing all over again with cppyy.
not sure where the
Hi,
On Wed, May 16, 2012 at 12:54 PM, Eleytherios Stamatogiannakis
wrote:
> Is there in the plans a Jit friendly callback mechanism (from C to pypy) for
> the new API?
It is far too early to have such plans, but I guess so.
Armin
___
pypy-dev mailing
Is there in the plans a Jit friendly callback mechanism (from C to pypy)
for the new API?
IMHO, right now callback performance in pypy is very bad (2x to 12x
slower then CPython), and there is no way to do it efficiently apart
from going the RPython way and retranslating all of pypy.
l.
Hi Amaury,
On Wed, May 16, 2012 at 9:58 AM, Amaury Forgeot d'Arc
wrote:
> Another incarnation of SWIG?
...I suppose you can say so a priori. The difference is that we won't
try to perform conversions for the user. Instead he gets his
instances of C types as real Python objects and, if needed,
Armin Rigo, 16.05.2012 08:36:
> On Wed, May 16, 2012 at 7:01 AM, Stefan Behnel wrote:
>> I'm with Jean-Paul here.
>
> ...for a reason that might be unrelated to Jean-Paul's original
> complain: it's not like Cython gives first-class object manipulation
> on the result of parsing its .pyx files...
On Tuesday, 15 May 2012 16:23:14 Armin Rigo wrote:
> Hi all,
Hi,
> Fijal and me would like to raise interest among various groups of
> people about building a better ctypes replacement for Python.
I have a suggestion, and it (possibly) involves using ctypes...
> Opinions? Interests? This mai
2012/5/16 Armin Rigo
>
> I'm not against the idea of recognizing also Cython syntax extensions
> in the declarations, and indeed external files are a better idea than
> big inlined strings then. But I would also like to try out different
> paths. In one of them, these inline declarations would
Hi Stefan,
On Wed, May 16, 2012 at 7:01 AM, Stefan Behnel wrote:
> I'm with Jean-Paul here.
...for a reason that might be unrelated to Jean-Paul's original
complain: it's not like Cython gives first-class object manipulation
on the result of parsing its .pyx files... well, too bad but Python
is
Maciej Fijalkowski, 15.05.2012 22:01:
> On Tue, May 15, 2012 at 9:22 PM, wrote:
>> I don't think it's true that using strings instead of types (or other rich
>> objects) simplifies anything. Quite the opposite, it takes all of the
>> complexity which must exist and throws a huge wall up to preven
On Tue, May 15, 2012 at 12:59 PM, mark florisson
wrote:
> On 15 May 2012 17:34, Armin Rigo wrote:
> > Hi Yury,
> >
> > On Tue, May 15, 2012 at 5:56 PM, Yury Selivanov
> wrote:
> >> While I don't like some design quirks of Cython, I think that it's far
> >> better than any ffi or ctypes-like solu
On 15 May 2012 17:34, Armin Rigo wrote:
> Hi Yury,
>
> On Tue, May 15, 2012 at 5:56 PM, Yury Selivanov
> wrote:
>> While I don't like some design quirks of Cython, I think that it's far
>> better than any ffi or ctypes-like solution. Essentially, it's an ffi
>> merged with the language, not a s
Armin Rigo, 15.05.2012 18:34:
> On Tue, May 15, 2012 at 5:56 PM, Yury Selivanov wrote:
>> While I don't like some design quirks of Cython, I think that it's far
>> better than any ffi or ctypes-like solution. Essentially, it's an ffi
>> merged with the language, not a separate module. And that's
Maciej Fijalkowski, 15.05.2012 18:31:
>> However, CPython doesn't have a JIT compiler, and that's one of the biggest
>> drawbacks for (something like) ctypes. There's a reason we compile real
>> code in Cython, not just a thin glue layer. So, if you want something
>> that's usable outside of PyPy,
Hi Yury,
On Tue, May 15, 2012 at 5:56 PM, Yury Selivanov wrote:
> While I don't like some design quirks of Cython, I think that it's far
> better than any ffi or ctypes-like solution. Essentially, it's an ffi
> merged with the language, not a separate module. And that's a pretty
> unique approa
>
>
> However, CPython doesn't have a JIT compiler, and that's one of the biggest
> drawbacks for (something like) ctypes. There's a reason we compile real
> code in Cython, not just a thin glue layer. So, if you want something
> that's usable outside of PyPy, you will have to come up with somethin
On 15 May 2012 17:14, Stefan Behnel wrote:
> Maciej Fijalkowski, 15.05.2012 17:39:
>> On Tue, May 15, 2012 at 5:16 PM, Stefan Behnel wrote:
>>> Armin Rigo, 15.05.2012 16:23:
Fijal and me would like to raise interest among various groups of
people about building a better ctypes replacemen
Maciej Fijalkowski, 15.05.2012 17:39:
> On Tue, May 15, 2012 at 5:16 PM, Stefan Behnel wrote:
>> Armin Rigo, 15.05.2012 16:23:
>>> Fijal and me would like to raise interest among various groups of
>>> people about building a better ctypes replacement for Python.
>>> [...]
>>> The working alternativ
On 2012-05-15, at 10:23 AM, Armin Rigo wrote:
> Opinions? Interests? This mail is deliberately low on details about
> how we think we can do it. Instead I'm seeking general reactions for
> now and would like to move this soon to its own project, independent
> of PyPy.
While I don't like some de
Hi Skip,
On Tue, May 15, 2012 at 5:14 PM, Skip Montanaro wrote:
> Do either of the PyPy subprojects you mentioned address
> C++ interfaces? Do you plan to support it?
No. The subprojects I mentioned are the "ffistruct" branch
introducing a new built-in module by Antonio, and a different design
On Tue, May 15, 2012 at 5:16 PM, Stefan Behnel wrote:
> Armin Rigo, 15.05.2012 16:23:
> > Fijal and me would like to raise interest among various groups of
> > people about building a better ctypes replacement for Python.
> > [...]
> > The working alternatives nowadays are Cython and ctypes. For
Skip Montanaro, 15.05.2012 17:14:
>> So we would like to propose something (a bit more publically than the
>> two subprojects of PyPy attempting to do that --- did you know about
>> their existence?).
>
> No, can you provide references?
>
>> The simplest FFI we know of for a high-level language i
> So we would like to propose something (a bit more publically than the
> two subprojects of PyPy attempting to do that --- did you know about
> their existence?).
No, can you provide references?
> The simplest FFI we know of for a high-level language is LuaJIT's FFI.
> If you are interested, re
Armin Rigo, 15.05.2012 16:23:
> Fijal and me would like to raise interest among various groups of
> people about building a better ctypes replacement for Python.
> [...]
> The working alternatives nowadays are Cython and ctypes. For Cython
> you have to learn a whole new language; we can argue inf
Hi Armin, hi all,
On 05/15/2012 04:23 PM, Armin Rigo wrote:
> Hi all,
>
> Fijal and me would like to raise interest among various groups of
> people about building a better ctypes replacement for Python.
[cut]
> Opinions? Interests? This mail is deliberately low on details about
> how we thin
Hi all,
Fijal and me would like to raise interest among various groups of
people about building a better ctypes replacement for Python.
The general background first, at least as far as we know it. People
generally agree that CPython extension modules are not extremely hard
to write, but also not
40 matches
Mail list logo
