From david at boddie.org.uk Fri Dec 1 00:44:05 2006 From: david at boddie.org.uk (David Boddie) Date: Thu, 30 Nov 2006 15:44:05 -0800 Subject: [Edu-sig] FYI: PataPata postmortem link Message-ID: <200611301544.AA1734672486@boddie.org.uk> On Wed, 29 Nov 2006 10:29:30 -0600, Ian Bicking wrote: [Constrained objects and persistence] >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. Sure. The interesting things begin when you start to (ab)use these layout tools to describe processes. For example, using Qt Designer's signals and slots editor to describe higher-level actions in an application. >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. Rather than serialising Python objects, it's possibly easier to think about describing components that can be implemented in Python. This means that you're no longer editing Python, but tweaking parameters for some set of components in a flowchart, and optionally rearranging them to do different things. Maybe that's a step too far. >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. I agree. >Forking would clone a process. I'm not really interested in cloning the process. I'm thinking about restarting individual "smaller" processes - that is, processes with fewer responsibilities than normal applications. You would need more than one of these to do interesting things, and they would communicate through interfaces. [Reloading modules] >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. Sure. That's why it would be interesting to use clearly-separated components that can be reconfigured and (re)started. >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. Or maybe just turn everything into separated components; or use a different way to describe discrete packages of Python, perhaps inspired by an existing XML format for GUIs. There's lots of scope for different approaches, but it's quite easy to get distracted by the detailed techniques required to achieve them. As PataPata has perhaps taught us, I think it's important to establish some limits on what you want to achieve and remain focused on that. David From david at boddie.org.uk Fri Dec 1 00:01:31 2006 From: david at boddie.org.uk (David Boddie) Date: Thu, 30 Nov 2006 15:01:31 -0800 Subject: [Edu-sig] OLPC (was FYI: PataPata postmortem link) Message-ID: <200611301501.AA1925644490@boddie.org.uk> On Wed Nov 29 16:17:12 CET 2006, Bert Freudenberg bert 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. There may be little _visible_ activity, but not everything is discussed and planned on edu-sig. ;-) Still, your concerns are valid. It may be that the OLPC program needs to reach out further to certain interested parties. David From delza at livingcode.org Fri Dec 1 01:20:51 2006 From: delza at livingcode.org (Dethe Elza) Date: Thu, 30 Nov 2006 16:20:51 -0800 Subject: [Edu-sig] FYI: PataPata postmortem link In-Reply-To: <200611301544.AA1734672486@boddie.org.uk> References: <200611301544.AA1734672486@boddie.org.uk> Message-ID: <9FF61DCE-108B-474D-8541-AD6250671B06@livingcode.org> On 30-Nov-06, at 3:44 PM, David Boddie wrote: > On Wed, 29 Nov 2006 10:29:30 -0600, Ian Bicking wrote: > > [Constrained objects and persistence] > >> 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. It's unfortunate that Glade (and Renaissance for Cocoa, and XUL for Mozilla, and BML for Java and etc.) are all so closely tied to their respective toolkits. It makes it harder to get good re-use. And having a declarative, HTML-like language for UI building could be quite powerful. [snip] > Rather than serialising Python objects, it's possibly easier to > think about > describing components that can be implemented in Python. This means > that > you're no longer editing Python, but tweaking parameters for some > set of > components in a flowchart, and optionally rearranging them to do > different > things. Maybe that's a step too far. This sounds like a Smalltalk image. >> 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. > > I agree. Oberon, Self, and Hypercard allowed you to get "behind" the widgets to see the code they would invoke, and the code that created them. HTML and the current desktop-widget tools do this too. It requires some additional work on the UI framework to support this, but a UI that was built from Python or XML should be able to support it. >> Forking would clone a process. > > I'm not really interested in cloning the process. I'm thinking about > restarting individual "smaller" processes - that is, processes with > fewer > responsibilities than normal applications. You would need more than > one > of these to do interesting things, and they would communicate through > interfaces. Interestingly enough, Stackless Python can do this now. You can create "tasklets" which are lightweight processes that can be serialized, sent over a network, restarted, and communicate with each other. [rest of dicussion snipped. Interesting, but I don't have anything to add] --Dethe "Any idea that couldn't stand a few decades of neglect is not worth anything." --Gabriel Garcia Marquez From delza at livingcode.org Fri Dec 1 01:31:40 2006 From: delza at livingcode.org (Dethe Elza) Date: Thu, 30 Nov 2006 16:31:40 -0800 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: <64AA1EF7-4850-46E0-97AE-6DED859A518B@livingcode.org> On 29-Nov-06, at 4:45 AM, Bert Freudenberg wrote: > 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'd love to write software for the OLPC, but I don't have one available. The virtual version is distributed as a VMWare image, which is great as far as it goes. The VMWare player hasn't been ported to my computer yet (Mac Intel) and the image doesn't load in Parallels (the VM I use for running Windows for testing). I've signed up for the beta program with VMWare, but haven't heard back from them. So unless I want to spend several hundred dollars on a computer to run a simulation of the $100 laptop, I'm out of the running. I'm sure when the simulator (and the real thing) get into more hands you will start to see more software for it. --Dethe Young children play in a way that is strikingly similar to the way scientists work --Busytown News From david at boddie.org.uk Fri Dec 1 01:50:20 2006 From: david at boddie.org.uk (David Boddie) Date: Thu, 30 Nov 2006 16:50:20 -0800 Subject: [Edu-sig] FYI: PataPata postmortem link Message-ID: <200611301650.AA1836777810@boddie.org.uk> On Thu, 30 Nov 2006 16:20:51 -0800, Dethe Elza wrote: >Oberon, Self, and Hypercard allowed you to get "behind" the widgets >to see the code they would invoke, and the code that created them. >HTML and the current desktop-widget tools do this too. It requires >some additional work on the UI framework to support this, but a UI >that was built from Python or XML should be able to support it. Depending on what you mean by "the code they would invoke", I think that may be a bit too much detail for some people. A high-level view would be interesting, though. >Interestingly enough, Stackless Python can do this now. You can >create "tasklets" which are lightweight processes that can be >serialized, sent over a network, restarted, and communicate with each >other. Yes, that's interesting to know. I had something like that in mind, but I don't have any experience of Stackless Python. >[rest of dicussion snipped. Interesting, but I don't have anything >to add] And I don't really have time to contribute to such a deep discussion, no matter how interesting it is. :-( David From tom.hoffman at gmail.com Fri Dec 1 02:39:17 2006 From: tom.hoffman at gmail.com (Tom Hoffman) Date: Thu, 30 Nov 2006 20:39:17 -0500 Subject: [Edu-sig] OLPC (was FYI: PataPata postmortem link) In-Reply-To: <64AA1EF7-4850-46E0-97AE-6DED859A518B@livingcode.org> 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> <64AA1EF7-4850-46E0-97AE-6DED859A518B@livingcode.org> Message-ID: <92de6c880611301739n1827451ch31c759c546c40123@mail.gmail.com> On 11/30/06, Dethe Elza wrote: > On 29-Nov-06, at 4:45 AM, Bert Freudenberg wrote: > > I'd love to write software for the OLPC, but I don't have one > available. The virtual version is distributed as a VMWare image, > which is great as far as it goes. The VMWare player hasn't been > ported to my computer yet (Mac Intel) and the image doesn't load in > Parallels (the VM I use for running Windows for testing). I've > signed up for the beta program with VMWare, but haven't heard back > from them. So unless I want to spend several hundred dollars on a > computer to run a simulation of the $100 laptop, I'm out of the running. Actually, the OLPC provides a standard disk image you can use with qemu. I packaged one of those up last week as a vmware appliance and posted it to my blog, which has subsequently been downloaded an zillion times, since it suddenly made it easy for average Windows users to have a crack at it. So yeah, on one hand, you could say the OLPC folks could be doing a better job of marketing (like reaching out to those Windows users themselves), but on the other hand, the main criticism of the project is probably that it is all hype and marketing, so either way, they lose ;-). No matter how you slice it though, it does seem to be more tricky to get an emulator for it running on the Mac. qemu should work, albiet more slowly than Parallels. The main wiki page for OLPC emulation is here: http://wiki.laptop.org/go/OS_images_for_emulation --Tom From delza at livingcode.org Fri Dec 1 03:23:03 2006 From: delza at livingcode.org (Dethe Elza) Date: Thu, 30 Nov 2006 18:23:03 -0800 Subject: [Edu-sig] OLPC (was FYI: PataPata postmortem link) In-Reply-To: <92de6c880611301739n1827451ch31c759c546c40123@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> <64AA1EF7-4850-46E0-97AE-6DED859A518B@livingcode.org> <92de6c880611301739n1827451ch31c759c546c40123@mail.gmail.com> Message-ID: On 30-Nov-06, at 5:39 PM, Tom Hoffman wrote: > Actually, the OLPC provides a standard disk image you can use with > qemu. I packaged one of those up last week as a vmware appliance and > posted it to my blog, which has subsequently been downloaded an > zillion times, since it suddenly made it easy for average Windows > users to have a crack at it. And OS X users too... > So yeah, on one hand, you could say the OLPC folks could be doing a > better job of marketing (like reaching out to those Windows users > themselves), but on the other hand, the main criticism of the project > is probably that it is all hype and marketing, so either way, they > lose ;-). At least they're not in Kathy Sierra's "Zone of Mediocrity." As long as folks either love 'em or hate 'em, then chances are they're doing something important. > No matter how you slice it though, it does seem to be more tricky to > get an emulator for it running on the Mac. qemu should work, albiet > more slowly than Parallels. Qool. I haven't looked into running other emulators in a while. > The main wiki page for OLPC emulation is here: > > http://wiki.laptop.org/go/OS_images_for_emulation Alright. I didn't know about that. I had seen a blog post (maybe yours, can't remember off-hand) that linked to images for VMWare. But the page you link to above has instructions for getting it running under Parallels, so I'll see if I can't get that working. Thanks for the pointers! --Dethe "...coding isn't the poor handmaiden of design or analysis. Coding is where your fuzzy, comfortable ideas awaken in the harsh dawn of reality. It is where you learn what your computer can do. If you stop coding, you stop learning." Kent Beck, Smalltalk Best Practice Patterns From delza at livingcode.org Fri Dec 1 03:31:02 2006 From: delza at livingcode.org (Dethe Elza) Date: Thu, 30 Nov 2006 18:31:02 -0800 Subject: [Edu-sig] FYI: PataPata postmortem link In-Reply-To: <200611301650.AA1836777810@boddie.org.uk> References: <200611301650.AA1836777810@boddie.org.uk> Message-ID: On 30-Nov-06, at 4:50 PM, David Boddie wrote: > On Thu, 30 Nov 2006 16:20:51 -0800, Dethe Elza wrote: > >> Oberon, Self, and Hypercard allowed you to get "behind" the widgets >> to see the code they would invoke, and the code that created them. >> HTML and the current desktop-widget tools do this too. It requires >> some additional work on the UI framework to support this, but a UI >> that was built from Python or XML should be able to support it. > > Depending on what you mean by "the code they would invoke", I think > that may be a bit too much detail for some people. A high-level view > would be interesting, though. What I mean by that, is that if you examine a button or menu, you would see the code it will call, much like the "onclick" handler in HTML. That might only be the name of a function, in which case it would be useful to be able to examine *that* and get to the actual function. For all that to work, you'd need some kind of Hypertext system. If only there was one of those in common use that we could build on... The other alternative if you view source on a button would be to get to the code for the button itself, whether that may be Button (title="Do Something", action="foo(this)", color="green") or