On Mon, 25 Aug 2008 23:29:03 +0200
Ondrej Certik [EMAIL PROTECTED] wrote:
Cython is not perfect, but one can get C level speed now. They plan to
allow a pure python syntax, so that the same code actually also runs
in Python.
What do you mean here ? Cython already allows pure python syntax.
On Sun, 27 Jul 2008 18:11:15 -0600
rahul garg [EMAIL PROTECTED] wrote:
Hi.
I am writing a compiler called unPython (http://code.google.com/p/unpython)
a very young and immature compiler for compiling Python to C.
I am presenting the compiler at SciPy conference and need to write a paper
On Fri, 23 May 2008 12:18:12 +0200
Carl Friedrich Bolz [EMAIL PROTECTED] wrote:
Hi all,
seems that the video recordings of S3 are available:
http://www.swa.hpi.uni-potsdam.de/s3/program/
Does this work for anyone ?
Simon.
___
On Mon, 4 Feb 2008 11:58:12 +0100
Armin Rigo [EMAIL PROTECTED] wrote:
Hi Simon,
On Tue, Jan 29, 2008 at 09:06:22AM -0800, Simon Burton wrote:
I've taken some statistics on how the boehm gc performs with our current
application,
it has terrible worst case performance, often stopping
I've taken some statistics on how the boehm gc performs with our current
application,
it has terrible worst case performance, often stopping for hundreds of mS at a
time.
I tried calling GC_enable_incremental() but that seems to cause the code to
explode.
I don't have any idea how to obtain
On Thu, 4 Oct 2007 09:11:08 +0200
Carl Friedrich Bolz [EMAIL PROTECTED] wrote:
Hi Simon,
2007/10/3, Simon Burton [EMAIL PROTECTED]:
...
I just use a function from rctypes to find a library, i think
rffi has such a function now..
Then it should be possible to use the function that rffi
On Wed, 03 Oct 2007 17:55:12 +0200
Christian Tismer [EMAIL PROTECTED] wrote:
Hi friends,
to what extent has this been discussed?
Maciek and I had a chat on pypy-irc about it: we did not
seem to agree entirely.
Also, this ctypes-up-front approach was my original suggestion
(perhaps badly
On Wed, 3 Oct 2007 18:56:36 +0200
Carl Friedrich Bolz [EMAIL PROTECTED] wrote:
to which nobody replied about the RCTypes issue.
Note that I think it is fine to discuss the issue even now. But it is
very strange in my opinion to say now that it was never discussed.
No, I'm not talking
Well, I still want to defend this approach...
The idea is:
* ctypes is the API for interfacing with external objects
* genrffi constructs rffi objects by introspecting the ctypes objects
It has nothing to do with rctypes (although it uses ctypes_platform
to find the libraries). I would at least
Someone on pypy irc posted a link to a talk by Simon Peyton-Jones
on transactional memory:
http://oscon.blip.tv/file/317758/
it's worth checking out.
Also, i noticed on the llvm list someone has added support
for TM:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-August/010365.html
Simon.
On Wed, 20 Jun 2007 12:23:06 +0200
Martijn Faassen [EMAIL PROTECTED] wrote:
...
I happen to be interested in use case a) though. It is quite exciting to
me that we could have a faster template language interpreter
What is this interpreter you refer to here ?
Simon.
On Sun, 19 Aug 2007 12:33:09 +0200
Armin Rigo [EMAIL PROTECTED] wrote:
Hi all,
Those that follow IRC already know it, but it's worth being announced a
bit more widely: I've been working on a form of sandboxing for RPython
programs, which now seems to work for the whole of PyPy.
It's
On Wed, 22 Aug 2007 15:23:40 -0700
Simon Burton [EMAIL PROTECTED] wrote:
Following some hints from Samuele, I am trying to wrap such functions in
another function that does some casting.
Here is the latest:
def softwrapper(funcptr, arg_tps):
unrolling_arg_tps = unrolling_iterable
On Thu, 23 Aug 2007 19:13:26 +0200
Maciek Fijalkowski [EMAIL PROTECTED] wrote:
You need to create the structure which you push by hand. As well as
array argument.
I stuck a test in test_rffi but didn't want to commit it.
It works fine. (attached)
Simon.
import py
from
On Fri, 20 Jul 2007 14:52:54 +0200
Armin Rigo [EMAIL PROTECTED] wrote:
Hi Simon,
On Thu, Jul 19, 2007 at 06:31:17PM -0700, Simon Burton wrote:
The lltype's are very strict about types.
Indeed, it seems worthwhile to loosen this restriction at least for the
purpose of calling external
I've been working with Richard on a new (rpython) buffer class.
See attached for two approaches.
The richbuf seems much clearer, but i'm not sure how to get other
types out of it (like long long or short), or do byte swapping.
I don't understand this much, can someone point the right direction
On Tue, 07 Aug 2007 14:15:48 +0200
Maciek Fijalkowski [EMAIL PROTECTED] wrote:
Simon Burton wrote:
On Fri, 3 Aug 2007 12:14:13 -0700
Simon Burton [EMAIL PROTECTED] wrote:
I would like to expose some functions as external
symbols when i build a .so
def foo(i, j):
return i
On Fri, 3 Aug 2007 12:14:13 -0700
Simon Burton [EMAIL PROTECTED] wrote:
I would like to expose some functions as external
symbols when i build a .so
def foo(i, j):
return i+j
foo._expose_ = [rffi.INT, rffi.INT]
It seems like this could also enable a plugin system for rpython
I would like to expose some functions as external
symbols when i build a .so
def foo(i, j):
return i+j
foo._expose_ = [rffi.INT, rffi.INT]
This is basically so I can write cpython extension modules in rpython.
(and manually doing ref counting (etc.) on the cpython objects.)
Simon.
The lltype's are very strict about types.
If I declare an llexternal that takes a Float arg,
I cannot call it with an int arg. Well maybe that's
not so bad. But in rlib.rsdl there are functions that take
Unsigned, and these don't work even if called with
a non-negative constant int... Can we
On Thu, 28 Jun 2007 11:03:34 +0200
Maciek Fijalkowski [EMAIL PROTECTED] wrote:
Do you think is enough or you was thinking about a deeper introduction?
I would extremely enjoy it, hence you give us some reason why we're
talking about this at all :) There are a bit of orthogonal issues
Do you think we could extend rffi to be able to
expose function calls to outside callers, so that eg.
we can make nifty cpython extension modules ?
(i think this is number 3 in my list)
Simon.
On Sat, 16 Jun 2007 13:03:16 +0200
Maciek Fijalkowski [EMAIL PROTECTED] wrote:
Simon Burton wrote
I'd like to synchronize with Maciek and Antonio with regards
talking about rpython at EP this year. My talk comes right after
your rpython talk - i think we can perhaps share the burden (joy?)
of talking about rpython a bit.
Simon.
___
On Thu, 14 Jun 2007 18:45:54 +0200
Armin Rigo [EMAIL PROTECTED] wrote:
Any comments or objections? Are there people that already make heavy
use of rctypes, or the extension compiler?
Indeed. Mainly rctypes.
As well as an ever expanding use of libc,
we recently have interfaced to libSDL
On Tue, 24 Apr 2007 13:48:26 +1000
Maurice Ling [EMAIL PROTECTED] wrote:
This could be a nice idea - make R codes run on Numpy + Python. My line
of thought is that since there is an implementation of Numpy (I do not
know how complete it is) in PyPy already (pypy/rpython/numpy),
In terms
On Tue, 24 Apr 2007 10:58:19 +0200
Carl Friedrich Bolz [EMAIL PROTECTED] wrote:
Robert Schmitt wrote:
What about a C/C++ interpreter/compiler, there would be some real
benefit if people could transpile C code to python.
To be honest, I don't see how a C-to-Python-compiler a) relates to
On Mon, 23 Apr 2007 15:13:36 -0400
Terry Reedy [EMAIL PROTECTED] wrote:
| Naturally PyPy wouldn't be able to use its magical optimization abilities
on those bits
Many to most of 'those bits' have been heavily optimized already, which is
why to use them.
Terry Jan Reedy
Yes, but how
On Thu, 5 Apr 2007 16:03:25 -0400
Gary Robinson [EMAIL PROTECTED] wrote:
Hello,
In PyPy's facilities for writing a CPython extension, would it be conceivable
to have an option to release the CPython GIL when the extension is entered
and grab it back upon exit?
It's easy enough to call
On Thu, 29 Mar 2007 18:00:47 +0200
Armin Rigo [EMAIL PROTECTED] wrote:
Hi Simon,
On Mon, Mar 26, 2007 at 02:30:15PM -0700, Simon Burton wrote:
The attached script is an attempt to get __str__ to work in rpython.
After annotation, it looks for str(someinstance), rewriting the block
On Wed, 28 Mar 2007 19:54:35 +0200
Christian Tismer [EMAIL PROTECTED] wrote:
This looks good, congrats!
I had a different approach in mind which
would work without explicitly adding a pass to the
annotator, no idea which idea is more practical.
What I wanted to do is a tiny patch to
The attached script is an attempt to get __str__ to work in rpython.
After annotation, it looks for str(someinstance), rewriting the block to call
__str__.
Then the modified blocks are fed back into the annotator.
It seems to work. (And now i know a lot more about the internals of the
Not likely.
Simon.
On Tue, 23 Jan 2007 15:29:00 -0500
Neal Becker [EMAIL PROTECTED] wrote:
Subject says it all. Will I be able to use my existing c (c++ actually)
modules?
___
pypy-dev@codespeak.net
On Wed, 20 Dec 2006 11:50:37 +0900
David Cournapeau [EMAIL PROTECTED] wrote:
So for example, if a and b are numpy arrays, a python expression b *= a
would be translated in C by something like for(i = 0; i b.size; ++i)
{b[i] *= a[i];} ?
Yes, but numpy already does this. The ultimate goal
, line
16, in ?
from pypy.annotation.listdef import ListDef, MOST_GENERAL_LISTDEF
ImportError: cannot import name ListDef
?
Simon.
--
Simon Burton, B.Sc.
Licensed PO Box 8066
ANU Canberra 2601
Australia
Ph. 61 02 6249 6940
http://arrowtheory.com
Hi,
I'm hoping to come to europython this year; one of
the main attractions will be the pypy sprint. Have the
dates for this been decided ?
cheers,
Simon.
--
Simon Burton, B.Sc.
Licensed PO Box 8066
ANU Canberra 2601
Australia
Ph. 61 02 6249 6940
http://arrowtheory.com
are absolutely obsessed
with
speed.)
I just found out that the python AST branch
has been merged, so i'll be investigating this aswell.
bye for now,
Simon.
[1] https://lineal.developer.nicta.com.au/lineal
--
Simon Burton, B.Sc.
Licensed PO Box 8066
ANU Canberra 2601
Australia
Ph. 61 02 6249
36 matches
Mail list logo
