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
On 2012-05-04, at 3:06 PM, Ronny Pfannschmidt wrote:
> On 05/04/2012 09:05 PM, Yury Selivanov wrote:
>> On 2012-05-04, at 2:57 PM, Ronny Pfannschmidt wrote:
>>
>>> personally i think unless you find a proper way to deal with the git has no
>>> named branches
On 2012-05-04, at 2:57 PM, Ronny Pfannschmidt wrote:
> personally i think unless you find a proper way to deal with the git has no
> named branches thing, this is a no-go
Um, what is "named branches" thing that git apparently doesn't have?
-
Yury
___
Hello,
It looks like https://github.com/pypy/pypy is out of sync. Can somebody take a
look at that?
Thanks!
-
Yury
___
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
Maybe it's a good idea to find the bottleneck in the test and extend speed.pypy
suite? The more performance tests it hosts the better.
-Yury
On 2011-11-25, at 11:31 AM, Serhat Sevki Dincer wrote:
> https://bugs.pypy.org/issue940
>
> On Fri, Nov 25, 2011 at 6:22 PM, Piotr Skamruk
> wrote:
>>
Hello Antonio,
And what are the rough time-estimates?
Thank you,
-Yury
On 2011-09-12, at 9:49 AM, Antonio Cuni wrote:
> Hello pypy-dev,
>
> in the past weeks, I and the other core developers have talked a lot about
> supporting Python 3 in PyPy. The task is huge and it's unlikely that it will
Thank you, Armin.
On 2011-09-02, at 2:48 AM, Armin Rigo wrote:
> Hi Yury,
>
> On Thu, Sep 1, 2011 at 8:26 PM, Yury Selivanov
> wrote:
>> Will it be possible at some point to write modules for pypy in RPython
>> without the need to rebuild the entire interpreter?
>
On 2011-09-01, at 1:03 PM, Armin Rigo wrote:
>> Back on topic, it surprised me, too, that RPython components are not
>> modular. Do I understand correctly that this means that, after making
>> modifications to the component, the entire PyPy interpreter needs to be
>> rebuilt?
>
> Yes. You should
If you read that Armin's email carefully, you notice that he talks about a
low-level primitive called "stacklets", which have some limitations, but are
not intended for a regular use. Greenlets will be implemented on top of them.
So anything that was possible to do before will be supported in
+1 to the question. Why can't it be that way?
On 2011-08-17, at 2:30 PM, Miquel Torres wrote:
> @Armin
>> This would remain as a branch for the foreseeable future though,
>> because we still need a Python 2 interpreter, if only to run our own
>> translation toolchain on (and not suffer the 2.5x
On 2011-08-16, at 8:25 PM, Alex Gaynor wrote:
> Personally I think #3 is the only sane path. We *need* a Python 2 VM for the
> forseeable future. We're pretty lucky in that the JIT, GC, and all the
> honest to god complex code is totally seperate from the VM, so just
> supporting 2 Python VMs
argument, and not only for a python community.
On 2011-08-16, at 10:42 PM, Benjamin Peterson wrote:
> 2011/8/16 Yury Selivanov :
>> Re option #1, just trying to start a discussion:
>>
>> I know it's a hard topic, but why not to adapt python 3? Python 3 is the
>> f
r libs
in python 3 to save time later?
On 2011-08-16, at 6:39 PM, Benjamin Peterson wrote:
> 2011/8/16 Yury Selivanov :
>> Is it possible for pypy core developers to create a high-level roadmap with
>> what needs to be done and where? Should python3 be another translation
>&g
Is it possible for pypy core developers to create a high-level roadmap with
what needs to be done and where? Should python3 be another translation target?
Will it be required to touch rpython spec? What data structures need to be
introduced? etc. I don't think this planning will take weeks
14 matches
Mail list logo
