2011/12/9 Rinu Boney :
> Can almost any language be implemented in RPython and be faster ?
> ( like can we implement a langugae like java ? )
Presumably, though I think you'd have to work to beat HotSpot.
--
Regards,
Benjamin
___
pypy-dev mailing list
Can almost any language be implemented in RPython and be faster ?
( like can we implement a langugae like java ? )
___
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
2011/12/9 Alexander Golec :
> Hey all,
>
> When the RPython receives the code objects, are all the objects that the
> interpreter would push and pop on the stack already present? Or does the
> abstract interpreter handle creating those objects as well?
>
> In other words, is interpretation abstra
2011/12/9 Alexander Golec :
> Also, if you take a look at gateway.py, you can see that type is being
> called. Does the interpreter treat class definitions and calls to type
> differently?
>
> https://bitbucket.org/pypy/pypy/src/94737f156c30/pypy/interpreter/gateway.py
That happens before the flow
Hey all,
When the RPython receives the code objects, are all the objects that the
interpreter would push and pop on the stack already present? Or does the
abstract interpreter handle creating those objects as well?
In other words, is interpretation abstract from the start of the program to the
Also, if you take a look at gateway.py, you can see that type is being called.
Does the interpreter treat class definitions and calls to type differently?
https://bitbucket.org/pypy/pypy/src/94737f156c30/pypy/interpreter/gateway.py
Alex
On Dec 9, 2011, at 8:22 PM, Benjamin Peterson wrote:
> 2
2011/12/9 Alexander Golec :
> So at no point reachable from the entry_point (or is it run?) of the program
> can you create classes and functions?
All the classes that there will ever by instances of in the RPython
program are known at translation.
--
Regards,
Benjamin
___
So at no point reachable from the entry_point (or is it run?) of the program
can you create classes and functions?
Alex
On Dec 9, 2011, at 8:18 PM, Benjamin Peterson wrote:
> 2011/12/9 Alexander Golec :
>> Hey all,
>>
>> Sorry to keep asking questions on the mailing list, but I've been doing
2011/12/9 Alexander Golec :
> Hey all,
>
> Sorry to keep asking questions on the mailing list, but I've been doing my
> semester research project on PyPy, and my deadline is beginning to loom...
>
> I have a question concerning what I think is a conflict between the RPython
> coding guide and the 2
Hey all,
Sorry to keep asking questions on the mailing list, but I've been doing my
semester research project on PyPy, and my deadline is beginning to loom...
I have a question concerning what I think is a conflict between the RPython
coding guide and the 2005 EU paper. The paper states:
Our
2011/12/9 Alexander Golec :
> I think it's coming together now, then. So then the code for object spaces
> are shared between PyPy and the RPython compiler, as is the code for abstract
> interpretation? The thing that triggered this was me wondering what does the
> interpretation of the bytecode
I think it's coming together now, then. So then the code for object spaces are
shared between PyPy and the RPython compiler, as is the code for abstract
interpretation? The thing that triggered this was me wondering what does the
interpretation of the bytecodes, but I'm guessing its the shared i
2011/12/9 Alexander Golec :
> So the RPython compiler reuses interpreter code from PyPy to perform bytecode
> interpretation on the objects that the were given it by the standard CPython
> dis module? Namely I'm thinking of the bits that handle branching code, where
> the interpreter must effect
So the RPython compiler reuses interpreter code from PyPy to perform bytecode
interpretation on the objects that the were given it by the standard CPython
dis module? Namely I'm thinking of the bits that handle branching code, where
the interpreter must effectively take both branches at once.
2011/12/9 Alexander Golec :
> I guess that's bugging me is where does the flow object space live? It is in
> RPython or the PyPy interpreter?
The flow space is not RPython. It's in pypy/objspace/flow
> Also, does RPython exist as a standalone thing, i.e. can I say 'rpython
> something.py' and g
I guess that's bugging me is where does the flow object space live? It is in
RPython or the PyPy interpreter? Also, does RPython exist as a standalone
thing, i.e. can I say 'rpython something.py' and get a translation?
Alex
On Dec 9, 2011, at 7:00 PM, Benjamin Peterson wrote:
> 2011/12/9 Ale
2011/12/9 Alexander Golec :
> Hi Armin,
>
> Thanks for the answer, but I'm having a hard time wrapping my head around
> this. I'm reading about object spaces, and I keep wondering how do the object
> spaces find their way into the CPython interpreter. In other words, since
> there is an element
Hi Martijn,
On Fri, Dec 9, 2011 at 23:55, Martijn Faassen wrote:
> Yes, I figured merging would be the main benefit, that makes sense.
> Hopefully it can be made to work in parallel with the Python 2
> implementation eventually though.
After all, all you need is "hg" and a bit (or a lot) of hack
Hey,
On Sat, Dec 10, 2011 at 12:20 AM, Armin Rigo wrote:
> On Fri, Dec 9, 2011 at 23:55, Martijn Faassen wrote:
>> Yes, I figured merging would be the main benefit, that makes sense.
>> Hopefully it can be made to work in parallel with the Python 2
>> implementation eventually though.
>
> After
Hey,
On Fri, Dec 9, 2011 at 6:27 PM, Armin Rigo wrote:
> On Fri, Dec 9, 2011 at 17:57, Martijn Faassen wrote:
>> Oh, I was assuming that PyPy would have one branch supporting both
>> python 2 and python 3. Is that currently not the case? What are the
>> reasons behind not separating the two impl
Hi Armin,
Thanks for the answer, but I'm having a hard time wrapping my head around this.
I'm reading about object spaces, and I keep wondering how do the object spaces
find their way into the CPython interpreter. In other words, since there is an
element of partial initialization to the transl
Hi Alexander,
The RPython toolchain is meant to be useful essentially for people
that want to implement an interpreter for a dynamic language, or that
want to hack at PyPy itself. If you're not in either category, you
probably only want to use the "pypy" executable, in the same way as
you use the
Hey all,
I have the following conception of the RPython toolchain:
- RPython translator is written in RPython, meaning it can be interpreted by
CPython, and then run as a standalone executable once translated
- The translator runs the standard interpreter on the input program.
- The input p
Hi,
On Fri, Dec 9, 2011 at 17:57, Martijn Faassen wrote:
> Oh, I was assuming that PyPy would have one branch supporting both
> python 2 and python 3. Is that currently not the case? What are the
> reasons behind not separating the two implementations in different
> packages?
I think it was not
Hi there,
Armin:
> like what you would get if you imported in the same Python both the
> "default" and the "py3k" branch (with the proper amount of import
> hacks to keep them from conflicting).
On Fri, Dec 9, 2011 at 4:50 PM, Amaury Forgeot d'Arc wrote:
> I was thinking of two object spaces wi
Hi there,
On Fri, Dec 9, 2011 at 4:18 PM, Bengt Richter wrote:
> PMJI, but I was thinking that if you had both py272 and py3k modules it
> would seem
> natural to keep them in separate directories,
True, I imagine you'd normally give them different module names. The
standard library however is
2011/12/9 Armin Rigo
> Hi Amaury,
>
> On Fri, Dec 9, 2011 at 14:36, Amaury Forgeot d'Arc
> wrote:
> >> Getting two completely separate interpreters in one process is trivial
> >> in PyPy
> >
> > Well, not so trivial; I played with this idea last evening.
> > A few lines in targetpypystandalone.p
Hi Amaury,
On Fri, Dec 9, 2011 at 14:36, Amaury Forgeot d'Arc wrote:
>> Getting two completely separate interpreters in one process is trivial
>> in PyPy
>
> Well, not so trivial; I played with this idea last evening.
> A few lines in targetpypystandalone.py to install a new objspace,
> and tried
Martijn Faassen, 08.12.2011 20:12:
On 12/08/2011 01:54 PM, Stefan Behnel wrote:
So, assuming that Martijn was actually referring to legacy code, I agree
that it won't solve the problem at hand. But that doesn't mean it would
be impossible to benefit from it.
Not sure what you mean here - I was
On 12/09/2011 01:09 PM Martijn Faassen wrote:
Hey Armin,
Thanks for your response!
On Fri, Dec 9, 2011 at 12:31 PM, Armin Rigo wrote:
On Thu, Dec 8, 2011 at 20:12, Martijn Faassen wrote:
Anyway, separate from the binding, I'm wondering about the challenge of two
Pythons in one runtime - ho
Hey,
On Fri, Dec 9, 2011 at 2:36 PM, Amaury Forgeot d'Arc wrote:
> 2011/12/9 Armin Rigo
>>
>> Getting two completely separate interpreters in one process is trivial
>> in PyPy
> Well, not so trivial; I played with this idea last evening.
Awesome! I'm glad someone who actually sounds like he kn
2011/12/9 Armin Rigo
> Getting two completely separate interpreters in one process is trivial
> in PyPy
>
Well, not so trivial; I played with this idea last evening.
A few lines in targetpypystandalone.py to install a new objspace,
and tried to translate...
Here are the issues I encountered so
On 9 December 2011 11:31, Armin Rigo wrote:
> Hi Martijn,
>
> On Thu, Dec 8, 2011 at 20:12, Martijn Faassen
> wrote:
> > Anyway, separate from the binding, I'm wondering about the challenge of
> two
> > Pythons in one runtime - how hard would it be to generate this with the
> > current PyPy? (im
Hey Armin,
Thanks for your response!
On Fri, Dec 9, 2011 at 12:31 PM, Armin Rigo wrote:
> On Thu, Dec 8, 2011 at 20:12, Martijn Faassen wrote:
>> Anyway, separate from the binding, I'm wondering about the challenge of two
>> Pythons in one runtime - how hard would it be to generate this with t
Hi Martijn,
On Thu, Dec 8, 2011 at 20:12, Martijn Faassen wrote:
> Anyway, separate from the binding, I'm wondering about the challenge of two
> Pythons in one runtime - how hard would it be to generate this with the
> current PyPy? (imagining two different Python interpreters were available)
Ge
35 matches
Mail list logo
