Amaury Forgeot d'Arc wrote:
>
> wxPython has the same number of functions, and uses Swig to do the wrapping.
swig parses C++ headers, and basically a significant part of C++. There
is really no way to do any kind of wrapping of C++ without parsing it,
or at least a significant portion of it.
>
>
David Cournapeau wrote:
> > No. You can use py++ if you like to generate boost::python. This (py++) is
> > fairly new, and I believe relatively few boost::python users follow this
> > route. Most of us write boost::python wrappers by hand (it's usually
> > pretty easy).
> I was talking in the co
Neal Becker wrote:
> David Cournapeau wrote:
>
>> Carl Friedrich Bolz wrote:
>>> Neal Becker wrote:
[...]
>> Indeed. But there are tools to generate most of the painful code:
>> Swig, boost::python, and others.
>> With Swig, you can even subclass C++ classes and override virtual
>>
Antonio Cuni wrote:
> The JVM backend has been mostly written by me and Niko Matsakis. At the
> moment both of us work on it in our spare time, but if my phd proposal
> gets accepted I should be able to work on it much more continuously.
That's excellent. Having just completed a dynlang compiler
Charles Oliver Nutter wrote:
> Wiring in support for calling Java libraries won't be particularly
> difficult, given the many reflective capabilities already present for
> Java. But I agree it needs to be there for most people to find a lot of
> use.
Indeed, I think this is the easiest part to
Antonio Cuni wrote:
> If you meant a "Python to JVM bytecode compiler", that's what I was
> talking about too :-).
> I'm not sure that having it will cover 90% of people interested in
> pypy-jvm; to fully exploit python on jvm we need to allow access to Java
> classes from Python (and vice-versa
* Neal Becker <[EMAIL PROTECTED]> [2007-11-16 09:41:12 -0500]:
> No. You can use py++ if you like to generate boost::python. This (py++) is
> fairly new, and I believe relatively few boost::python users follow this
> route. Most of us write boost::python wrappers by hand (it's usually
> pretty
On Wed, 14 Nov 2007 17:16:48 +0100, Carl Friedrich Bolz <[EMAIL PROTECTED]>
wrote:
>Hi all,
>
>I thought I would start a new thread for discussing what PyPy needs to
>become "production ready" (whatever that is) and succeed as a Python
>implementation. This is something were outside opinions are v
Hi,
Maciej Fijalkowski wrote:
> But besides, I fully agree to the BIG FAT WARNING. This code is mostly
> there for tests. Even strings should not cross this border
Hmm, it seems quite stable, though (besides a few bug in the exception
handling). Note that passing and receiving strings works fine
David Cournapeau wrote:
> Carl Friedrich Bolz wrote:
>> Neal Becker wrote:
>>> [...]
> Indeed. But there are tools to generate most of the painful code:
> Swig, boost::python, and others.
> With Swig, you can even subclass C++ classes and override virtual
> methods in python.
>
[...]
>> Indeed. But there are tools to generate most of the painful code:
>> Swig, boost::python, and others.
>> With Swig, you can even subclass C++ classes and override virtual
>> methods in python.
>> I wish pypy could do the same.
> Both methods involve parsing C++, which is not fun. For examp
Carl Friedrich Bolz wrote:
> Neal Becker wrote:
>> [...]
Indeed. But there are tools to generate most of the painful code:
Swig, boost::python, and others.
With Swig, you can even subclass C++ classes and override virtual
methods in python.
I wish pypy could do the same.
>>
Neal Becker wrote:
> [...]
>>> Indeed. But there are tools to generate most of the painful code:
>>> Swig, boost::python, and others.
>>> With Swig, you can even subclass C++ classes and override virtual
>>> methods in python.
>>> I wish pypy could do the same.
>> Both methods involve parsing C++,
Amaury Forgeot d'Arc wrote:
> David Cournapeau wrote:
>> Martijn Faassen wrote:
>>> Yes, this one would be a major challenge. If you can crack it and the
>>> PyPy interpreter offers another benefit (an obvious one is speed), you
>>> will be in awesome position. If not, the other benefits will have
In a message of Wed, 14 Nov 2007 17:40:54 GMT, Douglas McNeil writes:
>
>
>Arbitrary code is less interesting to me than JIT-powered fast numerical
>code. Moreover, we numerics types have much lower standards of
>"production ready" than the general public, and are willing to turn on
>options wi
David Cournapeau wrote:
> Martijn Faassen wrote:
>>
>> Yes, this one would be a major challenge. If you can crack it and the
>> PyPy interpreter offers another benefit (an obvious one is speed), you
>> will be in awesome position. If not, the other benefits will have to
>> weigh more strongly. Thi
David Cournapeau wrote:
> Martijn Faassen wrote:
>> Yes, this one would be a major challenge. If you can crack it and the
>> PyPy interpreter offers another benefit (an obvious one is speed), you
>> will be in awesome position. If not, the other benefits will have to
>> weigh more strongly. This
David Cournapeau wrote:
> Martijn Faassen wrote:
> >
> > Yes, this one would be a major challenge. If you can crack it and the
> > PyPy interpreter offers another benefit (an obvious one is speed), you
> > will be in awesome position. If not, the other benefits will have to
> > weigh more strongly.
Martijn Faassen wrote:
>
> Yes, this one would be a major challenge. If you can crack it and the
> PyPy interpreter offers another benefit (an obvious one is speed), you
> will be in awesome position. If not, the other benefits will have to
> weigh more strongly. This is definitely one to evolve
Hey Carl,
Carl Friedrich Bolz wrote:
> I thought I would start a new thread for discussing what PyPy needs to
> become "production ready" (whatever that is) and succeed as a Python
> implementation. This is something were outside opinions are very welcome
> (of course there is no guarantee we can
> >From previous discussions, I suspect I'm not the only lurker-fan who would
> be willing to commit time to working on numericentric graph optimizations
> when that becomes a worthwhile investment. There's no reason that the
> mostly-fortran bits of python code shouldn't run almost as fast as for
Charles Oliver Nutter wrote:
>> Moreover, I would add to this list that the possibility to compile
>> python to jvm bytecode instead of python bytecode; maybe a pypy-jvm
>> would be usable even without it, but e.g. developing applets requires
>> it.
>>
>> Hopefully, I'll be able to work on t
Martijn Faassen wrote:
>> - for PyPy-JVM: bindings to allow the interaction with arbitrary Java
>> libraries, threading support
>
> Does this already exist for PyPy-CLR?
yes, but it's more or less only a proof of concept. You can use .NET
classes from Python but you can't, e.g., inherit fr
Antonio Cuni wrote:
> Carl Friedrich Bolz wrote:
>
>> - for PyPy-JVM: bindings to allow the interaction with arbitrary Java
>> libraries, threading support
>
> Moreover, I would add to this list that the possibility to compile
> python to jvm bytecode instead of python bytecode; maybe a py
Just a small note. We've got nowadays pieces of code that can help you
handle safety-for-speed even in compiled rpython code, --sandbox uses those.
(Like check for NULL pointers, enable assertions, etc.)
But besides, I fully agree to the BIG FAT WARNING. This code is mostly there
for tests. Even s
Douglas McNeil wrote:
> This is probably the most low-hanging fruit there could be for a (fully
> float-aware) JIT. The functions tends to be embarrassingly simple, and
> seldom leave the int/float/list domain. Most numerical code is borderline
> RPython as-is.
if everything you need is to e
cfb wrote:
> I thought I would start a new thread for discussing what PyPy needs to
> become "production ready" (whatever that is) and succeed as a Python
> implementation.
> [...]
> - Speed. The JIT is still not in a state where it really speeds up
>arbitrary Python code. I expect this to c
Carl Friedrich Bolz wrote:
> - for PyPy-JVM: bindings to allow the interaction with arbitrary Java
> libraries, threading support
Moreover, I would add to this list that the possibility to compile
python to jvm bytecode instead of python bytecode; maybe a pypy-jvm
would be usable even wit
Hi all,
I thought I would start a new thread for discussing what PyPy needs to
become "production ready" (whatever that is) and succeed as a Python
implementation. This is something were outside opinions are very welcome
(of course there is no guarantee we can implement all of your wishes :-)
).
29 matches
Mail list logo
