cc 'ing pypy-dev, since I cant get to #pypy these days. On Tue, 25 Oct 2005, Christian Tismer wrote:
Richard Emslie wrote:
Did see ll_osdefs.h breaks llvm in horrible ways...
Aaahrrrgggg!!!
Why that at all? Just a brave part of the inclues, taken from CPython ( *gulp* ) how can this hurt so much ?
:-) Yes arrrggghhhh!! But no fault of yours - just that we use a (llvm) C compiler for externs. If a local compiler is not available, we go to a remote machine to generate llvm code. So local includes are not possible - hence in genllvm we manually include C files from #include statements. :-( Now listdir() uses opaque (dont know if you introduced this or someone else) - and llvm doesnt have proper support for opaque types... yet. So we cannot compile pypy right now.
will try to fix, but it is becoming more of a hassle trying to maintain llvm backend when it is not really giving much back.
Sorry for the negativeness. It would be interesting however to have the core developers opinion(s) about backends in general and whether it is believed maintaining it (the llvm one) is a worthwhile goal.
Sorry about that.I tried to make my live easier when I had to port this listdir() mess, which does not fit winnows at all :-)
No need to apologize - the include fix was minor and opaque types are part of rpython and cannot be avoided. :-) Cheers & good nite, Richard
Ooops - sorry about the horrible subject in last mail (it's late) On Thu, 27 Oct 2005, Richard Emslie wrote:
cc 'ing pypy-dev, since I cant get to #pypy these days.
On Tue, 25 Oct 2005, Christian Tismer wrote:
Richard Emslie wrote:
Did see ll_osdefs.h breaks llvm in horrible ways...
Aaahrrrgggg!!!
Why that at all? Just a brave part of the inclues, taken from CPython ( *gulp* ) how can this hurt so much ?
:-) Yes arrrggghhhh!! But no fault of yours - just that we use a (llvm) C compiler for externs. If a local compiler is not available, we go to a remote machine to generate llvm code. So local includes are not possible - hence in genllvm we manually include C files from #include statements. :-(
Now listdir() uses opaque (dont know if you introduced this or someone else) - and llvm doesnt have proper support for opaque types... yet. So we cannot compile pypy right now.
will try to fix, but it is becoming more of a hassle trying to maintain llvm backend when it is not really giving much back.
Sorry for the negativeness. It would be interesting however to have the core developers opinion(s) about backends in general and whether it is believed maintaining it (the llvm one) is a worthwhile goal.
Sorry about that.I tried to make my live easier when I had to port this listdir() mess, which does not fit winnows at all :-)
No need to apologize - the include fix was minor and opaque types are part of rpython and cannot be avoided. :-)
Cheers & good nite, Richard
On Thu, 27 Oct 2005, Richard Emslie wrote:
Ooops - sorry about the horrible subject in last mail (it's late)
Which externs do you need? Are these for system prototypes or pypy functions? -Chris
cc 'ing pypy-dev, since I cant get to #pypy these days.
On Tue, 25 Oct 2005, Christian Tismer wrote:
Richard Emslie wrote:
Did see ll_osdefs.h breaks llvm in horrible ways...
Aaahrrrgggg!!!
Why that at all? Just a brave part of the inclues, taken from CPython ( *gulp* ) how can this hurt so much ?
:-) Yes arrrggghhhh!! But no fault of yours - just that we use a (llvm) C compiler for externs. If a local compiler is not available, we go to a remote machine to generate llvm code. So local includes are not possible - hence in genllvm we manually include C files from #include statements. :-(
Now listdir() uses opaque (dont know if you introduced this or someone else) - and llvm doesnt have proper support for opaque types... yet. So we cannot compile pypy right now.
will try to fix, but it is becoming more of a hassle trying to maintain llvm backend when it is not really giving much back.
Sorry for the negativeness. It would be interesting however to have the core developers opinion(s) about backends in general and whether it is believed maintaining it (the llvm one) is a worthwhile goal.
Sorry about that.I tried to make my live easier when I had to port this listdir() mess, which does not fit winnows at all :-)
No need to apologize - the include fix was minor and opaque types are part of rpython and cannot be avoided. :-)
Cheers & good nite, Richard
_______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
-Chris -- http://nondot.org/sabre/ http://llvm.org/
On Thursday 27 October 2005 07:21, Chris Lattner wrote:
On Thu, 27 Oct 2005, Richard Emslie wrote:
Ooops - sorry about the horrible subject in last mail (it's late)
Which externs do you need? Are these for system prototypes or pypy functions?
With externs in this context we mean functions we need to call from the O.S. (libc). Plus a little wrapper code to make it compatible with Python. (Sometimes raise an exception instead of returning an errorcode, etc.) cheers Eric
-Chris
cc 'ing pypy-dev, since I cant get to #pypy these days.
On Tue, 25 Oct 2005, Christian Tismer wrote:
Richard Emslie wrote:
Did see ll_osdefs.h breaks llvm in horrible ways...
Aaahrrrgggg!!!
Why that at all? Just a brave part of the inclues, taken from CPython ( *gulp* ) how can this hurt so much ?
:-) Yes arrrggghhhh!! But no fault of yours - just that we use a
(llvm) C compiler for externs. If a local compiler is not available, we go to a remote machine to generate llvm code. So local includes are not possible - hence in genllvm we manually include C files from #include statements. :-(
Now listdir() uses opaque (dont know if you introduced this or someone else) - and llvm doesnt have proper support for opaque types... yet. So we cannot compile pypy right now.
will try to fix, but it is becoming more of a hassle trying to maintain llvm backend when it is not really giving much back.
Sorry for the negativeness. It would be interesting however to have the core developers opinion(s) about backends in general and whether it is believed maintaining it (the llvm one) is a worthwhile goal.
Sorry about that.I tried to make my live easier when I had to port this listdir() mess, which does not fit winnows at all :-)
No need to apologize - the include fix was minor and opaque types are part of rpython and cannot be avoided. :-)
Cheers & good nite, Richard
_______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
-Chris
On Thu, 27 Oct 2005, Eric van Riet Paap wrote:
On Thursday 27 October 2005 07:21, Chris Lattner wrote:
On Thu, 27 Oct 2005, Richard Emslie wrote:
Ooops - sorry about the horrible subject in last mail (it's late) Which externs do you need? Are these for system prototypes or pypy functions?
With externs in this context we mean functions we need to call from the O.S. (libc). Plus a little wrapper code to make it compatible with Python. (Sometimes raise an exception instead of returning an errorcode, etc.)
Using the C front-end to parse C headers is a pretty big hammer for this problem. In particular:
Now listdir() uses opaque (dont know if you introduced this or someone else) - and llvm doesnt have proper support for opaque types... yet. So we cannot compile pypy right now.
I'm not sure is considered to be "proper support" for opaque types, but we certainly do support them. I'm not sure what the prototype for listdir is supposed to be, but you should always be able to use something like this (assuming it takes a pointer to some structure type): declare void %listdir(opaque*) or: declare void %listdir(sbyte*) LLVM cares that it is a pointer, but as long as you're not directly accessing any of the members of the struct, it doesn't care what it is a pointer to. -Chris
cc 'ing pypy-dev, since I cant get to #pypy these days.
On Tue, 25 Oct 2005, Christian Tismer wrote:
Richard Emslie wrote:
Did see ll_osdefs.h breaks llvm in horrible ways...
Aaahrrrgggg!!!
Why that at all? Just a brave part of the inclues, taken from CPython ( *gulp* ) how can this hurt so much ?
:-) Yes arrrggghhhh!! But no fault of yours - just that we use a
(llvm) C compiler for externs. If a local compiler is not available, we go to a remote machine to generate llvm code. So local includes are not possible - hence in genllvm we manually include C files from #include statements. :-(
Now listdir() uses opaque (dont know if you introduced this or someone else) - and llvm doesnt have proper support for opaque types... yet. So we cannot compile pypy right now.
will try to fix, but it is becoming more of a hassle trying to maintain llvm backend when it is not really giving much back.
Sorry for the negativeness. It would be interesting however to have the core developers opinion(s) about backends in general and whether it is believed maintaining it (the llvm one) is a worthwhile goal.
Sorry about that.I tried to make my live easier when I had to port this listdir() mess, which does not fit winnows at all :-)
No need to apologize - the include fix was minor and opaque types are part of rpython and cannot be avoided. :-)
Cheers & good nite, Richard
_______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
-Chris
pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
-Chris -- http://nondot.org/sabre/ http://llvm.org/
Hi Chris, On Thu, 27 Oct 2005, Chris Lattner wrote:
On Thu, 27 Oct 2005, Eric van Riet Paap wrote:
On Thursday 27 October 2005 07:21, Chris Lattner wrote:
On Thu, 27 Oct 2005, Richard Emslie wrote:
Ooops - sorry about the horrible subject in last mail (it's late) Which externs do you need? Are these for system prototypes or pypy functions?
With externs in this context we mean functions we need to call from the O.S. (libc). Plus a little wrapper code to make it compatible with Python. (Sometimes raise an exception instead of returning an errorcode, etc.)
Using the C front-end to parse C headers is a pretty big hammer for this problem. In particular:
Yes this is what we do currently do. We were going to go one step further and preprocess the file locally and then send that to a remote server. But I am not sure of the merits of this and whether it would work at all.
Now listdir() uses opaque (dont know if you introduced this or someone else) - and llvm doesnt have proper support for opaque types... yet. So we cannot compile pypy right now.
I'm not sure is considered to be "proper support" for opaque types, but we certainly do support them. I'm not sure what the prototype for listdir is supposed to be, but you should always be able to use something like this (assuming it takes a pointer to some structure type):
declare void %listdir(opaque*)
or:
declare void %listdir(sbyte*)
Sorry for the ambiguity here. In RPython there is an Opaque low level type. I was saying the llvm backend was not complete (basically initialisation code). Right now we are effectively translating to your latter suggestion (sbyte *), although will probably change it to opaque* since they are already called that in rpython. :-)
LLVM cares that it is a pointer, but as long as you're not directly accessing any of the members of the struct, it doesn't care what it is a pointer to.
That's where I got to (eventually) last night! ;-) pypy should compile again with the llvm backend (although I havent been able to test it) Thanks very much for the insights & sorry for the confusion. Cheers, Richard
On Thu, 27 Oct 2005, Richard Emslie wrote:
LLVM cares that it is a pointer, but as long as you're not directly accessing any of the members of the struct, it doesn't care what it is a pointer to.
That's where I got to (eventually) last night! ;-) pypy should compile again with the llvm backend (although I havent been able to test it)
Ok, great news! -Chris -- http://nondot.org/sabre/ http://llvm.org/
Richard Emslie wrote: listdir()
:-) Yes arrrggghhhh!! But no fault of yours - just that we use a (llvm) C compiler for externs. If a local compiler is not available, we go to a remote machine to generate llvm code. So local includes are not possible - hence in genllvm we manually include C files from #include statements. :-(
Now listdir() uses opaque (dont know if you introduced this or someone else) - and llvm doesnt have proper support for opaque types... yet. So we cannot compile pypy right now.
No, it was Armin :-) I had the same trouble, windows didn't compile any longer, so I had to build support. Now you have the same problem :-) Maybe easiest to get around this is to just comment the interface away. Then you have time.
Sorry for the negativeness. It would be interesting however to have the core developers opinion(s) about backends in general and whether it is believed maintaining it (the llvm one) is a worthwhile goal.
I felt a little like this for windows, although without reason because it is really needed. In a sense, someone jumps into a direction and we have to follow, this is not bad after all. But I think it makes sense to ask what the plans concerning LLVM are, and who is willing to support it. Maybe pypy-sync? ciao - chris -- Christian Tismer :^) <mailto:tismer@stackless.com> tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
participants (4)
-
Chris Lattner -
Christian Tismer -
Eric van Riet Paap -
Richard Emslie