From ajsiegel at optonline.net Sat Nov 4 01:42:06 2006 From: ajsiegel at optonline.net (Arthur) Date: Fri, 03 Nov 2006 19:42:06 -0500 Subject: [Edu-sig] Vpython 4.0 Message-ID: <454BE1DE.5050007@optonline.com> Making a long story as short as I can: Taking on the project of getting vpython to numpy compatibility (think I got there) brought me for the first time to a serious look at vpython 4.0 beta, which I had been avoiding, knowing it was buggy. Bugs, aside - turns out it is a major step forward, implementing transparency, texturing, advanced lighting, among other cool features - including some undocumented features that are intended to make vpython accessible to other GUI toolkits (from what I gather). Anybody interested might run the texture_and_lighting.py demo to get a feel for some of the new capabilities. Very cool. The only deal killing bug seems to be the one related to mouse.getclick() crashes, on Windows. So I thought I'd have a look, getting quickly way over my C++ head, finding that a mouse click event involved code that included shared pointers, signals and slots, threads,and the direct manipulation of the Python GIL. Way over my C++ head. I tried to follow the code and on a gander decided to see what would happen if I cut out the direct Python gil manipulation, having some clue/instinct that there was some conflict between that and what the boost::shared_ptr library was doing in managing object life cycles. And with that one change (simple changing a call from "py_pop" to "pop" to short-circuit going into the gil code), the demo that was consistently crashing, the diople.py demo, now seems stable Which of course seems too good to be true, because presumably Jonathan Brandmeyer, the CS student author of this, had some specific reasons to be messing with the Python gil, and I don't know what I may be breaking, on what platforms, by my fix, if it is in fact a fix at all. Or else I'm a genius, or lucky, or something. Anybody willing to jump in here, to any extent, to have a look see? Art From ajsiegel at optonline.net Sat Nov 4 16:15:45 2006 From: ajsiegel at optonline.net (Arthur) Date: Sat, 04 Nov 2006 10:15:45 -0500 Subject: [Edu-sig] Vpython 4.0 In-Reply-To: <454BE1DE.5050007@optonline.com> References: <454BE1DE.5050007@optonline.com> Message-ID: <454CAEA1.3070809@optonline.com> Arthur wrote: >...including some undocumented features that are intended to make vpython >accessible to other GUI toolkits (from what I gather). > > Looking closer, what Jonathan has done is expose the "display_kernel" functionality to Python. It is the same display_kernel functionality that is inherited and specialized in the C++ code to create the functioning gtk and native Windows displays. It appears to me that the idea is that one should be able to specialize other windowing environments - say wxPython - by sub-classing from "display_kernel" *in Python*. Which sounds to me a clever way to go, if it is in fact workable. Dethe???. Art From delza at livingcode.org Sat Nov 4 19:13:54 2006 From: delza at livingcode.org (Dethe Elza) Date: Sat, 4 Nov 2006 10:13:54 -0800 Subject: [Edu-sig] Vpython 4.0 In-Reply-To: <454CAEA1.3070809@optonline.com> References: <454BE1DE.5050007@optonline.com> <454CAEA1.3070809@optonline.com> Message-ID: On 4-Nov-06, at 7:15 AM, Arthur wrote: > Looking closer, what Jonathan has done is expose the "display_kernel" > functionality to Python. It is the same display_kernel functionality > that is inherited and specialized in the C++ code to create the > functioning gtk and native Windows displays. It appears to me > that the > idea is that one should be able to specialize other windowing > environments - say wxPython - by sub-classing from > "display_kernel" *in > Python*. Which sounds to me a clever way to go, if it is in fact > workable. > > Dethe???. Hi Art, I've been following your VPython adventures with interest, but am pretty tied up right now (article draft overdue for IBM and a big release coming at work). On OS X the 4.0 beta won't even finish configure, much less build. checking for GTK... configure: error: gtkglextmm 1.2, pangoft2, glibmm-2.4, and pangomm-1.4 libglademm-2.4 are required on Unix-like systems I've tried to get these installed via fink, but no luck so far. Admittedly, I haven't put a lot of time into it yet, but I have taken a few stabs. If I can get it to build, I'd happily work on getting it working. I get frustrated when I'm stuck in the configure stage. --Dethe Young children play in a way that is strikingly similar to the way scientists work --Busytown News From ajsiegel at optonline.net Sun Nov 5 14:42:50 2006 From: ajsiegel at optonline.net (Arthur) Date: Sun, 05 Nov 2006 08:42:50 -0500 Subject: [Edu-sig] Vpython 4.0 In-Reply-To: References: <454BE1DE.5050007@optonline.com> <454CAEA1.3070809@optonline.com> Message-ID: <454DEA5A.80106@optonline.com> Dethe Elza wrote: > Hi Art, > > I've been following your VPython adventures with interest, but am > pretty tied up right now (article draft overdue for IBM and a big > release coming at work). On OS X the 4.0 beta won't even finish > configure, much less build. Yeah, fitting this kind of stuff in can be tough. I had been traveling overseas alot over the last few weeks, and getting some grounding in the Vpython C++ code and working on the numpy compatibility issue (which, as opposed to the issues related to the wndowing code, is a pretty straightforward matter) was a perfect way to kill time on flights and airport layovers. > > checking for GTK... configure: error: gtkglextmm 1.2, pangoft2, > glibmm-2.4, and pangomm-1.4 libglademm-2.4 are required on Unix-like > systems > Yeah, all that just to get the GTK++ windowing. Ultimately there should be an option to build just as far as the display_kernel, which would make all these dependencies go away. Though one still needs to deal with the Boost dependencies, which I don't think ./configure checks for. In fact VPython4.xxx extends the boost dependencies beyong Boost.Python, and into the Boost.Threading library. Debian/ubuntu has binary distributions of the boost libraries which install painlessly. Thankfully, because understanding the boost native build and install system can be painful. I have spent enough hunt and peck time with it over the last few weeks though, that I think I finally have the issues under some control. And I do see that Boost.build does recognize the use of the darwin toolset as a build option, so the dependency on it should not be a barrier to a native OS X distribution. As I see it, Boost is pretty major stuff, and certainly don't think it reasonable to consider vpython's dependeny on it as a deal killer in any way, beyond it being a deal killer for inclusion in the Python standard library, particularly once the dependencies extend beyond Boost.Python. That disappoints me some, but probably saves me a losing battle. One dependency decision that Jonathan made with which I think I disagree is that of using the sigc++ libraries. It is part of the GTK toolchain, and creates build complications on Windows, and I suspect it will do so on OS X native, as well. In fact Boost.Signals and sigc++ have similar functionality and I believe there is a viable alternative to move to that, and thereby limit the overall dependencies to the Boost libraries. The issue might also go away, because I see that the C++ authorities are looking at combining the best of the sigc++ and Boost.Signals ideas and make it part of the C++ standard library. Was kind of looking for a Winter project, and if I want to get to the next stage of sophistication with PyGeo's possiblities I probably need to become a vpython guru. We'll see how far I get. But so far, its a learning curve I am enjoying. Art > I've tried to get these installed via fink, but no luck so far. > Admittedly, I haven't put a lot of time into it yet, but I have taken > a few stabs. > > If I can get it to build, I'd happily work on getting it working. I > get frustrated when I'm stuck in the configure stage. > > --Dethe > > > Young children play in a way that is strikingly similar to the way > scientists work --Busytown News > > > > From Scott.Daniels at Acm.Org Mon Nov 6 00:42:00 2006 From: Scott.Daniels at Acm.Org (Scott David Daniels) Date: Sun, 05 Nov 2006 15:42:00 -0800 Subject: [Edu-sig] Truth values and comparisons In-Reply-To: <6B0E2998-010E-1000-CE84-18BA582E8EB6-Webmail-10011@mac.com> References: <4545FE1A.2060303@optonline.com> <6B0E2998-010E-1000-CE84-18BA582E8EB6-Webmail-10011@mac.com> Message-ID: davelist at mac.com wrote: > I've not used .any or .all, but having just taught my CS1 students about boolean operators, I was reminded that Python works as the following example describes: > > x = a and b > # if both a and b are true, x is assigned b, otherwise x is assigned a You are misleading your students. If a is true, x is assigned b, otherwise x is assigned a: For example: x = [1] and () > x = a or b > # if a is true, x is assigned a, if a is true, x is assigned a, if a is false and b is true, x is assigned b, if both a and b are false, x is assigned False If a is true, x is assigned a, otherwise it is assigned b. x = () or [1] Check these out with: print (() and [], () and [1], (1,) and [], (1,) and [1]) and print (() or [], () or [1], (1,) or [], (1,) or [1]) Of course these doesn't address Arthur's issues, because Numeric and friends deal with boolean conversion in an array-processing form. --Scott David Daniels Scott.Daniels at Acm.Org From Scott.Daniels at Acm.Org Mon Nov 6 00:51:08 2006 From: Scott.Daniels at Acm.Org (Scott David Daniels) Date: Sun, 05 Nov 2006 15:51:08 -0800 Subject: [Edu-sig] Truth values and comparisons In-Reply-To: <45464156.3050805@optonline.com> References: <4545FE1A.2060303@optonline.com> <6B0E2998-010E-1000-CE84-18BA582E8EB6-Webmail-10011@mac.com> <45462CFE.2010100@optonline.com> <200610301107.04522.john.zelle@wartburg.edu> <45464156.3050805@optonline.com> Message-ID: Arthur wrote: > > ... Is concerning myself with this distinction sound programming, or is > the hard core answer more to the effect what works works, what doesn't > doesn't - and one should focus only on that, and perhaps the performance > impact of available alternatives? For my money (and that of most professional programmers I don't revile), it is _vital_ to concern yourself with such distinctions. Writing code should be an exercise in "how do I express this the most clearly," not "how can I make it run as fast as possible." Code first must be correct, then "obviously" correct, then "fast enough" (which in some special cases is "as fast as possible"). Clearly correct can either come from how the code itself is written, or (if necessary hen getting the speed up) through comments that help the reader understand why it is correct. > Though I guess we are all allowed to define "sound programming" for > ourselves. With the exception you pointed out about space shuttles. --Scott David Daniels Scott.Daniels at Acm.Org From ajsiegel at optonline.net Mon Nov 6 14:49:03 2006 From: ajsiegel at optonline.net (Arthur) Date: Mon, 06 Nov 2006 08:49:03 -0500 Subject: [Edu-sig] Truth values and comparisons In-Reply-To: References: <4545FE1A.2060303@optonline.com> <6B0E2998-010E-1000-CE84-18BA582E8EB6-Webmail-10011@mac.com> <45462CFE.2010100@optonline.com> <200610301107.04522.john.zelle@wartburg.edu> <45464156.3050805@optonline.com> Message-ID: <454F3D4F.9090405@optonline.com> Scott David Daniels wrote: >>Though I guess we are all allowed to define "sound programming" for >>ourselves. >> >> > >With the exception you pointed out about space shuttles. > > if sum(abs(the_array)) != 0: go ahead Am I still blowing up anything, potentially?? Still preferring something along these lines in the context in which I am working. "any" may be more readable (it is certainly more succinct).to the knowing reader, but less so to the less knowing. But it is hard to separate readability from some concept of who your readers might be, and overall context. It also allows me to switch easily to the concept of "zero for practical purposes" as opposed to true/false. if sum(abs(the_array)) > EPS: go ahead OTOH, I am the one always fighting condescension. I can see it be argued (my own objection to some of the arguments against int/int = int, always , was something along these lines) that my approach - in a pedagogical settings - effectively avoids an opportunity to elucidate something that should be elucidated. Probably no way to win in any black and white sense with these kinds of issues. Think I'll go with "any" in the end, unless there is a real reason to believe that "zero for practical purposes" is or might come into play. Art From ajsiegel at optonline.net Tue Nov 7 18:30:32 2006 From: ajsiegel at optonline.net (Arthur) Date: Tue, 07 Nov 2006 12:30:32 -0500 Subject: [Edu-sig] forking vpython???? Message-ID: <4550C2B8.7050509@optonline.com> For the record: I have made my peace with Bruce Sherwood, the physics professor who administers the the vpython project. Anyone listening in on visual-python list can see that our recent interactions are quite cordial- as are the private interaction we have recently had. He and Ruth Chabay are hard at work meeting a deadline for a second addition of "Matters and Interaction" http://www4.ncsu.edu/~rwchabay/mi/ which is seems to me is an innovative introductory physics textbook, and an innovative use of Python, via VPython, in education. That being said: The possibility that I will approach my contributions to vpython as a fork, rather "joining" the project seems strong. a) I am frustrated with the pace of feedback to my efforts to contribute, and in fact there is no one currently committed to the project very qualified to evaluate those efforts. b) I am upfront about my lack of C++ expertise, and shy from the responsibility of making contributions in an environment where the program is being used in a growing number of college curricula and where there is not the expertise to vet those contributions, however: - PyGeo exercises vpython extensively, and has developed a fairly extensive set of tests (of a kind). I am satisfied to consider my vpython-fork code as production quality to the extent those tests are passed. OTOH, those test are not designed explicitly to test vpython, and I can understand a decision that they are inadequate for this purpose. c) In going through the vpython code I am finding a lot of undocumented features, and a lot of easy extensions. There are, for example, a number of functions on vectors and vector methods that are already written and used internally. There are written and used internally because they are of the kind that are useful in 3d mathematics. The boost.python framework is there, allowing them to be exposed to Python trivially - one line of code. The availability of these functions and methods would add performance to PyGeo. Not sure I want to have to debate the point with anyone as to why they have not been exposed, and whether they should be. Would like to be in a "just do it" position. There are whole other structures - vector_arrays and scalar_arrays - that have been exposed to Python, but, are incomplete and therefore totally undocumented. Completing and extending them, I am feeling now, is within my capabilities. I would like to get on with it outside of committee type discussion. d) VPython_main is free to access my forked versions and make their own decisions on which changes I have made to incorporate, and which not. I think I prefer not to be in that direct loop or advocating for this change or that - as to VPython_main. Wonder if anyone here has any thoughts on this. Art From ajsiegel at optonline.net Thu Nov 9 18:00:21 2006 From: ajsiegel at optonline.net (Arthur) Date: Thu, 09 Nov 2006 12:00:21 -0500 Subject: [Edu-sig] pygeo, vpyython stats Message-ID: <45535EA5.5060104@optonline.com> FWIW - Just to get some bearings I just looked at some sourceforge download statistics for pygeo and for vpython. PyGeo VPython Nov 2006 31 24 Oct 2006 113 144 Sep 2006 112 160 Aug 2006 90 193 Jul 2006 114 132 Jun 2006 133 575 May 2006 120 72 Apr 2006 119 43 Mar 2006 118 62 Feb 2006 110 66 Jan 2006 136 53 Both numbers are meager by many standards, but I am not disappointed in PyGeo's, in that I have purposefully refrained from promoting it an iota for over 3 years, other then discussion of it here, and only here. My thinking is that I will only promote it when it is complete, in the sense of suitable for a general audience, e.g.well-documented, and having its own editing environment as part of the distribution. And that will be when that will be. Since I don't consider there to be any competition for it - it's kind of its own thing - I don't feel under any enormous pressure. But having trouble making sense of the statistics above, since PyGeo requires vpython and the PyGeo site points folks to the vpython download site. In many months there are more downloads of PyGeo than Vpython, which either means that folks are downloading PyGeo without understanding the dependencies, and giving up, or that PyGeo is being downloaded as an add-on to existing Vpython installations. Or that the statistics are unreliable for some other reason that is not apparent. Assuming the statistics are meaningful , it does seem fair to conclude that PyGeo is a very major factor in generating interest in Vpython, to the extent such interest exists. Where I go with that info, not sure. Art From francois.schnell at gmail.com Thu Nov 9 19:47:24 2006 From: francois.schnell at gmail.com (francois schnell) Date: Thu, 9 Nov 2006 19:47:24 +0100 Subject: [Edu-sig] pygeo, vpyython stats In-Reply-To: <45535EA5.5060104@optonline.com> References: <45535EA5.5060104@optonline.com> Message-ID: <13a83ca10611091047l7a03946avc887a719724ed42e@mail.gmail.com> On 09/11/06, Arthur wrote: > > > > > Or that the statistics are unreliable for some other reason that is not > apparent. Hello Arthur, >From my personal experience when I download vpython I do it from the official vpython website : http://www.vpython.org On this site the downloads are mainly from the site (not from a link to sourceforge downloads): http://www.vpython.org/win_download25.html http://www.vpython.org/linux_download.html http://vpython.org/OSX_download-10.2.html On pygeo website this is not the case : http://pw1.netcom.com/~ajs/download.html francois _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20061109/b3e82eea/attachment.html From ajsiegel at optonline.net Fri Nov 10 15:30:55 2006 From: ajsiegel at optonline.net (Arthur) Date: Fri, 10 Nov 2006 09:30:55 -0500 Subject: [Edu-sig] pygeo, vpyython stats In-Reply-To: <13a83ca10611091047l7a03946avc887a719724ed42e@mail.gmail.com> References: <45535EA5.5060104@optonline.com> <13a83ca10611091047l7a03946avc887a719724ed42e@mail.gmail.com> Message-ID: <45548D1F.2040708@optonline.com> Hi Francois - Thanks for the correction. Closer look, the only distro that is being downloaded on sourceforge is the vpython 4.xxx beta series. Those are the numbers the stats I looked at are tracking. Oops, again. BTW, business has been bringing me to Strasbourg recently. A client/friend is negotiating buying an interest in a manufacturer out near Colmar, and I am advising. Was there for the second time, the week before last. Beautiful area. If what we are working on goes further I will probably be back there from time to time. Would be nice to get together and duke out the differences in world views we seem to have. Art > > Hello Arthur, > > From my personal experience when I download vpython I do it from the > official vpython website : > > http://www.vpython.org > > On this site the downloads are mainly from the site (not from a link > to sourceforge downloads): > > http://www.vpython.org/win_download25.html > http://www.vpython.org/linux_download.html > http://vpython.org/OSX_download-10.2.html > > > On pygeo website this is not the case : > > http://pw1.netcom.com/~ajs/download.html > > > francois > > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > > > >------------------------------------------------------------------------ > >_______________________________________________ >Edu-sig mailing list >Edu-sig at python.org >http://mail.python.org/mailman/listinfo/edu-sig > > From francois.schnell at gmail.com Sat Nov 11 13:00:39 2006 From: francois.schnell at gmail.com (francois schnell) Date: Sat, 11 Nov 2006 13:00:39 +0100 Subject: [Edu-sig] pygeo, vpyython stats In-Reply-To: <45548D1F.2040708@optonline.com> References: <45535EA5.5060104@optonline.com> <13a83ca10611091047l7a03946avc887a719724ed42e@mail.gmail.com> <45548D1F.2040708@optonline.com> Message-ID: <13a83ca10611110400j5ddc7049l397e3887aa4726ab@mail.gmail.com> On 10/11/06, Arthur wrote: > > > BTW, business has been bringing me to Strasbourg recently. A > client/friend is negotiating buying an interest in a manufacturer out > near Colmar, and I am advising. > > Was there for the second time, the week before last. Beautiful area. Yes its a nice area especially the vineyards and the mountains with plenty of castles. The Japanese like also the place (Sony, Ricoh, Yamaha, Sharp ...) they even did a soap in a typical vineyard village which was a big hit in Japan ... If what we are working on goes further I will probably be back there > from time to time. Would be nice to get together and duke out the > differences in world views we seem to have. hum "duke out" ? """ 7.duke it out, to fight, esp. with the fists; do battle: The adversaries were prepared to duke it out in the alley. """ (dictionary.com) With pleasure, be warned you're in my territory ! ;) Don't hesitate to contact me next time :) francois Art > > > > > > Hello Arthur, > > > > From my personal experience when I download vpython I do it from the > > official vpython website : > > > > http://www.vpython.org > > > > On this site the downloads are mainly from the site (not from a link > > to sourceforge downloads): > > > > http://www.vpython.org/win_download25.html > > http://www.vpython.org/linux_download.html > > http://vpython.org/OSX_download-10.2.html > > > > > > On pygeo website this is not the case : > > > > http://pw1.netcom.com/~ajs/download.html > > > > > > francois > > > > > > _______________________________________________ > > Edu-sig mailing list > > Edu-sig at python.org > > http://mail.python.org/mailman/listinfo/edu-sig > > > > > > > >------------------------------------------------------------------------ > > > >_______________________________________________ > >Edu-sig mailing list > >Edu-sig at python.org > >http://mail.python.org/mailman/listinfo/edu-sig > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20061111/96e1e0fa/attachment.html From ajudkis at verizon.net Fri Nov 17 04:30:58 2006 From: ajudkis at verizon.net (Andy Judkis) Date: Thu, 16 Nov 2006 22:30:58 -0500 Subject: [Edu-sig] experiences teaching Python with turtle graphics? Message-ID: <008b01c709f8$cf5d8320$6401a8c0@Gandalf> In a few weeks I am going to start the programming unit of my tenth grade computer applications course. This will be my 5th time through it, and the previous 4 times have been only partially satisfactory. The course I teach is required, and although the students are all fairly bright, they are not all enthusiastic about this kind of thing. We have about 4 weeks to spend on the programming portion. I've started with about 4 days of RUR-PLE, where students program a robot sprite to move around inside a maze. RUR-PLE is basically a Python version of Karl The Robot, with a nice interface and some very appealing graphics. This has worked out quite well as a starting point, and introduces some of the basic ideas of subroutines, branches, and loops in a constrained environment. I've found that students are quite surprised to see the kinds of complex behavior that can come from a few lines of code. My favorite student quote: "It's so logical, but so frustrating." >From there, they've gone on to using IDLE, writing the simple text-based "guess the number" sequence of programs that I've seen in several introductory books and the first chapter of the Livewires. This takes a few days, introducing variables and reiterating the looping and branching from RUR-PLE in a more free-form environment. Then we've gone on to do some ultra-simple graphics, using the Livewires primitives to draw circles, lines, etc. This reiterates the subroutines from RUR-PLE, and introduces (with mixed results) return values and parameters. Then we do a little bit with lists - I have them generate random Shakepearean insults from lists of words. >From there, they do some ultra-simple animation, using a loop with sleep() to move disks around and bounce them off the sides of the window, and polling the keyboard to use cursor keys to move objects around on the screen. At this point, about a quarter of the kids are really into it, and they make a simple pong-like game. The other three quarters are dying for the unit to be over. One poster here several weeks ago said that 70% of the kids in their programming courses never really "get it" and unfortunately that's been my experience as well. I'd really like to do better. I'm particularly interested in using Gregor Lingl's xturtle library. I know that versions of turtle graphics have been around for various environments for a long time but I've only started to look at it, and it seems like it should be a lot of fun. More specifically, it seems like if it is used wisely, it should appeal to more of the kids for a longer period of time, and still provide a platform for getting across the concepts. Does anybody out there have any specific experience with teaching Python to this kind of audience using turtle graphics? Are there any books or lesson plans available that you can recommend as a starting point? As a point of reference, the first time I tried to teach Python I thought that the Livewires course would be perfect but I quickly found that, as slow and gentle as it seems to an experienced programmer, it moves way too fast and has way too little hand-holding for most high school kids. Thanks, Andy Judkis Academy of Allied Health and Science Neptune, NJ From ernesto at dei.uc.pt Fri Nov 17 15:07:42 2006 From: ernesto at dei.uc.pt (Ernesto Costa) Date: Fri, 17 Nov 2006 14:07:42 +0000 Subject: [Edu-sig] experiences teaching Python with turtle graphics? In-Reply-To: <008b01c709f8$cf5d8320$6401a8c0@Gandalf> References: <008b01c709f8$cf5d8320$6401a8c0@Gandalf> Message-ID: Hi, I used xturtle in a CS1 course for students with little or no previous knowledge about programming. Of course they are not kids and so I use it just to illustrate some simple programming concepts. It is a nice tool but be prepared for some limitations (IMHO). In particular if you are thinking about applications where you have to input data it is just impossible (at least I could not find a way of doing it from the manual). Anyway you can do nice things with the onClick() and onKey() methods. Concerning books what I've done is to rely on the old, but very good book, by Abelson and diSessa "Turtle Geometry" (MIT Press) and translate the logo code to Python. There are other old books on Logo, including some with nice small programs, that you can also convert to Python. Returning to the question of a "good" module about graphics. I'm using Zohn Zelle's book for my course. It has a interesting and simple to use graphics module. It would be nice if that module could be "merged" with xturtle i.e to incorporate a turtle class that use the graphics canvas :-)! Ernesto Costa On 2006/11/17, at 03:30, Andy Judkis wrote: > I'd really like to do better. I'm particularly interested in using > Gregor > Lingl's xturtle library. I know that versions of turtle graphics > have been > around for various environments for a long time but I've only > started to > look at it, and it seems like it should be a lot of fun. More > specifically, > it seems like if it is used wisely, it should appeal to more of the > kids for > a longer period of time, and still provide a platform for getting > across the > concepts. > > Does anybody out there have any specific experience with teaching > Python to > this kind of audience using turtle graphics? Are there any books > or lesson > plans available that you can recommend as a starting point? As a > point of > reference, the first time I tried to teach Python I thought that the > Livewires course would be perfect but I quickly found that, as slow > and > gentle as it seems to an experienced programmer, it moves way too > fast and > has way too little hand-holding for most high school kids. From john.zelle at wartburg.edu Fri Nov 17 15:42:09 2006 From: john.zelle at wartburg.edu (John Zelle) Date: Fri, 17 Nov 2006 08:42:09 -0600 Subject: [Edu-sig] experiences teaching Python with turtle graphics? In-Reply-To: References: <008b01c709f8$cf5d8320$6401a8c0@Gandalf> Message-ID: <200611170842.09881.john.zelle@wartburg.edu> On Friday 17 November 2006 8:07 am, Ernesto Costa wrote: > Hi, > > Returning to the question of a "good" module about graphics. I'm > using Zohn Zelle's book for my course. It has a interesting and > simple to use graphics module. It would be nice if that module could > be "merged" with xturtle i.e to incorporate a turtle class that use > the graphics canvas :-)! > One project that we often use in my classes is writing a simple turtle module on top of graphics.py. It's a great exercise for introducing students to writing their own classes. Still, I have to say that xturtle looks very interesting, and this might be a great combination. I haven't looked at xturtle's implementation in any detail, so I don't have any sense on how hard such a merger would be. --John -- John M. Zelle, Ph.D. Wartburg College Professor of Computer Science Waverly, IA john.zelle at wartburg.edu (319) 352-8360 From tjd at sfu.ca Fri Nov 17 18:19:23 2006 From: tjd at sfu.ca (Toby Donaldson) Date: Fri, 17 Nov 2006 09:19:23 -0800 Subject: [Edu-sig] Edu-sig Digest, Vol 40, Issue 9 In-Reply-To: References: Message-ID: > I'd really like to do better. I'm particularly interested in using Gregor > Lingl's xturtle library. I know that versions of turtle graphics have been > around for various environments for a long time but I've only started to > look at it, and it seems like it should be a lot of fun. More specifically, > it seems like if it is used wisely, it should appeal to more of the kids for > a longer period of time, and still provide a platform for getting across the > concepts. > > Does anybody out there have any specific experience with teaching Python to > this kind of audience using turtle graphics? Are there any books or lesson > plans available that you can recommend as a starting point? As a point of > reference, the first time I tried to teach Python I thought that the > Livewires course would be perfect but I quickly found that, as slow and > gentle as it seems to an experienced programmer, it moves way too fast and > has way too little hand-holding for most high school kids. I've used turtle graphics briefly in short sessions with kids in grade 6/7, and they easily got it in just an hour or two. We walked through a simple set of tasks that lead to a an interesting final result. I think xturtle is very good; I've created a self-installing disutils package for Windows et al to distribute to my students. As has been mentioned, looking at Logo resources is probably the best thing to do. Wikipedia's entry on Logo is a reasonable place to start: http://en.wikipedia.org/wiki/Logo_programming_language My experience has been that most students enjoy turtle graphics, and there always some students who quickly bump into the limitations of the package. Even xturtle is not yet as flexible as a grade 6 student would like. :-) I think the Squeak approach is much more interesting, although its epic scope makes it difficult to do outside of Smalltalk. Toby -- Dr. Toby Donaldson School of Computing Science Simon Fraser University (Surrey) From bmiller at LUTHER.EDU Fri Nov 17 18:32:59 2006 From: bmiller at LUTHER.EDU (Brad Miller) Date: Fri, 17 Nov 2006 11:32:59 -0600 Subject: [Edu-sig] experiences teaching Python with turtle graphics? In-Reply-To: <200611170842.09881.john.zelle@wartburg.edu> References: <008b01c709f8$cf5d8320$6401a8c0@Gandalf> <200611170842.09881.john.zelle@wartburg.edu> Message-ID: On Nov 17, 2006, at 8:42 AM, John Zelle wrote: > On Friday 17 November 2006 8:07 am, Ernesto Costa wrote: >> Hi, >> >> Returning to the question of a "good" module about graphics. I'm >> using Zohn Zelle's book for my course. It has a interesting and >> simple to use graphics module. It would be nice if that module could >> be "merged" with xturtle i.e to incorporate a turtle class that use >> the graphics canvas :-)! >> > > One project that we often use in my classes is writing a simple > turtle module > on top of graphics.py. It's a great exercise for introducing > students to > writing their own classes. Still, I have to say that xturtle looks > very > interesting, and this might be a great combination. I haven't > looked at > xturtle's implementation in any detail, so I don't have any sense > on how hard > such a merger would be. > > --John > Hi, I've been using Gregor's xturtle in my CS 1 class this fall, along with John's CS1 text. Although this is a college course the students do not have any prior programming experience. I have found that it is a really nice way to introduce students to the concept of using an object. Creating instances, calling methods etc. We have used xturtle for several projects including: - drawing a sierpinski triangle - drawing simple scenes - plotting simple functions I extended xturtle to have a setWorldCoordinates method that works like the like the setWorldCoords method in John's graphics.py. After we do the scaling and translation for ourselves once, its nice to let the system do it for us the rest of the time. - "bouncing turtles" moving multiple turtles around a box, bouncing off the walls and other turtles - classic video game xturtle has an onClick, onTimer, and onKey function that lets you setup callbacks for those three event types. Using a turtle or turtles as a sprite the students were able to make some really fun classic games like pong, space invaders, asteroids Now, we are learning how to write our own classes and we are implementing a set of classes that look like the those defined in graphics.py. Behind the scenes we are using xturtle to create the window and do the real drawing. I have used graphics.py in past years to build a turtle, so this year we are doing the opposite. So far I like doing it this way because graphics is such a natural object oriented application and the inheritance hierarchy for shapes is such a nice one. I also like using turtle graphics when I'm teaching recursion. Brad > > -- > John M. Zelle, Ph.D. Wartburg College > Professor of Computer Science Waverly, IA > john.zelle at wartburg.edu (319) 352-8360 > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig Bradley Miller Assistant Professor Computer Science Luther College Decorah, IA 52101 http://www.cs.luther.edu/~bmiller -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20061117/1cf0a798/attachment.html From da.ajoy at gmail.com Sun Nov 19 05:16:46 2006 From: da.ajoy at gmail.com (Daniel Ajoy) Date: Sat, 18 Nov 2006 23:16:46 -0500 Subject: [Edu-sig] experiences teaching Python with turtle graphics? In-Reply-To: References: Message-ID: <455F945E.31908.63A95005@da.ajoy.gmail.com> On 18 Nov 2006 at 12:00, edu-sig-request at python.org wrote: > As has been mentioned, looking at Logo resources is probably the best > thing to do. Wikipedia's entry on Logo is a reasonable place to start: > http://en.wikipedia.org/wiki/Logo_programming_language > I have a small collection of classic turtle graphics here: http://mondragon.angeltowns.net/paradiso/GaleriaGT.html And I've promoted this page in the past: http://mondragon.angeltowns.net/paradiso/Construcciones.html Daniel Del Paraiso de Logo (Logo Paradise) From glingl at aon.at Sun Nov 19 22:49:10 2006 From: glingl at aon.at (Gregor Lingl) Date: Sun, 19 Nov 2006 22:49:10 +0100 Subject: [Edu-sig] turtle-graphics - Abelson and a sign of the times? Message-ID: <4560D156.3030607@aon.at> > Concerning books what I've done is to rely on the old, but very good > book, by Abelson and diSessa "Turtle Geometry" (MIT Press) and > translate the logo code to Python. To confront you with a newer (and very interesting) idea of Abelson have a look at: ttp://lambda-the-ultimate.org/node/1840 Regards, Gregor P.S.: After having finished the second edition of "Python f?r Kids" which was a huge rewrite due to using the new xturtle module I went on vacation. Back from this I've got to do a lot of work which I didn't have time to complete while writing the book. I just have turned on the edu-sig posting delevery again and I hope to be able to enter the turtlegraphics thread soon and also the development of the xturtle module in the very near future. From pdfernhout at kurtz-fernhout.com Sun Nov 26 22:50:02 2006 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Sun, 26 Nov 2006 16:50:02 -0500 Subject: [Edu-sig] FYI: PataPata postmortem link Message-ID: <456A0C0A.2010603@kurtz-fernhout.com> Just as an FYI, as a way to wind up the PataPata project (or at least one phase of it), I wrote a lengthy postmortem critique of the PataPata project to date, plus ideas for where to go from here. You can read the critique by following this link: "PataPata critique: the good, the bad, the ugly" http://sourceforge.net/mailarchive/forum.php?thread_id=31111569&forum_id=48729 Comments welcome. For reference, the PataPata project is/was """an experiment to support educational constructivism on the Python platform, inspired by "Squeak" and "Self", but going beyond those in a Pythonic way.""" From the introduction: """It's been about three months from my last post to the PataPata list as well as my last major change to the system. I have been thinking about the system in the intervening time, and feel ready to produce a critique of it as an experiment (sort of as a, sadly, "postmortem" report). Others are welcome to chime in. This critique covers various good, bad, and ugly results from this experiment, and then outlines some thoughts on where to go next. This note marks the end of this phase of the PataPata experiment. I am uncertain if this project on SourceForge will see more development, but I am certain if there is more development on this particular SourceForge project, it will likely be in a radically different direction than the work published here to date. """ === By the way, my decision to write a critique of PataPata was inspired in part by this paper by Drew McDermott, "Artificial Intelligence meets Natural Stupidity". http://portal.acm.org/citation.cfm?id=1045340 [fee based link] The core of the paper is here: http://www.everything2.com/index.pl?node_id=1406540 From there: "McDermott explains how all research should be based on actual implementations, and be a thorough report on them. What is needed is a very clear picture of what was tried, what worked, what didn't, why didn't that work. And there must be a working program that later researchers can play with. Later research can build on these partial solutions, and report the exact improvements made since the previous version, the improvement in performance, etc. As McDermott states: The standard for such research should be a partial success, but AI as a field is starving for a few carefully documented failures. Anyone can think of several theses that could be improved stylistically and substantively by being rephrased as reports on failures. I can learn more by just being told why a technique won't work than by being made to read between the lines." Thanks again to people here for your previous feedback on the project. --Paul Fernhout From pdfernhout at kurtz-fernhout.com Sun Nov 26 23:57:28 2006 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Sun, 26 Nov 2006 17:57:28 -0500 Subject: [Edu-sig] FYI: PataPata postmortem link (better link) In-Reply-To: <456A0C0A.2010603@kurtz-fernhout.com> References: <456A0C0A.2010603@kurtz-fernhout.com> Message-ID: <456A1BD8.6010308@kurtz-fernhout.com> The email message referenced in the PataPata SourceForge email archive I linked to is somehow cut off about two-thirds of the way through. Here is a link to a complete version I just put up on the web site. Sorry about any inconvenience. PataPata critique: the good, the bad, the ugly http://patapata.sourceforge.net/critique.html --Paul Fernhout Paul D. Fernhout wrote: > Just as an FYI, as a way to wind up the PataPata project (or at least one > phase of it), I wrote a lengthy postmortem critique of the PataPata > project to date, plus ideas for where to go from here. You can read the > critique by following this link: > > "PataPata critique: the good, the bad, the ugly" > http://sourceforge.net/mailarchive/forum.php?thread_id=31111569&forum_id=48729 > > Comments welcome. From ajsiegel at optonline.net Mon Nov 27 07:18:24 2006 From: ajsiegel at optonline.net (Arthur) Date: Mon, 27 Nov 2006 01:18:24 -0500 Subject: [Edu-sig] FYI: PataPata postmortem link In-Reply-To: <456A0C0A.2010603@kurtz-fernhout.com> References: <456A0C0A.2010603@kurtz-fernhout.com> Message-ID: <456A8330.7090502@optonline.com> Paul D. Fernhout wrote: >For reference, the PataPata project is/was """an experiment to support >educational constructivism on the Python platform, inspired by "Squeak" >and "Self", but going beyond those in a Pythonic way.""" > > Was PataPata an experiment in education or an experiment in technology?? My own reaction was a strong desire to take it apart to see what made it tick, but little interest in using it as intended - or said better, its intent was never clear to me. Certainly not its *educational* intent.. Nothing about that is made clearer by reading your self-critique. I think that the real introspection that is necessary in order for you to better apply your technical expertise to the matter of education would be in regard to some of the underlying assumption you are making about "educational constructivism", particularly as that relates to the use of technology, and more particularly as it relates to use of the GUI.. IOW, I think the real issues are at the level of your axioms, not your implementation Sure there is a strong school-of-thought that would support your axioms. What that school-of-thought seems to rally around, it sometimes seems to me, is hostility to the notion that devotion to these axioms needs to re-examined every few decades. That is the self-critique I would like to be reading, anyway. Art From ianb at colorstudy.com Mon Nov 27 19:14:40 2006 From: ianb at colorstudy.com (Ian Bicking) Date: Mon, 27 Nov 2006 12:14:40 -0600 Subject: [Edu-sig] FYI: PataPata postmortem link In-Reply-To: <456A0C0A.2010603@kurtz-fernhout.com> References: <456A0C0A.2010603@kurtz-fernhout.com> Message-ID: <456B2B10.8060702@colorstudy.com> Paul D. Fernhout wrote: > Just as an FYI, as a way to wind up the PataPata project (or at least one > phase of it), I wrote a lengthy postmortem critique of the PataPata > project to date, plus ideas for where to go from here. You can read the > critique by following this link: > > "PataPata critique: the good, the bad, the ugly" > http://sourceforge.net/mailarchive/forum.php?thread_id=31111569&forum_id=48729 > > Comments welcome. Thanks for putting this together; it's useful to know how this went, as it was a fairly ambitious rethinking of Python development. There's some similar issues being considered for OLPC. Specifically the laptop has a "view source" key, which (unsurprisingly) lets you view the source of what you are doing. What that means is application (aka "Activity") specific, but a general Python solution is called for. Of course it's a little hard to say what that actually should be. Just a text editor? Not too exciting. Really there should be a view of the process. And some way to manipulate the in-process objects and source. One thing I was unsure of -- and I think your postmortem confirmed -- is whether it's really feasible to generally edit objects in-process in a persistent way. I'm inclined not to go so far, perhaps simply relying on UI hints to indicate when the change is likely to be persistent. It's fairly easy to edit a function definition persistently, for instance, or add a function definition. You can still explore and poke around in the process any way you want, but you don't have complete power. Of course, at some point you need complete power, which means editing the source in ways that can only be meaningful when you restart the process from scratch. I'm not sure how or where to make that break. OTOH, emphasizing clean/fast/easy restarts might be more general and easier to implement than in-process persistent editing. I'm also not sure what to build on, or what to use. It's interesting that you felt out-of-process interaction was successful. This fits with my own intuition that in-process stuff can be dangerous and fragile. But I'm not that familiar with the details of how the interprocess communication should happen; perhaps IDLE is a good place to start looking. Perhaps IDLE is a good place to start the development? I don't believe Tk will be available on the laptops, only GTK, and probably not wx either, so that limits the possibility of reusing most UI, though other bits of code might be fine. -- Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org From rmalouf at mail.sdsu.edu Mon Nov 27 19:31:59 2006 From: rmalouf at mail.sdsu.edu (Rob Malouf) Date: Mon, 27 Nov 2006 10:31:59 -0800 Subject: [Edu-sig] FYI: PataPata postmortem link In-Reply-To: <456B2B10.8060702@colorstudy.com> References: <456A0C0A.2010603@kurtz-fernhout.com> <456B2B10.8060702@colorstudy.com> Message-ID: <25ACD8C9-9B01-4DB4-BFC1-25DDC0497675@mail.sdsu.edu> Hi, On Nov 27, 2006, at 10:14 AM, Ian Bicking wrote: > There's some similar issues being considered for OLPC. > Specifically the > laptop has a "view source" key, which (unsurprisingly) lets you > view the > source of what you are doing. What that means is application (aka > "Activity") specific, but a general Python solution is called for. > > Of course it's a little hard to say what that actually should be. > Just > a text editor? Not too exciting. Really there should be a view of > the > process. And some way to manipulate the in-process objects and > source. > One thing I was unsure of -- and I think your postmortem > confirmed -- > is whether it's really feasible to generally edit objects in- > process in > a persistent way. I'm inclined not to go so far, perhaps simply > relying > on UI hints to indicate when the change is likely to be persistent. > It's fairly easy to edit a function definition persistently, for > instance, or add a function definition. You can still explore and > poke > around in the process any way you want, but you don't have complete > power. Sounds a lot like a LISP Machine.... Have you looked into those for UI ideas? --- Rob Malouf Department of Linguistics and Asian/Middle Eastern Languages San Diego State University From pdfernhout at kurtz-fernhout.com Tue Nov 28 03:40:12 2006 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Mon, 27 Nov 2006 21:40:12 -0500 Subject: [Edu-sig] FYI: PataPata postmortem link In-Reply-To: <456A8330.7090502@optonline.com> References: <456A0C0A.2010603@kurtz-fernhout.com> <456A8330.7090502@optonline.com> Message-ID: <456BA18C.4070209@kurtz-fernhout.com> Arthur- Fair enough criticism of the critique, and thanks for the perspective. You made a very good point I will need to meditate on. Thank you. Sadly, nothing about PataPata experiment really progressed far enough in terms of a user base to, in even just an "action research" experimental way, even begin to resolve the issue you raise. I'll have to muse on how one would even begin to construct an experiment to evaluate this axiom. --Paul Fernhout Arthur wrote: > Paul D. Fernhout wrote: > > >>For reference, the PataPata project is/was """an experiment to support >>educational constructivism on the Python platform, inspired by "Squeak" >>and "Self", but going beyond those in a Pythonic way.""" >> >> > > Was PataPata an experiment in education or an experiment in technology?? > > My own reaction was a strong desire to take it apart to see what made it > tick, but little interest in using it as intended - or said better, its > intent was never clear to me. Certainly not its *educational* intent.. > > Nothing about that is made clearer by reading your self-critique. > > I think that the real introspection that is necessary in order for you > to better apply your technical expertise to the matter of education > would be in regard to some of the underlying assumption you are making > about "educational constructivism", particularly as that relates to the > use of technology, and more particularly as it relates to use of the GUI.. > > IOW, I think the real issues are at the level of your axioms, not your > implementation > > Sure there is a strong school-of-thought that would support your > axioms. What that school-of-thought seems to rally around, it sometimes > seems to me, is hostility to the notion that devotion to these axioms > needs to re-examined every few decades. > > That is the self-critique I would like to be reading, anyway. > > Art > > > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > > From pdfernhout at kurtz-fernhout.com Tue Nov 28 04:12:42 2006 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Mon, 27 Nov 2006 22:12:42 -0500 Subject: [Edu-sig] FYI: PataPata postmortem link In-Reply-To: <456B2B10.8060702@colorstudy.com> References: <456A0C0A.2010603@kurtz-fernhout.com> <456B2B10.8060702@colorstudy.com> Message-ID: <456BA92A.8090703@kurtz-fernhout.com> Ian- Thanks for the comment. I think the issue you raise is a really difficult one to resolve. If I understand the general issue correctly, when you are looking at a GUI interface with underlying processes, and a person wants to "see the code", the question is what to show them, and also whether to show it to them in such a way as they can modify either what they see right then, or what they might see if the restarted the program. One thing I had sometimes dreamed about is mapping every pixel on the screen with a programming or debugging equivalent of a "Z-Buffer". But in this, call it perhaps an "S-Buffer", instead of storing Z-depth from a pixel on a polygon, you could associate a stack trace with every pixel from the process that last wrote to that pixel (you might even store the stacks of everyone who wrote to that pixel). So, in that way you would have a somewhere logical to begin to explore the system related to constructing each aspect of the current view. If you see a button on a screen, mouse over to it, hit a key, and immediately you are in the debugger with a stack trace related to the code that drew the button, which presumably would link to the button itself. You would need pretty much the entire stack since otherwise you would just end up with references to the polygon drawing routines. :-) Possibly not feasible with today's technology though -- you might need several K per pixel at least, and with a megapixel display, that might mean gigabytes just for that storage. Might be possible in a few years though. Or might be feasible sooner for beginners if you restricted the window to, say, a 200 X 200 size, or if you could do something clever related to not storing independent copies of each stack trace, since whole areas of pixels would likely be drawn by essentially the same common routines with the same underlying stack. Perhaps, considering that overlap, if you skipped the last one or two specific frames on the stack, you might be able to store such a "S-Buffer" with little more than an extra 10 megabytes or so for 32 bit pointer for each pixel of a megabit display, plus maybe just a few megabytes for the really relevant stack? Something someone in academia might want to explore, perhaps as a student project, possibly. Of course, if you really wanted to do it right, you should save the state of the virtual machine in it's entirety when writing each pixel. So that is probably a few megabytes at least per pixel, or probably a few terabytes per display. Now I now what I'll be doing with all that memory the computer I buy in 2020 will have; storing a million similar copies off the same virtual machine. :-) Again though, with clever ideas like compression, storing checkpoints (like OCaml does) or using other approaches to VM design (the Pointrel System I wrote has a data storage approach in some versions which only adds data, never changes or erases it), it might be possible to reduce the memory demand for such a "complete VM state saving S-Buffer" down to only dozens or hundreds of megabytes per display, which is within reach even now. Even if this worked, you might still find exploring the system awkward if the system created objects in one place, but displayed them at another time in a refresh, as most systems do. You would still need then to work backward to figure out how the particular object on the screen got initialized. So maybe all you really need that is ultimately useful is an association of a graphical object doing th drawing with each pixel on the screen? And essentially, that is what PataPata does (and many other drawing-composition-oriented programs as well); it maps from a pixel on the screen back to a GUI widget, and then presents that widget in a browser. Anyway, I think perhaps there are some genral ideas to explore here. Whether changes to anything you explored by picking a pixel from the screen were useful to modifying what you saw right then and there would have a lot to do with the underlying programming model. In the case of conventional Python GUIs, where you have a builder method that assembles all the widgets, it would really take a restart of the GUI (or at least the modified window) to map back from source to display. And any changes just made to widgets would not likely be easily saved with that model -- unless you pursued writing out object to source in some fashion similar to what PataPata tried. The notion of a Smalltalk image (a saved binary file representing the current state of a world of object) seems a much easier approach to support this kind of dynamic interface redesign, and I think that is one of the reasons I feel more productive programming GUIs in Smalltalk than Python; I rarely have to restart a complex Smalltalk application the way I often have to do with Python ones (unless you use various tricks, some of which I have posted on before to the Jython list). While I did end up doing things "out of process" a lot in terms of editing the source file as text, I think the reasons I did it on further reflection could have had more to do with my confidence about the system then anything else. I was often making changes to key GUI components or other core implementation things (including file writing). If I was working as a "user" level instead of a "maintainer" level, I think the "in process" editing of windows using the hierarchical browser might have been a lot more satisfactory and appealing. But that remains speculation; still I think when I used the inspector to change things, I probably was thinking more like I was testing the system from a "user" standpoint. Of course, the whole point of something like PataPata is to blur the line of "user" and "maintainer", so the issue is never that simple. Thanks again for your conceptual help with key ideas in the project like using metaclasses to build prototypes; that part of going from source to prototypes I was very pleased with. :-) --Paul Fernhout Ian Bicking wrote: > Paul D. Fernhout wrote: > >>Just as an FYI, as a way to wind up the PataPata project (or at least one >>phase of it), I wrote a lengthy postmortem critique of the PataPata >>project to date, plus ideas for where to go from here. You can read the >>critique by following this link: >> >>"PataPata critique: the good, the bad, the ugly" >>http://sourceforge.net/mailarchive/forum.php?thread_id=31111569&forum_id=48729 >> >>Comments welcome. > > > Thanks for putting this together; it's useful to know how this went, as > it was a fairly ambitious rethinking of Python development. > > There's some similar issues being considered for OLPC. Specifically the > laptop has a "view source" key, which (unsurprisingly) lets you view the > source of what you are doing. What that means is application (aka > "Activity") specific, but a general Python solution is called for. > > Of course it's a little hard to say what that actually should be. Just > a text editor? Not too exciting. Really there should be a view of the > process. And some way to manipulate the in-process objects and source. > One thing I was unsure of -- and I think your postmortem confirmed -- > is whether it's really feasible to generally edit objects in-process in > a persistent way. I'm inclined not to go so far, perhaps simply relying > on UI hints to indicate when the change is likely to be persistent. > It's fairly easy to edit a function definition persistently, for > instance, or add a function definition. You can still explore and poke > around in the process any way you want, but you don't have complete power. > > Of course, at some point you need complete power, which means editing > the source in ways that can only be meaningful when you restart the > process from scratch. I'm not sure how or where to make that break. > OTOH, emphasizing clean/fast/easy restarts might be more general and > easier to implement than in-process persistent editing. > > I'm also not sure what to build on, or what to use. It's interesting > that you felt out-of-process interaction was successful. This fits with > my own intuition that in-process stuff can be dangerous and fragile. > But I'm not that familiar with the details of how the interprocess > communication should happen; perhaps IDLE is a good place to start > looking. Perhaps IDLE is a good place to start the development? I > don't believe Tk will be available on the laptops, only GTK, and > probably not wx either, so that limits the possibility of reusing most > UI, though other bits of code might be fine. > From ianb at colorstudy.com Tue Nov 28 17:17:41 2006 From: ianb at colorstudy.com (Ian Bicking) Date: Tue, 28 Nov 2006 10:17:41 -0600 Subject: [Edu-sig] FYI: PataPata postmortem link In-Reply-To: <456BA92A.8090703@kurtz-fernhout.com> References: <456A0C0A.2010603@kurtz-fernhout.com> <456B2B10.8060702@colorstudy.com> <456BA92A.8090703@kurtz-fernhout.com> Message-ID: <456C6125.7020707@colorstudy.com> Paul D. Fernhout wrote: > Ian- > > Thanks for the comment. > > I think the issue you raise is a really difficult one to resolve. If I > understand the general issue correctly, when you are looking at a GUI > interface with underlying processes, and a person wants to "see the code", > the question is what to show them, and also whether to show it to them in > such a way as they can modify either what they see right then, or what > they might see if the restarted the program. > > One thing I had sometimes dreamed about is mapping every pixel on the > screen with a programming or debugging equivalent of a "Z-Buffer". But in > this, call it perhaps an "S-Buffer", instead of storing Z-depth from a > pixel on a polygon, you could associate a stack trace with every pixel > from the process that last wrote to that pixel (you might even store the > stacks of everyone who wrote to that pixel). Of course that takes a lot of space, and OLPC is a considerable step backwards in terms of resources. With 128Mb of RAM (and not really any feasible swap) we have to be very conservative. This also can't have any overhead if a child isn't using it. My initial thought was more like a "view source" that showed the "main" file -- which might be automatically detectable, or maybe we'd just have the activity declare what its main file is. Then you could essentially enter a stepped mode, where the next event would be captured and you'd see execution at that point. OTOH, a "mouse-in" event is often pretty boring, so there might be different kinds of events you can catch. Also, we can just look at events until we see one that actually points to Python code (with the assumption that all C code is totally opaque -- which in practice it is). That will help you see why the program acts like it does, but not how it got to be how it is. Simple/safe restarting might make that even more complicated -- if we try to get activities to safely shut down and restart without losing state or information, then a lot of state is going to essentially appear from nowhere (like from a pickle). And that state might be "corrupt" in some fashion, if you are preserving buggy state, or you are preserving state with no longer matches the code (if you are restarting to see edits). Ugh; I hate persistence. OK, so now I realize we need to think about simple ad hoc persistence. And that persistence has to be transparent, otherwise it's not possible to debug or handle upgrades. Well, there should always be an option to ditch anything that has persisted and start from scratch. Sigh... this opens up enough issues that I have to think about it some more. Serialization is going to be a big deal. Oh, but in conclusion -- restarting with saved sessions makes it even harder to figure out why the state (and UI) gets set up the way it does, and it wasn't easy to begin with. -- Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org From pdfernhout at kurtz-fernhout.com Tue Nov 28 20:13:47 2006 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Tue, 28 Nov 2006 14:13:47 -0500 Subject: [Edu-sig] FYI: PataPata postmortem link In-Reply-To: <456C6125.7020707@colorstudy.com> References: <456A0C0A.2010603@kurtz-fernhout.com> <456B2B10.8060702@colorstudy.com> <456BA92A.8090703@kurtz-fernhout.com> <456C6125.7020707@colorstudy.com> Message-ID: <456C8A6B.6020002@kurtz-fernhout.com> Ian- Yep, that sounds about right to me -- I like how you phrase "That will help you see why the program acts like it does, but not how it got to be how it is.". And that is why modifying complex systems like event driven GUIs of significant size is non-trivial, and involves using some analogue of all the Smalltalk-inspired tools of Inspector, Browser, Debugger, and Workspace, no matter how much we how some great tool could make it easier, or how approachable we try to make the experience for beginners. There is a lot going on under the hood of a modern application (or in its support libraries at least) and making it easier to understand in detail might require an entire paradigm shift (perhaps functional programming or even logical AI programming?). --Paul Fernhout Ian Bicking wrote: > Paul D. Fernhout wrote: > >>Ian- >> >>Thanks for the comment. >> >>I think the issue you raise is a really difficult one to resolve. If I >>understand the general issue correctly, when you are looking at a GUI >>interface with underlying processes, and a person wants to "see the code", >>the question is what to show them, and also whether to show it to them in >>such a way as they can modify either what they see right then, or what >>they might see if the restarted the program. >> >>One thing I had sometimes dreamed about is mapping every pixel on the >>screen with a programming or debugging equivalent of a "Z-Buffer". But in >>this, call it perhaps an "S-Buffer", instead of storing Z-depth from a >>pixel on a polygon, you could associate a stack trace with every pixel >>from the process that last wrote to that pixel (you might even store the >>stacks of everyone who wrote to that pixel). > > > Of course that takes a lot of space, and OLPC is a considerable step > backwards in terms of resources. With 128Mb of RAM (and not really any > feasible swap) we have to be very conservative. This also can't have > any overhead if a child isn't using it. > > My initial thought was more like a "view source" that showed the "main" > file -- which might be automatically detectable, or maybe we'd just have > the activity declare what its main file is. Then you could essentially > enter a stepped mode, where the next event would be captured and you'd > see execution at that point. OTOH, a "mouse-in" event is often pretty > boring, so there might be different kinds of events you can catch. > Also, we can just look at events until we see one that actually points > to Python code (with the assumption that all C code is totally opaque -- > which in practice it is). > > That will help you see why the program acts like it does, but not how it > got to be how it is. Simple/safe restarting might make that even more > complicated -- if we try to get activities to safely shut down and > restart without losing state or information, then a lot of state is > going to essentially appear from nowhere (like from a pickle). And that > state might be "corrupt" in some fashion, if you are preserving buggy > state, or you are preserving state with no longer matches the code (if > you are restarting to see edits). Ugh; I hate persistence. > > OK, so now I realize we need to think about simple ad hoc persistence. > And that persistence has to be transparent, otherwise it's not possible > to debug or handle upgrades. Well, there should always be an option to > ditch anything that has persisted and start from scratch. > > Sigh... this opens up enough issues that I have to think about it some > more. Serialization is going to be a big deal. Oh, but in conclusion > -- restarting with saved sessions makes it even harder to figure out why > the state (and UI) gets set up the way it does, and it wasn't easy to > begin with. > > From ajsiegel at optonline.net Wed Nov 29 12:31:21 2006 From: ajsiegel at optonline.net (Arthur) Date: Wed, 29 Nov 2006 06:31:21 -0500 Subject: [Edu-sig] FYI: PataPata postmortem link In-Reply-To: <456C6125.7020707@colorstudy.com> References: <456A0C0A.2010603@kurtz-fernhout.com> <456B2B10.8060702@colorstudy.com> <456BA92A.8090703@kurtz-fernhout.com> <456C6125.7020707@colorstudy.com> Message-ID: <456D6F89.5090705@optonline.com> Ian Bicking wrote: >Of course that takes a lot of space, and OLPC is a considerable step >backwards in terms of resources. With 128Mb of RAM (and not really any >feasible swap) we have to be very conservative. This also can't have >any overhead if a child isn't using it. > > Sure is difficult for us tech mortals to understand where these issues intersect with the intent of OLPC. As a point of real-world reference, I have communicated a bit with my son - working now in the South Pacific equivalent of the bush, for the U.S. Peace Corps - about OLPC, i.e. the availablility of inexpensive laptops that can used in an environment without ready access to electicity. He tells me books are difficult to access, and that he could see it as a great advantage to be able to retrieve and distribute books and other text information electronically. Sounds logical, and the kind of thing I would expect OLPC to be focusing upon. What are we talking about here? I know, why be nasty..... but I smell a generally decent idea being hijacked by the absolutely unproven - as in the only proof that does exist is in the negataive - radical electronic constructivists. And I suspect the influence of my usual suspects (suspect) is at the root. Too bad, really. I have "oops" consistently here lately, and am certainly as oops prone as anyone else, at least. If I am oopings here again, i apologize in advance. But I also get it right often enough, going by smell. Art >My initial thought was more like a "view source" that showed the "main" >file -- which might be automatically detectable, or maybe we'd just have >the activity declare what its main file is. Then you could essentially >enter a stepped mode, where the next event would be captured and you'd >see execution at that point. OTOH, a "mouse-in" event is often pretty >boring, so there might be different kinds of events you can catch. >Also, we can just look at events until we see one that actually points >to Python code (with the assumption that all C code is totally opaque -- >which in practice it is). > >That will help you see why the program acts like it does, but not how it >got to be how it is. Simple/safe restarting might make that even more >complicated -- if we try to get activities to safely shut down and >restart without losing state or information, then a lot of state is >going to essentially appear from nowhere (like from a pickle). And that >state might be "corrupt" in some fashion, if you are preserving buggy >state, or you are preserving state with no longer matches the code (if >you are restarting to see edits). Ugh; I hate persistence. > >OK, so now I realize we need to think about simple ad hoc persistence. >And that persistence has to be transparent, otherwise it's not possible >to debug or handle upgrades. Well, there should always be an option to >ditch anything that has persisted and start from scratch. > >Sigh... this opens up enough issues that I have to think about it some >more. Serialization is going to be a big deal. Oh, but in conclusion >-- restarting with saved sessions makes it even harder to figure out why >the state (and UI) gets set up the way it does, and it wasn't easy to >begin with. > > > > From ajsiegel at optonline.net Wed Nov 29 13:00:04 2006 From: ajsiegel at optonline.net (Arthur) Date: Wed, 29 Nov 2006 07:00:04 -0500 Subject: [Edu-sig] FYI: PataPata postmortem link In-Reply-To: <456D6F89.5090705@optonline.com> References: <456A0C0A.2010603@kurtz-fernhout.com> <456B2B10.8060702@colorstudy.com> <456BA92A.8090703@kurtz-fernhout.com> <456C6125.7020707@colorstudy.com> <456D6F89.5090705@optonline.com> Message-ID: <456D7644.1070608@optonline.com> Arthur wrote: >What are we talking about here? > >I know, why be nasty..... > > Certainly not intending to insult Ian, whose reputation as a leader in the Python community has been earned form the ground up, by Good Works, in the best tradition of an Open source community.... And maybe I simply *don't* understand.... But.... reading the lines, and between the lines, I fear not only that OLPC is turning into a toy, but a toy for the wrong follks, folks who have enough toys, rooms full of them, lost in their toys, blinking and whizzing hynoptic. Art From bert at freudenbergs.de Wed Nov 29 13:45:42 2006 From: bert at freudenbergs.de (Bert Freudenberg) Date: Wed, 29 Nov 2006 13:45:42 +0100 (MET) Subject: [Edu-sig] OLPC (was FYI: PataPata postmortem link) In-Reply-To: <456D7644.1070608@optonline.com> References: <456A0C0A.2010603@kurtz-fernhout.com> <456B2B10.8060702@colorstudy.com> <456BA92A.8090703@kurtz-fernhout.com> <456C6125.7020707@colorstudy.com> <456D6F89.5090705@optonline.com> <456D7644.1070608@optonline.com> Message-ID: <193554DE-94AB-462B-B12F-F500FE38E60D@freudenbergs.de> On Nov 29, 2006, at 13:00 , Arthur wrote: > I fear not only that OLPC is turning into a toy, but a toy for the > wrong follks, folks who have enough toys, rooms full of them, > lost in > their toys, blinking and whizzing hynoptic. Would you agree that the software (and not the greenish toy-like hardware) would make all the difference between that little machine being a toy and it being a serious platform for education? Why, then, are so few folks working on actual educational software for it? So far, you can count the specifically educational activities on the OLPC on one hand. Even if you lost most fingers. - Bert - From ajsiegel at optonline.net Wed Nov 29 14:39:39 2006 From: ajsiegel at optonline.net (Arthur) Date: Wed, 29 Nov 2006 08:39:39 -0500 Subject: [Edu-sig] OLPC (was FYI: PataPata postmortem link) In-Reply-To: <193554DE-94AB-462B-B12F-F500FE38E60D@freudenbergs.de> References: <456A0C0A.2010603@kurtz-fernhout.com> <456B2B10.8060702@colorstudy.com> <456BA92A.8090703@kurtz-fernhout.com> <456C6125.7020707@colorstudy.com> <456D6F89.5090705@optonline.com> <456D7644.1070608@optonline.com> <193554DE-94AB-462B-B12F-F500FE38E60D@freudenbergs.de> Message-ID: <456D8D9B.6060506@optonline.com> Bert Freudenberg wrote: >On Nov 29, 2006, at 13:00 , Arthur wrote: > > > >>I fear not only that OLPC is turning into a toy, but a toy for the >>wrong follks, folks who have enough toys, rooms full of them, >>lost in >>their toys, blinking and whizzing hynoptic. >> >> > >Would you agree that the software (and not the greenish toy-like >hardware) would make all the difference between that little machine >being a toy and it being a serious platform for education? Why, then, >are so few folks working on actual educational software for it? So >far, you can count the specifically educational activities on the >OLPC on one hand. Even if you lost most fingers. > >- Bert - > > Not sure what are saying. Just checked my facts: Squeak, and Scratch on top of Squeak seemed to be the done deal centerpieces. You wouldn't be implying - God forbid - that this is not state of the art, best practices, educational software. There is a team, and that team has a point of view: """ Educational Software The responsibilities of this group include selecting suitable educational software, (with an understanding of memory consumption of the software). Ebook and book authoring technology belongs here. Other issues include teacher preparation, migration of exisiting content, a framework for new content development, school-server technologies, a "Kids Corps" for maintenance. /Who:/ Walter Bender, David Cavallo, Seymour Papert , Brian Smith, Alan Kay , K12LTSP(?), Mitchel Resnick, Roseli de Deus Lopes There is also a need for basic tools for programming and authoring. LOGO , OpenOffice, Dia, TuxPaint, etc. all should be considered. However, let's keep in mind that there is a difference between Edutainment and and Playful Learning. And we want Playful Learning instead of Edutainment . Also, we don't want kids to be punished by rewards . Some understanding of constructionist educational philosophy will be useful for developers. """ I don't argue the merits of constructivitist educational philosophy. And I don't like punishment, much less punishment by rewards. Just that I see these matters as having next to nothing to do with electronics. More than nothing to do with electronics. That the Wizards think they can construct this reality electronically is not only absurd, in my view, but an absolute - almost tragic - distraction from more coherent and human to human based efforts toward these espoused ends. Which I might see in the end to have maybe a 4% electronic component. I guess as I grow up I am less and less impressed by the expression of good intentions. Great intentions tend to have great effects almost exclusively in the hands of less than great egos - is what life experience seems have informed me. Not sure those kind of folks are well represented by the team assembled here. Certainly, they would not be noticed, or have influence if they were. Its all just more of the same. The non-electronic component, beating the best of intentions. Other than what Alan Kay, and his posse, says he has accomplished in the field of education, what has Alan Kay demostrably accomplished in the field of education. How many days has he spent in a classroom? He has gotten to the top of a field he has never even entered. Gotten there electronically. True wizardry, to be sure. This team is quite silly, when you look at it, deconstructed from my perspective at least. Art . From bert at freudenbergs.de Wed Nov 29 15:58:23 2006 From: bert at freudenbergs.de (Bert Freudenberg) Date: Wed, 29 Nov 2006 15:58:23 +0100 (MET) Subject: [Edu-sig] OLPC (was FYI: PataPata postmortem link) In-Reply-To: <456D8D9B.6060506@optonline.com> References: <456A0C0A.2010603@kurtz-fernhout.com> <456B2B10.8060702@colorstudy.com> <456BA92A.8090703@kurtz-fernhout.com> <456C6125.7020707@colorstudy.com> <456D6F89.5090705@optonline.com> <456D7644.1070608@optonline.com> <193554DE-94AB-462B-B12F-F500FE38E60D@freudenbergs.de> <456D8D9B.6060506@optonline.com> Message-ID: <69AA9223-7956-4072-9D48-C00F403DEF8C@freudenbergs.de> On Nov 29, 2006, at 14:39 , Arthur wrote: > Bert Freudenberg wrote: > >> On Nov 29, 2006, at 13:00 , Arthur wrote: >> >> I fear not only that OLPC is turning into a toy, but a toy for the >>> wrong follks, folks who have enough toys, rooms full of them, >>> lost in >>> their toys, blinking and whizzing hynoptic. >>> >> >> Would you agree that the software (and not the greenish toy-like >> hardware) would make all the difference between that little >> machine being a toy and it being a serious platform for >> education? Why, then, are so few folks working on actual >> educational software for it? So far, you can count the >> specifically educational activities on the OLPC on one hand. Even >> if you lost most fingers. >> >> - Bert - >> > Not sure what are saying. Just checked my facts: > > Squeak, and Scratch on top of Squeak seemed to be the done deal > centerpieces. Squeak (actually, Etoys) is there, and it is indeed the only educational activity I can see at the moment. Which prompted my message - I can imagine a lot of people with different ideas, but why are they so silent? Why don't they create a project on dev.laptop.org and start hacking? You surely would not want to leave the territory to us Etoys folks, would you? Haven't heard of Scratch being on the machine, there certainly is no specific OLPC Scratch activity, yet. > You wouldn't be implying - God forbid - that this is not state of > the art, best practices, educational software. I was implying that this is edu-sig, and since Python is on the laptop (actually as the major language, which is *not* Squeak), why isn't there anyone else contributing? It's not like OLPC was a closed project. At the current state of affairs you could get *anything* onto it. So are you dismissing the whole idea just because the lauded head honchos are constructionists? Contribute your own! > Just that I see these matters as having next to nothing to do with > electronics. More than nothing to do with electronics. Granted. Still, you are an electronic mailing list discussing educational topics as applied to an electronic device - the idea does not seem too far-fetched to me. > That the Wizards think they can construct this reality > electronically is not only absurd, in my view, but an absolute - > almost tragic - distraction from more coherent and human to human > based efforts toward these espoused ends. Which I might see in the > end to have maybe a 4% electronic component. Whatever human-to-human based efforts you (or anyone) are pursuing, by all means, continue. As has been pointed out elsewhere, this is not a zero-sum game. Virtually nobody involved in the OLPC project would instead be going to Brazil and become a teacher. So why not let everyone do what they do best, and enjoy doing? - Bert - From tom.hoffman at gmail.com Wed Nov 29 16:06:49 2006 From: tom.hoffman at gmail.com (Tom Hoffman) Date: Wed, 29 Nov 2006 10:06:49 -0500 Subject: [Edu-sig] OLPC (was FYI: PataPata postmortem link) In-Reply-To: <193554DE-94AB-462B-B12F-F500FE38E60D@freudenbergs.de> References: <456A0C0A.2010603@kurtz-fernhout.com> <456B2B10.8060702@colorstudy.com> <456BA92A.8090703@kurtz-fernhout.com> <456C6125.7020707@colorstudy.com> <456D6F89.5090705@optonline.com> <456D7644.1070608@optonline.com> <193554DE-94AB-462B-B12F-F500FE38E60D@freudenbergs.de> Message-ID: <92de6c880611290706n7a213be5ga83b44d38b0d90d6@mail.gmail.com> On 11/29/06, Bert Freudenberg wrote: > On Nov 29, 2006, at 13:00 , Arthur wrote: > > > I fear not only that OLPC is turning into a toy, but a toy for the > > wrong follks, folks who have enough toys, rooms full of them, > > lost in > > their toys, blinking and whizzing hynoptic. > > Would you agree that the software (and not the greenish toy-like > hardware) would make all the difference between that little machine > being a toy and it being a serious platform for education? Why, then, > are so few folks working on actual educational software for it? So > far, you can count the specifically educational activities on the > OLPC on one hand. Even if you lost most fingers. I would point out that writing educational software for people who don't have computers isn't very useful either, and that once kids have computers (on a common, free platform) there's a lot more incentive to write educational software for them. --Tom From bert at freudenbergs.de Wed Nov 29 16:17:12 2006 From: bert at freudenbergs.de (Bert Freudenberg) Date: Wed, 29 Nov 2006 16:17:12 +0100 (MET) Subject: [Edu-sig] OLPC (was FYI: PataPata postmortem link) In-Reply-To: <92de6c880611290706n7a213be5ga83b44d38b0d90d6@mail.gmail.com> References: <456A0C0A.2010603@kurtz-fernhout.com> <456B2B10.8060702@colorstudy.com> <456BA92A.8090703@kurtz-fernhout.com> <456C6125.7020707@colorstudy.com> <456D6F89.5090705@optonline.com> <456D7644.1070608@optonline.com> <193554DE-94AB-462B-B12F-F500FE38E60D@freudenbergs.de> <92de6c880611290706n7a213be5ga83b44d38b0d90d6@mail.gmail.com> Message-ID: <921C8997-CA61-4F89-8555-7B2DD73CA6DF@freudenbergs.de> On Nov 29, 2006, at 16:06 , Tom Hoffman wrote: > On 11/29/06, Bert Freudenberg wrote: >> On Nov 29, 2006, at 13:00 , Arthur wrote: >> >>> I fear not only that OLPC is turning into a toy, but a toy for the >>> wrong follks, folks who have enough toys, rooms full of them, >>> lost in >>> their toys, blinking and whizzing hynoptic. >> >> Would you agree that the software (and not the greenish toy-like >> hardware) would make all the difference between that little machine >> being a toy and it being a serious platform for education? Why, then, >> are so few folks working on actual educational software for it? So >> far, you can count the specifically educational activities on the >> OLPC on one hand. Even if you lost most fingers. > > I would point out that writing educational software for people who > don't have computers isn't very useful either, and that once kids have > computers (on a common, free platform) there's a lot more incentive to > write educational software for them. Exactly my reasoning - OLPC is going to be a common, free platform, so it should be plenty of incentive. Yet, little is happening. - Bert - From david at boddie.org.uk Wed Nov 29 16:06:24 2006 From: david at boddie.org.uk (David Boddie) Date: Wed, 29 Nov 2006 16:06:24 +0100 Subject: [Edu-sig] FYI: PataPata postmortem link Message-ID: <200611291606.24789.david@boddie.org.uk> Ian Bicking wrote: > There's some similar issues being considered for OLPC. Specifically the > laptop has a "view source" key, which (unsurprisingly) lets you view the > source of what you are doing. What that means is application (aka > "Activity") specific, but a general Python solution is called for. > > Of course it's a little hard to say what that actually should be. Just > a text editor? Not too exciting. Really there should be a view of the > process. And some way to manipulate the in-process objects and source. When I hear something like this, I think of pipelines or trees of self-contained components rather than source-level objects. Wasn't there a talk at EuroPython 2006 about data processing that covered this approach? [...] > Of course, at some point you need complete power, which means editing > the source in ways that can only be meaningful when you restart the > process from scratch. I'm not sure how or where to make that break. > OTOH, emphasizing clean/fast/easy restarts might be more general and > easier to implement than in-process persistent editing. In many ways, it's more interesting to consider making modified copies of existing processes. It avoids difficult issues with in-process interaction and encourages something like a prototype-based approach. It seems to me that this might work well with simple components, but maybe I'm just trying to avoid facing those difficult issues. :-/ > I'm also not sure what to build on, or what to use. It's interesting > that you felt out-of-process interaction was successful. This fits with > my own intuition that in-process stuff can be dangerous and fragile. > But I'm not that familiar with the details of how the interprocess > communication should happen; perhaps IDLE is a good place to start > looking. Perhaps IDLE is a good place to start the development? My experiments have led me to believe that interaction between processes using their standard input, output and error streams is a fairly robust foundation on which to implement out-of-process editing facilities for use with simple editing environments. David From ajsiegel at optonline.net Wed Nov 29 16:41:01 2006 From: ajsiegel at optonline.net (Arthur) Date: Wed, 29 Nov 2006 10:41:01 -0500 Subject: [Edu-sig] OLPC (was FYI: PataPata postmortem link) In-Reply-To: <921C8997-CA61-4F89-8555-7B2DD73CA6DF@freudenbergs.de> References: <456A0C0A.2010603@kurtz-fernhout.com> <456B2B10.8060702@colorstudy.com> <456BA92A.8090703@kurtz-fernhout.com> <456C6125.7020707@colorstudy.com> <456D6F89.5090705@optonline.com> <456D7644.1070608@optonline.com> <193554DE-94AB-462B-B12F-F500FE38E60D@freudenbergs.de> <92de6c880611290706n7a213be5ga83b44d38b0d90d6@mail.gmail.com> <921C8997-CA61-4F89-8555-7B2DD73CA6DF@freudenbergs.de> Message-ID: <456DAA0D.4020903@optonline.com> Bert Freudenberg wrote: >On Nov 29, 2006, at 16:06 , Tom Hoffman wrote: > > >>I would point out that writing educational software for people who >>don't have computers isn't very useful either, and that once kids have >>computers (on a common, free platform) there's a lot more incentive to >>write educational software for them. >> >> > >Exactly my reasoning - OLPC is going to be a common, free platform, >so it should be plenty of incentive. Yet, little is happening. > > Two points: One from Paul Fernhout, who just spent months on trying to make something happen: 1) """ Over the years, what I have discovered about "educational software" is that most of it is junk, and the really useful things to connect kids with are the open-ended packages which provide an avenue for their creativity and sense of mastery over aspects of the real or digital world -- so, for example, learning to write with a word processor is much better than playing some silly flash-words game, and using Photoshop or the GIMP is probably much better than using some silly math-blaster game or even the award winning Oregon Trail (which is pretty good as those things go). """ 2) What is happening is what is happening. And if the platform is indeed open enough, the official OLPC hierarchy is not relevenat. What belongs on the machines will find its way onto the machines. The best thing that the hierarchy can do is leave enough room. If I were going to contribute, I am all for help in an understanding of the memory constraints in which I need to work. My philosophy of rewards and punishment is nobody's business. I am not a child. Art From ianb at colorstudy.com Wed Nov 29 17:29:30 2006 From: ianb at colorstudy.com (Ian Bicking) Date: Wed, 29 Nov 2006 10:29:30 -0600 Subject: [Edu-sig] FYI: PataPata postmortem link In-Reply-To: <200611291606.24789.david@boddie.org.uk> References: <200611291606.24789.david@boddie.org.uk> Message-ID: <456DB56A.20009@colorstudy.com> David Boddie wrote: >> There's some similar issues being considered for OLPC. Specifically the >> laptop has a "view source" key, which (unsurprisingly) lets you view the >> source of what you are doing. What that means is application (aka >> "Activity") specific, but a general Python solution is called for. >> >> Of course it's a little hard to say what that actually should be. Just >> a text editor? Not too exciting. Really there should be a view of the >> process. And some way to manipulate the in-process objects and source. > > When I hear something like this, I think of pipelines or trees of > self-contained components rather than source-level objects. Wasn't > there a talk at EuroPython 2006 about data processing that covered > this approach? There's certainly tree-like structures in memory (and pipeline, and cubbies, and all sorts of other data structures). And it's entirely reasonable to create a browser for these objects, where you can inspect and traverse those in-memory objects. Where that currently falls down is that while you can change those objects, that change is not generally persistent. When the process is restarted, it will restart just like it was before. Given a more constrained concept of object that included a persistence system, you could make that object manipulation meaningful. But then you need a persistence system -- which notably Squeak has, and that's an idea most fully explored in Python in Zope 2 (with through-the-web development). Including a persistence system introduces a lot of complications, because key parts of the application have been moved into your persistence system and out of your source code. I'd like to avoid this (I wasn't a very happy Zope 2 through the web developer). In particular cases it might be more reasonable. For instance, consider glade (http://glade.gnome.org/) -- it's an XML description of a GUI. For an application that uses Glade and given an editor specific to that, you could edit the "objects" and then the XML is automatically written out. You'd be doing simultaneous editing of the in-process objects and the "source code", in this case the XML description of the layout. Glade isn't magic, of course -- you could add automatic serialization to any kind of object, or recreate something like Glade in Python. For a small number of basic Python objects this is already possible; mostly functions. Modules and classes are not nearly so simple. But really if we can cover a set of compelling things that children would want to edit, an incomplete in-process editing system could be valuable. > [...] > >> Of course, at some point you need complete power, which means editing >> the source in ways that can only be meaningful when you restart the >> process from scratch. I'm not sure how or where to make that break. >> OTOH, emphasizing clean/fast/easy restarts might be more general and >> easier to implement than in-process persistent editing. > > In many ways, it's more interesting to consider making modified copies of > existing processes. It avoids difficult issues with in-process interaction > and encourages something like a prototype-based approach. It seems to me > that this might work well with simple components, but maybe I'm just > trying to avoid facing those difficult issues. :-/ Forking would clone a process. But this doesn't get around the reload problem. I could go into the details, but there's lots of tricky aspects to reloading a module in Python. The reload() function is totally stupid -- it's just equivalent to: def reload(mod): exec open(mod.__file__).read() in mod.__dict__ As a result there's lots of references to the old objects. For every class there is now two instances of the class. Any imports like "from mod import Foo" will still be pointing at the old Foo. There might be references to functions, bound methods, etc, and old instances with a __class__ pointing to the old definition. People have implemented fancier reloaders that do better. For instance, recursively replacing the __dict__ of classes, instead of just creating a new class. There are always cases in which these fail. That said, if we could identify those cases and give warnings we'd be getting a lot further. Current reloaders are optimistic and ignore detectable problems. Once the warnings are in, and given alternate methods (e.g., alternatives to mutable class-level variables), we would be encouraging people to write reloadable code. -- Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org From ianb at colorstudy.com Wed Nov 29 17:31:18 2006 From: ianb at colorstudy.com (Ian Bicking) Date: Wed, 29 Nov 2006 10:31:18 -0600 Subject: [Edu-sig] FYI: PataPata postmortem link In-Reply-To: <456D6F89.5090705@optonline.com> References: <456A0C0A.2010603@kurtz-fernhout.com> <456B2B10.8060702@colorstudy.com> <456BA92A.8090703@kurtz-fernhout.com> <456C6125.7020707@colorstudy.com> <456D6F89.5090705@optonline.com> Message-ID: <456DB5D6.7040208@colorstudy.com> Arthur wrote: > As a point of real-world reference, I have communicated a bit with my > son - working now in the South Pacific equivalent of the bush, for the > U.S. Peace Corps - about OLPC, i.e. the availablility of inexpensive > laptops that can used in an environment without ready access to electicity. > > He tells me books are difficult to access, and that he could see it as a > great advantage to be able to retrieve and distribute books and other > text information electronically. Sounds logical, and the kind of thing I > would expect OLPC to be focusing upon. > > What are we talking about here? I think availability of non-programming information on the laptop is really important too. But Arthur, this is the Python Edu-SIG, what do you expect me to write about here? -- Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org From ajsiegel at optonline.net Wed Nov 29 18:53:58 2006 From: ajsiegel at optonline.net (ajsiegel at optonline.net) Date: Wed, 29 Nov 2006 17:53:58 +0000 (GMT) Subject: [Edu-sig] FYI: PataPata postmortem link In-Reply-To: <456DB5D6.7040208@colorstudy.com> References: <456A0C0A.2010603@kurtz-fernhout.com> <456B2B10.8060702@colorstudy.com> <456BA92A.8090703@kurtz-fernhout.com> <456C6125.7020707@colorstudy.com> <456D6F89.5090705@optonline.com> <456DB5D6.7040208@colorstudy.com> Message-ID: From: Ian Bicking > I think availability of non-programming information on the > laptop is > really important too. But Arthur, this is the Python Edu-SIG, > what do > you expect me to write about here? Whatever you like. You've earned that. But in my way, and by my own assessment, so have I. Art From pdfernhout at kurtz-fernhout.com Wed Nov 29 22:38:29 2006 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Wed, 29 Nov 2006 16:38:29 -0500 Subject: [Edu-sig] FYI: PataPata postmortem link In-Reply-To: <456DB56A.20009@colorstudy.com> References: <200611291606.24789.david@boddie.org.uk> <456DB56A.20009@colorstudy.com> Message-ID: <456DFDD5.5040804@kurtz-fernhout.com> Ian Bicking wrote: > There's certainly tree-like structures in memory (and pipeline, and > cubbies, and all sorts of other data structures). And it's entirely > reasonable to create a browser for these objects, where you can inspect > and traverse those in-memory objects. > > Where that currently falls down is that while you can change those > objects, that change is not generally persistent. When the process is > restarted, it will restart just like it was before. You previously brought up the issue of "knowing the state of an object vs. knowing how it got that way" in the context of development tools for kids and the OLPC project. Which makes me think about something related to my Pointrel data repository approach, some examples of which (including in Python) are here: http://sourceforge.net/projects/pointrel/ and also in a subdirectory called Pointrel of the PataPata project code (where I implement a crude Smalltalk environment but on top of Python). http://sourceforge.net/projects/patapata Essentially, the Pointrel system stores triples (sometimes quads or octs) which denote the change in state of the system over time. So, for example: Relation# A B C 1: X value 10 2: Y value 20 3: X value 20 4: Y Value 10 5: Y Value 20 This could be interpreted as showing two variables X and Y changing their values. (In practice this would be more complex, I'm just simplifying this here). You coudl also imagine: Relation# A B C 0001: X value 10 0002..0101: [internal changes (e.g. stack) for bytecode processing] 0102: Y value 20 0103..1002: [internal changes (e.g. stack) for bytecode processing] 1003: X value 20 1004..2003: [internal changes related to code processing] 2004: Y Value 10 2005..3004: [internal changes related to code processing] 3005: Y Value 20 The key thing is that if you also use the system to store the state related to the processor in one stream of changes (which the version I put in PataPata does, although not maybe general enough here as I tried to split it up into two memory steams of changes in that particular version), then, when you want to know what the state was of the system when any variable was changed, your tool could look at the most recent change to a field, and then working backward from there, see what the current state of the program was. This is sort of like storing a stack trace or the state of the machine whenever any pixel is set, but now it is looking at it in terms of when any variable is set (or *any* other changer is made). So, with the right tools, it would be at least easy for a novice programmer to see what was changing a piece of code. Now there still remains the problem you raise -- where to intervene if you want a persistent change. And also, there remain the complex logical problem of then pursuing a set of changes back in time and mapping them onto programmer "intent". Anyway, I thought I'd just mention this aspect of some versions of the Pointrel system, because with people always choosing to use (more robust) relational database systems like Postgres or MySQL, and with the ascendance of RDF for storing triadal information, and as other opportunities have passed by (e.g. easily adding OO to C) during the more than twenty years I've played around with these concepts, the Pointrel system has become a bit of a solution still looking for a good problem. :-) But clearly here is a problem it could solve (and I have always liked the Pointrel system for its promise of being able to do that, although, to be fair, OCaml manages something similar when its debugger steps backwards in time by using checkpoints and recalculating state from them -- although it can't deal well with IO issues which might be different during the recalculation from a checkpoint). Anyway, what occurs to me is I have never thought of emphasizing this aspect of being able to step backwards in the debugger as well as easily find the point in time when a variable was changed (as well as the state of the entire system at that time) in the context of a programming environment for *beginners*, so that is an idea I have to think about. And, it also lets you find out when any pixel was changed, if bitmaps are stored within triads. Of course, this is all very inefficient in some senses to store all this information and to search it, but in a system for small applications it might not be noticeable, or if it was noticeably slow, it still might be worth the wait for beginners in some situations (although in general beginners need faster systems then experts because they make so many more mistakes and a fast cycle time lets them learn faster and better). Again though, it does not solve the problem of how to make changes (persistent or not) once you have that information by understanding what state the system was in (and the related intent of the code) when of interest something happened in a way other than what you wanted. But maybe it could be linked with some other approaches that did (perhaps Smalltalk-like in terms of an image of live objects). --Paul Fernhout