etoys-dev November 2006

etoys-dev@lists.squeakfoundation.org

13 participants
32 discussions

[Etoys] View Source Button
by Bert Freudenberg 28 Nov '06

28 Nov '06

A complete stack trace per pixel ... maybe not that outrageous an idea, actually ;-) The discussion actually goes about what to do with the "view source" button on the XO. I though about mapping this to the user interrupt key (Cmd-.), but ideally we would peel away one layer at a time ... - Bert - Begin forwarded message: > From: "Paul D. Fernhout" <pdfernhout(a)kurtz-fernhout.com> > Date: November 28, 2006 4:12:42 GMT+01:00 > To: "edu-sig(a)python.org" <edu-sig(a)python.org> > Subject: Re: [Edu-sig] FYI: PataPata postmortem link > > 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. >> > _______________________________________________ > Edu-sig mailing list > Edu-sig(a)python.org > http://mail.python.org/mailman/listinfo/edu-sig

1 0

[Etoys] Fwd: PataPata postmortem link
by Bert Freudenberg 27 Nov '06

27 Nov '06

Hi folks, Paul Fernhout, former Squeaker, posted an interesting post-mortem analysis of his experiment to create an educational environment in Python: http://patapata.sourceforge.net/critique.html - Bert - Begin forwarded message: > From: "Paul D. Fernhout" <pdfernhout(a)kurtz-fernhout.com> > Date: November 26, 2006 22:50:02 GMT+01:00 > To: "edu-sig(a)python.org" <edu-sig(a)python.org> > Subject: [Edu-sig] FYI: PataPata postmortem link > > 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 > _______________________________________________ > Edu-sig mailing list > Edu-sig(a)python.org > http://mail.python.org/mailman/listinfo/edu-sig

2 1

[Etoys] [FIX]SqueakMapLoader
by karl 23 Nov '06

23 Nov '06

The SqueakMap loader in the OPLC image is not the latest version and will update it self if you try to use it. The problem is that if you don't save the image after SqueakMap is updated you will not be able to run it again. This is a small fix for that. Karl 'From OLPC1.0 of 17 August 2006 [latest update: #1065] on 14 October 2006 at 3:00:42 pm'! Object subclass: #SMInstallationRegistry instanceVariableNames: 'installedPackages installCounter map' classVariableNames: '' poolDictionaries: '' category: 'SMBase-domain'! SMPersonalObject subclass: #SMMaintainableObject instanceVariableNames: 'feedbackEmail' classVariableNames: '' poolDictionaries: '' category: 'SMBase-domain'! !SmartRefStream methodsFor: 'conversion' stamp: 'kfr 10/14/2006 14:55'! sMInstallationRegistryiim0 ^ SMInstallationRegistry! ! !SmartRefStream methodsFor: 'conversion' stamp: 'kfr 10/14/2006 14:54'! sMMaintainableObjectimcunsucromrf0 ^ SMMaintainableObject! !

2 1

[Etoys] Turtle graphics ideas
by Bert Freudenberg 19 Nov '06

19 Nov '06

Interesting turtle graphics, posted to the Python-Edu list. - Bert - Begin forwarded message: > From: "Daniel Ajoy" <da.ajoy(a)gmail.com> > Date: November 19, 2006 5:16:46 GMT+01:00 > To: edu-sig(a)python.org > Subject: Re: [Edu-sig] experiences teaching Python with turtle > graphics? > > On 18 Nov 2006 at 12:00, edu-sig-request(a)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) > > _______________________________________________ > Edu-sig mailing list > Edu-sig(a)python.org > http://mail.python.org/mailman/listinfo/edu-sig

2 1

[Etoys] [FIX]SqueakMapLoader
by karl 18 Nov '06

18 Nov '06

1 0

[Etoys] recent progress
by Yoshiki Ohshima 18 Nov '06

18 Nov '06

Hello, Some of you may have experienced some intermittent problem of our update stream server for the OLPC etoys images. It still works most of the time, but we may be moving out to a new place (and perhaps a new way of doing it) sometime later. The transition should be smooth. As for the recent progress, we have included the World Stethoscope code. There may be some simplification later and merging Markus' idea with it would be good (How is the other stuff going, Markus?) Some optimization of Kedama is done so that it doesn't take so much CPU time when it is idle. The OLPC seems to have some undecided, internal deadlines/milestones and we may synchronize our work with it in a few/several weeks, but we don't know yet. Any ideas, feedback, bug reports are always welcome. Thank you! -- Yoshiki

1 0

[Etoys] Fwd: RFC on your multimedia needs
by Bert Freudenberg 15 Nov '06

15 Nov '06

The message below was sent to the devel list, we might want to chime in with what we need or want for etoys ... - Bert - Begin forwarded message: > From: "Reynaldo H. Verdejo Pinochet" <reynaldo(a)opendot.cl> > Date: November 15, 2006 20:25:23 GMT+01:00 > To: devel(a)laptop.org > Subject: RFC on your multimedia needs > > Hi there > > This is an amazing project, congrats :) > > Ok, I work on mplayer/ffmpeg and I'd like to help you guys out > fullfiting whatever multimedia needs you may have (software wise) > . I had a little chat with some of you on #olpc today and a few ideas > where thrown on the table, Im here asking for your comments and any > other idea you may have, here is what i have so far then: > > 1.- The hability to play/display video is considered a must > 2.- Ttreaming would be nice > 3.- Real time encoding from camera is wished > - would this be the only 'encoding' need? > 4.- Optimization work for geode its a must > - there is already some work on olpc's software repo > 5.- The idea of streamlining mplayer was suggested, sounds doable. > 6.- The idea of building something new on top of ffmpeg was suggested, > sounds unpractical to me but, who knows .. > > Other not mentioned ideas > > 1.- What are the key points of system integration for the > displaying/encoding app? > - file manager ? > - browser ? > 2.- If cli sounds too complex for kids what do you think should be the > main caracteristics of a multimedia app gui? do you have some > usability guidelines i guess, does them apply to this subject? > > There is a lot to add here, hope to get the discussion started. > > Best regards > > Reynaldo > _______________________________________________ > Devel mailing list > Devel(a)laptop.org > http://mailman.laptop.org/mailman/listinfo/devel

1 0

[Etoys] Re: [Trac #441] Duplicate viewers when renaming
by Zarro Boogs per Child 15 Nov '06

15 Nov '06

#441: Duplicate viewers when renaming --------------------+------------------------------------------------------- Reporter: bert | Owner: bert Type: defect | Status: closed Priority: normal | Milestone: BTest-2 Component: Etoys | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by krstic): * status: new => closed * resolution: => fixed Comment: As per previous comment, this is fixed. -- Ticket URL: <http://dev.laptop.org/ticket/441#comment:3> One Laptop Per Child <http://laptop.org/>

1 0

[Etoys] Re: [Trac #441] Duplicate viewers when renaming
by Zarro Boogs per Child 14 Nov '06

14 Nov '06

#441: Duplicate viewers when renaming --------------------+------------------------------------------------------- Reporter: bert | Owner: bert Type: defect | Status: new Priority: normal | Milestone: BTest-2 Component: Etoys | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by ohshima): It is fixed in #1122. -- Ticket URL: <http://dev.laptop.org/ticket/441#comment:1> One Laptop Per Child <http://laptop.org/>

1 0

[Etoys] [Trac #441] Duplicate viewers when renaming
by Zarro Boogs per Child 14 Nov '06

14 Nov '06

#441: Duplicate viewers when renaming --------------------+------------------------------------------------------- Reporter: bert | Owner: bert Type: defect | Status: new Priority: normal | Milestone: BTest-2 Component: Etoys | Keywords: --------------------+------------------------------------------------------- When renaming an object in the viewer, a second viewer is created in the same flap. -- Ticket URL: <http://dev.laptop.org/ticket/441> One Laptop Per Child <http://laptop.org/>

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

etoys-dev November 2006