From regmi.amit at gmail.com Sun Dec 2 01:50:57 2007 From: regmi.amit at gmail.com (amit) Date: Sat, 01 Dec 2007 19:50:57 -0500 Subject: [pypy-dev] mapping C# iterator to Python iterator Message-ID: <47520171.9040109@gmail.com> Taking example of System.Collection.ArrayList class. If the class uses the interface IEnumerable that can be checked using reflection b_type = System.Type.GetType(fullname) ifaces = b_type.GetInterfaces() for interface in ifaces: if interface =="IEnumerable": print "yes" Problems mapping the two functions d['__iter__'] = d['GetEnumerator'] d['next'] = d['MoveNext'] to make C# objects iterable in PyPy-Cli module. a) MoveNext() is not available in both "methods" and "staticmethods" passed to build_wrapper b) and assignment of GetEnumerator to __iter__ gives following TypeError. TypeError: Can't convert object System.Collections.ArrayList+SimpleEnumerator to Python I had in mind something like class Dummy: __iter__(self): return CS.Current() next(self): bool = CS.MoveNext() if bool == false: raise StopIteration any thoughts ? -AmitReg From niko at alum.mit.edu Mon Dec 3 15:54:58 2007 From: niko at alum.mit.edu (Niko Matsakis) Date: Mon, 3 Dec 2007 15:54:58 +0100 Subject: [pypy-dev] System calls in Java Message-ID: So, there are a few system calls that I don't think Java supports, but Python does. So far I have found getpid() and setenv(), but probably I will run into a few more. Rather than implement the native wrappers required myself, I was considering linking against a pre-written library. I found two, jnios, used by Jython, and jtux, which seems a bit more general. The Jython wrapper is a bit problematic because it relies on a lot of Jython classes for building tuples and things. I haven't experimented with jtux yet, but it seems to be a straightforward wrapper. The biggest problem is that it does not have lots of easy-to-download-and-install jar files available for various platforms. http://basepath.com/aup/jtux/ The idea would be that if the library were not present on the CLASSPATH, everything would continue to work except those methods that require extra support. Does this make sense? Anybody have a better idea? Niko From cfbolz at gmx.de Mon Dec 3 16:13:06 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Mon, 03 Dec 2007 16:13:06 +0100 Subject: [pypy-dev] System calls in Java In-Reply-To: References: Message-ID: <47541D02.5060406@gmx.de> Niko Matsakis wrote: > So, there are a few system calls that I don't think Java supports, but > Python does. So far I have found getpid() and setenv(), but probably > I will run into a few more. Rather than implement the native wrappers > required myself, I was considering linking against a pre-written > library. I found two, jnios, used by Jython, and jtux, which seems a > bit more general. The Jython wrapper is a bit problematic because it > relies on a lot of Jython classes for building tuples and things. I > haven't experimented with jtux yet, but it seems to be a > straightforward wrapper. The biggest problem is that it does not have > lots of easy-to-download-and-install jar files available for various > platforms. > > http://basepath.com/aup/jtux/ > > The idea would be that if the library were not present on the > CLASSPATH, everything would continue to work except those methods that > require extra support. > > Does this make sense? Anybody have a better idea? This makes sense to me, for such low-level functions as getpid and setenv and whatever else is missing from the os module. For things like the socket module I guess it would make more sense to use some high-level java api that is more readily available. Keep up the good work! Cheers, Carl Friedrich From pedronis at openend.se Mon Dec 3 16:44:24 2007 From: pedronis at openend.se (Samuele Pedroni) Date: Mon, 03 Dec 2007 16:44:24 +0100 Subject: [pypy-dev] System calls in Java In-Reply-To: <47541D02.5060406@gmx.de> References: <47541D02.5060406@gmx.de> Message-ID: <47542458.7040609@openend.se> Carl Friedrich Bolz wrote: > Niko Matsakis wrote: > >> So, there are a few system calls that I don't think Java supports, but >> Python does. So far I have found getpid() and setenv(), but probably >> I will run into a few more. Rather than implement the native wrappers >> required myself, I was considering linking against a pre-written >> library. I found two, jnios, used by Jython, and jtux, which seems a >> bit more general. The Jython wrapper is a bit problematic because it >> relies on a lot of Jython classes for building tuples and things. I >> haven't experimented with jtux yet, but it seems to be a >> straightforward wrapper. The biggest problem is that it does not have >> lots of easy-to-download-and-install jar files available for various >> platforms. >> >> http://basepath.com/aup/jtux/ >> >> The idea would be that if the library were not present on the >> CLASSPATH, everything would continue to work except those methods that >> require extra support. >> >> Does this make sense? Anybody have a better idea? >> > > This makes sense to me, for such low-level functions as getpid and > setenv and whatever else is missing from the os module. there's been some discussion on Jython lists and some experimenting by JRuby people to use JNA (https://jna.dev.java.net/ ) which is a sort of ctypes for java, for this sort of purposes. > For things like > the socket module I guess it would make more sense to use some > high-level java api that is more readily available. > > yes, also there's been lot of recent work in Jython to use java.nio to get select etc functionality in Jython. Is probably worth to look at it. From fijal at genesilico.pl Mon Dec 3 18:16:04 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Mon, 03 Dec 2007 18:16:04 +0100 Subject: [pypy-dev] svn blame all Message-ID: <475439D4.2000509@genesilico.pl> Out of getting completely bored, I run svn blame on all .py files which are svn blameable, excluding unicodedata and pyrepl (which is external) in pypy directory. Results are here: http://codespeak.net/~fijal/svnblameall.txt :. From fijal at genesilico.pl Mon Dec 3 18:17:49 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Mon, 03 Dec 2007 18:17:49 +0100 Subject: [pypy-dev] svn blame all In-Reply-To: <475439D4.2000509@genesilico.pl> References: <475439D4.2000509@genesilico.pl> Message-ID: <47543A3D.2060204@genesilico.pl> Maciek Fijalkowski wrote: > Out of getting completely bored, I run svn blame on all .py files which > are svn blameable, excluding unicodedata and pyrepl (which is external) > in pypy directory. Results are here: > http://codespeak.net/~fijal/svnblameall.txt > > A little explanation - first column is percentage of overall code, second is number of lines (including blanks) third is a developer nickname. Enjoy :-) Cheers, fijal :. From niko at alum.mit.edu Mon Dec 3 19:10:37 2007 From: niko at alum.mit.edu (Niko Matsakis) Date: Mon, 3 Dec 2007 19:10:37 +0100 Subject: [pypy-dev] System calls in Java In-Reply-To: <47542458.7040609@openend.se> References: <47541D02.5060406@gmx.de> <47542458.7040609@openend.se> Message-ID: <45A94A74-249E-442E-A377-E7583D25D454@alum.mit.edu> > there's been some discussion on Jython lists and some experimenting > by JRuby > people to use JNA (https://jna.dev.java.net/ ) which is a sort of > ctypes for java, > for this sort of purposes. This is perfect! I just tried it out and it worked very well. >> For things like the socket module I guess it would make more sense >> to use some high-level java api that is more readily available. >> >> > yes, also there's been lot of recent work in Jython to use java.nio > to get select etc > functionality in Jython. Is probably worth to look at it. Definitely it makes sense where possible to use higher-level Java APIs. Niko From charles.nutter at sun.com Mon Dec 3 19:23:06 2007 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Mon, 03 Dec 2007 12:23:06 -0600 Subject: [pypy-dev] System calls in Java In-Reply-To: <47542458.7040609@openend.se> References: <47541D02.5060406@gmx.de> <47542458.7040609@openend.se> Message-ID: <4754498A.50307@sun.com> Samuele Pedroni wrote: > there's been some discussion on Jython lists and some experimenting by JRuby > people to use JNA (https://jna.dev.java.net/ ) which is a sort of ctypes > for java, > for this sort of purposes. More than experimenting in JRuby...we're using JNA extensively to provide all the missing POSIX/libc features we need. The library we're building around JNA is going to be spun off as an external project soon, so we should probably talk about coordinating on building it out. I'd love to see it become the defacto standard POSIX/libc API for Java, and to see others add more functions to it. - Charlie From tismer at stackless.com Mon Dec 3 19:47:25 2007 From: tismer at stackless.com (Christian Tismer) Date: Mon, 03 Dec 2007 10:47:25 -0800 Subject: [pypy-dev] svn blame all In-Reply-To: <47543A3D.2060204@genesilico.pl> References: <475439D4.2000509@genesilico.pl> <47543A3D.2060204@genesilico.pl> Message-ID: <47544F3D.3050703@stackless.com> Maciek Fijalkowski wrote: > Maciek Fijalkowski wrote: >> Out of getting completely bored, I run svn blame on all .py files which >> are svn blameable, excluding unicodedata and pyrepl (which is external) >> in pypy directory. Results are here: >> http://codespeak.net/~fijal/svnblameall.txt >> >> > A little explanation - first column is percentage of overall code, > second is number of lines (including blanks) third is a developer > nickname. Enjoy :-) Well, these are numbers which show some tendency, but I'm not sure why we want this? Who has the most lines or check-ins? I don't think this is a good measure, people have very different check-in behavior, some people are usually doing huge systematic changes, etc. So I'm really not sure what we want to do with these numbers. If not being a contest, what else would it be? btw. there are sites out there which do a similar but more intensive measure and rank you, based upon svn checkins. Taking that as a basis, then I almost did not contribute to Stackless (developed using CVS most of the time). Statistics are rubbish - ly chris -- Christian Tismer :^) 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/ From fijal at genesilico.pl Mon Dec 3 20:00:48 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Mon, 03 Dec 2007 20:00:48 +0100 Subject: [pypy-dev] svn blame all In-Reply-To: <47544F3D.3050703@stackless.com> References: <475439D4.2000509@genesilico.pl> <47543A3D.2060204@genesilico.pl> <47544F3D.3050703@stackless.com> Message-ID: <47545260.4070504@genesilico.pl> Christian Tismer wrote: > Maciek Fijalkowski wrote: >> Maciek Fijalkowski wrote: >>> Out of getting completely bored, I run svn blame on all .py files >>> which are svn blameable, excluding unicodedata and pyrepl (which is >>> external) in pypy directory. Results are here: >>> http://codespeak.net/~fijal/svnblameall.txt >>> >>> >> A little explanation - first column is percentage of overall code, >> second is number of lines (including blanks) third is a developer >> nickname. Enjoy :-) > > Well, these are numbers which show some tendency, but I'm > not sure why we want this? Who has the most lines or > check-ins? I don't think this is a good measure, people > have very different check-in behavior, some people are usually > doing huge systematic changes, etc. > So I'm really not sure what we want to do with these numbers. > If not being a contest, what else would it be? > > btw. there are sites out there which do a similar but more > intensive measure and rank you, based upon svn checkins. > Taking that as a basis, then I almost did not contribute > to Stackless (developed using CVS most of the time). > > Statistics are rubbish - ly chris It makes no sense. It's just that those statitics are different than of those sites and that which were generated by carl. This does not invalidate the fact that all of them are completely bogus. But I like statistics for pure fun of having them :-) Cheers, fijal :. From niko at alum.mit.edu Tue Dec 4 09:59:05 2007 From: niko at alum.mit.edu (Niko Matsakis) Date: Tue, 4 Dec 2007 09:59:05 +0100 Subject: [pypy-dev] System calls in Java In-Reply-To: <4754498A.50307@sun.com> References: <47541D02.5060406@gmx.de> <47542458.7040609@openend.se> <4754498A.50307@sun.com> Message-ID: That sounds interesting, can you give me a pointer into the JRuby sources perhaps? Niko On Dec 3, 2007, at 7:23 PM, Charles Oliver Nutter wrote: > Samuele Pedroni wrote: >> there's been some discussion on Jython lists and some experimenting >> by JRuby >> people to use JNA (https://jna.dev.java.net/ ) which is a sort of >> ctypes >> for java, >> for this sort of purposes. > > More than experimenting in JRuby...we're using JNA extensively to > provide all the missing POSIX/libc features we need. The library we're > building around JNA is going to be spun off as an external project > soon, > so we should probably talk about coordinating on building it out. I'd > love to see it become the defacto standard POSIX/libc API for Java, > and > to see others add more functions to it. > > - Charlie > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev From anto.cuni at gmail.com Tue Dec 4 10:52:02 2007 From: anto.cuni at gmail.com (Antonio Cuni) Date: Tue, 04 Dec 2007 10:52:02 +0100 Subject: [pypy-dev] mapping C# iterator to Python iterator In-Reply-To: <47520171.9040109@gmail.com> References: <47520171.9040109@gmail.com> Message-ID: <47552342.9070508@gmail.com> amit wrote: > Taking example of System.Collection.ArrayList class. > > If the class uses the interface IEnumerable that can be checked using > reflection > > b_type = System.Type.GetType(fullname) > ifaces = b_type.GetInterfaces() > for interface in ifaces: > if interface =="IEnumerable": > print "yes" > > Problems mapping the two functions > d['__iter__'] = d['GetEnumerator'] > d['next'] = d['MoveNext'] > > to make C# objects iterable in PyPy-Cli module. > > a) MoveNext() is not available in both "methods" and "staticmethods" > passed to build_wrapper sure, that's expected. MoveNext() is a method defined for the IEnumerator interface, not for IEnumerable. Moreover, I just realized that there is a discrepancy between .NET's MoveNext() and Python's next() methods: the former only advances the iterator without returning the current object, while the latter both advances the iterator and returns the current objects; also, we should throw StopIterationError when we reach the end of the iterator. In other words, next() should be implemented this way: def next(self): if not self.MoveNext(): raise StopIterationError return self.get_Current() To summarize: - for classes implementing IEnumerable: you should map __iter__ to GetEnumerator - for classes implementing IEnumerator: you should add a next() method like the one above, and add an __iter__ that returns self. > b) and assignment of GetEnumerator to __iter__ gives following TypeError. > TypeError: Can't convert object > System.Collections.ArrayList+SimpleEnumerator to Python could you check in a failing test please? > I had in mind something like > > class Dummy: > __iter__(self): > return CS.Current() > > next(self): > bool = CS.MoveNext() > if bool == false: > raise StopIteration this is also a good solution; you should remind to return CS.get_Current() at the end of next(). One thing I don't understand: what is CS? ciao Anto From regmi.amit at gmail.com Tue Dec 4 16:05:22 2007 From: regmi.amit at gmail.com (amit) Date: Tue, 04 Dec 2007 10:05:22 -0500 Subject: [pypy-dev] mapping C# iterator to Python iterator In-Reply-To: <47552342.9070508@gmail.com> References: <47520171.9040109@gmail.com> <47552342.9070508@gmail.com> Message-ID: <47556CB2.9060408@gmail.com> Antonio Cuni wrote: > amit wrote: >> Problems mapping the two functions >> d['__iter__'] = d['GetEnumerator'] >> d['next'] = d['MoveNext'] >> >> to make C# objects iterable in PyPy-Cli module. >> >> a) MoveNext() is not available in both "methods" and "staticmethods" >> passed to build_wrapper > > sure, that's expected. MoveNext() is a method defined for the > IEnumerator interface, not for IEnumerable. > > Moreover, I just realized that there is a discrepancy between .NET's > MoveNext() and Python's next() methods: the former only advances the > iterator without returning the current object, while the latter both > advances the iterator and returns the current objects; also, we should > throw StopIterationError when we reach the end of the iterator. In > other words, next() should be implemented this way: > > def next(self): > if not self.MoveNext(): > raise StopIterationError > return self.get_Current() This makes a lot of sense. I think what you mean is self.enumrator = self.GetEnumerator() # this returns IEnumerator def next(self): if not self.enumrator.MoveNext() raise StopIteration return self.enumrator.Current() # or self.get_Current() but MoveNext() can not be called this way. I have tried it. And MoveNext is not available to self as your example shows. > > To summarize: > > - for classes implementing IEnumerable: you should map __iter__ to > GetEnumerator > - for classes implementing IEnumerator: you should add a next() > method like the one above, and add an __iter__ that returns self. > I think classes only implement IEnumerable. and IEnumerable uses IEnumerator as below: public interface IEnumerable { IEnumerator GetEnumerator(); } >> b) and assignment of GetEnumerator to __iter__ gives following >> TypeError. >> TypeError: Can't convert object >> System.Collections.ArrayList+SimpleEnumerator to Python > could you check in a failing test please? > I have checked in failing test in test_clr.py - AmitReg From regmi.amit at gmail.com Tue Dec 4 16:19:59 2007 From: regmi.amit at gmail.com (amit) Date: Tue, 04 Dec 2007 10:19:59 -0500 Subject: [pypy-dev] mapping C# Delegates to Python Message-ID: <4755701F.5010702@gmail.com> /* C# delegate */ using System; delegate void Deleg(int x); class testclass { public static void Method1(int i) { Console.WriteLine("testClass.Method1 : "+ i); } public static void Method2(int i) { Console.WriteLine(".Method2 : "+ i*2); } } class Test { static void Main(string[] args) { Deleg DL1 = new Deleg(testclass.Method1); DL1(-55); Deleg DL2 = new Deleg(testclass.Method2); DL2(-22); Deleg DL3 = DL2 + DL1; DL3(-3333); } } /* * Now in Python what I might want to do is * * import System.Delegate * * class Deleg(Delegate): * __init__(self, ...): * pass * * t1 = testclass() * DL1 = Deleg(t1.Method1) * DL1(-55) # calls Method1 * * DL2 = Deleg(t1.Method2) * DL3 = DL2 + DL1 * * DL2(54) # calls Method2 * DL3(32) # calls Method2 then Method1 */ I tried : import clr deleg = clr.load_cli_class('System','Delegate') dd = deleg() and landed up with AttributeError: 'NoneType' object has no attribute 'Invoke' This looks like a rocket science to me but I really have to come up with this implementation to prevent myself from the pain of getting a "C" :( which now appears almost certain :(( Need guidance. -AmitReg From holger at merlinux.de Tue Dec 4 18:55:30 2007 From: holger at merlinux.de (holger krekel) Date: Tue, 4 Dec 2007 18:55:30 +0100 Subject: [pypy-dev] codespeak / pypy.org migrations Message-ID: <20071204175530.GP27185@solar.trillke> Hi folks, FYI we are migrating codespeak.net and pypy.org to new hardware and also to use new nameservers. Downtime is expected to stay below 2 hours sometime during tomorrow. There is a longer announcement on the general codespeak announcement mailing list which you may subscribe to at http://codespeak.net/mailman/listinfo/codespeak-ann cheers & best, holger -- merlinux GmbH Steinbergstr. 42 31139 Hildesheim http://merlinux.de tel +49 5121 20800 75 (fax 77) From regmi.amit at gmail.com Tue Dec 4 19:41:22 2007 From: regmi.amit at gmail.com (amit regmi) Date: Tue, 4 Dec 2007 13:41:22 -0500 Subject: [pypy-dev] Fwd: mapping C# iterator to Python iterator In-Reply-To: <47556CB2.9060408@gmail.com> References: <47520171.9040109@gmail.com> <47552342.9070508@gmail.com> <47556CB2.9060408@gmail.com> Message-ID: I think the best way to solve this is to call .GetEnumerator explicitly and use the resulting enumerator and access values using the enumerators MoveNext() , Reset() and Current() something like. enmtor = self.GetEnumerator() and use enmtor in the next() as I mentioned below. but is this likely in the code we have ? ---------- Forwarded message ---------- From: amit Date: Dec 4, 2007 10:05 AM Subject: Re: [pypy-dev] mapping C# iterator to Python iterator To: Antonio Cuni Cc: PyPy Dev Antonio Cuni wrote: > amit wrote: >> Problems mapping the two functions >> d['__iter__'] = d['GetEnumerator'] >> d['next'] = d['MoveNext'] >> >> to make C# objects iterable in PyPy-Cli module. >> >> a) MoveNext() is not available in both "methods" and "staticmethods" >> passed to build_wrapper > > sure, that's expected. MoveNext() is a method defined for the > IEnumerator interface, not for IEnumerable. > > Moreover, I just realized that there is a discrepancy between .NET's > MoveNext() and Python's next() methods: the former only advances the > iterator without returning the current object, while the latter both > advances the iterator and returns the current objects; also, we should > throw StopIterationError when we reach the end of the iterator. In > other words, next() should be implemented this way: > > def next(self): > if not self.MoveNext(): > raise StopIterationError > return self.get_Current() This makes a lot of sense. I think what you mean is self.enumrator = self.GetEnumerator() # this returns IEnumerator def next(self): if not self.enumrator.MoveNext() raise StopIteration return self.enumrator.Current() # or self.get_Current() but MoveNext() can not be called this way. I have tried it. And MoveNext is not available to self as your example shows. > > To summarize: > > - for classes implementing IEnumerable: you should map __iter__ to > GetEnumerator > - for classes implementing IEnumerator: you should add a next() > method like the one above, and add an __iter__ that returns self. > I think classes only implement IEnumerable. and IEnumerable uses IEnumerator as below: public interface IEnumerable { IEnumerator GetEnumerator(); } >> b) and assignment of GetEnumerator to __iter__ gives following >> TypeError. >> TypeError: Can't convert object >> System.Collections.ArrayList+SimpleEnumerator to Python > could you check in a failing test please? > I have checked in failing test in test_clr.py - AmitReg -------------- next part -------------- An HTML attachment was scrubbed... URL: From charles.nutter at sun.com Tue Dec 4 22:21:27 2007 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Tue, 04 Dec 2007 15:21:27 -0600 Subject: [pypy-dev] System calls in Java In-Reply-To: References: <47541D02.5060406@gmx.de> <47542458.7040609@openend.se> <4754498A.50307@sun.com> Message-ID: <4755C4D7.6070404@sun.com> Niko Matsakis wrote: > That sounds interesting, can you give me a pointer into the JRuby > sources perhaps? Ask me again in 24 hours :) Tom says he'll have a bunch of work committed on the POSIX stuff by then. He's currently mapping stat structures across platforms to provide full file stat support in JRuby. - Charlie From lac at openend.se Wed Dec 5 16:12:06 2007 From: lac at openend.se (Laura Creighton) Date: Wed, 05 Dec 2007 16:12:06 +0100 Subject: [pypy-dev] getting the IBM talk to run with firefox. Message-ID: <200712051512.lB5FC6ha031061@theraft.openend.se> I've got some advice from IBM on how to get our talk there to display properly. It's still not working for me. But perhaps some of you, especially those of you with macs can try it. Laura ------- Forwarded Message Return-Path: c1nose at us.ibm.com To: Laura Creighton Cc: Martin J Hirzel MIME-Version: 1.0 Subject: Re: Copy of your PyPy Talk X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: John Noschese Laura, Did you try installing the windows media ActiveX control for Firefox? If not try this: http://support.mozilla.com/kb/ActiveX Thanks, John ================================ John Noschese Watson Audio Visual Group (914) 784-7223 T/L 863 Internet: c1nose at us.ibm.com https://reswat4.research.ibm.com/projects/tcs/labops.nsf/pages/sss.av.html ================================ Laura Creighton 11/28/2007 11:26 AM To: John Noschese/Watson/Contr/IBM at IBMUS cc: Laura Creighton , Martin J Hirzel/Watson/IBM at IBMUS, lac at openend.se Subject: Re: Copy of your PyPy Talk In a message of Wed, 28 Nov 2007 09:45:11 EST, John Noschese writes: >This is a multipart message in MIME format. >--=_alternative 00510AE3852573A1_= >Content-Type: text/plain; charset="US-ASCII" > >Laura, > >If you're using Firefox here are some instructions: > > >Using Firefox to view Webcasts: >Please follow the Mozilla recommendations in order to view the Research >webcast presentations. >The navigation will take users that do note have the plug-in to download >Activex Control and hit continue I don't know how to do this. Is this a url, or what I should try to point at? Or what? >Please ensure your firewall will allow you to navigate to the external >site trusted site >You will be prompted to a green screen to "Download the precompiled >Plug-in >For users using Mozilla Firefox Version 2.0.0.3 will need to select the >Firefox 1.5 Plug in and hit the Click Here link. Please adhere to the >warning before downloading. >You will only need to download the plug-in once >You must restart your Mozilla browser and click on the Research webcast >presentation link Ok, now I need to know how to get to the 'download the presentation plugin page'. This is not happening automatically when I try to look at the zip file. >Hope this helps. > >Thanks, >John We're getting somewhere, but aren't quite there yet. Laura - --=_alternative 0060B1DD852573A1_= From anto.cuni at gmail.com Wed Dec 5 20:28:20 2007 From: anto.cuni at gmail.com (Antonio Cuni) Date: Wed, 05 Dec 2007 20:28:20 +0100 Subject: [pypy-dev] System calls in Java In-Reply-To: <45A94A74-249E-442E-A377-E7583D25D454@alum.mit.edu> References: <47541D02.5060406@gmx.de> <47542458.7040609@openend.se> <45A94A74-249E-442E-A377-E7583D25D454@alum.mit.edu> Message-ID: <4756FBD4.5050000@gmail.com> Niko Matsakis wrote: >> there's been some discussion on Jython lists and some experimenting >> by JRuby >> people to use JNA (https://jna.dev.java.net/ ) which is a sort of >> ctypes for java, >> for this sort of purposes. > > This is perfect! I just tried it out and it worked very well. Hi Niko, I noticed that your recent changes have broken the translation of pypy-jvm on tuatara, because now pypy-jvm requires jna, and it's not installed there. I tried to download jna from the web but I failed to understand what package(s) I need; do I need only jna.jar and/or the platform specific jar? I wonder whether it might make sense to include the .jar directly in our svn repo, to drop the external dependency on jna and simplify the life of those that want to build pypy-jvm by themselves. ciao Anto From anto.cuni at gmail.com Thu Dec 6 00:35:36 2007 From: anto.cuni at gmail.com (Antonio Cuni) Date: Thu, 06 Dec 2007 00:35:36 +0100 Subject: [pypy-dev] mapping C# Delegates to Python In-Reply-To: <4755701F.5010702@gmail.com> References: <4755701F.5010702@gmail.com> Message-ID: <475735C8.2080007@gmail.com> amit wrote: > /* > * Now in Python what I might want to do is > * > * import System.Delegate > * > * class Deleg(Delegate): > * __init__(self, ...): > * pass I don't think we want to do this. In .NET System.Delegate is treated specially by the virtual machine, and it needs an exact declaration of the signature. The interoperability between python and delegates is two-ways: 1) having a .NET delegate in a Python variable and being able to call it using the usual Python syntax 2) having a .NET method taking a delegate and being able to pass it a python callable Point 1 is quite easy: it's just a matter do map Invoke on __call__. Point 2 is probably very hard to solve for the general case, because .NET delegates are statically typed and Python callables are not; I didn't think very deeply about the problem, but I think the solution involves the creation of a thin wrapper method on the fly. I suggest to do only point 1 for now. The hardest part could be to find a way to test it properly, because we need to find a place in the standard library that returns a delegate we can call; maybe you can find something useful here: http://msdn2.microsoft.com/en-us/library/at6657xa.aspx ciao Anto From niko at alum.mit.edu Thu Dec 6 07:47:06 2007 From: niko at alum.mit.edu (Niko Matsakis) Date: Thu, 6 Dec 2007 07:47:06 +0100 Subject: [pypy-dev] System calls in Java In-Reply-To: <4756FBD4.5050000@gmail.com> References: <47541D02.5060406@gmx.de> <47542458.7040609@openend.se> <45A94A74-249E-442E-A377-E7583D25D454@alum.mit.edu> <4756FBD4.5050000@gmail.com> Message-ID: <7C4AECFD-09B1-48E2-88F1-46295B09F6DF@alum.mit.edu> > I noticed that your recent changes have broken the translation of > pypy-jvm on tuatara, because now pypy-jvm requires jna, and it's not > installed there. > > I tried to download jna from the web but I failed to understand what > package(s) I need; do I need only jna.jar and/or the platform > specific jar? > > I wonder whether it might make sense to include the .jar directly in > our svn repo, to drop the external dependency on jna and simplify > the life of those that want to build pypy-jvm by themselves. So, you only need jna.jar. I think it probably makes sense to put it in the repository. Niko From hpk at trillke.net Thu Dec 6 11:33:11 2007 From: hpk at trillke.net (holger krekel) Date: Thu, 6 Dec 2007 11:33:11 +0100 Subject: [pypy-dev] System calls in Java In-Reply-To: <7C4AECFD-09B1-48E2-88F1-46295B09F6DF@alum.mit.edu> References: <47541D02.5060406@gmx.de> <47542458.7040609@openend.se> <45A94A74-249E-442E-A377-E7583D25D454@alum.mit.edu> <4756FBD4.5050000@gmail.com> <7C4AECFD-09B1-48E2-88F1-46295B09F6DF@alum.mit.edu> Message-ID: <20071206103311.GJ27185@solar.trillke> Hey Niko! On Thu, Dec 06, 2007 at 07:47 +0100, Niko Matsakis wrote: > > I noticed that your recent changes have broken the translation of > > pypy-jvm on tuatara, because now pypy-jvm requires jna, and it's not > > installed there. > > > > I tried to download jna from the web but I failed to understand what > > package(s) I need; do I need only jna.jar and/or the platform > > specific jar? > > > > I wonder whether it might make sense to include the .jar directly in > > our svn repo, to drop the external dependency on jna and simplify > > the life of those that want to build pypy-jvm by themselves. > > So, you only need jna.jar. I think it probably makes sense to put it > in the repository. If you put it somewhere below svn/pypy/dist please insert at least an XXX into the LICENSE file and provide a reference to the project/license of JNA. best, holger From anto.cuni at gmail.com Thu Dec 6 12:42:51 2007 From: anto.cuni at gmail.com (Antonio Cuni) Date: Thu, 06 Dec 2007 12:42:51 +0100 Subject: [pypy-dev] System calls in Java In-Reply-To: <20071206103311.GJ27185@solar.trillke> References: <47541D02.5060406@gmx.de> <47542458.7040609@openend.se> <45A94A74-249E-442E-A377-E7583D25D454@alum.mit.edu> <4756FBD4.5050000@gmail.com> <7C4AECFD-09B1-48E2-88F1-46295B09F6DF@alum.mit.edu> <20071206103311.GJ27185@solar.trillke> Message-ID: <4757E03B.5080207@gmail.com> holger krekel wrote: > If you put it somewhere below svn/pypy/dist > please insert at least an XXX into the LICENSE file > and provide a reference to the project/license of JNA. Done. I added the following lines to the LICENSE file: License for 'pypy/translator/jvm/src/jna.jar' ============================================= The file 'pypy/translator/jvm/src/jna.jar' is licensed under the GNU Lesser General Public License of which you can find a copy here: http://www.gnu.org/licenses/lgpl.html I didn't add any info about the copyright because I couldn't find any copyright note neither in the sources nor in the web site. ciao Anto From cfbolz at gmx.de Thu Dec 6 22:12:50 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Thu, 06 Dec 2007 22:12:50 +0100 Subject: [pypy-dev] thunk object space : become() quirks In-Reply-To: <473B0B10.4050409@gmx.de> References: <77f4ed2b0711140625s3b11e45ej61394be678abc368@mail.gmail.com> <473B0B10.4050409@gmx.de> Message-ID: <475865D2.4040802@gmx.de> Hi Boris, Carl Friedrich Bolz wrote: > Boris Borcic wrote: >> Looking for a way to use pypy in any manner, I came up with an idea for a >> deterministic sudoku solver that would use the 'become()' feature of the thunk >> object space. However, this doesn't work as I expected. The following shell >> trace illustrates my problem. Is this a bug or otherwise ? Can anybody explain ? >> >> BTW, I am using the pypy 1.0.0 build 41438 windows binary distribution. >> >> [subquestion : is pypy-dev appropriate for such a question ?] > > It's a bug, I have a clue where it is and will try to fix it. Thanks for > reporting! Yes, the list is completely appropriate. Some updates on this thing: We discussed the problem extensively on the sprint and the think is that this shows a serious problem with the way the thunk object space is done. We have no concrete clue how to solve it yet. Thunks themselves are also affected by this bug, but only in more extreme situations. I created an issue in the bug tracker for this: https://codespeak.net/issue/pypy-dev/issue332 Thanks again for reporting this ? it only shows again that we should actually implement real stuff with thunks to get the bugs out of it. Cheers, Carl Friedrich From regmi.amit at gmail.com Sat Dec 8 22:27:52 2007 From: regmi.amit at gmail.com (amit) Date: Sat, 08 Dec 2007 16:27:52 -0500 Subject: [pypy-dev] /module/clr - Unable to load assembly. Message-ID: <475B0C58.2020406@gmail.com> Hi, Just uncommenting the line below in interp_clr.py raises System.IO FileNotFound. # currentDomain.Load("System.Windows.Forms",asEvidence) right now GetAssemblies() get "System.Xml" and "mscorlib" internally and the code makes use of these two to scan the namespaces. I tried loading the dll with full path as well but without joy. am I missing something ? -AmitReg From andre.roberge at gmail.com Sun Dec 9 18:22:10 2007 From: andre.roberge at gmail.com (Andre Roberge) Date: Sun, 9 Dec 2007 13:22:10 -0400 Subject: [pypy-dev] Sandboxing in Pypy and Crunchy Message-ID: <7528bcdd0712090922x40adf75ew9217568ced7d1edf@mail.gmail.com> Hello everyone, Please forget the intrusion but I did not know where else to ask this question. Through my involvement with Google's Highly Open Participation contest, I have learned about the sandboxing capabilities of pypy and, I believe although I can't find it anymore, the ability to limit the time allowed to a given process. Even if this last one is wrong, the sandboxing capability is something I would be extremely interested in using. The application I have in mind is Crunchy. In a nutshell: Crunchy takes an arbitrary html page (with embedded Python code inside 
tags) and transforms it so that the user can execute, in a variety of
ways, the Python code displayed in a browser (Firefox) window.  It is
a different way to interact with code than the ones given as examples
on http://play1.codespeak.net/.

Crunchy's user code (executed from the browser window) is not
sandboxed.  I was wondering how difficult it would be to have it
sandboxed.

Here are a few more specific questions:

1 a. Is it possible to create a "sandboxed python interpreter" that
can be included as a module distributed with a cPython based program
(Crunchy) without having pypy included in the distribution?
1 b. If so, does that module has to be (pre-)compiled for a given
target machine?

2. Is it possible to limit the time for a given process (as mentioned above)?

Thank you in advance for anyone that can give me some information
regarding the above.  If you feel this discussion is not appropriate
for this list, please do not hesitate to tell me so and perhaps answer
the questions "off-list".   And, if the answers are simply: read  this
URL, and try this example, it would be appreciated as well.

Cheers,

Andr?

P.S. Crunchy's code is ... the work of two Python hobbyists ... and is
probably not worth looking at - I can probably clarify any specific
point needed to find out how it works, if  needed to answer the
questions I raised, better by email than having anyone read its code.


From lac at openend.se  Sun Dec  9 23:04:04 2007
From: lac at openend.se (Laura Creighton)
Date: Sun, 09 Dec 2007 23:04:04 +0100
Subject: [pypy-dev] Sandboxing in Pypy and Crunchy
In-Reply-To: Message from "Andre Roberge"  of "Sun,
	09 Dec 2007 13:22:10 -0400."
	<7528bcdd0712090922x40adf75ew9217568ced7d1edf@mail.gmail.com> 
References: <7528bcdd0712090922x40adf75ew9217568ced7d1edf@mail.gmail.com> 
Message-ID: <200712092204.lB9M440V016389@theraft.openend.se>

In a message of Sun, 09 Dec 2007 13:22:10 -0400, "Andre Roberge" writes:
>Hello everyone,
>
>Please forget the intrusion but I did not know where else to ask this que
>stion.


Welcome.  This is not an intrusion.  You have come to the right place.
You may want to start by reading this.
http://codespeak.net/pypy/dist/pypy/doc/sandbox.html

Cpython is the python you know and use, the one that is written in C.
pypy-c is a pypy interpreter, which could be interpreting python, but
could also be interpreting prolog, or javascript, or squeak -- and
which produces as its output c code that you can run.  Just so you
don't confuse them as you are reading.

>
>Through my involvement with Google's Highly Open Participation
>contest, I have learned about the sandboxing capabilities of pypy and,
>I believe although I can't find it anymore, the ability to limit the
>time allowed to a given process.  Even if this last one is wrong, the
>sandboxing capability is something I would be extremely interested in
>using.
>
>The application I have in mind is Crunchy.  In a nutshell: Crunchy
>takes an arbitrary html page (with embedded Python code inside 
>tags) and transforms it so that the user can execute, in a variety of
>ways, the Python code displayed in a browser (Firefox) window.  It is
>a different way to interact with code than the ones given as examples
>on http://play1.codespeak.net/.
>
>Crunchy's user code (executed from the browser window) is not
>sandboxed.  I was wondering how difficult it would be to have it
>sandboxed.
>
>Here are a few more specific questions:
>
>1 a. Is it possible to create a "sandboxed python interpreter" that
>can be included as a module distributed with a cPython based program
>(Crunchy) without having pypy included in the distribution?
>1 b. If so, does that module has to be (pre-)compiled for a given
>target machine?
>
>2. Is it possible to limit the time for a given process (as mentioned abo
>ve)?
>
>Thank you in advance for anyone that can give me some information
>regarding the above.  If you feel this discussion is not appropriate
>for this list, please do not hesitate to tell me so and perhaps answer
>the questions "off-list".   And, if the answers are simply: read  this
>URL, and try this example, it would be appreciated as well.
>
>Cheers,
>
>Andr?

This list is the appropriate place for this discussion.  But so is
#pypy on irc.freenode.net.  There you can hold real conversations,
so its often faster to figure things out by talking to us there.

Can you post the details of the architecture of crunchy?  Where does
the student's code run?  On the student's machine? or on the teacher's
server machine?

The ability to sandbox is a property of the architecture of pypy.
It's not a module that you could port to Cpython.  The person you
want to sandbox has to be running pypy.

Laura

>
>P.S. Crunchy's code is ... the work of two Python hobbyists ... and is
>probably not worth looking at - I can probably clarify any specific
>point needed to find out how it works, if  needed to answer the
>questions I raised, better by email than having anyone read its code.
>_______________________________________________
>pypy-dev at codespeak.net
>http://codespeak.net/mailman/listinfo/pypy-dev


From andre.roberge at gmail.com  Sun Dec  9 23:56:17 2007
From: andre.roberge at gmail.com (Andre Roberge)
Date: Sun, 9 Dec 2007 18:56:17 -0400
Subject: [pypy-dev] Sandboxing in Pypy and Crunchy
In-Reply-To: <200712092204.lB9M440V016389@theraft.openend.se>
References: 
	<7528bcdd0712090922x40adf75ew9217568ced7d1edf@mail.gmail.com>
	<200712092204.lB9M440V016389@theraft.openend.se>
Message-ID: <7528bcdd0712091456s2d8eadf9mce1dbe4481f7bf63@mail.gmail.com>

Hi Laura,

I should have known that you'd be one of the first to reply. ;-)

On Dec 9, 2007 6:04 PM, Laura Creighton  wrote:
> In a message of Sun, 09 Dec 2007 13:22:10 -0400, "Andre Roberge" writes:

> You may want to start by reading this.
> http://codespeak.net/pypy/dist/pypy/doc/sandbox.html

I had read that, but it was not clear to me.
>
> Cpython is the python you know and use, the one that is written in C.
> pypy-c is a pypy interpreter, which could be interpreting python, but
> could also be interpreting prolog, or javascript, or squeak -- and
> which produces as its output c code that you can run.  Just so you
> don't confuse them as you are reading.
>

Ok, I had more or less understood that.
>
> >
[snip]
> >
> >Here are a few more specific questions:
> >
> >1 a. Is it possible to create a "sandboxed python interpreter" that
> >can be included as a module distributed with a cPython based program
> >(Crunchy) without having pypy included in the distribution?
> >1 b. If so, does that module has to be (pre-)compiled for a given
> >target machine?
> >
> >2. Is it possible to limit the time for a given process (as mentioned abo
> >ve)?
> >

>
> This list is the appropriate place for this discussion.  But so is
> #pypy on irc.freenode.net.  There you can hold real conversations,
> so its often faster to figure things out by talking to us there.
>
Sorry, I'm too old for the irc stuff ;-)


> Can you post the details of the architecture of crunchy?

Hmm, I'm not sure I can do that very well...   the best I can do I
think is to describe what it does.

1. Crunchy retrieves an html page.
2. It process it, removing pre-existing javascript and various
undesired html tags
3. It identifies where it needs to add custom elements (new html tags
& javascript code)
4. It feeds the page to the browser, leaving a line of communication
open, waiting for user instruction.

At step 3. above, a new thread is started for each place in the page
where an interaction with a Python interpreter is required.
Following user interaction (click of a button or entering some code in
an html input box), the user code is fed back to the appropriate
interpreter (thread) and the result is sent back to the browser.  If I
recall correctly, the interpreter used is a small variation from
code.py included in Python standard library.    It is this part (I
believe) that needs to be sandboxed - a single module.

>  Where does
> the student's code run?  On the student's machine? or on the teacher's
> server machine?

Right now Crunchy is primarily used in a single user environment.  It
would be possible to host it on a server, but it would be very
insecure to do so.  Ideally it should be hosted in a secure way on a
server in most situations.

>
> The ability to sandbox is a property of the architecture of pypy.
> It's not a module that you could port to Cpython.  The person you
> want to sandbox has to be running pypy.
>

Darn :(    I was hoping I could somehow just call a sandboxed
interpreter module ....    Then again, it means that I'll have to try
pypy myself, and play with it - something I meant to do ... but did
not for lack of time. It also makes it more of a burden on potential
users  if they have to install pypy in addition to Crunchy.

Thanks for your clarifications,

> Laura
>

PS.  Yes, Laura, it is cold and there is snow (unusual at this time of
the year) in your beloved Nova Scotia ;-)


From santagada at gmail.com  Mon Dec 10 03:17:34 2007
From: santagada at gmail.com (Leonardo Santagada)
Date: Mon, 10 Dec 2007 00:17:34 -0200
Subject: [pypy-dev] Sandboxing in Pypy and Crunchy
In-Reply-To: <200712092204.lB9M440V016389@theraft.openend.se>
References: <7528bcdd0712090922x40adf75ew9217568ced7d1edf@mail.gmail.com>
	<200712092204.lB9M440V016389@theraft.openend.se>
Message-ID: <912590F9-B701-433F-AF73-F1BA40C11E29@gmail.com>


Em 09/12/2007, ?s 20:04, Laura Creighton escreveu:
> Can you post the details of the architecture of crunchy?  Where does
> the student's code run?  On the student's machine? or on the teacher's
> server machine?


The idea is that you now run it on your on computer, as python is not  
sandboxed. But with pypy you could run it on an open server without  
problems. Well there is one problem, someone has to try it on pypy,  
and then if it work you have to setup a server to run it, to be like  
the ruby tutorial online (forgot the link).

--
Leonardo Santagada





From fijall at gmail.com  Mon Dec 10 12:06:13 2007
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 11 Dec 2007 00:06:13 +1300
Subject: [pypy-dev] pypy and crunchy
Message-ID: <693bc9ab0712100306h5b64fd7o744929a86e2133d4@mail.gmail.com>

(I've tried sending this mail from genesilico, but failed)

Hi Andre.

I think there is a bit of confusion. The ideal way would be to run crunchy
on top of cpython and fork a new process with sandboxed pypy. Sandboxing
works slightly different than import sandbox; sandbox.interact(), hence
even on top of pypy it would be hard to run one sadboxed thread and other
not sandboxed (I cannot really think about feasible solution). So this
looks like you would need to distribute pypy as a compiled interpreter.

This is the way play1 is done, it forks and runs different process for
each interpreter (without sandboxing, it's older than those features).
Although as I said before play1 is just a hack to make demos work, nothing
more  :)

Cheers,
fijal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From bborcic at gmail.com  Mon Dec 10 12:08:10 2007
From: bborcic at gmail.com (Boris Borcic)
Date: Mon, 10 Dec 2007 12:08:10 +0100
Subject: [pypy-dev] thunk object space : become() quirks
In-Reply-To: <475865D2.4040802@gmx.de>
References: <77f4ed2b0711140625s3b11e45ej61394be678abc368@mail.gmail.com>	<473B0B10.4050409@gmx.de>
	<475865D2.4040802@gmx.de>
Message-ID: <475D1E1A.3090500@gmail.com>

Carl Friedrich Bolz wrote:
> Hi Boris,
> 
> Carl Friedrich Bolz wrote:
>> Boris Borcic wrote:
>>> Looking for a way to use pypy in any manner, I came up with an idea for a
>>> deterministic sudoku solver that would use the 'become()' feature of the thunk
>>> object space. However, this doesn't work as I expected. The following shell
>>> trace illustrates my problem. Is this a bug or otherwise ? Can anybody explain ?
>>>
>>> BTW, I am using the pypy 1.0.0 build 41438 windows binary distribution.
>>>
>>> [subquestion : is pypy-dev appropriate for such a question ?]
>> It's a bug, I have a clue where it is and will try to fix it. Thanks for 
>> reporting! Yes, the list is completely appropriate.
> 
> Some updates on this thing: We discussed the problem extensively on the 
> sprint and the think is that this shows a serious problem with the way 
> the thunk object space is done. We have no concrete clue how to solve it 
> yet. Thunks themselves are also affected by this bug, but only in more 
> extreme situations.
> 
> I created an issue in the bug tracker for this:
> 
> https://codespeak.net/issue/pypy-dev/issue332

Well, I wouldn't have recognized the issue if you hadn't told me it's the same 
:) Thanks for the followup, glad to be of some help, sorry for the seriousness 
of the problem. Mmmh... I was going to ask whether it made sense for me to try 
implementing my algorithm idea with unification from the logic object space 
instead, but the (doc for the) latter seems to have vanished (while a surprise 
Prolog interpreter popped up, to be sure; fun stuff).

Best regards, Boris



From lac at openend.se  Mon Dec 10 12:09:11 2007
From: lac at openend.se (Laura Creighton)
Date: Mon, 10 Dec 2007 12:09:11 +0100
Subject: [pypy-dev] Sandboxing in Pypy and Crunchy
In-Reply-To: Message from "Andre Roberge"  of "Sun,
	09 Dec 2007 18:56:17 -0400."
	<7528bcdd0712091456s2d8eadf9mce1dbe4481f7bf63@mail.gmail.com> 
References: 
	<7528bcdd0712090922x40adf75ew9217568ced7d1edf@mail.gmail.com>
	<200712092204.lB9M440V016389@theraft.openend.se>
	<7528bcdd0712091456s2d8eadf9mce1dbe4481f7bf63@mail.gmail.com> 
Message-ID: <200712101109.lBAB9BNk004068@theraft.openend.se>

In a message of Sun, 09 Dec 2007 18:56:17 -0400, "Andre Roberge" writes:
>Hi Laura,
>Hmm, I'm not sure I can do that very well...   the best I can do I
>think is to describe what it does.
>
>1. Crunchy retrieves an html page.
>2. It process it, removing pre-existing javascript and various
>undesired html tags
>3. It identifies where it needs to add custom elements (new html tags
>& javascript code)
>4. It feeds the page to the browser, leaving a line of communication
>open, waiting for user instruction.
>
>At step 3. above, a new thread is started for each place in the page
>where an interaction with a Python interpreter is required.
>Following user interaction (click of a button or entering some code in
>an html input box), the user code is fed back to the appropriate
>interpreter (thread) and the result is sent back to the browser.  If I
>recall correctly, the interpreter used is a small variation from
>code.py included in Python standard library.    It is this part (I
>believe) that needs to be sandboxed - a single module.

I'm still confused.  Once you have figured out "each place in the page
where an interaction with a python interpreter is wanted" -- where do
you want the python interpreter which runs that code to itself run?
locally, on the same machine that has the browser?  inside the
browser? or do you open up a connection to some other machine --
yours, perhaps -- send the code there, and run it, and then send some
sort of result back to the machine where the student is running
the browser?

Wherever this is, this is where you need to run pypy.  And all of
these are possible.  You can run a sandboxed version of javascript --
a pypy with a javascript front end -- in your browser.  You can even
embed a sandboxed version of a python console in a browser.  too.

>>  Where does
>> the student's code run?  On the student's machine? or on the teacher's
>> server machine?
>
>Right now Crunchy is primarily used in a single user environment.  It
>would be possible to host it on a server, but it would be very
>insecure to do so.  Ideally it should be hosted in a secure way on a
>server in most situations.

Let me check one more thing -- are you running crunchy with the
idea that every student has one host machine, and every host machine
has one student?  And crunchy runs standalone on each and every
machine?  So your sandbox is to protect the student from him or
her self?  Because that is what this sounds like to me.  If so,
then each student needs a pypy intepreter.

But, usually, you want to sandbox somebody because the code they
are running is on a machine they share with other users, especially
a time sharing system where the other users could be using the
machine simultaneously.  Is this what you plan to do?  Because, in
that case, it is only the timesharing system that needs to be running
pypy.  And the students could connect to it using a crunchy-client
that ran under Cpython.

What is the part you want to sandbox?  The code that parses the
html page, looking for python code to run?  (I don't think so, but
I could be confused.)  Or the actual python code it finds?

>> The ability to sandbox is a property of the architecture of pypy.
>> It's not a module that you could port to Cpython.  The person you
>> want to sandbox has to be running pypy.
>>
>
>Darn :(    I was hoping I could somehow just call a sandboxed
>interpreter module ....    

Aha.  Sandboxing is not something that you construct around the outside
of arbitrary code.  It is a function of the transation process itself.
You need to construct a sandboxed version of pypy, and use that to
run any code that you want sandboxed.

When you run the special "pypy-c-sandbox" executable, instead of
running any library or system calls, it instead marshals the operation
name and the arguments to its stdout and it waits for the marshalled
result on its stdin. Which means there has to be an 'other side' -- a
separate process that reads the stdout and does something with it and
then marshals it up and sends it back.  This has 2 implications.
First of all, if the other side hasn't been written with the ability
to do something appropriate with a particular library or system call
that is of interest to you, then we will have to write that part
before the program will be of use. Not every python system call is
supported now.  We'd have to investigate to see if you need one that
hasn't been written yet.

And secondly, it is not the case that this second program, the other
side, is written in such a way that it, in effect, says 'using my
Godlike powers of understanding, I know that you, nasty person, just
tried to break out of the sandbox using a buffer overflow!  I won't
allow that!! '  Instead, the reason that things are secure is that no
matter what horrible things the other side is asked to deal with, the
user is still waiting for something to come back to his stdin.  If all
you can do is read from stdin and write to stdout, then there is no
ability to exploit whatever bug you are interested in.  You discover
that when some other process attempted to run the nasty code you typed
in, it generated a fatal RPython error.  That doesn't help you use the
error.  Thus, no cleverness and Godlike understanding is required.

>Then again, it means that I'll have to try
>pypy myself, and play with it - something I meant to do ... but did
>not for lack of time. It also makes it more of a burden on potential
>users  if they have to install pypy in addition to Crunchy.

Maybe over Christmas -- if there is no pyContest for the shortest
python program to do something -- we could work together on getting a
sandboxed-server version of crunchy working.  You wouldn't have any
more trips to Switzerland planned, either, would you?  Because we
could probably get together over a weekend around a trip like that, too.
And there is always PyCon.  

> >Thanks
for your clarifications,

Any time.

>
>> Laura
>>
>
>PS.  Yes, Laura, it is cold and there is snow (unusual at this time of
>the year) in your beloved Nova Scotia ;-)

You _really_ know how to make a person want to go home. :-(
Enjoy it for those of us who cannot.  Nothing but rain around here
in G?teborg.  Bah!  Where's the real winter?

PS. It's a _very polite and friendly_ irc channel.  I promise.


From cfbolz at gmx.de  Mon Dec 10 12:27:32 2007
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Mon, 10 Dec 2007 12:27:32 +0100
Subject: [pypy-dev] thunk object space : become() quirks
In-Reply-To: <475D1E1A.3090500@gmail.com>
References: <77f4ed2b0711140625s3b11e45ej61394be678abc368@mail.gmail.com>	<473B0B10.4050409@gmx.de>
	<475865D2.4040802@gmx.de> <475D1E1A.3090500@gmail.com>
Message-ID: <475D22A4.5050906@gmx.de>

Boris Borcic wrote:
> Carl Friedrich Bolz wrote:
>> Hi Boris,
>>
>> Carl Friedrich Bolz wrote:
>>> Boris Borcic wrote:
>>>> Looking for a way to use pypy in any manner, I came up with an idea 
>>>> for a
>>>> deterministic sudoku solver that would use the 'become()' feature of 
>>>> the thunk
>>>> object space. However, this doesn't work as I expected. The 
>>>> following shell
>>>> trace illustrates my problem. Is this a bug or otherwise ? Can 
>>>> anybody explain ?
>>>>
>>>> BTW, I am using the pypy 1.0.0 build 41438 windows binary distribution.
>>>>
>>>> [subquestion : is pypy-dev appropriate for such a question ?]
>>> It's a bug, I have a clue where it is and will try to fix it. Thanks 
>>> for reporting! Yes, the list is completely appropriate.
>>
>> Some updates on this thing: We discussed the problem extensively on 
>> the sprint and the think is that this shows a serious problem with the 
>> way the thunk object space is done. We have no concrete clue how to 
>> solve it yet. Thunks themselves are also affected by this bug, but 
>> only in more extreme situations.
>>
>> I created an issue in the bug tracker for this:
>>
>> https://codespeak.net/issue/pypy-dev/issue332
> 
> Well, I wouldn't have recognized the issue if you hadn't told me it's 
> the same :) Thanks for the followup, glad to be of some help, sorry for 
> the seriousness of the problem. Mmmh... I was going to ask whether it 
> made sense for me to try implementing my algorithm idea with unification 
> from the logic object space instead, but the (doc for the) latter seems 
> to have vanished (while a surprise Prolog interpreter popped up, to be 
> sure; fun stuff).

The logic object space was removed during the cleanup sprint, we 
couldn't maintain it. Even if it were there, it would have had the same 
problems as the thunk object space :-).

The Prolog interpreter is there for a while, I wrote it for my Bachelor 
thesis. It doesn't interact with the Python interpreter yet though 
(which would be quite an interesting project, but I don't really have 
time for it right now).

Cheers,

Carl Friedrich


From cfbolz at gmx.de  Mon Dec 10 12:45:48 2007
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Mon, 10 Dec 2007 12:45:48 +0100
Subject: [pypy-dev] Sandboxing in Pypy and Crunchy
In-Reply-To: <7528bcdd0712091456s2d8eadf9mce1dbe4481f7bf63@mail.gmail.com>
References: 	<7528bcdd0712090922x40adf75ew9217568ced7d1edf@mail.gmail.com>	<200712092204.lB9M440V016389@theraft.openend.se>
	<7528bcdd0712091456s2d8eadf9mce1dbe4481f7bf63@mail.gmail.com>
Message-ID: <475D26EC.3090901@gmx.de>

Hi Andr?,

I'm trying to clear up some confusion:

Andre Roberge wrote:
[snip]
> On Dec 9, 2007 6:04 PM, Laura Creighton  wrote:
>> the student's code run?  On the student's machine? or on the teacher's
>> server machine?
> 
> Right now Crunchy is primarily used in a single user environment.  It
> would be possible to host it on a server, but it would be very
> insecure to do so.  Ideally it should be hosted in a secure way on a
> server in most situations.
> 
>> The ability to sandbox is a property of the architecture of pypy.
>> It's not a module that you could port to Cpython.  The person you
>> want to sandbox has to be running pypy.
>>
> 
> Darn :(    I was hoping I could somehow just call a sandboxed
> interpreter module ....

The sandboxed PyPy Python interpreter needs to be controlled by an 
external Python interpreter to provide the virtual environment for the 
sandbox. This external interpreter can be a completely normal CPython. 
ASCII diagram:

+-----------------------------------------+
| controlling Python interpreter (CPython)|
+-----------------------------------------+
        |                   ^
        | all communication |
        v                   |
+----------------------------------+
| sandboxed PyPy Python interpreter|
+----------------------------------+


the two boxes are different processes. With a bit of effort, the view of 
the controlling Python on the sandboxed interpreter can be that of a 
simple module that provides a sandboxed way to execute Python code. 
There is also no reason why the outer process cannot control more than 
one sandboxed interpreter. Therefore the answer to your question might 
be yes. Deployment-wise it doesn't behave much like an extension module 
though: You have a bit of pure-Python code for the upper interpreter 
plus a binary with a full Python interpreter.

> Then again, it means that I'll have to try
> pypy myself, and play with it - something I meant to do ... but did
> not for lack of time. It also makes it more of a burden on potential
> users  if they have to install pypy in addition to Crunchy.

Yes, probably. However, you just need this solution only if you want the 
Python code to run on a server, not if the Python code runs on the users 
machine.

Cheers,

Carl Friedrich


From andre.roberge at gmail.com  Mon Dec 10 12:49:43 2007
From: andre.roberge at gmail.com (Andre Roberge)
Date: Mon, 10 Dec 2007 07:49:43 -0400
Subject: [pypy-dev] Sandboxing in Pypy and Crunchy
In-Reply-To: <475D26EC.3090901@gmx.de>
References: 
	<7528bcdd0712090922x40adf75ew9217568ced7d1edf@mail.gmail.com>
	<200712092204.lB9M440V016389@theraft.openend.se>
	<7528bcdd0712091456s2d8eadf9mce1dbe4481f7bf63@mail.gmail.com>
	<475D26EC.3090901@gmx.de>
Message-ID: <7528bcdd0712100349s680b8793lfb4e12368413a77a@mail.gmail.com>

Thanks,  (to all of you)

This clarifies things quite a bit.   Something to look at in 2008,
after the Crunchy 1.0 release.

Andr?

On 12/10/07, Carl Friedrich Bolz  wrote:
> Hi Andr?,
>
> I'm trying to clear up some confusion:
>
> Andre Roberge wrote:
> [snip]
> > On Dec 9, 2007 6:04 PM, Laura Creighton  wrote:
> >> the student's code run?  On the student's machine? or on the teacher's
> >> server machine?
> >
> > Right now Crunchy is primarily used in a single user environment.  It
> > would be possible to host it on a server, but it would be very
> > insecure to do so.  Ideally it should be hosted in a secure way on a
> > server in most situations.
> >
> >> The ability to sandbox is a property of the architecture of pypy.
> >> It's not a module that you could port to Cpython.  The person you
> >> want to sandbox has to be running pypy.
> >>
> >
> > Darn :(    I was hoping I could somehow just call a sandboxed
> > interpreter module ....
>
> The sandboxed PyPy Python interpreter needs to be controlled by an
> external Python interpreter to provide the virtual environment for the
> sandbox. This external interpreter can be a completely normal CPython.
> ASCII diagram:
>
> +-----------------------------------------+
> | controlling Python interpreter (CPython)|
> +-----------------------------------------+
>         |                   ^
>         | all communication |
>         v                   |
> +----------------------------------+
> | sandboxed PyPy Python interpreter|
> +----------------------------------+
>
>
> the two boxes are different processes. With a bit of effort, the view of
> the controlling Python on the sandboxed interpreter can be that of a
> simple module that provides a sandboxed way to execute Python code.
> There is also no reason why the outer process cannot control more than
> one sandboxed interpreter. Therefore the answer to your question might
> be yes. Deployment-wise it doesn't behave much like an extension module
> though: You have a bit of pure-Python code for the upper interpreter
> plus a binary with a full Python interpreter.
>
> > Then again, it means that I'll have to try
> > pypy myself, and play with it - something I meant to do ... but did
> > not for lack of time. It also makes it more of a burden on potential
> > users  if they have to install pypy in addition to Crunchy.
>
> Yes, probably. However, you just need this solution only if you want the
> Python code to run on a server, not if the Python code runs on the users
> machine.
>
> Cheers,
>
> Carl Friedrich
>


From anto.cuni at gmail.com  Tue Dec 11 11:19:25 2007
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Tue, 11 Dec 2007 11:19:25 +0100
Subject: [pypy-dev] [pypy-svn] r49617
	-	pypy/branch/clr-module-improvements/pypy/module/clr
In-Reply-To: <20071210234847.ABA67168434@codespeak.net>
References: <20071210234847.ABA67168434@codespeak.net>
Message-ID: <475E642D.40801@gmail.com>

Hi Amit,

regmee at codespeak.net wrote:
> +    assembliesToScan = [ "/usr/lib/mono/1.0/mscorlib.dll",
> +                         "/usr/lib/mono/1.0/System.dll",
> +                         "/usr/lib/mono/1.0/System.Web.dll",
> +                         "/usr/lib/mono/1.0/System.Data.dll",
> +                         "/usr/lib/mono/1.0/System.Xml.dll",
> +                         "/usr/lib/mono/1.0/System.Drawing.dll"
> +                    ]
> +    assems = []
> +    for assemblyName in assembliesToScan:
> +        assems.append(System.Reflection.Assembly.LoadFile(assemblyName))

sorry for bugging you again :-),
but this is not what we want.

We don't need to preload assemblies that the user might not want. For 
example, in IronPython to access the System.Xml namespace you need to 
explicitly load System.Xml.dll by using one of the clr.LoadAssembly* 
methods.

Moreover, what happens if I wanto to load an assembly that it's not on 
this list? And what if I load an assembly after the list of namespaces 
has already been computed?

I think what you need to do is to maintain a cache of valid namespaces, 
and check whether a new assembly has been loaded every time you import 
something.
You can easily get the list of currently loaded assemblies by calling 
AppDomain.CurrentDomain.GetAssemblies().

ciao Anto


From lac at openend.se  Tue Dec 11 11:48:13 2007
From: lac at openend.se (Laura Creighton)
Date: Tue, 11 Dec 2007 11:48:13 +0100
Subject: [pypy-dev] PyPy talk not accepted at PyCon
Message-ID: <200712111048.lBBAmDmV010219@theraft.openend.se>


------- Forwarded Message

Return-Path: pycon-pc at python.org
Delivery-Date: Tue Dec 11 09:01:50 2007
Return-Path: 
Subject: PyCon 2008 proposal #81 decision
From: pycon-pc at python.org
To: fijall at gmail.com, lac at openend.se
Date: Tue, 11 Dec 2007 07:34:57 GMT
Message-Id: <20071211073457.5EE8E2D02A at rampart.timecastle.net>

Dear Maciej Fijalkowski, Ms. Laura A Creighton,

we are sorry to inform you that your proposal,
"The PyPy way and the tales of nice features and pleasant design",
was not accepted for inclusion in the conference program. PyCon has grown
tremendously over the last few years; this year we received over 140 proposals,
and had space in the schedule for less than half. A number of excellent
proposals had to be cut.

We do want you to know that PyCon will feature a number of Open Space sessions
that are not part of the formal presentation schedule. Please consider
presenting your talk as an Open Space presentation, or as a five-minute
lightning talk. Thank you for your effort in submitting a proposal,
and we hope you will still join us in Chicago!

We are attaching the program committee's reviews of your proposal below;
they are also visible to authors on the PyCon website. Finally, we want to
hear your thoughts on this year's online proposal system and submission
process. What went well? What could've been better? Please take a
moment to provide feedback:

    < http://us.pycon.org/2008/survey/propmgr/ >

Alternatively, you may provide comments in reply to this e-mail.




Sincerely,
    Ivan Krsti?? , program committee chair, PyCon 2008
    David Goodger , conference chair, PyCon 2008


- --------------------------------------------------------------------------------
Proposal: < http://us.pycon.org/2008/conference/proposals/81/ >


Reviewer #73: +1

PyPy talks at PyCon have not been represented well so far. 
This talk has the potential to clarify a lot of the mystery which many
people still associate with the PyPy project.
................................................................................

Reviewer #4: +0

PyPy is interesting. My concern (and thus +0) is that it is too big for
a 30 min talk. The 30 min limit needs to be taken into consideration when planning
the timed outline.
................................................................................

Reviewer #76: +0

I think this could be a good talk.  It's an interesting project, but it 
seems like it would have a somewhat limited audience.  The author mentions
demos, which will be important to make things concrete.




- --------------------------------------------------------------------------------
You have received this e-mail because you are participating in PyCon 2008.
If you feel you have received this e-mail in error, please contact:
    Jeff Rush at jeff at taupro.com




------- End of Forwarded Message



From fijal at genesilico.pl  Tue Dec 11 11:58:39 2007
From: fijal at genesilico.pl (Maciek Fijalkowski)
Date: Tue, 11 Dec 2007 11:58:39 +0100
Subject: [pypy-dev] PyPy talk not accepted at PyCon
In-Reply-To: <200712111048.lBBAmDmV010219@theraft.openend.se>
References: <200712111048.lBBAmDmV010219@theraft.openend.se>
Message-ID: <475E6D5F.4030502@genesilico.pl>

Laura Creighton wrote:

 > 

This is slightly misleading. There *is* pypy talk (Christians about 
stackless) accepted, just not this one.

Cheers,
fijal


:.



From lac at openend.se  Tue Dec 11 12:09:50 2007
From: lac at openend.se (Laura Creighton)
Date: Tue, 11 Dec 2007 12:09:50 +0100
Subject: [pypy-dev] PyPy talk not accepted at PyCon
In-Reply-To: Message from Maciek Fijalkowski  
	of "Tue, 11 Dec 2007 11:58:39 +0100." <475E6D5F.4030502@genesilico.pl> 
References: <200712111048.lBBAmDmV010219@theraft.openend.se>
	<475E6D5F.4030502@genesilico.pl> 
Message-ID: <200712111109.lBBB9oGi013551@theraft.openend.se>

In a message of Tue, 11 Dec 2007 11:58:39 +0100, Maciek Fijalkowski writes:
>Laura Creighton wrote:
>
> > 
>
>This is slightly misleading. There *is* pypy talk (Christians about 
>stackless) accepted, just not this one.
>
>Cheers,
>fijal

Ah yes, sorry about that.

Laura



From jon.riehl at gmail.com  Tue Dec 11 20:18:06 2007
From: jon.riehl at gmail.com (Jon Riehl)
Date: Tue, 11 Dec 2007 13:18:06 -0600
Subject: [pypy-dev] PyPy talk not accepted at PyCon
In-Reply-To: <200712111048.lBBAmDmV010219@theraft.openend.se>
References: <200712111048.lBBAmDmV010219@theraft.openend.se>
Message-ID: <3ca1de0712111118k4a02a468r8dd218affc22db58@mail.gmail.com>

Hi Laura, all,

I know many of you don't know me (however, I was surprised to see my
full name in the last PyPy PyCon talk I was at; I figured ya'll would
have ditched my parser by then), but I've been working on Python
language evolution and extensibility as well.  Language implementation
and features don't usually fly so well at PyCon (though, they seem to
love hosting simple parser generator talks, oddly enough).  Perhaps we
can grab some open space for a BoF, where we can team up to provide
back to back language implementation talks (mine didn't make it in
either) and possibly sync up.

I'm currently local to Chicago, so I'm pretty sure I can be around to
help make this happen.  If anyone is interested, here are some slides
from a talk I gave at the University of Chicago on 11/17:

http://people.cs.uchicago.edu/~jriehl/MythonTalk.pdf

Regards (and sympathies),
-Jon

On Dec 11, 2007 4:48 AM, Laura Creighton  wrote:
> (snip)


From regmi.amit at gmail.com  Wed Dec 12 02:11:52 2007
From: regmi.amit at gmail.com (amit)
Date: Tue, 11 Dec 2007 20:11:52 -0500
Subject: [pypy-dev] adding support for Generic classes in the "/module/clr"
Message-ID: <475F3558.7030102@gmail.com>

Support for generic classes

---IronPythonic way---------
from System.Collections.Generic import *
l = List[str]()
l.Add("Hello")
l.Add("Hi")
l.Add(3)        # fails with ValueError:  

d = Dictionary[str, int]()
d.Add('abc', 1)
d.Add('def', 2)
for i in d.Keys:
    print d[i]

So here in pypy-clr what we'd like to do is

    import System.Collections.Generic.LinkedList
    l= System.Collections.Generic.LinkedList()
    l.Add("hello")
    l.Add("hi")
    l.Add(3)        # throw ValueError exception

the import is to be analysed if its an import for a Generic Class and 
loaded as

    
clr.load_cli_generic_class('System.Collections.Generic','LinkedList')

The implementation of load_cli_generic_class is a BlackBox to me as of now.

 From the import line we can check if the class is a "generic" and then 
reflection can be used to determine:
a) Generic type
b) type arguments
c) Parameter attributes
.... and more

I hope somehow the existing build_wrapper could be used after putting 
some checks but I am not sure how.

-AmitReg




From anto.cuni at gmail.com  Wed Dec 12 12:23:02 2007
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Wed, 12 Dec 2007 12:23:02 +0100
Subject: [pypy-dev] adding support for Generic classes in the
	"/module/clr"
In-Reply-To: <475F3558.7030102@gmail.com>
References: <475F3558.7030102@gmail.com>
Message-ID: <58e316a40712120323y7ad6fd3dp6347a1fbfc3a63f3@mail.gmail.com>

On Dec 12, 2007 2:11 AM, amit  wrote:
> Support for generic classes
>
> ---IronPythonic way---------
> from System.Collections.Generic import *
> l = List[str]()
> l.Add("Hello")
> l.Add("Hi")
> l.Add(3)        # fails with ValueError:
>
> d = Dictionary[str, int]()
> d.Add('abc', 1)
> d.Add('def', 2)
> for i in d.Keys:
>     print d[i]
>
> So here in pypy-clr what we'd like to do is
>
>     import System.Collections.Generic.LinkedList

we can't use this syntax, because the parser would complain. We need
to use the same trick as IronPython, i.e. use square brackets.

>     l= System.Collections.Generic.LinkedList()
>     l.Add("hello")
>     l.Add("hi")
>     l.Add(3)        # throw ValueError exception
>
> the import is to be analysed if its an import for a Generic Class and
> loaded as
>
>
> clr.load_cli_generic_class('System.Collections.Generic','LinkedList')

No, I don't think we want to do so. I think the best is to mimic
IronPython as much as possible. I.e., let the user to import the
generic class by itself, e.g. "import
System.Collections.Generic.List"; then, if you do "List[str]" it
returns a concrete class that can be istantiated as in IronPython.

> The implementation of load_cli_generic_class is a BlackBox to me as of now.
>
>  From the import line we can check if the class is a "generic" and then
> reflection can be used to determine:
> a) Generic type
> b) type arguments
> c) Parameter attributes
> .... and more
>
> I hope somehow the existing build_wrapper could be used after putting
> some checks but I am not sure how.

well, basically you have to check whether a class is generic; if it
is, we need to construct it by using another metaclass which has
support for __getitem__; something like this:

class MetaGenericCliClassWrapper(...):
     def __getitem__(self, *types):
         # do something
         return load_cli_class(...)

But before you can use this metaclass, you need to ensure that
load_cli_class works fine with concrete instantiations of generic
classes. So, the first thing to do is to write a test like this:

def test_generic_class(self):
    ListInt = load_cli_class("System.Collections.Generic", "List`1")
    x = ListInt()
    x.Add(42)
    # etc...

Then we need to write other tests for the error cases (e.g., test that
if you put a string inside x it raises ValueError).
Maybe these test swould work out of the box, I don't know. After that,
all we need to do is to provide some nice syntactic sugar like square
brackets & co.

ciao Anto


From lac at openend.se  Fri Dec 14 14:30:48 2007
From: lac at openend.se (Laura Creighton)
Date: Fri, 14 Dec 2007 14:30:48 +0100
Subject: [pypy-dev] In case you don't read comp.lang.python.announce
Message-ID: <200712141330.lBEDUmN3013373@theraft.openend.se>


Looks like we are being asked for by name.

Laura

------- Forwarded Message

From: Raymond Hettinger 
Newsgroups: comp.lang.python.announce
Subject: Call for Papers (Python or PyPy):  Workshop on Self-sustaining   Systems (S3) 2008
Date: Thu, 13 Dec 2007 11:41:44 -0800 (PST)
Organization: http://groups.google.com
Lines: 95

*** Workshop on Self-sustaining Systems (S3) 2008 ***

May 15-16, 2008
Potsdam, Germany
http://www.swa.hpi.uni-potsdam.de/s3/

- -- Call for papers:

The Workshop on Self-sustaining Systems (S3) is a forum for discussion
of topics relating to computer systems and languages that are able to
bootstrap, implement, modify, and maintain themselves. One property of
these systems is that their implementation is based on small but
powerful abstractions; examples include (amongst others) Squeak/
Smalltalk, COLA, Klein/Self, PyPy/Python, Rubinius/Ruby, and Lisp.
Such systems are the engines of their own replacement, giving
researchers and developers great power to experiment with, and explore
future directions from within, their own small language kernels.

S3 will be take place May 15-16, 2008 at the Hasso-Plattner-Institute
in Potsdam, Germany. It is an exciting opportunity for researchers and
practitioners interested in self-sustaining systems to meet and share
their knowledge, experience, and ideas for future research and
development.

- -- Invited talk:

Ian Piumarta: Late-bound Object Lambda Architectures (Viewpoints
Research Institute, USA)

- -- Submissions and proceedings:

S3 invites submissions of high-quality papers reporting original
research, or describing innovative contributions to, or experience
with, self-sustaining systems, their implementation, and their
application. Papers that depart significantly from established ideas
and practices are particularly welcome.

Submissions must not have been published previously and must not be
under review for any another refereed event or publication. The
program committee will evaluate each contributed paper based on its
relevance, significance, clarity, and originality. Revised papers will
be published as post-proceedings in the Springer LNCS series.

Papers should be submitted electronically via EasyChair at
http://www.easychair.org/conferences/?conf=s3 in PDF format.
Submissions must be written in English (the official language of the
workshop) and must not exceed 20 pages. They should use the LNCS
format, templates for which are available at http://www.springer.de/comp/lncs/authors.html.

- -- Venue:

Hasso-Plattner-Institut (Potsdam, Germany)

- -- Important dates:

Submission of papers: February 15, 2008
Author notification: April 11, 2008
Revised papers due: April 25, 2008

S3 workshop: May 15-16, 2008

Final papers for LNCS post-proceedings due: June 6, 2008

- -- Chairs:

* Robert Hirschfeld (Hasso-Plattner-Institut Potsdam, Germany)
* Kim Rose (Viewpoints Research Institute, USA)

- -- Program committee:

* Johan Brichau, Universite Catholique de Louvain, Belgium
* Pascal Costanza, Vrije Universiteit Brussel, Belgium
* Wolfgang De Meuter, Vrije Universiteit Brussel, Belgium
* Stephane Ducasse, INRIA Lille, France
* Michael Haupt, Hasso-Plattner-Institut, Germany
* Robert Hirschfeld, Hasso-Plattner-Institut, Germany
* Dan Ingalls, Sun Microsystems Laboratories, USA
* Martin von L?wis, Hasso-Plattner-Institut, Germany
* Hidehiko Masuhara, University of Tokyo, Japan
* Ian Piumarta, Viewpoints Research Institute, USA
* David Ungar, IBM, USA

- -- Registration fees:

Early (until April 18, 2008)
* Regular participants: EUR 160
* Students: EUR 80

Late (after April 18, 2008)
* Regular participants: EUR 170
* Students: EUR 90



- -- 
http://mail.python.org/mailman/listinfo/python-announce-list

        Support the Python Software Foundation:
        http://www.python.org/psf/donations.html

------- End of Forwarded Message



From cfbolz at gmx.de  Fri Dec 14 19:57:30 2007
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Fri, 14 Dec 2007 19:57:30 +0100
Subject: [pypy-dev] Roadmap draft
Message-ID: <4762D21A.3090903@gmx.de>

Hi all!

Just to inform you a bit: Several PyPy developers have sat together and 
worked on a very rough roadmap for what tasks need to be done to make 
PyPy a realistic replacement for CPython. The work is going on here:

https://codespeak.net/svn/pypy/extradoc/planning/roadmap/

We plan to work on this some more in the next days. As soon as it is in 
a more finished state we will ask write a mail to pypy-dev again and ask 
for general feedback.

Cheers,

Carl Friedrich


From fijall at gmail.com  Fri Dec 14 20:10:46 2007
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Fri, 14 Dec 2007 20:10:46 +0100
Subject: [pypy-dev] Roadmap draft
In-Reply-To: <4762D21A.3090903@gmx.de>
References: <4762D21A.3090903@gmx.de>
Message-ID: <693bc9ab0712141110xb4b0746sda965bd4963caf66@mail.gmail.com>

In a broader context this also mean that we would like to produce
production-ready pypy interpreter as our goal :)

On Dec 14, 2007 7:57 PM, Carl Friedrich Bolz  wrote:

> Hi all!
>
> Just to inform you a bit: Several PyPy developers have sat together and
> worked on a very rough roadmap for what tasks need to be done to make
> PyPy a realistic replacement for CPython. The work is going on here:
>
> https://codespeak.net/svn/pypy/extradoc/planning/roadmap/
>
> We plan to work on this some more in the next days. As soon as it is in
> a more finished state we will ask write a mail to pypy-dev again and ask
> for general feedback.
>
> Cheers,
>
> Carl Friedrich
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ondrej at certik.cz  Fri Dec 14 20:44:37 2007
From: ondrej at certik.cz (Ondrej Certik)
Date: Fri, 14 Dec 2007 20:44:37 +0100
Subject: [pypy-dev] Roadmap draft
In-Reply-To: <693bc9ab0712141110xb4b0746sda965bd4963caf66@mail.gmail.com>
References: <4762D21A.3090903@gmx.de>
	<693bc9ab0712141110xb4b0746sda965bd4963caf66@mail.gmail.com>
Message-ID: <85b5c3130712141144q33e405b3u1f46a43de149cc5e@mail.gmail.com>

On Dec 14, 2007 8:10 PM, Maciej Fijalkowski  wrote:
> In a broader context this also mean that we would like to produce
> production-ready pypy interpreter as our goal :)

Wow, I like that. :)

Ondrej


From tjreedy at udel.edu  Sat Dec 15 02:49:15 2007
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 14 Dec 2007 20:49:15 -0500
Subject: [pypy-dev] Roadmap draft
References: <4762D21A.3090903@gmx.de>
Message-ID: 


"Carl Friedrich Bolz"  wrote in message 
news:4762D21A.3090903 at gmx.de...
| Hi all!
|
| Just to inform you a bit: Several PyPy developers have sat together and
| worked on a very rough roadmap for what tasks need to be done to make
| PyPy a realistic replacement for CPython. The work is going on here:
|
| https://codespeak.net/svn/pypy/extradoc/planning/roadmap/

Looks like a good start.

| We plan to work on this some more in the next days. As soon as it is in
| a more finished state we will ask write a mail to pypy-dev again and ask
| for general feedback.

An idea for your consideration:

- Target Python 3.0 for 'production' PyPy.

Rationale:

It looks to me that the road to production PyPy will take several months --  
about the time until 2.6 and possibly 3.0 are released.  You are currently 
'behind' at 2.4, working on catching up to 2.5.  If you do release a 2.5 
version, you will soon if not immediately be behind again.  Leapfrogging 
would put you up to date and probably ahead of the other ports.

2.6 will have all the new 3.0 stuff that will fit without breaking 
anything -- but without any of the 3.0 deletions that balance the 
additions.  It will be a relatively
bloated and confusing release that newcomers should probably skip over. 
Parsing 3.0 should be easier with fewer alternatives, including no 
__future__s.

Some of the new 3.0 stuff, such as most of the new IO system (io.py) is 
written in Python.  So you get that much for free.

If there are any showstoppers in 3.0 with respect to alternate 
implementations, now is the best time to find out and let Guido, etc, know.

While there will be a 2to3.py for at least partly converting Python code, 
there is not, as far as I know, anything similar for C code using the C 
API.  I expect (but could of course be wrong) that some of the people 
maintaining wrappers of C libraries might consider a 3.0 version to be a 
good time to switch using ctypes if they have not already.  I am assuming 
that a complete cytpes module will be part of a production release, so that 
it will have relatively easy access to compiled shared libraries.

Terry Jan Reedy






From arigo at tunes.org  Wed Dec 19 18:39:29 2007
From: arigo at tunes.org (Armin Rigo)
Date: Wed, 19 Dec 2007 18:39:29 +0100
Subject: [pypy-dev] Microbenchmark plots
Message-ID: <20071219173929.GA16868@code0.codespeak.net>

Hi all,

Michael has been running microbenchmarks on the tuatara machine (a
PowerPC OS/X) for quite a while now.  In case you don't know them, they
are at http://tuatara.cs.uni-duesseldorf.de/benchmark.html.  Now I've
plugged this information through a CGI script using gnuplot, and it
gives this: http://wyvern.cs.uni-duesseldorf.de/~arigo/plots.html (lower
is better).

In the last couple of days it was a useful tool to find out a few
mistakes we made over the months - notaby, several innocent-looking
checkins that disabled some useful optimization as a side-effect.  As
you can see on the right edge of the graphs, as of today - with these
mistakes corrected - we are faster than ever on Richards and Pystone,
and our custom GCs beat Boehm hand-down, too.


A bientot,

Armin


From arigo at tunes.org  Wed Dec 19 19:50:53 2007
From: arigo at tunes.org (Armin Rigo)
Date: Wed, 19 Dec 2007 19:50:53 +0100
Subject: [pypy-dev] Sprint in Leysin?
Message-ID: <20071219185052.GA24076@code0.codespeak.net>

Hi all!

Around the Gothenburg sprint, we mentioned the idea to hold a sprint in
Leysin (Switzerland) again this winter.  We don't have the EU any more
to pay us, but the Swiss Franc is now cheaper compared to the Euro :-)

I checked with the "usual place", Chalet Ermina, and with my own
schedule.  The best dates would be in January before the 26th;
afterwards it becomes a bit harder.  If mid-January is too soon or
otherwise too impossible for too many people I can check again for later
in the winter, say in March (ski conditions are usually still good).

What do you think about it?


A bientot,

Armin.


From faassen at startifact.com  Wed Dec 19 20:25:54 2007
From: faassen at startifact.com (Martijn Faassen)
Date: Wed, 19 Dec 2007 20:25:54 +0100
Subject: [pypy-dev] Roadmap draft
In-Reply-To: <4762D21A.3090903@gmx.de>
References: <4762D21A.3090903@gmx.de>
Message-ID: 

Carl Friedrich Bolz wrote:
> Just to inform you a bit: Several PyPy developers have sat together and 
> worked on a very rough roadmap for what tasks need to be done to make 
> PyPy a realistic replacement for CPython. The work is going on here:
> 
> https://codespeak.net/svn/pypy/extradoc/planning/roadmap/
> 
> We plan to work on this some more in the next days. As soon as it is in 
> a more finished state we will ask write a mail to pypy-dev again and ask 
> for general feedback.

Hey,

I subscribed to the mailing list again. I'm very glad that this planning 
is taking place.

Some feedback:

If I read it correctly, the list seems more or less to be about an 
end-result to the process, a more or less "ideal" production release. 
Not quite idea perhaps -- library support may still be limited, but yet 
quite a lot of things are in there. That's good for a goal; one should 
set the sights high, and I'm sure the project is capable of 
accomplishing all this technically, eventually.

I think it's also very important to space out how you get there: have 
nearer-term goals with releases that aim to be useful.
I think some of the most important thinking that still that needs to go 
into this roadmap is to figure out how to space this out over multiple 
releases, where you have multiple releases of hopefully increasing 
usefulness. This way you set up a positive feedback cycle where people 
test things and hopefully people will be motivated in contributing in 
useful places (libraries and such, and reporting bugs). At least, 
waiting until all of this is completed sounds like it would take quite a 
while as there are many tasks involved.

To get to a list of projected releases, you could restrict your 
ambitions along various dimensions. For instance, you could focus on 
only supporting one or a limited amount of backends for a first release. 
Or you could defer erformance optimizations. Alternatively you could 
restrict the amount of libraries you are going to implement (this is 
already in the roadmap, but on the other hand the support for a GUI 
toolkit is in there too). I'm sure other dimensions exist that I can't 
even think of.

Regards,

Martijn



From jacob at openend.se  Wed Dec 19 22:49:43 2007
From: jacob at openend.se (Jacob =?iso-8859-1?q?Hall=E9n?=)
Date: Wed, 19 Dec 2007 22:49:43 +0100
Subject: [pypy-dev] Roadmap draft
In-Reply-To: 
References: <4762D21A.3090903@gmx.de> 
Message-ID: <200712192249.43787.jacob@openend.se>

Thanks for the feedback Martijn, some comments below

onsdagen den 19 december 2007 skrev Martijn Faassen:
> Carl Friedrich Bolz wrote:
> > Just to inform you a bit: Several PyPy developers have sat together and
> > worked on a very rough roadmap for what tasks need to be done to make
> > PyPy a realistic replacement for CPython. The work is going on here:
> >
> > https://codespeak.net/svn/pypy/extradoc/planning/roadmap/
> >
> > We plan to work on this some more in the next days. As soon as it is in
> > a more finished state we will ask write a mail to pypy-dev again and ask
> > for general feedback.
>
> Hey,
>
> I subscribed to the mailing list again. I'm very glad that this planning
> is taking place.
>
> Some feedback:
>
> If I read it correctly, the list seems more or less to be about an
> end-result to the process, a more or less "ideal" production release.
> Not quite idea perhaps -- library support may still be limited, but yet
> quite a lot of things are in there. That's good for a goal; one should
> set the sights high, and I'm sure the project is capable of
> accomplishing all this technically, eventually.
>
> I think it's also very important to space out how you get there: have
> nearer-term goals with releases that aim to be useful.
> I think some of the most important thinking that still that needs to go
> into this roadmap is to figure out how to space this out over multiple
> releases, where you have multiple releases of hopefully increasing
> usefulness. This way you set up a positive feedback cycle where people
> test things and hopefully people will be motivated in contributing in
> useful places (libraries and such, and reporting bugs). At least,
> waiting until all of this is completed sounds like it would take quite a
> while as there are many tasks involved.

The roadmap is part of a multi step process. After we get acceptance from 
people in the project on where we want to go, the next step is outlining how 
to get there. I hope that people will conclude that the best way to go about 
things is to make a series of releases, but we will see. Releases take a lot 
of effort and there is a balance to strike between producing and releasing.

> To get to a list of projected releases, you could restrict your
> ambitions along various dimensions. For instance, you could focus on
> only supporting one or a limited amount of backends for a first release.
> Or you could defer erformance optimizations. Alternatively you could
> restrict the amount of libraries you are going to implement (this is
> already in the roadmap, but on the other hand the support for a GUI
> toolkit is in there too). I'm sure other dimensions exist that I can't
> even think of.

I think the roadmap is a set of restrictions. To be a viable replacement for 
CPython, there is a single backend that needs to be supported. We are not 
focusing on the JVM or .NET in this roadmap and we are not talking about 
support for other languages. For libraries, I think that is something that is 
absolutely necessary in order to get traction among Python users. While it 
would be nice if someone comes along and ports a GUI library, I don't think 
we can count on that happening. It is in any case a task that belongs near 
the end of a timeline with releases.

So, the roadmap reflects our current understanding of what we have to do to 
have a system that can attain critical mass and become a major Python 
implementation, hopefully supplanting CPython one day. I am certain we will 
have reason to revise the roadmap along the way, dropping some tasks and 
introducing others. Unfortunately, there are a large number of things that 
have to get done, but that is to a large extent the consequences of Python 
being a fairly old and well established programming language.

Jacob


From holger at merlinux.de  Wed Dec 19 23:34:23 2007
From: holger at merlinux.de (holger krekel)
Date: Wed, 19 Dec 2007 23:34:23 +0100
Subject: [pypy-dev] Roadmap draft
In-Reply-To: <200712192249.43787.jacob@openend.se>
References: <4762D21A.3090903@gmx.de> 
	<200712192249.43787.jacob@openend.se>
Message-ID: <20071219223423.GX13357@solar.trillke>

Hi Jacob, Martijn, all, 

thanks for your advises and input! IMHO it makes sense to wait a bit with 
discussing release plans or strategies until after the tasks and their 
interaction are more settled and somewhat commonly agreed.  And until after
we know a bit more on everyone's commitments and availabilities. 

Maybe Carl Friedrich or Armin could kick this off once they 
think it makes sense to discuss release plans or strategies?  

best & happy days to you all! 

holger

> Thanks for the feedback Martijn, some comments below
> 
> onsdagen den 19 december 2007 skrev Martijn Faassen:
> > Carl Friedrich Bolz wrote:
> > > Just to inform you a bit: Several PyPy developers have sat together and
> > > worked on a very rough roadmap for what tasks need to be done to make
> > > PyPy a realistic replacement for CPython. The work is going on here:
> > >
> > > https://codespeak.net/svn/pypy/extradoc/planning/roadmap/
> > >
> > > We plan to work on this some more in the next days. As soon as it is in
> > > a more finished state we will ask write a mail to pypy-dev again and ask
> > > for general feedback.
> >
> > Hey,
> >
> > I subscribed to the mailing list again. I'm very glad that this planning
> > is taking place.
> >
> > Some feedback:
> >
> > If I read it correctly, the list seems more or less to be about an
> > end-result to the process, a more or less "ideal" production release.
> > Not quite idea perhaps -- library support may still be limited, but yet
> > quite a lot of things are in there. That's good for a goal; one should
> > set the sights high, and I'm sure the project is capable of
> > accomplishing all this technically, eventually.
> >
> > I think it's also very important to space out how you get there: have
> > nearer-term goals with releases that aim to be useful.
> > I think some of the most important thinking that still that needs to go
> > into this roadmap is to figure out how to space this out over multiple
> > releases, where you have multiple releases of hopefully increasing
> > usefulness. This way you set up a positive feedback cycle where people
> > test things and hopefully people will be motivated in contributing in
> > useful places (libraries and such, and reporting bugs). At least,
> > waiting until all of this is completed sounds like it would take quite a
> > while as there are many tasks involved.
> 
> The roadmap is part of a multi step process. After we get acceptance from 
> people in the project on where we want to go, the next step is outlining how 
> to get there. I hope that people will conclude that the best way to go about 
> things is to make a series of releases, but we will see. Releases take a lot 
> of effort and there is a balance to strike between producing and releasing.
> 
> > To get to a list of projected releases, you could restrict your
> > ambitions along various dimensions. For instance, you could focus on
> > only supporting one or a limited amount of backends for a first release.
> > Or you could defer erformance optimizations. Alternatively you could
> > restrict the amount of libraries you are going to implement (this is
> > already in the roadmap, but on the other hand the support for a GUI
> > toolkit is in there too). I'm sure other dimensions exist that I can't
> > even think of.
> 
> I think the roadmap is a set of restrictions. To be a viable replacement for 
> CPython, there is a single backend that needs to be supported. We are not 
> focusing on the JVM or .NET in this roadmap and we are not talking about 
> support for other languages. For libraries, I think that is something that is 
> absolutely necessary in order to get traction among Python users. While it 
> would be nice if someone comes along and ports a GUI library, I don't think 
> we can count on that happening. It is in any case a task that belongs near 
> the end of a timeline with releases.
> 
> So, the roadmap reflects our current understanding of what we have to do to 
> have a system that can attain critical mass and become a major Python 
> implementation, hopefully supplanting CPython one day. I am certain we will 
> have reason to revise the roadmap along the way, dropping some tasks and 
> introducing others. Unfortunately, there are a large number of things that 
> have to get done, but that is to a large extent the consequences of Python 
> being a fairly old and well established programming language.
> 
> Jacob
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
> 

-- 
merlinux GmbH       Steinbergstr. 42    31139 Hildesheim   
http://merlinux.de  tel +49 5121 20800 75 (fax 77) 


From ondrej at certik.cz  Wed Dec 19 23:41:52 2007
From: ondrej at certik.cz (Ondrej Certik)
Date: Wed, 19 Dec 2007 23:41:52 +0100
Subject: [pypy-dev] Roadmap draft
In-Reply-To: <20071219223423.GX13357@solar.trillke>
References: <4762D21A.3090903@gmx.de> 
	<200712192249.43787.jacob@openend.se>
	<20071219223423.GX13357@solar.trillke>
Message-ID: <85b5c3130712191441i78c3bd68i8588c64894d8b324@mail.gmail.com>

On Dec 19, 2007 11:34 PM, holger krekel  wrote:
> Hi Jacob, Martijn, all,
>
> thanks for your advises and input! IMHO it makes sense to wait a bit with
> discussing release plans or strategies until after the tasks and their
> interaction are more settled and somewhat commonly agreed.  And until after
> we know a bit more on everyone's commitments and availabilities.
>
> Maybe Carl Friedrich or Armin could kick this off once they
> think it makes sense to discuss release plans or strategies?

Yes, imho Carl or Armin (or someone else from the core pypy team)
should lead this effort.

Ondrej


From hpk at trillke.net  Thu Dec 20 01:37:50 2007
From: hpk at trillke.net (holger krekel)
Date: Thu, 20 Dec 2007 01:37:50 +0100
Subject: [pypy-dev] Sprint in Leysin?
In-Reply-To: <20071219185052.GA24076@code0.codespeak.net>
References: <20071219185052.GA24076@code0.codespeak.net>
Message-ID: <20071220003750.GY13357@solar.trillke>

Hi Armin, 

On Wed, Dec 19, 2007 at 19:50 +0100, Armin Rigo wrote:
> Hi all!
> 
> Around the Gothenburg sprint, we mentioned the idea to hold a sprint in
> Leysin (Switzerland) again this winter.  We don't have the EU any more
> to pay us, but the Swiss Franc is now cheaper compared to the Euro :-)
>
> I checked with the "usual place", Chalet Ermina, and with my own
> schedule.  The best dates would be in January before the 26th;
> afterwards it becomes a bit harder.  If mid-January is too soon or
> otherwise too impossible for too many people I can check again for later
> in the winter, say in March (ski conditions are usually still good).
> 
> What do you think about it?

FWIW I can well imagine to go to Leysin for Skiing, 
py-test and PyPy and other hacking around mid January.  

best, 

holger


From niko at alum.mit.edu  Thu Dec 20 08:10:36 2007
From: niko at alum.mit.edu (Niko Matsakis)
Date: Thu, 20 Dec 2007 08:10:36 +0100
Subject: [pypy-dev] [pypy-sprint]  Sprint in Leysin?
In-Reply-To: <20071220003750.GY13357@solar.trillke>
References: <20071219185052.GA24076@code0.codespeak.net>
	<20071220003750.GY13357@solar.trillke>
Message-ID: 

>> Around the Gothenburg sprint, we mentioned the idea to hold a  
>> sprint in
>> Leysin (Switzerland) again this winter.  We don't have the EU any  
>> more
>> to pay us, but the Swiss Franc is now cheaper compared to the  
>> Euro :-)
>>
>> I checked with the "usual place", Chalet Ermina, and with my own
>> schedule.  The best dates would be in January before the 26th;
>> afterwards it becomes a bit harder.  If mid-January is too soon or
>> otherwise too impossible for too many people I can check again for  
>> later
>> in the winter, say in March (ski conditions are usually still good).
>>
>> What do you think about it?
>
> FWIW I can well imagine to go to Leysin for Skiing,
> py-test and PyPy and other hacking around mid January.

I would love to attend, but I will be out of the country until January  
17th (taking a trip to Egypt!).


Niko


From faassen at startifact.com  Thu Dec 20 09:22:27 2007
From: faassen at startifact.com (Martijn Faassen)
Date: Thu, 20 Dec 2007 09:22:27 +0100
Subject: [pypy-dev] Roadmap draft
In-Reply-To: <200712192249.43787.jacob@openend.se>
References: <4762D21A.3090903@gmx.de> 
	<200712192249.43787.jacob@openend.se>
Message-ID: 

Jacob Hall?n wrote:
> Thanks for the feedback Martijn, some comments below
[snip]
> The roadmap is part of a multi step process. After we get acceptance from 
> people in the project on where we want to go, the next step is outlining how 
> to get there. I hope that people will conclude that the best way to go about 
> things is to make a series of releases, but we will see. Releases take a lot 
> of effort and there is a balance to strike between producing and releasing.

Yes, I'm talking about a roadmap for the roadmap. :) Just making clear 
that the hard part is not so much in deciding what you would like to 
produce in the end, but in coming up with a way to get there. This will 
also be an iterative approach with adjustment along the road.

>> To get to a list of projected releases, you could restrict your
>> ambitions along various dimensions. For instance, you could focus on
>> only supporting one or a limited amount of backends for a first release.
>> Or you could defer erformance optimizations. Alternatively you could
>> restrict the amount of libraries you are going to implement (this is
>> already in the roadmap, but on the other hand the support for a GUI
>> toolkit is in there too). I'm sure other dimensions exist that I can't
>> even think of.
> 
> I think the roadmap is a set of restrictions. To be a viable replacement for 
> CPython, there is a single backend that needs to be supported. We are not 
> focusing on the JVM or .NET in this roadmap and we are not talking about 
> support for other languages. 

Support for other languages is indeed not in there - this is a roadmap 
for CPython replacement, after all.

Ah, wait, I see two end-goals in here, something I missed previously: 
cpython replacement and jython/ironpython replacement. I had at first 
thought everything in this directory was part of a single roadmap, but 
apparently it is not?

> For libraries, I think that is something that is 
> absolutely necessary in order to get traction among Python users. While it 
> would be nice if someone comes along and ports a GUI library, I don't think 
> we can count on that happening. It is in any case a task that belongs near 
> the end of a timeline with releases.

Yes, my point was that you don't have to wait until you cover a good 
portion of libraries yet. Before that's completed you can already do 
quite a few releases and get people contributing.

> So, the roadmap reflects our current understanding of what we have to do to 
> have a system that can attain critical mass and become a major Python 
> implementation, hopefully supplanting CPython one day. I am certain we will 
> have reason to revise the roadmap along the way, dropping some tasks and 
> introducing others. Unfortunately, there are a large number of things that 
> have to get done, but that is to a large extent the consequences of Python 
> being a fairly old and well established programming language.

I never doubted there was still a large amount of things to do. It's 
good that these things are being explicitly identified now.

Regards,

Martijn



From cfbolz at gmx.de  Thu Dec 20 09:27:52 2007
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Thu, 20 Dec 2007 09:27:52 +0100
Subject: [pypy-dev] [pypy-sprint] Sprint in Leysin?
In-Reply-To: <20071219185052.GA24076@code0.codespeak.net>
References: <20071219185052.GA24076@code0.codespeak.net>
Message-ID: <476A2788.8010809@gmx.de>

Hi Armin,

Armin Rigo wrote:
> Around the Gothenburg sprint, we mentioned the idea to hold a sprint in
> Leysin (Switzerland) again this winter.  We don't have the EU any more
> to pay us, but the Swiss Franc is now cheaper compared to the Euro :-)
> 
> I checked with the "usual place", Chalet Ermina, and with my own
> schedule.  The best dates would be in January before the 26th;
> afterwards it becomes a bit harder.  If mid-January is too soon or
> otherwise too impossible for too many people I can check again for later
> in the winter, say in March (ski conditions are usually still good).
> 
> What do you think about it?

We should think about how this interacts with Michael Leuschel's idea to 
do a paper sprint at one point in winter (probably in Leysin too). I 
personally wouldn't mind coming to a sprint in January, but on the other 
hand I would really like to do this paper sprint and probably couldn't 
go to two sprints that are close to each other.

Cheers,

Carl Friedrich


From faassen at startifact.com  Thu Dec 20 10:04:18 2007
From: faassen at startifact.com (Martijn Faassen)
Date: Thu, 20 Dec 2007 10:04:18 +0100
Subject: [pypy-dev] Roadmap draft
In-Reply-To: <4762D21A.3090903@gmx.de>
References: <4762D21A.3090903@gmx.de>
Message-ID: 

Hey,

The most important point I want to make is this one. The current 
discussion is about a roadmap towards CPython replacement (or other 
interpreter replacements). This is a *different* goal from having PyPy 
being useful in *some* production settings. The latter is a more modest 
goal. It also shifts the focus: instead of aiming for parity with 
CPython, you aim to be *better* than CPython at *some* things, while not 
having parity in other areas.

So, you could have an interpreter that is not yet a full replacement for 
CPython being very useful for some tasks. This is where my primarily 
interest lies right now: it'll take a while before I can use a 
PyPy-derived interpreter instead of CPython for many tasks, but I'm 
interested in using it for at least *some* tasks.

Being better at some things than existing interpreters in production 
will validate the project in the minds of many, and should increase the 
mindshare of PyPy tremendously and attract enough contributors to reach 
the final goal of being better at *everything*. I don't want to detract 
from that goal of parity with existing interpreters (and beyond). I 
don't want to take away from that. I just want to frame the discussion 
in a different light, and highlight other goals. You don't need parity 
in all respects in order to go beyond existing interpreters in some.

I'll first note one way in which PyPy is already better than existing 
interpreters: flexibility. Unfortunately this benefit by itself is not 
going to be very useful in production itself. The idea is to exploit 
this flexibility. Flexibility is a goal of the project, but it's only a 
means, not a goal, of a production-interpreter project.

As to the goal of being a CPython replacement, one important realisation 
is that you might in fact reach replacement of CPython through a 
completely other route than the one sketched out. Who is to say that a 
CPython replacement has to be run through a C compiler, after all? The 
only requirement is for it to run Python code. If that Python code runs 
on top of .NET or JVM, so be it, as long as it runs, right? Of course as 
an *end* goal you might want third-party library support, but you could 
get quite far as a replacement of CPython in other ways without covering 
those.

So, what intermediate goals could you set that would make PyPy better 
than other interpreters in production settings? These are the main 
routes that I can see right now:

You could aim for compliance with CPython (and library support) - but 
then actually replacing CPython is a goal you can't compete on soon! 
Your compliance will shine the most on other backends, like .NET or JVM, 
and the feature would be access to libraries on those platforms, so 
integration features would be the most important. Any performance or 
JIT-related task is less important on the near term, while integration 
tasks are most important.

You could make compliance less important and aim for performance. In 
this case you could complete with CPython right away, even if your 
compliance and library support isn't perfect yet. You might only support 
Python 2.4 features and implement a limited set of libraries, and 
limited extension facilities, and still attract people. Performance and 
JIT related tasks are the most important.

You could also target one specialist platform (some embedded 
architecture, or some dedicated VM architecture, like the Google Android 
platform). You could make PyPy work way better than any competition on 
that. (Multi)platform support beyond Linux, OS/X and Windows becomes way 
more important then.

What your initial focus is would influence which tasks you focus on 
first a lot. I think this is important to keep in mind during the 
roadmap discussions. I'd of course also be curious to find out which 
ones you're most interested in as initial goals. Saying "all of them, 
right now" is not good enough. :)

Regards,

Martijn



From holger at merlinux.de  Thu Dec 20 11:50:20 2007
From: holger at merlinux.de (holger krekel)
Date: Thu, 20 Dec 2007 11:50:20 +0100
Subject: [pypy-dev] Roadmap draft
In-Reply-To: 
References: <4762D21A.3090903@gmx.de> 
Message-ID: <20071220105020.GF13357@solar.trillke>

Dear Martijn, all, 

I am aware that you have initiated and participated in various 
successful open source communities and i know that you have experience 
and advises to share.  But the roadmap files are currently not 
about release planning or strategies and ASFAIK no active developer
has asked for a public discussion about such topics.  
I ask you and everybody to respect that.  If neccessary 
please only write brief mails. 

FWIW, i think i understand and share your main point that 
next-release goals do not neccessarily need to focus around 
a PyPy's CPython-replacing interpreter.   Btw, did you see that Anto 
has added his drafts of a "goal_jython_ironpython_replacement.txt"? 

best & cheers, 

holger

On Thu, Dec 20, 2007 at 10:04 +0100, Martijn Faassen wrote:
> Hey,
> 
> The most important point I want to make is this one. The current 
> discussion is about a roadmap towards CPython replacement (or other 
> interpreter replacements). This is a *different* goal from having PyPy 
> being useful in *some* production settings. The latter is a more modest 
> goal. It also shifts the focus: instead of aiming for parity with 
> CPython, you aim to be *better* than CPython at *some* things, while not 
> having parity in other areas.
> 
> So, you could have an interpreter that is not yet a full replacement for 
> CPython being very useful for some tasks. This is where my primarily 
> interest lies right now: it'll take a while before I can use a 
> PyPy-derived interpreter instead of CPython for many tasks, but I'm 
> interested in using it for at least *some* tasks.
> 
> Being better at some things than existing interpreters in production 
> will validate the project in the minds of many, and should increase the 
> mindshare of PyPy tremendously and attract enough contributors to reach 
> the final goal of being better at *everything*. I don't want to detract 
> from that goal of parity with existing interpreters (and beyond). I 
> don't want to take away from that. I just want to frame the discussion 
> in a different light, and highlight other goals. You don't need parity 
> in all respects in order to go beyond existing interpreters in some.
> 
> I'll first note one way in which PyPy is already better than existing 
> interpreters: flexibility. Unfortunately this benefit by itself is not 
> going to be very useful in production itself. The idea is to exploit 
> this flexibility. Flexibility is a goal of the project, but it's only a 
> means, not a goal, of a production-interpreter project.
> 
> As to the goal of being a CPython replacement, one important realisation 
> is that you might in fact reach replacement of CPython through a 
> completely other route than the one sketched out. Who is to say that a 
> CPython replacement has to be run through a C compiler, after all? The 
> only requirement is for it to run Python code. If that Python code runs 
> on top of .NET or JVM, so be it, as long as it runs, right? Of course as 
> an *end* goal you might want third-party library support, but you could 
> get quite far as a replacement of CPython in other ways without covering 
> those.
> 
> So, what intermediate goals could you set that would make PyPy better 
> than other interpreters in production settings? These are the main 
> routes that I can see right now:
> 
> You could aim for compliance with CPython (and library support) - but 
> then actually replacing CPython is a goal you can't compete on soon! 
> Your compliance will shine the most on other backends, like .NET or JVM, 
> and the feature would be access to libraries on those platforms, so 
> integration features would be the most important. Any performance or 
> JIT-related task is less important on the near term, while integration 
> tasks are most important.
> 
> You could make compliance less important and aim for performance. In 
> this case you could complete with CPython right away, even if your 
> compliance and library support isn't perfect yet. You might only support 
> Python 2.4 features and implement a limited set of libraries, and 
> limited extension facilities, and still attract people. Performance and 
> JIT related tasks are the most important.
> 
> You could also target one specialist platform (some embedded 
> architecture, or some dedicated VM architecture, like the Google Android 
> platform). You could make PyPy work way better than any competition on 
> that. (Multi)platform support beyond Linux, OS/X and Windows becomes way 
> more important then.
> 
> What your initial focus is would influence which tasks you focus on 
> first a lot. I think this is important to keep in mind during the 
> roadmap discussions. I'd of course also be curious to find out which 
> ones you're most interested in as initial goals. Saying "all of them, 
> right now" is not good enough. :)
> 
> Regards,
> 
> Martijn
> 
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
> 

-- 
merlinux GmbH       Steinbergstr. 42    31139 Hildesheim   
http://merlinux.de  tel +49 5121 20800 75 (fax 77) 


From holger at merlinux.de  Thu Dec 20 14:32:14 2007
From: holger at merlinux.de (holger krekel)
Date: Thu, 20 Dec 2007 14:32:14 +0100
Subject: [pypy-dev] Roadmap draft
In-Reply-To: <4762D21A.3090903@gmx.de>
References: <4762D21A.3090903@gmx.de>
Message-ID: <20071220133214.GN13357@solar.trillke>

Hi Carl Friedrich, all, 

On Fri, Dec 14, 2007 at 19:57 +0100, Carl Friedrich Bolz wrote:
> Just to inform you a bit: Several PyPy developers have sat together and 
> worked on a very rough roadmap for what tasks need to be done to make 
> PyPy a realistic replacement for CPython. The work is going on here:
> 
> https://codespeak.net/svn/pypy/extradoc/planning/roadmap/
> 
> We plan to work on this some more in the next days. As soon as it is in 
> a more finished state we will ask write a mail to pypy-dev again and ask 
> for general feedback.

As i mentioned to you on chat, i see many of the files in the
above directory as goals, coarse- or fine-grained and sometimes 
depending on other goals.  They can be used to construct roadmaps out 
of it which then should also include release plans etc - as it stands the
discussion can easily get confused there.  IOW, I'd like to
get to more clarity both for internal, project and outside
communication purposes.

best & cheers, 

holger


From cfbolz at gmx.de  Thu Dec 20 15:21:38 2007
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Thu, 20 Dec 2007 15:21:38 +0100
Subject: [pypy-dev] Roadmap draft
In-Reply-To: <20071220133214.GN13357@solar.trillke>
References: <4762D21A.3090903@gmx.de> <20071220133214.GN13357@solar.trillke>
Message-ID: <348899050712200621h1d9584afi38e1144bfa3dd2b1@mail.gmail.com>

Hi Holger,

2007/12/20, holger krekel :
> Hi Carl Friedrich, all,
>
> On Fri, Dec 14, 2007 at 19:57 +0100, Carl Friedrich Bolz wrote:
> > Just to inform you a bit: Several PyPy developers have sat together and
> > worked on a very rough roadmap for what tasks need to be done to make
> > PyPy a realistic replacement for CPython. The work is going on here:
> >
> > https://codespeak.net/svn/pypy/extradoc/planning/roadmap/
> >
> > We plan to work on this some more in the next days. As soon as it is in
> > a more finished state we will ask write a mail to pypy-dev again and ask
> > for general feedback.
>
> As i mentioned to you on chat, i see many of the files in the
> above directory as goals, coarse- or fine-grained and sometimes
> depending on other goals.  They can be used to construct roadmaps out
> of it which then should also include release plans etc - as it stands the
> discussion can easily get confused there.  IOW, I'd like to
> get to more clarity both for internal, project and outside
> communication purposes.

Could you be a bit more specific what your point is, e.g. which
specific files you mean? I agree that not everything is clear yet, but
I don't think that things are completely confusing.

To restate: I think a task is a concrete thing to do, including steps
etc. while a goal is a largeish collection of tasks. Right now I think
we should collect goals and tasks that we think we can manage in the
mid-term. Exactly which of the tasks should be made into releases is
an orthogonal issue, IMO. Maybe we could add a new kind of file
release-XXX.txt that points to various tasks? On the other hand I am
not sure it makes sense to plan more than one release ahead.

To say a bit about the next release: My opinion is (and I think others
agreed during the Gothenburg sprint, see
http://morepypy.blogspot.com/2007/11/sprint-discussions-releases-testing.html
) that the next release should be really mostly a compliance and
testing release. Which means that to make the release we should set up
better test infrastructure and test "real-world-applications" on
PyPy's Python interpreter, as well as write some mid-sized apps for
our special features. In a sense that would be a rather boring release
with mostly only many incremental features but on the other hand with
a lot of stability improvements. How does this sound?

Cheers,

Carl Friedrich


From holger at merlinux.de  Thu Dec 20 17:16:22 2007
From: holger at merlinux.de (holger krekel)
Date: Thu, 20 Dec 2007 17:16:22 +0100
Subject: [pypy-dev] Roadmap draft
In-Reply-To: <348899050712200621h1d9584afi38e1144bfa3dd2b1@mail.gmail.com>
References: <4762D21A.3090903@gmx.de> <20071220133214.GN13357@solar.trillke>
	<348899050712200621h1d9584afi38e1144bfa3dd2b1@mail.gmail.com>
Message-ID: <20071220161622.GR13357@solar.trillke>

Hi CF, 

On Thu, Dec 20, 2007 at 15:21 +0100, Carl Friedrich Bolz wrote:
> 2007/12/20, holger krekel :
> > Hi Carl Friedrich, all,
> >
> > On Fri, Dec 14, 2007 at 19:57 +0100, Carl Friedrich Bolz wrote:
> > > Just to inform you a bit: Several PyPy developers have sat together and
> > > worked on a very rough roadmap for what tasks need to be done to make
> > > PyPy a realistic replacement for CPython. The work is going on here:
> > >
> > > https://codespeak.net/svn/pypy/extradoc/planning/roadmap/
> > >
> > > We plan to work on this some more in the next days. As soon as it is in
> > > a more finished state we will ask write a mail to pypy-dev again and ask
> > > for general feedback.
> >
> > As i mentioned to you on chat, i see many of the files in the
> > above directory as goals, coarse- or fine-grained and sometimes
> > depending on other goals.  They can be used to construct roadmaps out
> > of it which then should also include release plans etc - as it stands the
> > discussion can easily get confused there.  IOW, I'd like to
> > get to more clarity both for internal, project and outside
> > communication purposes.
> 
> Could you be a bit more specific what your point is, e.g. which
> specific files you mean?  I agree that not everything is clear yet, but
> I don't think that things are completely confusing.

I referred to the notion of a "roadmap" in that it usually contains 
releases, milestones and concrete plans for such.   Currently, 
i think we are in the phase of (individually) collecting goals/tasks. 
Next is to complete, settle and somewhat agree on them if you ask me. 

Mentioning too much the "roadmap" word at this point IMO can contribute
to raise the discussion to a wrong (and possibly confusing) level. 
i didn't mean to imply "completely confusing", btw. 

> To restate: I think a task is a concrete thing to do, including steps
> etc. while a goal is a largeish collection of tasks.  

I am trying to talk about the concrete files/contents and their foreseeable 
future - not about possible definitions of "goal" and "tasks". 

There I see files following the "status/todo/expected outcome" structure
to contain relatively concrete tasks in their "todo" sections, but
representing goals itself, e.g. "pervastive testing" or "oo bytecode compiler".  
Others, like the current "have pypy provide the CPython API for existing 
C-Extensions" also sound like goals to me, not concrete steps or tasks. 

Anyway, maybe we can at this point just agree to disagree on the importance 
of having a categorization of "goals" and "tasks"? 

> Right now I think
> we should collect goals and tasks that we think we can manage in the
> mid-term.  Exactly which of the tasks should be made into releases is
> an orthogonal issue, IMO. 

fine with me. 

best & cheers, 

holger


From tismer at stackless.com  Fri Dec 21 01:37:15 2007
From: tismer at stackless.com (Christian Tismer)
Date: Thu, 20 Dec 2007 16:37:15 -0800
Subject: [pypy-dev] Sprint in Leysin?
In-Reply-To: <20071219185052.GA24076@code0.codespeak.net>
References: <20071219185052.GA24076@code0.codespeak.net>
Message-ID: <476B0ABB.8050007@stackless.com>

Armin Rigo wrote:
> Hi all!
> 
> Around the Gothenburg sprint, we mentioned the idea to hold a sprint in
> Leysin (Switzerland) again this winter.  We don't have the EU any more
> to pay us, but the Swiss Franc is now cheaper compared to the Euro :-)
> 
> I checked with the "usual place", Chalet Ermina, and with my own
> schedule.  The best dates would be in January before the 26th;
> afterwards it becomes a bit harder.  If mid-January is too soon or
> otherwise too impossible for too many people I can check again for later
> in the winter, say in March (ski conditions are usually still good).
> 
> What do you think about it?

Not sure yet, but it is very likely that they want me to continue
on Psyco until we make a release. So I might be away early January
for another couple of weeks.

ciao - chris

-- 
Christian Tismer             :^)   
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/


From pedronis at openend.se  Fri Dec 21 12:25:33 2007
From: pedronis at openend.se (Samuele Pedroni)
Date: Fri, 21 Dec 2007 12:25:33 +0100
Subject: [pypy-dev] [pypy-sprint] Sprint in Leysin?
In-Reply-To: <476A2788.8010809@gmx.de>
References: <20071219185052.GA24076@code0.codespeak.net>
	<476A2788.8010809@gmx.de>
Message-ID: <476BA2AD.2090304@openend.se>

Carl Friedrich Bolz wrote:
> Hi Armin,
>
> Armin Rigo wrote:
>   
>> Around the Gothenburg sprint, we mentioned the idea to hold a sprint in
>> Leysin (Switzerland) again this winter.  We don't have the EU any more
>> to pay us, but the Swiss Franc is now cheaper compared to the Euro :-)
>>
>> I checked with the "usual place", Chalet Ermina, and with my own
>> schedule.  The best dates would be in January before the 26th;
>> afterwards it becomes a bit harder.  If mid-January is too soon or
>> otherwise too impossible for too many people I can check again for later
>> in the winter, say in March (ski conditions are usually still good).
>>
>> What do you think about it?
>>     
>
> We should think about how this interacts with Michael Leuschel's idea to 
> do a paper sprint at one point in winter (probably in Leysin too). I 
> personally wouldn't mind coming to a sprint in January, but on the other 
> hand I would really like to do this paper sprint and probably couldn't 
> go to two sprints that are close to each other.
>   
As I said on irc is very unlikely I can make to a sprint in January.




From fijall at gmail.com  Sun Dec 23 12:59:39 2007
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Sun, 23 Dec 2007 12:59:39 +0100
Subject: [pypy-dev] [pypy-sprint] Sprint in Leysin?
In-Reply-To: <476BA2AD.2090304@openend.se>
References: <20071219185052.GA24076@code0.codespeak.net>
	<476A2788.8010809@gmx.de> <476BA2AD.2090304@openend.se>
Message-ID: <693bc9ab0712230359g5a5fcce2k64985cb5b7b2a528@mail.gmail.com>

Hey. It's hard to tell right now, but I would love to make sprint in Leysin
(not sure if mid-January is feasible for me though)

On Dec 21, 2007 12:25 PM, Samuele Pedroni  wrote:

> Carl Friedrich Bolz wrote:
> > Hi Armin,
> >
> > Armin Rigo wrote:
> >
> >> Around the Gothenburg sprint, we mentioned the idea to hold a sprint in
> >> Leysin (Switzerland) again this winter.  We don't have the EU any more
> >> to pay us, but the Swiss Franc is now cheaper compared to the Euro :-)
> >>
> >> I checked with the "usual place", Chalet Ermina, and with my own
> >> schedule.  The best dates would be in January before the 26th;
> >> afterwards it becomes a bit harder.  If mid-January is too soon or
> >> otherwise too impossible for too many people I can check again for
> later
> >> in the winter, say in March (ski conditions are usually still good).
> >>
> >> What do you think about it?
> >>
> >
> > We should think about how this interacts with Michael Leuschel's idea to
> > do a paper sprint at one point in winter (probably in Leysin too). I
> > personally wouldn't mind coming to a sprint in January, but on the other
> > hand I would really like to do this paper sprint and probably couldn't
> > go to two sprints that are close to each other.
> >
> As I said on irc is very unlikely I can make to a sprint in January.
>
>
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From gh at ghaering.de  Tue Dec 25 18:15:24 2007
From: gh at ghaering.de (=?ISO-8859-1?Q?Gerhard_H=E4ring?=)
Date: Tue, 25 Dec 2007 18:15:24 +0100
Subject: [pypy-dev] Preliminary ctypes-based pysqlite implementation
Message-ID: <47713AAC.4080803@ghaering.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear pypy developers,

A few weeks ago, I've read with great interest the thread "missing
things for making PyPy "production" ready (for some value of
production)" on this list. That's when I decided to help with the
standard library and the module I'm most familiar with, the "sqlite3"
module based on pysqlite.

Mercurial mirror here: http://hg.ghaering.de/pysqlite3/

Download with "hg clone http://hg.ghaering.de/pysqlite3/" if Mercurial
installed.

This is in a rough pre-alpha state now so that one set of pysqlite's
unit tests pass (the DB-API ones). It's really rough code I'd not
normally release to the public, but xorAxAx (Alexander Schremmer) on
#pypy said it would perhaps motivate people to improve PyPy's ctypes
implementation.

I didn't get PyPy to compile correctly (*), but trying to import the
"pysqlite3 pre-alpha" led an error about c_void_p() not working. This
demonstrates:

$ pypy/bin/py.py --withmod-_ffi
>>>> from ctypes import *
>>>> ptr = c_void_p()
Traceback (application-level):
  File "", line 1 in 
    ptr = c_void_p()
TypeError: __init__() takes exactly 2 arguments (1 given)
>>>> ptr = c_void_p()

This is probably just one of the issues that hinder using the new
pysqlite with PyPy. It would be extra sweet if one of you could hack
on ctypes to make it more compatible with the CPython one, but patches
to my code to make it work with PyPy's ctypes would also be welcome.

I'll give experimenting with PyPy/ctypes another shot myself when the
svn version starts to compile (err. translate?!) again. The version on
top of CPython is too slow for such experiments.

Cheers,

- -- Gerhard

(*) "python translate.py --run targetpypystandalone.py --withmod-_ffi"
crashes with current pypy svn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHcTqsdIO4ozGCH14RArbyAKCNF5AGhSBs/taqxE+WZDl6xlmjDgCeMK4b
Gn6F7n3Rhn170xnXybnNFEk=
=AvIW
-----END PGP SIGNATURE-----


From cfbolz at gmx.de  Tue Dec 25 20:09:23 2007
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Tue, 25 Dec 2007 20:09:23 +0100
Subject: [pypy-dev] Preliminary ctypes-based pysqlite implementation
In-Reply-To: <47713AAC.4080803@ghaering.de>
References: <47713AAC.4080803@ghaering.de>
Message-ID: <47715563.6020507@gmx.de>

Hi Gerhard,

Gerhard H?ring wrote:
 > A few weeks ago, I've read with great interest the thread "missing
 > things for making PyPy "production" ready (for some value of
 > production)" on this list. That's when I decided to help with the
 > standard library and the module I'm most familiar with, the "sqlite3"
 > module based on pysqlite.
 >
 > Mercurial mirror here: http://hg.ghaering.de/pysqlite3/
 >
 > Download with "hg clone http://hg.ghaering.de/pysqlite3/" if Mercurial
 > installed.
 >
 > This is in a rough pre-alpha state now so that one set of pysqlite's
 > unit tests pass (the DB-API ones). It's really rough code I'd not
 > normally release to the public, but xorAxAx (Alexander Schremmer) on
 > #pypy said it would perhaps motivate people to improve PyPy's ctypes
 > implementation.

Cool, cool, cool! You probably won't have any luck to use this with
PyPy, because our ctypes implementation is extremely rudimentary (e.g.
it imports and not much else).  However, I hope to work on it a bit in
the next weeks, so making the sqlite wrapper work is a nice first
target. Thank you!
 >
 > I didn't get PyPy to compile correctly (*), but trying to import the
 > "pysqlite3 pre-alpha" led an error about c_void_p() not working. This
 > demonstrates:
 >
 > $ pypy/bin/py.py --withmod-_ffi
 >>>>> from ctypes import *
 >>>>> ptr = c_void_p()
 > Traceback (application-level):
 >   File "", line 1 in 
 >     ptr = c_void_p()
 > TypeError: __init__() takes exactly 2 arguments (1 given)
 >>>>> ptr = c_void_p()
 >
 > This is probably just one of the issues that hinder using the new
 > pysqlite with PyPy. It would be extra sweet if one of you could hack
 > on ctypes to make it more compatible with the CPython one, but patches
 > to my code to make it work with PyPy's ctypes would also be welcome.

I think our goal is to be as compatible to the ctypes one as possible.
As I said above, I am not surprised that nothing works yet :-).

Merry Christmas,

Carl Friedrich


From arigo at tunes.org  Mon Dec 31 17:35:36 2007
From: arigo at tunes.org (Armin Rigo)
Date: Mon, 31 Dec 2007 17:35:36 +0100
Subject: [pypy-dev] PyPy Leysin Winter Sprint (12-19th January 2008)
Message-ID: <20071231163536.GA11745@code0.codespeak.net>

=====================================================================
         PyPy Leysin Winter Sprint (12-19th January 2008)
=====================================================================
..                             image:: http://www.ermina.ch/002.JPG

The next PyPy sprint will be in Leysin, Switzerland, for the
fifth time.  This is a fully public sprint: newcomers and
topics other than those proposed below are welcome.

------------------------------
Goals and topics of the sprint
------------------------------

* Like previous winters, the main side goal is to have fun in winter
  sports :-) We can take a couple of days off for ski; at this time of
  year, ski days end before 4pm, which still leaves plenty of time
  to recover (er, I mean hack).

* the overall idea of the sprint is to continue working on making PyPy ready
  for general use.  A few more specific tasks:

  - app-level ctypes: getting to a basically usable point
    would be really nice.

  - JIT: there is a long-standing timeshifter refactoring,
    towards making the JIT be more interpreter-like.  Starting
    it during the sprint might be a good way to share some of
    the knowledge of how the JIT really works.  Alternatively,
    we can work on supporting ootype in the timeshifter.

  - Testing: e.g. we run various nightly test runs but the
    results are not summarized in a single page yet.

  - LLVM: llvm 2 is now at version 2.1 and nicely stable
    again.  Our llvm backend has improved in the last few
    months, but refactoring it together with the genc backend
    to share code more directly would be a nice task.

* We are open to all sorts of other tasks during the sprint, just
  propose something.

-----------------------
Location & Accomodation
-----------------------

Leysin, Switzerland, "same place as before".  Let me refresh your
memory: both the sprint venue and the lodging will be in a very spacious
pair of chalets built specifically for bed & breakfast:
http://www.ermina.ch/.  The place has a good ADSL Internet connexion
with wireless installed.  You can of course arrange your own
lodging anywhere (so long as you are in Leysin, you cannot be more than a
15 minute walk away from the sprint venue), but I definitely recommend
lodging there too -- you won't find a better view anywhere else (though you
probably won't get much worse ones easily, either :-)

I made pre-reservations in the Chalet, so please *confirm* quickly that
you are coming so that we can adjust the reservations as appropriate.  The
rate so far has been around 60 CHF a night all included in 2-person rooms,
with breakfast.  There are larger rooms too (less expensive) and maybe the
possibility to get a single room if you really want to.

Please register by svn:

  http://codespeak.net/svn/pypy/extradoc/sprintinfo/leysin-winter-2008/people.txt

or on the pypy-sprint mailing list if you do not yet have check-in rights:

  http://codespeak.net/mailman/listinfo/pypy-sprint

You need a Swiss-to-(insert country here) power adapter.  There will be
some Swiss-to-EU adapters around - bring a EU-format power strip if you
have one.

-----------
Exact times
-----------

Officially, 12th-19th January 2008.  Both dates are flexible, you can
arrive or leave earlier or later.  We will give introductions and
tutorials depending on who needs them, either on the 13th or the 14th.


-+-

Carl Friedrich, Armin


From paul.degrandis at gmail.com  Mon Dec 31 18:14:05 2007
From: paul.degrandis at gmail.com (Paul deGrandis)
Date: Mon, 31 Dec 2007 12:14:05 -0500
Subject: [pypy-dev] JVM integration
Message-ID: <9c0bb8a00712310914k17265838w26666b09b29fce0d@mail.gmail.com>

Anto, Niko, and All,

I have begun working on PyPy again and am starting on jvm integration.
 After talking briefly with Carl on IRC, I looked at the code in CLI.

I have a few questions:
It appears as though the general approach is to identify entry points
into CLI code (via dlls), use reflection, and make calls.  This is
also later used to make (r)python modules into dlls themselves
(allowing for bidirectional integration).  Is this correct?  Also, how
does the notion of PythonNet play into this (ie: where do you get the
CLR module from)?
If this is not the current approach, is there a document that someone
can point me to that talks about this in further detail?
Lastly, as work for integration on the JVM begins, a larger goal is
the generalize the approach.  Has any work been done in the CLI/CLR to
generalize the approach so far?

Regards,
Paul