RE: [pypy-dev] website update / pypy developments

holger krekel <hpk@trillke.net> wrote:
After some discussions especially with Armin i now think that we should promote as a goal to
dynamically tie into/adapt arbritrary C-Libraries and operation system calls.
The latter would basically mean that you could use Python directly to drive your favourite OS. Think rapidly specializing for whatever embedded device without even a libc and doing that with 99% of the code beeing written in Python.
I'm a little unclear by what you mean by this goal. As best I can tell, you envision being able to put a shared library facade over pypy functions, and then have the C/whatever library function calls be able to seamlessly call into pypy without recompilation. e.g. we could write a glibc facade which runs pypy 'under the hood' and drive precompiled linux programs with pypy. Is this getting close to the idea? ... If so, you are either insanely brilliant, or insanely insane - though I'd lean toward the former. What-will-they-think-up-next-ly 'ers -Rocco __________________________________________________________________ McAfee VirusScan Online from the Netscape Network. Comprehensive protection for your entire computer. Get your free trial today! http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397 Get AOL Instant Messenger 5.1 free of charge. Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promo=380455

[Rocco Moretti Thu, Jul 03, 2003 at 11:37:38PM -0400]
holger krekel <hpk@trillke.net> wrote:
After some discussions especially with Armin i now think that we should promote as a goal to
dynamically tie into/adapt arbritrary C-Libraries and operation system calls.
The latter would basically mean that you could use Python directly to drive your favourite OS. Think rapidly specializing for whatever embedded device without even a libc and doing that with 99% of the code beeing written in Python.
I'm a little unclear by what you mean by this goal. As best I can tell, you envision being able to put a shared library facade over pypy functions, and then have the C/whatever library function calls be able to seamlessly call into pypy without recompilation. e.g. we could write a glibc facade which runs pypy 'under the hood' and drive precompiled linux programs with pypy.
That's also an interesting idea :-) It's more the other way round: Dynamically setup a "C-call" from Python and execute it. ASFAIK you need assembler-written "trampolin" functions that help you in doing this work. (Thomas Heller's ctypes module uses e.g. libffi on unices to do this). It seems to be a far fetched goal but note that this was mentioned under "EU-funding" because they apparently want "ambitious" goals. Given we implement such a "trampolin" technique you can imagine all sorts of nice stuff like having a small embedded device basically running on linux+python. PyPy would probably head for beeing a runtime-system in this case rather than "just" a language reimplementation.
Is this getting close to the idea? ... If so, you are either insanely brilliant, or insanely insane - though I'd lean toward the former.
I guess we have all kinds of such productive people in the project :-) cheers, holger

Hello Holger, On Fri, Jul 04, 2003 at 07:16:14AM +0200, holger krekel wrote:
After some discussions especially with Armin i now think that we should promote as a goal to
dynamically tie into/adapt arbritrary C-Libraries and operation system calls.
You and me discussed this at EuroPython, but I expressed the thought that this could be *one* of the various ambitious goals of the project. Using libffi or some other custom machinery to call native C libraries directly from Python is one step (though you can already do that with ctypes, as you mentioned). It is true that it is probably easier and cleaner to do it with PyPy because we control low-level code emission much more closely; some more hacking could probably get us rid of glibc altogether. Getting rid of glibc is a neat idea, but all the other goals that we discussed in pypy-dev and on the sprints are also important in other respects and should not be disregarded if we want to promote PyPy as a "software platform". I, for example, tend to attach a lot of value to the interpreter's great flexibility as an experimentation platform. Others want to make object spaces with slightly or heavily customized semantics, dream to plug-and-play their own syntax, or just build lightweight versions of Python. All these goals together are what make a great and ambitious project ! A bientot, Armin.

[Armin Rigo Fri, Jul 04, 2003 at 09:10:55PM +0200]
Hello Holger,
On Fri, Jul 04, 2003 at 07:16:14AM +0200, holger krekel wrote:
After some discussions especially with Armin i now think that we should promote as a goal to
dynamically tie into/adapt arbritrary C-Libraries and operation system calls.
You and me discussed this at EuroPython, but I expressed the thought that this could be *one* of the various ambitious goals of the project. Using libffi or some other custom machinery to call native C libraries directly from Python is one step (though you can already do that with ctypes, as you mentioned). It is true that it is probably easier and cleaner to do it with PyPy because we control low-level code emission much more closely; some more hacking could probably get us rid of glibc altogether.
Getting rid of glibc is a neat idea, but all the other goals that we discussed in pypy-dev and on the sprints are also important in other respects and should not be disregarded if we want to promote PyPy as a "software platform". I, for example, tend to attach a lot of value to the interpreter's great flexibility as an experimentation platform. Others want to make object spaces with slightly or heavily customized semantics, dream to plug-and-play their own syntax, or just build lightweight versions of Python. All these goals together are what make a great and ambitious project !
Well put! Actually i didn't mean to suddenly reduce the number of goals/dreams to just one. Then again, i specifically put C/system-call trampolins under "EU-funding" because i think connecting a high-level language like python directly to the kernel-level or C-libraries feels (to me) more like a "software platform" than a nice language with a nice flexible interpreter (which is nevertheless the pre-condition for c/sys trampolin integration, isn't it?). Speaking of EU-Funding. Should we setup a mailing-list for information exchange and discussion? If we are to really go for the October 15th deadline then we should start to rush or don't go for it this year (IMHO). cheers, holger
participants (3)
-
Armin Rigo
-
holger krekel
-
roccomoretti@netscape.net