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
_______________________________________________
[email protected]
http://codespeak.net/mailman/listinfo/pypy-dev
