[pypy-dev] Re: CLI code generation
holger krekel [EMAIL PROTECTED] writes: Re-Hi! On Mon, Mar 20, 2006 at 21:53 +0100, Armin Rigo wrote: On Mon, Mar 20, 2006 at 09:43:26PM +0100, holger krekel wrote: Good point which i indeed had forgotten about. Also regarding GCs it is higher level than C. So probably we need oo + part-of-lltypes :) You keep inserting lltype here -- probably just out of our well-established habit of loving confusion :-) ootype contains lltype-ish aspects of its own, because all OO target languages that we have in mind need these aspects. There is nothing special about IL -- certainly not anything that would make it different than C#, as far as I can tell. didn't intend to doubt the latter. But I guess i need to refresh/improve my knowledge of ootypes. A particular, relevant fact here is that the ootypesystem and the lltypesystem are not disjoint -- they share at least the Primitives, which is to say the representations of integers, floats, etc. Cheers, mwh -- 112. Computer Science is embarrassed by the computer. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] Re: CLI code generation
holger krekel [EMAIL PROTECTED] writes: Re-Hi! On Mon, Mar 20, 2006 at 21:53 +0100, Armin Rigo wrote: On Mon, Mar 20, 2006 at 09:43:26PM +0100, holger krekel wrote: Good point which i indeed had forgotten about. Also regarding GCs it is higher level than C. So probably we need oo + part-of-lltypes :) You keep inserting lltype here -- probably just out of our well-established habit of loving confusion :-) ootype contains lltype-ish aspects of its own, because all OO target languages that we have in mind need these aspects. There is nothing special about IL -- certainly not anything that would make it different than C#, as far as I can tell. didn't intend to doubt the latter. But I guess i need to refresh/improve my knowledge of ootypes. A particular, relevant fact here is that the ootypesystem and the lltypesystem are not disjoint -- they share at least the Primitives, which is to say the representations of integers, floats, etc. Hi Michael, Does the ootypesystem has high level representations of lists and dicts yet? Would that perhaps be a good thing for me to try to implement as a way of helping out? Cheers, Ben Cheers, mwh -- 112. Computer Science is embarrassed by the computer. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
[pypy-dev] Re: suggestion of next pypy-sync meeting topics
[EMAIL PROTECTED] (holger krekel) writes: Hi all, here are suggestions for the next pypy-sync topics. Please correct/comment if i missed information (i was busy and around in the US the last weeks). - status of Tokyo Sprint planning and content announcement? details? - planning the next releases and their content (at least start the discussion) The plan is for 0.9 in May sometime right? - everyone: stating blockers and your perceiption of main problems/challenges with current development It hurts my head? :) - publishing (some of) our Translation papers at a non-python conference: where/when what is possible for this year? who goes for it? Well, as always it sounds like a good idea... Maybe it makes sense to go for such a collection and pre-dicussion of issues before each pypy-sync meeting? Well, the above is certainly more than 30 minutes worth of discussion starting from zero. Who is going to moderate it btw? Me. I am somewhat reluctant (because of over-busy-ness) to do it this or the next week but could do it afterwards i think. Good, because I am on holiday next week :) feedback welcome - i don't mind discussion here but i think we should nevertheless go for conclusions at the pypy-sync meeting because it's hard to reach consensus via email :) Yup. Cheers, mwh -- Guido (like us!) is a bit schizophrenic here: he wants to be a benevolent dictator, but also wants to treat people like grownups. This probably worked better before Python got a large American audience 0.9 wink. -- Tim Peters, 10 Feb 2000 ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] Re: CLI code generation
Hi Ben [EMAIL PROTECTED] wrote: Does the ootypesystem has high level representations of lists and dicts yet? Would that perhaps be a good thing for me to try to implement as a way of helping out? No, it doesn't have them, yet. But the general idea is to delegate completely to the host language here, ie represent RPython lists and dicts with corresponding collections from the host language. There will be nothing like the rdict and rlist implementations that the lltypesystem uses. I'm not too sure how specifically this delegation should be done (maybe Samuele can say something about it), this is one of the last open issues for the ootypesystem. But I'm planning to look into this a bit before the end of the week and make e.g. at least tuples work for ootypes and the Squeak backend. As I will have much less time for PyPy after this week, maybe you can then take over and look into dicts and lists for ootype? I'm not sure how realistic it is to expect you to start from scratch here without any groundwork already done for ootype collections. Cheers Nik ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] Re: CLI code generation
Niklaus Haldimann [EMAIL PROTECTED] wrote on 21/03/2006 10:35:44: Hi Ben [EMAIL PROTECTED] wrote: Does the ootypesystem has high level representations of lists and dicts yet? Would that perhaps be a good thing for me to try to implement as a way of helping out? No, it doesn't have them, yet. But the general idea is to delegate completely to the host language here, ie represent RPython lists and dicts with corresponding collections from the host language. There will be nothing like the rdict and rlist implementations that the lltypesystem uses. I'm not too sure how specifically this delegation should be done (maybe Samuele can say something about it), this is one of the last open issues for the ootypesystem. But I'm planning to look into this a bit before the end of the week and make e.g. at least tuples work for ootypes and the Squeak backend. As I will have much less time for PyPy after this week, maybe you can then take over and look into dicts and lists for ootype? I'm not sure how realistic it is to expect you to start from scratch here without any groundwork already done for ootype collections. Thanks Nik. At most I only have a few hours a week to spend on PyPy, so I am looking for something relatively easy to get going on. I'll leave the lists and dicts to you then, if you already have a idea of how you are going to do it. Cheers, Ben Cheers Nik ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] Re: suggestion of next pypy-sync meeting topics
On Tue, Mar 21, 2006 at 09:44 +, Michael Hudson wrote: [EMAIL PROTECTED] (holger krekel) writes: here are suggestions for the next pypy-sync topics. Please correct/comment if i missed information (i was busy and around in the US the last weeks). - status of Tokyo Sprint planning and content announcement? details? - planning the next releases and their content (at least start the discussion) The plan is for 0.9 in May sometime right? Yes, that was mentioned sometime and i think it's a good idea. I guess it should contain many things stackless (WP07 in EU mumble jumble), shouldn't it? - everyone: stating blockers and your perceiption of main problems/challenges with current development It hurts my head? :) ah, so no news on that front. But more concretely i'd like to know in some detail what the status and plans are on: - GC integration - stackless/co-routines/tasklets (including pickling) - JIT efforts - Logic programming efforts (Workpackage 9 status) - rctypes and RPython compiler tool and get an idea of who intends to work on what next with what goal. - publishing (some of) our Translation papers at a non-python conference: where/when what is possible for this year? who goes for it? Well, as always it sounds like a good idea... We really have material that is almost there - i just think we lack the focus to actually go for one of these conferences in due time. Of course they still require work but compared to - say - December 2005 it's not a huge effort anymore, i'd say. Maybe it makes sense to go for such a collection and pre-dicussion of issues before each pypy-sync meeting? Well, the above is certainly more than 30 minutes worth of discussion starting from zero. I suggest to go for determining the status and maybe conclude on steps anyway. Who is going to moderate it btw? Me. great :) holger ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
[pypy-dev] Re: [Edu-sig] Properties use case
Douglas Blank just sent this to edu-sig. I want to use PyPy to control Robots. Just think of the demos we could make! :-) Laura In a message of Tue, 21 Mar 2006 12:58:55 EST, Douglas S. Blank writes: On Tue, 2006-03-21 at 11:57 -0500, Arthur wrote: [snip] I am of course thinking whether I have been knee-jerk in bringing Numer ic into play as a fundamental tool for my application. Which I why I then move on to trying to get serious about gaining some profiling skills. Gain some intelligence about the trade-offs of doing the kind of simple linear algebra my application requires in pure Python, v ersus what I may gaining by the creepy calls to laplack. Judgment calls need to be made in the end, but I take them seriously en ough to want them to be informed judgment calls. I've been wrestling with these issues. I've built a Python robotics 2D simulator in 99% Python, 1% Numeric. It works amazingly well: fast enough and realistic enough to do the job. The robot can have sonar, IR, and bumpers; lights, and light bulbs; a 2D camera with pan-zoom, and a gripper to pick up things. The world has some simple physics (bump a puck head-on and it will slide, with some friction). Then I extended it to be a 3D simulator. Still, amazingly, fast enough and realistic enough to do the job. On the one hand, I like all of the source code to be accessible to the student. We say that it is Pythons all the way down. And that also makes it portable. But on the other hand, it has to run fast enough. We are able to do it all in Python, expect for the nitty gritty vision and image processing code, which we use SWIG and C++. I did some profiling, and was surprised at where some of the time was spent. (This simulator is also controlled over sockets, so I had some additional items to speed up). But, was able to refactor some, and get some very substantial speedup, just in the Python portion. castRay() is still the most expensive bit in Python. I am also looking at IronPython for .NET and Mono, and am wondering how much I can get in one layer (without going to C/C++) and how fast it will be... Here are some pictures: http://pyrorobotics.org/?page=The_20Pyrobot_20Simulator -Doug No conclusions as yet. Art -- Douglas S. Blank Computer Science Assistant ProfessorBryn Mawr College (610)526-6501 http://cs.brynmawr.edu/~dblank ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
[pypy-dev] First version of the CLI backend checked in
Hi, I've just checked in the first version of the CLI backend; for now I've checked it in a branch located at http://codespeak.net/svn/user/antocuni/pypy-antocuni/ At the moment I've tested it only with mono under linux; for running the tests you need to have ilasm and mono in your path; the IL code is generated even if mono is not installed and can be found in /tmp/usession-*. Comments are welcome, ciao Anto ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] CLI code generation
Samuele Pedroni wrote: Carl Friedrich Bolz wrote: Will the .NET backend use the ootypesystem (which is what gensqueak uses) it should use it but as it is, I think the ootypesystem is a bit too lax type-wise, so the rtypeing of it can get away skipping casts (this is mostly because so far its evolution has been driven by gensqueak), basically the casts in ootype.py should not be noop but switch between type-restricted views on the same object. this has been addressed now. ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
