Hi Paul! Paul Boddie wrote: > Carl Friedrich Bolz wrote: >>>. there is no reason why the pypy project can't have a .NET architecture >>>instead of the java-like arrangement I assume it has now >>Sorry, I can't really follow you here. In what way does PyPy have a >>Java-like arrangement? > > I imagine that this remark was made in reference to the just-in-time > compilation techniques that PyPy may end up using, although I was under > the impression that most CLR implementations also use such techniques > (and it is possible to compile Java to native code as gcj proves).
Well, PyPy is still quite far from having a JIT build in. Plus the JIT-techniques will probably differ quite a bit from Java _and_ the CLR :-). > But on the subject of LLVM: although it seems like a very interesting > and versatile piece of software, it also seems to be fairly difficult > to build; my last attempt made the old-style gcc bootstrapping process > seem like double-clicking on setup.exe. Does this not worry the PyPy > team, or did I overlook some easier approach? (Noting that a Debian > package exists for LLVM 1.4 but not 1.5.) We are not that worried about this since a) building LLVM is not _that_ bad (you don't need to build the C-frontend, which is the really messy part) and b) the LLVM-backend is one of the more experimental backends we have anyway (in fact, we have discovered some bugs in LLVM with PyPy already). Since the C backend is quite stable we are not dependent solely on LLVM so this is not too big a problem. Note that this doesn't mean that the LLVM backend is not important: it's the only other backend (apart from the C one) that can succesfully translate the whole PyPy interpreter. Cheers, Carl Friedrich -- http://mail.python.org/mailman/listinfo/python-list