Hi Armin, On 16.06.2007, at 19:10, Armin Rigo wrote:
> Hi Simon, > > (This is also a follow-up on concerns raised by Christian on #pypy > today) Well, reacting a bit to it, here... The reason why this stuff kept me busy thinking since the meeting was the fact that we are about to trash exactly the little stuff people are actually using. We do have very little users, and most of them are involved right here. So if we are going to trasg stuff, then we should go and offer help to those few users, to not getting distracted from PyPy. <please assume that I could insert all of Martijn's text, too> So my thoughts were around these ideas: - Try to extend CTypes to support primitive-enough concepts that do translate to RPython or - offer support to our users, to make transition to rffi smooth and easy. I think both ways are possible, I also guess the latter woulod be supported even if we asked for help or some funding for this necessary work. Whatever way we choose, I think it would be best for PyPy if we try to be as user-friendly as possible, saying like """we believe we must change this and that immediately, but we will not leave you in the rain, but actively help porting your stuff.""" This also relates a bit to my former thoughts about things which we have donated to the open source. We can, physically, just trash anything, of course. But from a point of view of users and our growing community, this is a matter of belief and trust that we should be careful about. I'm not saying that we don't care, these are just my thoughts and feelings about what I want to be not questionable. > On Fri, Jun 15, 2007 at 05:44:54PM -0700, Simon Burton wrote: >> I hope we can do all this with rffi, but there are two really >> cool things about rctypes: >> 1) it runs on cpython (our main app takes 30minutes+ to compile) >> 2) it has an automatic code generator (ctypes can autogenerate >> python wrappers from C header files) > > For 1), this would actually be possible with rffi too. The trick > would > be to have two implementations of the lltypesystem objects (array, > structures, etc.). I think the idea is not bad, but unless I'm missing something, don't we exactly loose the testing feature by this, by having to have two different implementations, the benefit of simple CPython testing for lltypesystem would be gone? > The existing implementation would only be used when > ctypes is not available; if ctypes can be imported, then the other > implementation could systematically be used. With a bit of effort it > could have a fully compatible interface, but be internally implemented > as ctypes objects (e.g. lltype.malloc(S) would build a ctypes > structure > type corresponding to S, and internally instantiate that). Then we > could really call rffi functions, by turning it internally into a > ctypes > function and calling it with the ctypes objects underlying the > passed-in > arguments. Not sure that I immediately get it. You would use CTypes to emulate rffi functions if we are in Python, and use them directly when you are in RPython? How would the memory ownership problem be handled? Ah, the problem is circumvented by doing all this stuff on app-level, dropping high efficiency constraints? No I am confused. > This might even not be completely insane - in my opinion, less than > implementing and maintaining rctypes itself. It's also something that > can be done by someone not deeply into the code base, as long as he > knows the lltype interface and how to use ctypes. By 'it', you mean the CTypes implementation, at app-level, based upon rffi? I hope I'm not completely lost, here :-) ciao - chris _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
