Squeak-dev October 2006

squeak-dev@lists.squeakfoundation.org

175 participants
305 discussions

Re: 3.9 underscore still there?
by Bill Schwab 30 Oct '06

30 Oct '06

Lex, My preference would be for ANSI compatibility. With that said, having underscored in selectors, and even just all but the first slot, would do almost everying I need. I doubt I use them in variable names, and if I do, I could change it. If I were to move my production code to Squeak, I would be editing a lot more than a few variable names. Most of uses of underscores are matching the outside world, and that is not so readily altered to suit my whim or Squeak's limitations. If we can get Ian's fix in the mainstream, it would be greatly appreciated. Bill Lex spoon: "Bill Schwab" <BSchwab@...> writes: > Please keep in mind that my most emphatic request is to promote Ian's (I > believe) fix, for underscores in all but the first slot in a selector, > to part of the mainstream release so that it will get maintained as the > compiler evolves. I am not aware that it breaks any code. That kind of thing would sound great to me. The stable universe provides a good test for this theory, if anyone wanst to do that test and lend support to the underscores cause. By the way, do you only mean selectors, or also variable identifiers? What would the proposal do about this kind of code? x_3 "is it x := 3, or the identifier x_3 ?" > I disagree with your assessment that I am suggesting a change for legacy > reasons. That was a typo; indeed, I am the one arguing that we support our legacy. I am happy to support the ANSI standard if possible, but I would put the top priority on existing Squeak code. Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bills(a)anest4.anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029

2 1

Re: Squeak is a social community
by mmille10＠comcast.net 30 Oct '06

30 Oct '06

I agree. I think Squeak is a bunch of different groups. Since Smalltalk was the prototype for the modern day personal computer platforms, Mac OS and Windows, they have similar issues. Each of them have different communities to support as well. They have their users who just want to do some word processing, e-mail, and web browsing. They have their "power users" who want to do desktop publishing, web publishing; photo and video editing, business functions, games, etc. They have a development community that writes this software. And they have the system level coders who write system utilities for these platforms. These are different from the Squeak communities, but I'm sure similar dynamics are involved. Each time the OS vendor produces a new upgrade, they recognize they need to provide compatibility and "goodies" to each of these communities in order for the platform to thrive. ---Mark -------------- Original message -------------- From: Lex Spoon <lex(a)cc.gatech.edu> > Howard Stearns writes: > > > Who is Squeak for? What are the guiding principles for decisions? > > > > There's been a lot of discussion about this lately -- as always. So I > > thought some folks might (or might not!) be interested in the > > philosophy that Squeak is defined not by technical nor procedural > > means, but as a social phenomenon among the people who happen to > > consider themselves Squeakers (or Smalltalkers). > > > > Many years ago, Kent Pitman made this argument about Lisp, and I think > > he said it well: http://www.nhplace.com/kent/PS/Lambda.html > > Thanks for the link, Howard, I look forward to reading it. > > I view Squeak as a common area for a lot of different groups, and thus > the social aspect cannot be ignored if you want to understand Squeak. > It's not a project with a single goal and a 5-year plan for getting > there. > > Brenda Laurel compares the situation to Renaissance Festivals, and has > a great way of putting it: "Everyone there is having a good time, but > everyone there is having a *different* good time." > > As a quick stab, we have: > > - The Squeakland project, Alan Kay's favorite branch, which uses > Squeak as a new kind of media. Squeakland tries to > > - Myriad computer-science research groups who love having a free, > malleable Smalltalk as a base to experiement from. > > - Classroom usage for teaching how objects work. > > - Development. Smalltalk is very productive, and Squeak is > a good one. > > - ... and maybe a part of the Hundred Dollar Laptop. > > > An older article I wrote tries to make the same enumeration, as well > as sketch what kind of bilaws would make any sense for such a diverse > group: > > http://people.squeakfoundation.org/article/44.html > > Anyway, I'm sure I left some folks out. What do others think? > > -Lex > >

4 3

Re: 3.9 underscore still there?
by Bill Schwab 30 Oct '06

30 Oct '06

Lex, First, the 3.7 stable universe idea is a good one. Asking me to allow the old code to run is an odd way to put it: I have absolutely no power over it. However, it might be interesting to see how much of that code passes even a basic smoke test. I might be pleasantly surprised, but given the complaints I have read over time re things like the Canvas protocol[*], I suspect that much of the code is broken over far worse things than underscores. Please keep in mind that my most emphatic request is to promote Ian's (I believe) fix, for underscores in all but the first slot in a selector, to part of the mainstream release so that it will get maintained as the compiler evolves. I am not aware that it breaks any code. I disagree with your assessment that I am suggesting a change for legacy reasons. Quite the opposite. I am suggesting it for compatibility with other dialects and ANSI compliance. I submit that yours is the legacy argument. And it is one legacy of Squeak which should not be celebrated. Hijacking the underscore for single-character assignment was a mistake; the same capability could and should have been provided within the editor, keeping the compiler and sources clean. Please allow that to be corrected, albeit at a pace that keeps associated discomfort to a minimum. Sincerely, Bill [*] I'm simply stating that my imperfect memory of unmoderated comments gives the impression that it has been a moving target. The less accurate that statement is, the happier I get - within reason. Lex Spoon: There is a lot of legacy code not even in the image that uses underscore for assignment. Please allow this code to keep working. We should not break massive amounts of code just for legacy reasons. At the very very least, allow such legacy code to file in. If you or anyone have a parsing hack you would like to try, e.g. to allow it in identifiers while still allowing it for assignment, a great sample set would be the 3.7 stable universe. This is 200 packages worth of Squeak content, quite a lot of which uses _ for assignment. If your idea works there without breaking anything, then it is probably okay. The download is here: http://minnow.cc.gatech.edu/squeak/3835 Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bills(a)anest4.anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029

2 1

RE: here is a plan! (was: Smalltalk Reloaded)
by Ron Teitelbaum 30 Oct '06

30 Oct '06

+1 Ron Teitelbaum > -----Original Message----- > From: squeak-dev-bounces(a)lists.squeakfoundation.org [mailto:squeak-dev- > bounces(a)lists.squeakfoundation.org] On Behalf Of Jecel Assumpcao Jr > Sent: Monday, October 30, 2006 10:48 AM > To: The general-purpose Squeak developers list > Subject: here is a plan! (was: Smalltalk Reloaded) > > Guy Bloomfield wrote on Sat, 28 Oct 2006 19:30:14 +1300 > > 2. A functional issue - The ideal Squeak would have Etoys Morphic in > > the image and these could be unloaded by the experienced programmer > > who wants to "Run light without overbyte" whereas the neophyte can > > enjoy them out of the box > > This is a plan that is practical and which I fully support: if we can > unload eToys but not load it back, then let's just include eToys in the > full image that we distribute and allow everyone the one way option of > removing it. I don't mind at all eliminating the Flash logo, the welcome > windows and other stuff every time I begin working with a newly > downloaded image. The fact that I can't get any of these easily back if > I want has never been a problem since I could just start over from a > clean image. > > Sure, a reloadable eToys would be even better but I doubt it will > happen. > > -- Jecel >

1 0

Re: ClassBuilder changes (was: Re: Navigating traits in 3.9)
by Roel Wuyts 30 Oct '06

30 Oct '06

hi Andreas, long time no see :-) rw is me. I had a quick look at the method in the RC2 image. I added a trigger in this method for the change mechanism to tell: * whether the category of a class changed, * whether the class definition changed, * or when it is a new class that was added. The implementation checks for these occurences and is validated by the corresponding unit tests. Do you think there is problems with it ? > Begin forwarded message: > >> From: Andreas Raab <andreas.raab(a)gmx.de> >> Date: 23 octobre 2006 20:40:33 HAEC >> To: The general-purpose Squeak developers list <squeak- >> dev(a)lists.squeakfoundation.org> >> Subject: ClassBuilder changes (was: Re: Navigating traits in 3.9) >> Reply-To: The general-purpose Squeak developers list <squeak- >> dev(a)lists.squeakfoundation.org> >> >> Trying to identify the problem made me stumble into ClassBuilder >> and looking at the core method ClassBuilder>>name: className >> inEnvironment: env subclassOf: newSuper type: type >> instanceVariableNames: instVarString classVariableNames: >> classVarString poolDictionaries: poolString category: category >> unsafe: unsafe. >> >> This makes me wonder what the intend of the latest changes there >> were. They do look rather suspicious to me. Could someone with the >> initials "rw" please explain the reasoning for these changes? It's >> the last person who touched that method and unfortunately there is >> no method history any longer :-((( (the version found in 3.8 from >> '04 looks approximately correct so any changes inbetween would be >> interesting) >> >> Cheers, >> - Andreas >> >> >> Andreas Raab wrote: >>> Klaus D. Witzel wrote: >>>> on Mon, 23 Oct 2006 10:35:13 +0200, you wrote: >>>>> ... Looking at TCompilingBehavior's users I find TPureBehavior; >>>>> looking at TCompilingDescription's users I find ... "an >>>>> IdentitySet(ClassDescription ClassDescription >>>>> TraitDescription)". Huh? Anyone else seeing this? An identity >>>>> set with a duplicate entry? >>>> >>>> Confirmed, printing "array fourth == array fifth" in an >>>> inspector on TCompilingDescription => true. >>> And not only that. All of the following traits have duplicate >>> users and it's not limited to ClassDescription/TraitDescription >>> either. >>> TAccessingMethodDictDescription users >>> an IdentitySet(ClassDescription ClassDescription TraitDescription) >>> TBasicCategorisingDescription users >>> an IdentitySet(ClassDescription ClassDescription TraitDescription) >>> TBehaviorCategorization users >>> an IdentitySet(Trait Class Class Class) >>> TCommentDescription users >>> an IdentitySet(ClassDescription ClassDescription TraitDescription) >>> TCompilingDescription users >>> an IdentitySet(ClassDescription ClassDescription TraitDescription) >>> TCopyingDescription users >>> an IdentitySet(ClassDescription ClassDescription TraitDescription) >>> TFileInOutDescription users >>> an IdentitySet(ClassDescription ClassDescription TraitDescription) >>> TPrintingDescription users >>> an IdentitySet(ClassDescription ClassDescription TraitDescription) >>> TPureBehavior users >>> an IdentitySet(TraitBehavior Behavior Behavior) >>> TTestingDescription users >>> an IdentitySet(ClassDescription ClassDescription TraitDescription) >>> TTraitsCategorisingDescription users >>> an IdentitySet(ClassDescription ClassDescription TraitDescription) >> >> >> >

4 6

Squeak News Retraction
by Ron Teitelbaum 30 Oct '06

30 Oct '06

All, I've deleted a news item I posted because it was inaccurate. I'm sorry for posting the item and my bad attempt at humor. Ron Teitelbaum

1 0

The Weekly Squeak Summary No. 4: Oct 22 - Oct 28, 2006
by Michael Haupt 30 Oct '06

30 Oct '06

Dear Squeakers, welcome to the The Weekly Squeak Summary, a weekly report on what's going on in the world of Squeak based on the Weekly Squeak blog. Highlights of the week: Around the image, some development is going on, and problems need to be solved. As for development, Colin Putney has posted a roadmap for OmniBrowser development, a likely future replacement of the standard system browser [1]. Recent images require some looking-into; there appears to be a freezing problem that needs to be documented by anyone willing to help [4]. News related to the commercial world bring us two offers this week: a job offer at Cadence [10], and an iPod offer for a nifty improvement of just about any possible kind [5] to Gjallar, the open-source issue tracker written using Seaside and Magma. (I've seen Göran's demo at OOPSLA, it's pretty impressive.) Last week's news items: [1] OmniBrowser Roadmap http://weeklysqueak.wordpress.com/2006/10/23/omnibrowser-roadmap/ [2] Serial port howto http://weeklysqueak.wordpress.com/2006/10/23/serial-port-howto/ [3] Minnow Wiki http://weeklysqueak.wordpress.com/2006/10/26/minnow-wiki/ [4] Image Freezing http://weeklysqueak.wordpress.com/2006/10/26/image-freezing/ [5] IPOD anyone? http://weeklysqueak.wordpress.com/2006/10/26/ipod-anyone/ [6] Efficient Thread-local shared variables http://weeklysqueak.wordpress.com/2006/10/26/efficient-thread-local-shared-… [7] Removing EToys? http://weeklysqueak.wordpress.com/2006/10/26/removing-etoys/ [8] RESTFull URL http://weeklysqueak.wordpress.com/2006/10/26/restfull-url/ [9] Craig Turn Around, Time For Your Close-UP http://weeklysqueak.wordpress.com/2006/10/26/craig-turn-around-time-for-you… [10] Job in San Jose, California http://weeklysqueak.wordpress.com/2006/10/26/job-in-san-jose-california/ You can find this and much more on The Weekly Squeak blog, the newsblog dedicated to the world of Squeak: http://news.squeak.org/ Subscribe to the Weekly Squeak RSS feed: http://news.squeak.org/feed/ Happy squeaking, Michael

1 0

re: Is something like #collect:until: exist?
by Bill Schwab 29 Oct '06

29 Oct '06

Is this what you had in mind? collect: aBlock until:quitBlock "Evaluate aBlock with each of the receiver's elements as the argument. Stop when quitBlock evaluates to true. Collect the resulting values into a collection like the receiver. Answer the new collection." | newCollection | newCollection := self species new. self do: [:each | ( quitBlock value:each ) ifFalse:[ newCollection add: (aBlock value: each) ] ifTrue:[ ^newCollection. ]. ]. ^ newCollection. You might first look at #select:thenCollect: to see if it meets your needs. The "until" is a little stream-like, so you might also consider moving items from a read stream to a write stream on a new collection and then collect from it. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bills(a)anest4.anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029

2 1

Re: Smalltalk Reloaded Was:Re: Removing Etoys (was Re: A process proposal for 3.10)
by mmille10＠comcast.net 29 Oct '06

29 Oct '06

Okay. Now I get it. To quote myself from earlier: "Re: eToys was hacked into Morphic. That's the reason things keep breaking. In the PC world I've sometimes seen system implementations that are "just enough" to run another technology on top of it. It sounds like this is what happened with Morphic--just enough was implemented to run eToys. I wonder what the expectation was? Was this done by design, and the assumption was that if there were improvements to be made, that the UI would just grow organically out of what was already there? Maybe the original developers didn't have a full implementation of Morphic in mind, but rather just wanted to get the development process started, and hoped that others would just build on top of it. Like I said, I'm just learning about it at this point, so I don't know the internals as well as others on here. Again, I wonder if the reason why stuff keeps breaking, is that the developers who are working with it are trying to impose a model on it that is incompatible with the way it was developed earlier. Maybe whoever did it had other intentions in mind and the current crop of developers are not seeing it. I'm finding it difficult to believe that with the design of Smalltalk being so elegant that something like this would be done sloppily. I guess I'm wondering about the history of how this developed." I found this from Alan Kay on April 22 in this list: "Etoys was a demo and a prototype. It is a real tribute to Squeak (and the team) that it was actually shippable around the world. But it is not a production system, and it is not scalable to the hundred dollar laptop as it stands. It needs to be reimplemented, and many parts have to be improved. We have been doing some of this (and the results are interesting) but we have to take every avenue to get a scalable version that can be taken care of by more production like people." This explains a lot. It sounds like from what he's saying that work was under way then to rework eToys. What I'm unclear on is to what end, since I grabbed this out of the discussion that was going on about the possibility of porting eToys to Python. Anyway, this answered my questions about eToys. For the edification of others, the post I got this quote from is here: http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-April/102912.ht… ---Mark

1 0

Re: Smalltalk Reloaded Was:Re: Removing Etoys (was Re: A process proposal for 3.10)
by mmille10＠comcast.net 29 Oct '06

29 Oct '06

Just an observation but you sound kind of jaded. Re: no one is in charge of the dev. team So you on your own can decide to release the main image of Squeak for everyone else to download? You're not making a lot of sense here. Who decides what goes into the main image? Who decides when it's in beta, and when it's ready for final release? To hear you talk no one is in charge of any of this. Sounds pretty chaotic to me and not very realistic in terms of managing a credible project. Even though some object to the notion, most of the open source projects I've heard about that are successful have "benevolent dictators" who decide what goes into a release and what doesn't. They take a lot of input, of course, but ultimately one or a few people make the decisions. Re: code talks Yeah, I'm beginning to see that. It sounds like the problem is the users who don't want to take the time to dig into the internals don't have a voice at all in your scheme of things. If the developers don't see a use for something in their own projects, no problem. You can just take it out of the main image that everyone downloads, and the users who depend on what you took out can just go take a hike. If this is the prevailing attitude it's just going to turn Squeak into yet another dev. tool that no one besides developers will have an interest in. So much for Smalltalk representing a new computing platform, right? Instead of just serving your own interests, why not take the time to do what it takes to maintain the vision that is there and improve upon it? I'm not speaking just of you when I say this, but of the Squeak developers generally. If it takes a long time to refactor eToys, why not take the time to do it, however long it takes? What's the rush to get out the next release? That's what I was kind of getting at in my previous post. Why not take the time to do it right? If it means it takes a few years, then it takes a few years. I understand I could contribute to this, but if none of the other Squeak system developers are interested in the same vision, it's kind of a disincentive to invest the time, because it'll mean I'm carrying the load myself. Plus it may not be appreciated for what it is and get tossed out. This is what I'm alluding to with the "overall vision" thing. I am interested in the overall vision of Squeak as it exists persisting, even though I may not use some of the features. If there's no guiding vision, how is anyone going to have an idea if a contribution to the main image is going to be accepted or not? What's the incentive to make a contribution that's altruistic? In the situation you're talking about, as I see it, it's everyone for themselves. People will just contribute things that they have a personal invested interest in, because at least if it's not accepted, it'll be useful to themselves. It kind of sounds like that's the way things have been going. And it takes me full circle ba ck to what I see as the main problem: the users who are not system developers don't have a voice in the process. Basically they're depending on there *being* a guiding vision, because they don't know enough to have control over the internals. They're just depending on what they're used to continuing to work. I may very well become a contributor in the future. As I've indicated I'm very interested in the platform. I'm learning about Squeak right now, so I don't think my skills would be that useful in terms of refactoring eToys at this point in time. Maybe in the future. You mentioned Tweak. I went by a web page for it, and it didn't look like there was a lot to it, at least from the screenshots they were showing. Does it have a complete implementation of eToys or just a subset? Re: eToys was hacked into Morphic. That's the reason things keep breaking. In the PC world I've sometimes seen system implementations that are "just enough" to run another technology on top of it. It sounds like this is what happened with Morphic--just enough was implemented to run eToys. I wonder what the expectation was? Was this done by design, and the assumption was that if there were improvements to be made, that the UI would just grow organically out of what was already there? Maybe the original developers didn't have a full implementation of Morphic in mind, but rather just wanted to get the development process started, and hoped that others would just build on top of it. Like I said, I'm just learning about it at this point, so I don't know the internals as well as others on here. Again, I wonder if the reason why stuff keeps breaking, is that the developers who are working with it are trying to impose a model on it that is incompatible with the way it was developed earlier. Maybe whoever did it had other intentions in mind and the current crop of developers are not seeing it. I'm finding it difficult to believe that with the design of Smalltalk being so elegant that something like this would be done sloppily. I guess I'm wondering about the history of how this developed. Re: This is just my opinion Alright. So I've expressed mine too. :) ---Mark -------------- Original message -------------- From: Todd Blanchard <tblanchard(a)mac.com> The thing you are missing is that no one is in charge of the dev team. The dev team is you, me, and anybody else with time and inclination to build and release software. Furthermore, there is no "one true vision". We all have visions and are trying to realize them. At the end of the day - code talks. You like eToys? Believe it should live in Squeak forever? Put in the time to clean it up and make it reloadable. Nobody is stopping you. We would all like that. But everybody has his own itch to scratch and finite resources. The reason people are considering removing eToys is that it made Morphic too complicated and brittle. It slows us down the way it is. It is why things keep getting broken. It wasn't built on top of Morphic - it was hacked into it. Feel free to put in the time. I think the best approach is to hack it out - clean up Morphic, and then reimplement it on top of a clean Morphic in an architecturally sound way (assuming somebody wants it badly enough to put in the effort). There is also a completely new UI framework called Tweak that might replace Morphic - and has an implementation of eToys being built on top of it. Which kind of implies that Morphic is an interim solution anyhow and we might as well do the expedient thing. This is all just my opinion.? I could be wrong. -Todd Blanchard On Oct 27, 2006, at 10:44 PM, mmille10(a)comcast.net wrote: I think whoever is in charge of the dev. team needs to be cognizant of the guiding vision for Squeak and insist that the developers of the official distribution stick to it.

1 0

← Newer
1
2
3
4
5
6
7
...
31
Older →

Jump to page: