http://muharem.wordpress.com/2007/07/31/erlang-vs-stackless-python-a-first-benchmark/ Christian: with a dedication for you :) We should try pypy on this btw. :. _______________________________________________ pypy-dev <at> codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
A first, a joke: (syntax-rules () ((i-have-spare day ...) (hack 'macros (day ....)))) So we have recursive macros expanding recursively, as they should. I was working on macros with ellipsis almost whole week i. I was changing approach several times. But it looks like flat ellipses (not nested) work well. All most important parts of macros are SyntaxRule.match method, or rather matchr, and W_Transformer.substitute. They raise exception when discover ellipsis to handle it at higher level. matchr is kinda handling nested ellipses, but substitute not yet. That's pretty it. I would like to get nested ellipses working and then start playing with continuations. Wish me luck. Cheers, Jakub Gustak _______________________________________________ pypy-dev <at> codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
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.
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
On Fri, 3 Aug 2007 12:14:13 -0700 Simon Burton <simon <at> arrowtheory.com> 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, and for example, (c or rpython) extension modules for the PyPy interpreter. Simon. _______________________________________________ pypy-dev <at> codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Hi Maciek Maciek Fijalkowski wrote: > http://muharem.wordpress.com/2007/07/31/erlang-vs-stackless-python-a-first-benchmark/ > > Christian: with a dedication for you :) > > We should try pypy on this btw. seems a bit meaningless, given that one of erlang's most important strengths is the possibility of using it to transparently across multiple processes and especially multiple machines. Cheers, Carl Friedrich _______________________________________________ pypy-dev <at> codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Anto, Niko, and all,
I've been trying to get some of the string and float tests to pass. The trouble I'm running into is that ooparse_float doesn't know how to parse ll_str_0, but for the life of me can't find where I need to be looking or where I should override the ooparse_float method. I feel like it should go in my
opcodes.py file (translator/jvm).
Also, one question I had about long conversions, in translator/jvm/test/test_float.py:22, there is a test for long conversion. Tracing the results shows I get the correct answer for the conversion, but my result is not an r_longlong, the tests returns a Java Long. Any tips or hints?
Regards,
Paul
_______________________________________________ pypy-dev <at> codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Hi Paul! Paul deGrandis wrote: > Anto, Niko, and all, > > I've been trying to get some of the string and float tests to pass. The > trouble I'm running into is that ooparse_float doesn't know how to parse > ll_str_0, but for the life of me can't find where I need to be looking > or where I should override the ooparse_float method. I feel like it > should go in my opcodes.py file (translator/jvm). I'm not sure to understand the question. ooparse_float is an opcode which converts strings to floats. To implement it, you must add the corresponding definition to translator/jvm/opcodes.py; the simplest thing to do is probably to call java.lang.Double.parseDouble(); I don't know the exact syntax to use, but I guess Niko could help here. > Also, one question I had about long conversions, in > translator/jvm/test/test_float.py:22, there is a test for long > conversion. Tracing the results shows I get the correct answer for the > conversion, but my result is not an r_longlong, the tests returns a Java > Long. Any tips or hints? This happens because the same tests are used to test both the llinterpreter and the backends: when run in the llinterpreter, the return type is effectively r_longlong and the test runs fine, but when translated by a backend such as cli or jvm, the result is simply printed to stdout, without any information about the type: thus, there is no way to test if the result was effectively a r_longlong. Look at the source of the test, in rpython/test/test_rfloat.py:69: you see that the type-checking is done by calling the is_of_type method; now, look how the CLI test framerwork implements this method, in cli/test/runtest.py:299: as you can see, it simply returns always true, because it has no chance to test it. What you need to do is simply to do the same in jvm/test/runtest.py. ciao Anto _______________________________________________ pypy-dev <at> codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Simon Burton wrote: > On Fri, 3 Aug 2007 12:14:13 -0700 > Simon Burton <simon <at> arrowtheory.com> 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, > and for example, (c or rpython) extension modules for the PyPy interpreter. > > Simon. > I kind of don't understand what are you trying to do. Could you explain in a bit more detail? (Ie are you trying to have rffi-rffi bridge between interpreter and compiled module?) Why not fix extcompiler instead? :. _______________________________________________ pypy-dev <at> codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
On Tue, 07 Aug 2007 14:15:48 +0200
Maciek Fijalkowski <fijal <at> genesilico.pl> wrote:
> Simon Burton wrote:
> > On Fri, 3 Aug 2007 12:14:13 -0700
> > Simon Burton <simon <at> arrowtheory.com> 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,
> > and for example, (c or rpython) extension modules for the PyPy interpreter.
> >
> > Simon.
> >
> I kind of don't understand what are you trying to do. Could you explain
> in a bit more detail? (Ie are you trying to have rffi-rffi bridge
> between interpreter and compiled module?) Why not fix extcompiler instead?
>
> :.
>
well, the above code would produce:
extern int foo(int i, int j)
{
return i+j;
}
(and perhaps an accompanying .h file)
thereby providing an interface for other C programs.
This is rffi producing rather than consuming a C interface.
Simon.
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Macros looks like working. One thing to be added: they are acting like first-class objects, but should not. Right now I am working on continuations. First a puzzle: What will return evaluation of s-expression like this: (call/cc call/cc) Or what will be bound to k after this s-expression: (define k (call/cc call/cc)) After some asking on #pypy I decided to create own implementation of continuations, and not try to use stackless. The reason is that coroutines are one-shot. So I created execution stack simulation, or rather stack for continuation frames. Right now not every macro uses it, so not every one is continuation-safe. If macro has defined method continue_tr it should get along with continuations well. Another issue: this implementations is stack-only so it introduce lot of overhead both on capturing and throwing continuations. And one more: every W_Procedure is continuations-safe but VERY slow, even when no capture occurs. I'd rather would like to think about how to throw continuations more generally, and not have to implement continue_tr for every W_Callable, than implementing capture differently. Or maybe try totally different approach e.g write every call in CPS, but it probably would require way too much changes right now. Cheers, Jakub Gustak _______________________________________________ pypy-dev <at> codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
RSS Feed133 | |
|---|---|
125 | |
118 | |
174 | |
40 | |
129 | |
47 | |
64 | |
58 | |
121 | |
139 | |
192 | |
220 | |
151 | |
186 | |
287 | |
190 | |
184 | |
122 | |
285 | |
236 | |
282 | |
217 | |
146 | |
238 | |
183 | |
218 | |
157 | |
76 | |
218 | |
127 | |
15 | |
139 | |
94 | |
129 | |
62 | |
55 | |
53 | |
106 | |
33 | |
18 | |
67 | |
48 | |
100 | |
75 | |
22 | |
21 | |
27 | |
28 | |
111 | |
49 | |
54 | |
72 | |
39 | |
36 | |
38 | |
32 | |
53 | |
53 | |
42 | |
51 | |
25 | |
39 | |
39 | |
54 | |
69 | |
163 | |
113 | |
83 | |
65 | |
49 | |
93 | |
36 | |
94 | |
100 | |
57 | |
37 | |
56 | |
32 | |
27 | |
10 | |
60 | |
111 | |
40 | |
67 | |
138 | |
154 | |
33 | |
56 | |
66 | |
48 | |
108 | |
161 | |
69 | |
72 | |
55 | |
106 | |
67 | |
55 | |
93 | |
66 | |
58 | |
79 | |
11 | |
23 | |
60 | |
80 | |
53 | |
24 | |
55 | |
13 | |
30 | |
37 | |
56 | |
33 | |
89 | |
104 | |
21 | |
100 | |
112 | |
30 | |
36 | |
76 | |
186 | |
365 |
