I would have liked to be a fly on the wall during that, even though I suspect it was way beyond my comprehension... Which leads me to one of my most brilliant ideas ever (IMHO)... With the second life setup used by NPR's Science Friday radio show http://www.sciencefriday.com/ and the Metanomics virtual world TV show http://www.metanomics.net/ it IS possible to be a fly on the wall during such an event. My idea: have 2 talented Squeak programmers working on some problem. It might be a simple one or hideously complex or whatever. Have a skype connection between the two + a VNC connection. Now, pipe the skype into Second Life voice. Pipe the VNC into a passive streaming QT connection. Simulcast on Second Life and a web page. Leverage the metanomics mega-local-chat for kibbitzing and questions (highlighted by prefixing QUESTION: to the local chat). Now let the pair programming begin. Occasionally, one of the programmers can glance at the comments flowing past from Second Life and the website and respond (you can writer a filter the comments by the prefix "QUESTION:", so they can go to a separate window, ditto with "SUGGESTION:"). What do you gain? You gain the ability to let other programmers look over your shoulder during pair programming and discuss what is going on quietly among themselves, which could make for a wonderful real-world teaching tool. You ALSO gain the ability to have an unlimited number of programmers glancing over your shoulder and making suggestions without distracting the flow of the programming session. This wouldn't be hard to set up. I know the people who work on the Science Friday and Metanomics projects and I suspect they would be quite interested in working this up. The only issue is $$ for the simulcast video stream. You could start small for tests and work up. With "unlimited" funding you could easily have 500+ passive participants in the session once it gets going. Everyone is thinking "why not do this with croquet/cobalt?" The answer is that you can! BUT, SciFri and Metanomics have already set up the machinery for this on a large scale in Second Life, and there is a pre-existing potential audience of many thousands of computer geeks who lurk in Second Life already at any given moment. It would also be great advertising for Squeak/Cobalt/Croquet if such sessions showed off some spiffy aspect of those technologies. You could have purely beginning level, intermediate level and advanced teaching sessions, as well as real-world problem solving sessions. They may or may not be widely watched, but you never know unless you try. And imagine if such a session were slash-dotted and/or mentioned on Science Friday... Lawson (always in marketing mode) Alexandre Bergel wrote:
Aldo and I seat down during the Pharo Sprint on Saturday. We had fun. Below what we did.
ISSUE #262 (fixed) Doits are now executed by primtive. This means, a doit method is *never* installed in a class. We removed all now unnecessary checks of isDoit
- Behavior>>allLocalCallsOn: - ChangeSet>>atSelector: selector class: class put: changeType - MethodReference>>isValid - PCCByCompilation>>methodsWithDisabledCall - PackageInfo>>methods - SystemNavigation>>browseAllCallsOn: aLiteral localTo: aClass
Pair programmed with Aldo Mettini
Slice_262_isDoIt-Alexandre_Bergel.1 in Pharo Inbox
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ISSUE #1486 (fixed)
Added BehaviorTest>>testAllLocalCallsOn
Pair programmed with Aldo Mettini during the Pharo Sprint @ Smalltalks 2009
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
ISSUE #1488 (new)
Dictionary is not a superclass of SmallDictionary, and SmallDictionary is not a subclass of Dictionary. The only common superclass of these two classes is Collection. Putting unreferencedKeys in Collection does not look too good as well. Therefore, unreferencedKeys looks like to be a good candidate for being shared by a trait.
Pair programmed with Aldo Mettini during the Pharo Sprint @ Smalltalks 2009
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
ISSUE #261 (fix)
Even though allCallsOn: implies something about "calls" which seems to be related to sends, it actually even is used for references to classes.
We added a SystemNavigation>>allReferencesTo: aLiteral that returns the list of methods referencing aLiteral. We simplified allCallsOn: since now it acts on symbols only. It raises a deprecation warning if a binding is provided to allCallsOn:. We refactored all callers of allCallsOn: and wrote some tests (for the one that was easy to write): BehaviorTest>>testAllCallsOn
Pair programmed with Aldo Mettini during the Pharo Sprint @ Smalltalks 2009
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Cheers, Alexandre