Squeak-dev July 2009

squeak-dev@lists.squeakfoundation.org

126 participants
195 discussions

I suggest a change to PluggableListMorph
by Niko Schwarz 04 Jul '09

04 Jul '09

Hello! Typing a burst into a pluggable list morph results in a behaviour quite remote from e.g. Finder. E.g. typing the same key twice will go to the next match. I suggest changing the behaviour to make it resemble the behaviour that a user may anticipate more closely. I submitted a fix for the situation as Polymorph-Widgets-nes.79 into the Pharo inbox just now. see http://code.google.com/p/pharo/issues/detail?id=926.

1 0

Method missing in trunk from update 7160
by Ken Causey 04 Jul '09

04 Jul '09

I've started checking the current trunk against all the changes applied in the update stream since 7159. One of the methods in 7160 is !PartsBin methodsFor: '*BabySRE-connectors-initialization' stamp: 'edc 12/4/2007 16:01'! listDirection: aListDirection quadList: quadList buttonClass: buttonClass and it is missing in trunk. There are no senders. Was its removal intentional? Ken

4 10

Re: [squeak-dev] Re: Deprecation policy
by Keith Hodges 04 Jul '09

04 Jul '09

Ralph wrote: > How about the following. In Squeak 3.11 we add a method deprecated3.11 > in Object which does nothing and is called by each deprecated method. > When Squeak 3.12 (say) is released it has a method deprecated3.12 for > newly deprecated methods. Meanwhile method deprecated3.11 now > generates an error if invoked. When Squeak 3.13 is released all methods > that invoke deprecated3.11 are removed and deprecated3.12 now generates > an error. Of course all newly deprecated methods in Squeak 3.13 invoke a > new method in object called deprecated3.13 which does nothing. etc. > > For deprecated classes in Squeak 3.11 we implement a method > deprecatedClass3.11 which is invoked by each deprecated class's new > method and implemented in Object class. It does nothing for Squeak > 3.11 and generates an > error in Squeak 3.12. In Squeak 3.13 it disappears along with the > classes that > invoke it. > > This is very interesting. Ralph is doing exactly what I have done in Bob, planning ahead what should happen in future releases. That is what Bob does in code, those steps are already coded. For example the task #removeDeprecatedApi is already included in the task that generates every new release. You have just demonstated the reason for having a new release process, that was called 3.11, the ability to encode the release process in such a way as it can be repeated every 2 months or so, for test and "release often" development. Keith

1 0

Re: Deprecation policy
by Ralph Boland 04 Jul '09

04 Jul '09

> I would like to suggest that we develop a formal deprecation policy. It > could be as simple as deprecate in one release, remove in the next. I > just think we need to be consistent about it and remove no individual > methods without following it. How this relates to the idea of > repackaging and removing whole categories of classes, I'm not so sure. > Ken How about the following. In Squeak 3.11 we add a method deprecated3.11 in Object which does nothing and is called by each deprecated method. When Squeak 3.12 (say) is released it has a method deprecated3.12 for newly deprecated methods. Meanwhile method deprecated3.11 now generates an error if invoked. When Squeak 3.13 is released all methods that invoke deprecated3.11 are removed and deprecated3.12 now generates an error. Of course all newly deprecated methods in Squeak 3.13 invoke a new method in object called deprecated3.13 which does nothing. etc. For deprecated classes in Squeak 3.11 we implement a method deprecatedClass3.11 which is invoked by each deprecated class's new method and implemented in Object class. It does nothing for Squeak 3.11 and generates an error in Squeak 3.12. In Squeak 3.13 it disappears along with the classes that invoke it. Note that users can easily remove or modify the deprecation methods or invocations to suit their purposes. They know what they are doing and implicitly are prepared to live with the consequences. Ralph Boland

1 0

Squeakers & Etoys
by Timothy Falconer 04 Jul '09

04 Jul '09

Hi everyone, Scott Wallace & Rita Freudenberg pointed me to the recent thread on squeak-dev about Squeak, Etoys, and the future. Quite a good read. Even missed a lunch meeting because I was so caught up with it. For the last six months, I've been helping to create Squeakland Foundation, the spin-off from VPRI to champion Etoys and education. As a group, we've talked quite a bit about the issues raised in this thread. Who's we? http://squeakland.org/about/people/ Until now, we've been mostly getting our act together, planning Squeakfest Brasil and Squeakfest USA (squeakfest.org), and creating new educational materials. VPRI has been a big part of this process, spending considerable time & money helping us become self-sufficient, along with helping us retain the spirit that led to the creation of Squeak and Etoys. Our goal is to become much more collaborative in our decision-making, with both educators and developers. So let's start now ... here's the view from Squeakland. Please respond with as much passion and rancor as you like. We want to hear all sides. In my opinion ... ** Etoys has been extremely successful. There are many, many examples of inspiring work around the world. I came to VPRI's attention because of my work at Waveplace, where last year we trained many teachers and kids in some difficult places, like Haiti and Nicaragua. I've lived and breathed Etoys, teaching adults & kids, experiencing first hand what it's like to have a whole room hitting the same stumbling block at the same time. But here's the thing ... with the right mentoring they *get through* the stumbling blocks and reach the "light bulb" moment when they experience mastery and become hooked. Our first-hand experience has been overwhelmingly positive. But never mind words ... what's missing from this talk are the children themselves: Have a look here: http://waveplace.com/locations/nicaragua/movie.jsp?id=80 (six minutes) or here: http://waveplace.com/locations/nicaragua/movie.jsp?id=94 (thirty seconds) The look on the girl's face in the longer video (around 5:32) really tells the whole story for me. Transformation. ** Etoys is more than visual programming for kids. Squeakland's focus is to teach *with* Etoys. Towards that end we've begun work on a full-spectrum course that uses Etoys to help teach what teachers already need to teach: language arts, social studies, science, math, etc. We want to help the whole school, not just the computer lab. More here: http://confluence.immuexa.com/display/sq/Squeakland+Courseware and here: http://www.etoysillinois.org/library.php ** Etoys is very effective for younger children (6 to 12 years old) Our recent focus has been largely for this age range, as we believe Etoys has benefits over Alice and Scratch. It's also the age when the most profound transformations can occur, when creative problem solving can be reinforced in ways that last through a child's whole education. ** Squeakland Foundation can help teach both Squeak and Etoys When choosing the name for the new organization, we purposely kept "Squeak" in the name because we believe in the transition from Etoys to Squeak, and foresee a future where the efforts of Squeakland will help teach & inspire Squeak as well. We see Squeak as a natural extension of Etoys ... many educators and administrators have expressed interest in this. Yes, Alice and Scratch are suited to teaching programming to middle schoolers and high schoolers, but so is *Squeak*, with the right focus and training materials. We'd like to help paint this picture ... the "what next?" when kids outgrow Etoys. Please help us. ** Etoys could use improvement We're well aware of the stumbling blocks for new users of Etoys. A colleague once described Scratch as "low entry, low ceiling" and Etoys as "high entry, high ceiling". Much of our discussions have centered around lowering the barriers to entry, which includes user interface fixes, better tutorials, better documentation, etc. When I first met Alan Kay, I told him Squeakland needed a better website. He quickly responded, "Maybe you could help us with that." (How could I say no?) Now I put it to you ... "maybe you could help us with Etoys" ... we genuinely need your help. Your work will help inspire children from around the world, like the little girl in the Nicaragua movie. Please let us know you're out there by clicking "contact" on squeakland.org. You can also look over our evolving wiki & issue tracker & newsletter: http://wiki.squeakland.org http://tracker.squeakland.org http://squeakland.org/news/newsletter/ If something seems to be missing, it's because we're waiting for you. Thank you for your time, Timothy -- Timothy Falconer Squeakland Foundation http://squeakland.org 610-797-3100

3 4

Completed audit comparing trunk as of today (7/3/09) to 3.10.2 release as represented by update stream
by Ken Causey 04 Jul '09

04 Jul '09

I have completed my audit through the update stream between 7159 and 7179 checking the current status of trunk. The only issues I find: 1. 7161 - method categorized as BabySRE extension method and so packaged in seperate package not loaded. Move into proper category and mark as deprecated? As an additional data point, this method exists in 3.10-7159 but not in a *BabySRE extension category. 2. 7161 - Do-it to refresh objects flap not 'done'. 3. Version number. Policy still to be discussed. Otherwise it looks OK to me... Oh, ran the tests, one new failure TimeTest>>#testGeneralInquiries for some reason it seems that the now is not reliably less than or equal to now. Looks like a pain to track down to me. Any takers? Ken

2 1

SqNumberParser SqNumberParserTest
by Ken Causey 03 Jul '09

03 Jul '09

Is there any reason to not drop the Sq prefixes from SqNumberParser and SqNumberParserTest? Ken

1 0

Do-its in trunk
by Ken Causey 03 Jul '09

03 Jul '09

Another issue with update 7160 as represented currently in trunk. One of the issues addressed with this update was http://bugs.squeak.org/view.php?id=6793 and it was addressed with a do-it, one of the conveniences of changesets. It appears that this do-it was left behind in the conversion as the report is now valid again. How would I go about addressing that? Ken

1 1

Separation of EToys and Squeak
by Ralph Boland 03 Jul '09

03 Jul '09

I have never used EToys and am no Squeak guru but allow me to an opinion which to me at least appears obvious. My understanding from previous posts is that originally EToys was build first and Squeak came later which is why they are so closely integrated. If this is true then it was still a mistake to so closely integrate EToys and Squeak; simply bad design! But what's done is done. If the EToys guru's feel now that it is not worth their while to factor out Squeak from EToys then who am I to judge especially since I am not willing to help. However for Squeak it is a different matter. I consider that EToys must be factored out of Squeak and hopefully made into a loadable package. It is simply good design that must be done preferably sooner than later. When refactoring is needed but not done the mess accumulates until refactoring becomes unavoidable but very difficult to do. So why not do it now; that would be by you of course; I know nothing about EToys; my babies are finite state machines, parsing, and for the moment, the FasterSets package. :-) Ralph Boland

1 0

Problem with fork
by Mariano Martinez Peck 03 Jul '09

03 Jul '09

Hi all, this is my first post here, just joined this group so let me do a quick introduction. I have 10+ years of experience doing full-time development with VisualWorks (creating trading platforms for the European energy exchanges). Also I have near-zero experience with using Squeak or how its development process works. I'll slowly cut my teeth, starting by interacting on this mailing list. Multi threading is something I have spent a lot of quality time with, so I want to share some thoughts on the following: |semaphores tr| semaphores := Array new: 10. tr := ThreadSafeTranscript new. tr open. 1 to: 10 do: [ :index | semaphores at: index put: Semaphore new ]. 1 to: 10 do: [:i | [ tr nextPutAll: i printString, ' fork '; cr. (semaphores at: i) signal. ] fork ]. semaphores do: [:each | each wait ]. tr show: 'all forks proccesed'; cr. I have seen this pattern often (allocating a semaphore for every forked process), I usually interpret this as a signal that such code is still in its first 'make it work/make it right' stages. What a lot of people don't realize is that at its heart a semapore is a thread-safe counter/register (and if you look at the hierarchy it is implemented on you wouldn't guess that either, since the hierarchy stresses the implementation part that manages waiting processes rather than the counter aspect). So trying to take the code snippet toward 'make it abstract' territory this could be refactored to lean more on the counter aspect of semaphores and use only a single semaphore: |count sem tr| tr := ThreadSafeTranscript new. tr open. count := 10. sem := Semaphore new. 1 to: count do: [:i | [ tr nextPutAll: (i printString, ' fork\') withCRs. sem signal. ] fork]. count timesRepeat: [sem wait]. tr show: 'all forks proccesed'; cr. Now the above is about as far as you can go with the current Squeak and VisualWorks implementations so you can take it as a simple refactoring advise. However I want to press on a bit more (and go a bit off-topic for this list ;-) because I feel it still has a big problem: we need to maintain a 'count' and pass that between the two loops in the above example. In the current example this is not much of a problem but in more complex applications where the forking is done by yet other forked processes we will need to make 'count' thread-safe as well -- I find this very ugly, because you will need an extra semaphore just to make the original semaphore work as required. Furthermore you cannot add new forked processes once the second loop has started running. So here is an experiment I did a couple of years ago with VisualWorks: I altered the VM (just one line of its source ;-) so it would react properly to semaphores that have negative values in the 'excessSignals' instance variable, and I added a method #unsignal to Semaphore that would decrease the value of that ivar. In my experiments that yielded many opportunities to simplify multiprocessing code (not only for thread synchronization but also for passing around counts in a thread-safe register!). In the above code that would allow us to 'pre-load' the semaphore at the place where the threads are created with as result that the 'count' variable can be removed and the bottom loop can be removed too: |count sem tr| tr := ThreadSafeTranscript new. tr open. sem := Semaphore forMutualExclusion. "We need one excessSignal to balance the #wait below" 1 to: 10 do: [:i | sem unsignal. "outside the forked code" [ tr nextPutAll: (i printString, ' fork\') withCRs. sem signal. "balance the unsignal" ] fork]. sem wait. "no loop, no need to know the count!" tr show: 'all forks proccesed'; cr. Above was just a simple refactoring, but look at how I needed it: |sem tr| tr := ThreadSafeTranscript new. tr open. sem := Semaphore new. "no excessSignal this time" "set up a monitoring system first(!)" [ sem wait. tr show: 'all forks proccesed'; cr ] fork. "then create jobs (in my case I had only a single first job that would recursively create more jobs, not shown here)" 1 to: 10 do: [:i | sem unsignal. [ tr nextPutAll: (i printString, ' fork\') withCRs. sem signal. ] fork]. "Now that we are sure at least one job is entered balance the #wait we started out with" sem signal. Since we elided 'count' I can move the code that relied on it up in front of the thread creation code, I very much like this flavor of decoupling. I guess this illustrates that Semaphore is stuck in the 'make it work/ make it right' phase for thirty years now, and that moving it into 'make it abstract' territory will make lots of hairy multi-threading code much simpler to express... (And for those thinking this through: yes I did implement a thread- safe #add: and #valueWithReset on semaphore too ;-) I hope I didn't bore y'all and stray to far off-topic, but I did want to share this bit of insight I gained by tinkering with the semaphore implementation: semaphores are thread-safe counters at their heart. Cheers, Reinout ------- PS: big congrats with the license cleaning milestone, this is what finally pulled me into this project :-) _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

Jump to page: