Hi,
On 15/09/10 18:18, Maciej Fijalkowski wrote:
> Hey anto.
>
> There was a SoC about that, I guess it would be good to chat about it
> at least (personally I think jitting rlib/libffi is exactly bad layer
> to be jitted and some experiments were done).
yes, I read the code in the fast-ctypes br
On 16 September 2010 13:03, Saravanan Shanmugham wrote:
> Either way, it looks like there i not much enthusiasm for porting Shedskin on
> PyPy and have pypy generate a compiler instead of an interpreter.
In a sense, it already does :). And of course translation is compilation, too.
> >From vario
- Original Message
> From: Hart's Antler
> To: pypy-dev@codespeak.net
> Cc: Saravanan Shanmugham
> Sent: Wed, September 15, 2010 5:44:35 PM
> Subject: Re: External RPython mailing list
>
> Porting ShedSkin to use the PyPy translation toolchain on the surface sounds
>like a good id
If anyone wants to pay developers to work on rpython it should
probably follow this wishlist and not focus on trying to merge
shedskin into pypy (for the all the reasons given above).
Here is my version of the list
On Wed, Sep 15, 2010 at 9:44 PM, Hart's Antler wrote:
> RPython Wishlist:
>
On 16 September 2010 10:44, Hart's Antler wrote:
> [the GPL] is no good for commerical software.
Please don't go there.
> ... what is gained:
> 2. None and (int,float) are intermixable as attributes on an instance
> because ShedSkin has some limited support for dynamic-sub-types. (PyPy
Porting ShedSkin to use the PyPy translation toolchain on the surface sounds
like a good idea, but its not if we look at the details. The first issue is
legal, PyPy is MIT licensed, which works very well when integrated by
commerical software. But Shedskin uses the GNU GPL3, so importing any o
Hey anto.
There was a SoC about that, I guess it would be good to chat about it
at least (personally I think jitting rlib/libffi is exactly bad layer
to be jitted and some experiments were done).
Cheers,
fijal
On Wed, Sep 15, 2010 at 1:07 PM, wrote:
> Author: antocuni
> Date: Wed Sep 15 13:07:
At a higher level of abstraction, Python is a dynamic language. The dynamicity
is what makes it slow. There are simply so many things that might occur at
runtime that have to be taken into account in the code. The JIT is designed to
find cases where the dynamic properties of the language are not
Hi Amaury,
On 09/15/2010 01:11 AM, Amaury Forgeot d'Arc wrote:
> 2010/9/15 Saravanan Shanmugham:
>> I don't expect this python compiler to be for full python but just a
>> Restricted
>> statically typed subset of python as defined by Shedskin.
>>
>> Yes. JIT annotation may not serve the purpose o
