Squeak-dev February 2002

squeak-dev@lists.squeakfoundation.org

202 participants
665 discussions

Behavior design options (was: Behaviors vs Modules)
by Anthony Hannan 27 Feb '02

27 Feb '02

Nathanael <n.schaerli(a)gmx.net> wrote: > I'm really curious what kind of a mixin concept you have in mind. Well, lets look at different designs from simple to complex: A := Just single-inheritance classes. (today's Squeak) B := A + default methods (each selector has a default method that will execute if the receiver's hierarchy does not define a method for that selector. Default methods cannot access instance variables, they only can send messages). C := A + protocols (a protocol is a group of selectors, providing selector namespace. Each selector belongs to one and only protocol. Selectors in different protocols can have the same name, but they are considered different selectors, meaning the sender has to choose which one he means if its not obvious). D := A + mixins (a mixin is a set of methods that may be shared among different classes. Like default methods, mixin methods cannot access instance variables). E := B + C. F := C + D. G := B + C + D. H := Object roles (ie. PIE). I := Multiple-inheritance classes. I encourage people to vote for one they like the best (with an explanation of course) and/or add new designs to this list. My opinion: Ambiguities arise in designs C and higher that require even more design to disambiguate. Protocols require senders to sometimes use prefixes. Mixins require the importing class to resolve conflicts if the mixin implements a selector already included in the class or another imported mixin. Roles and multiple-inheritance have similar issues. So I vote for B. I like B over A because it allows reuse of methods outside of the single-inheritance structure and gives Squeak some function orientation, which is closer to reality. 80% of all selectors in the image have only one method definition (only 20% are polymorphic) [1]. The default methods can be grouped by functionality (modules) that often intersect many classes, but are usually executed together. However, having no class or receiver type associated with default methods will make it hard to figure out which receivers they are intended for. Protocols would solve this problem by associating a "protocol type" with the receiver. But, beside the cost of occasional message prefixes, it would require us to come up with many new standard names (protocol names) one per receiver type per module. For example, the "exceptions" module would contain additional methods for blocks, context, and general objects. We wouldn't want to add #on:do: to the existing "blockEvaluation" protocol (#value, etc.), instead we would want to add it to a new "blockExceptions" protocol. This prolification of protocols would be overkill. Instead, I propose we add the receiver as a variable in the method header, so we can name it something appropriate like we do with arguments. For example, here is how I would define the default method #ifError: block ifError: errorHandler ^ block on: Error do: errorHandler "block" is added to the front of the method header and replaces self in the code. Of course this would be optional. But if default methods include receiver variables then it will be easier to tell what kind of receiver is expected without actually tying it to a specific class or using protocols. Receiver variables, like argument variables, serve as informal types. Informal is a plus since formal types are overkill (as all Smalltalkers know). Tools could filter or sort default methods by the receiver variable, and they can even trace senders and implementors to figure out which default methods are applicable to which classes. Default methods provide reuse of outside-the-hierarchy behavior like mixins, reducing the need for mixins. So I would keep the behavior design simple with just functions and classes that may override those functions. Note, in my original post I proposed design E: default methods + protocols. This was because I thought protocols could serve as modules. But now I favor transactions/changesets as modules, so protocols are not worth their weight anymore. (Double Note, I still haven't studied SmallScript or PIE yet, which may change my opinion again :-). Cheers, Anthony Footnotes [1] Calculation of % of polymorphic selectors (methods with the same selector are counted as polymorphic even if they are not intended to be polymorphic): | poly all | poly _ IdentitySet new. all _ IdentitySet new. Smalltalk allBehaviorsDo: [:cls | cls methodDict keysDo: [:sel | (all includes: sel) ifTrue: [poly add: sel] ifFalse: [all add: sel]]]. (poly size / all size) asFloat "=> 0.224"

3 2

[BUG?] Bad scoping in a DoIt
by Brian Keefer 27 Feb '02

27 Feb '02

If I put this in a Workspace and doit each line separately, it prints true. If I highlight it all and doit, it prints nil. Is there some hidden meaning that this newbie's missing? a_true. b_[ |a| a_false]. Transcript show:a. This is on 3.2gamma #4743 with a Linux VM

2 1

Squeak Event (2nd / 3 call)
by Bergel Alexandre 27 Feb '02

27 Feb '02

SSUG is organizing a SqueakNic (kind of picnic around Squeak). We invite all Squeakers and other Smalltalkers to join this event to share their enthusiasm and knowledge about Squeak. Squeak can be regarded as a Great Big Toy. Morphics are for something. We can see each squeaker has his/her own hints and experience. Why not to share this knowledge ? The goal of SqueakNic is try to give an anwser... It consists basically of an meeting of squeakers (without regarding level) around computers (and pizza ? :-) The purpose is to show what you want about Squeak, these could be Morph manipulation, explanations about existing projects, new cooperation/interaction between research project (or simply independent developers), ... WHAT SQUEAK EVENT WHERE UNIVERSITY OF BERN - IAM Bern, Switzerland WHEN Saturday 16th March 2002 -- 12pm until ... CONTACT email : bergel(a)iam.unibe.ch tel : +41 31 631 3568 MORE INFORMATION on http://www.iam.unibe.ch/~bergel/Smalltalk/SqueakEvent1/ Bring your lunch with you and contact me so that we can arrange something. An apero sponsored by our sponsors: Daedalos Consulting AG (www.daedalos.ch), iFace AG (www.iface.ch) Object-Oriented Limited (www.object-oriented.com) will end the day. Alexandre PS: I will show some fun experience with morphs (How to build a platform game in 10 min, and how legoMinstorm can be driven from Squeak.....) PS2 : I will be away until the 11th march, so I may be long for answering. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._ Bergel Alexandre http://www.iam.unibe.ch/~bergel ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^

1 0

Re: SerialPort cross-platform question...
by Lex Spoon 27 Feb '02

27 Feb '02

> * it's not clear how to tell how many or what serial ports exist under Unix. I think ultimately Squeak/Unix is going to need a configuration file. Then, the config file can list where the ports are. Suitable defaults can be given for common Unices. At that point, numbered ports will make sense again. -Lex

3 5

Re: [UNIX][VM] config file (was: Re: SerialPort cross-platform question...)
by Lex Spoon 27 Feb '02

27 Feb '02

"David T. Lewis" <lewis(a)mail.msen.com> wrote: > On Wed, Feb 27, 2002 at 12:35:52PM +0100, Bert Freudenberg wrote: > > > > OTOH, a config file would be nice, indeed. How about "/etc/squeakrc", > > overridable by a "$(HOME)/.squeakrc"? Or, do we want to have a > > "$(HOME)/.squeak/" directory? > > For consistency, it would be "/etc/squeak.conf", overridable > by "$(HOME)/.squeakrc". Unfortunately, a small amount of VM support > would be needed, as Squeak does not currently know the location of > the $(HOME) directory. This could be added in the form of one new > primitive (primitiveUserHomePath). Well this is *VM* configuration. If it's useful in the image, let's not do it in this low-level configuration file. Anyway, this whole scheme sounds great. Additionally, there should be a SQUEAKRC environment variable which overrides the default locations the config file would be looked for. So the order of configuration options would be: 1. command-line options 2. environment variables 3. the config file, which is the first that exists of $SQUEAKRC, $HOME/.squeakrc, and /etc/squeak.whatever Ideally every option can be set in every location (so, as Bert pointed out, we could actually go ahead and add -ttys and SQUEAK_TTYS and modify the serial code accordingly....) Any volunteers? :) -Lex

1 0

One more Win32 programming question for OSProcess
by David T. Lewis 27 Feb '02

27 Feb '02

Sorry to pollute the Squeak list with this, but I need some help on Win32 anonymous pipes: In CommandShell, when running with OSProcess, I do a lot of IO to operating system pipes. In order to prevent hanging the Squeak VM on a blocking read or write on an operating system pipe, I set the pipe to nonblocking mode. On Unix, this is done with a call to fcntl(). Is there an equivalent mechanism on Win32, in which I could set the characteristics of a HANDLE on a Win32 anonymous pipe to cause it to be nonblocking? I suspect that the answer is no, but I thought I'd better ask before implementing something dumb like a thread to wait on a read or write to complete. Ugh, I'm sure that's going to end up being the answer. Thanks

3 3

[Modules]Again: Proposal of minimal module metainfo
by goran.hultgren＠bluefish.se 27 Feb '02

27 Feb '02

I would like to add support for the "minimal module metainfo" I was talking about earlier. I looked at the Annotations stuff but as I see it, these things does not get written to the external representation of the module. Henrik - should/could we add this to the definition file or should we put it somewhere else, perhaps in a third, "noncompulsory" file? Was the annotations only meant to live in the image? And since noone reacted on my list of fields I will go for what I posted. :-) regards, Göran goran.hultgren(a)bluefish.se wrote: > We need to agree on a minimal set of metainformation on modules. > It should be minimal but also rather easily extensible. > The metainformation should be included in the module (at least when on > disk). > Perhaps this information can be added by using the Annotations mechanism > - not sure. > This is what I have come up with sofar: > > --- > The first two are already in the Module class: > Name: The name of the module. > Version: The version of the module. > > Then we could add these as a "meta card" using annotations: > Summary: Short oneliner description. > Description: Longer textual description. > Homepage: Url to homepage of module if applicable. > License: Url to license. Mandatory. > Author: Name and email according to mail standard (like "Henrik Gedenryd > <h.gedenryd(a)open.ac.uk>") > Maintainer: Name and email according to mail standard. Mandatory. > Keywords: A bunch of keywords mostly for better searching > --- > > Question: Should this information be mandatory for all standalone > modules? I would think so. > > NOTE: This is the proposed MINIMAL info. Dependencies etc. are already > covered in the module. > Even though I would consider adding a few other relations between > modules like for example > "Conflicts with" and "Replaces" (inspired again by Debian). But that is > again something for > the module definition itself and not for this "module meta card". > > * I left out categorization on purpose - it got complicated to > coordinate a nice category tree. > * I first thought of centrally registering licenses etc. (in fact I was > thinking of stuffing them in a module!) > but again - coordination problems made me instead opt for a simple url. > > Let's bang this proposal around and if we can agree on it I could try to > add support for it. > > regards, Göran > > PS. The next part is the hard part - how do we make all this > metainformation available and up to date? > I have some ideas and will post later. DS

2 1

RE: Getting rid of metaclasses (Was: Behaviors vs Modules)
by Gary McGovern 27 Feb '02

27 Feb '02

Well thank you for those. I mentioned more intelligent objects months ago and it went down like a lead balloon. Perhaps one day there'll be intelligent objects in an intelligent system and we can dispense with dumb objects on dumb OSes. Couldn't vouch for the implementation though. Regards, Gary (Don't be afraid be very afraid, M$ has 90% stock in all Lino distros ;-) ) 25/02/02 23:53:16, Jerry Bell <jdbell(a)fareselaw.com> wrote: >Hi all, > >I have a couple of PIE documents which the folks at PARC were nice enough to >copy and send me. They are scanned and I've just made them available: > >A Layered Approach to Software Design >(Ira P. Goldstein and Daniel G.Bobrow, CSL-80-5 December 1980) >1.9 MB > >http://www.dolphinharbor.org/docs/PIE%20Layered%20Approach.pdf > >and: > >An Experimental Description-Based Programming Environment: Four Reports >(Ira Goldstein and Daniel Bobrow, CSL-81-3 March 1981) >3.18MB > >http://www.dolphinharbor.org/docs/PIE%20four%20reports.pdf > >Both are (c) Xerox. I hope there is no problem posting them. > > >Hope these are useful, > >Jerry Bell > > > > > > >> -----Original Message----- >> From: squeak-dev-admin(a)lists.squeakfoundation.org >> [mailto:squeak-dev-admin@lists.squeakfoundation.org]On Behalf Of Jim >> Benson >> Sent: Sunday, February 24, 2002 10:47 PM >> To: squeak-dev(a)lists.squeakfoundation.org >> Subject: Re: Getting rid of metaclasses (Was: Behaviors vs Modules) >> >> >> Nathanael, >> >> > The ideas of having multiple roles/views/perspectives >> associated to an >> > object sounds very interesting and promising. I'd really >> like to know more >> > about these PIE system and its implementation. If you have >> any pointers to >> > some information, please let me know. >> > >> >> The only place I've seen any of this written up was in the >> book Interactive >> Programming Environments [1984] edited by Barstow, Shrobe, >> Sandewall, ISBN >> 0-07-003885-6. PIE is written up as "A Layered Approach to >> Software Design" >> by Goldstein and Bobrow. pp 387-413. This paper was >> originally published as >> Xerox Parc CSL-80-5. >> >> Whenever I want to be depressed, I just pick that book up and >> start reading. >> It represented the state of the art in '84, and it's amazing >> how little >> things have advanced since then. >> >> I haven't found anything online, but I hoped that this >> information might >> help. >> >> Jim >> >> >> > >

1 0

Re: transforming points from global to local coordinates
by Bob Arning 27 Feb '02

27 Feb '02

Craig, The answer is that all coordinates are *global* unless there is a transformation morph somewhere in the hierarchy and then coordinates of morphs below that point are local to the transformation morph. In your example, global == local. Cheers, Bob On Tue, 26 Feb 2002 17:13:56 -0800 Craig Latta <Craig.Latta(a)NetJam.ORG> wrote: > I would expect (aMorph globalPointToLocal: aPointInGlobalCoordinates) >to answer aPointInGlobalCoordinates as translated into the local >coordinates of aMorph. This doesn't seem to be the case... should it? If >not, what should I do instead, and how could I have learned this? > > > thanks, > >-C > >*** > >"E.g., I would expect 25@25 from..." > >| morph | > >morph _ ( > (Morph new) > extent: 50@50; > position: 300@300). >morph globalPointToLocal: morph bounds center > >"...but I get 325@325 instead."

1 0

[newbie] Really Basic Morphic UI Question
by Jim Barton 27 Feb '02

27 Feb '02

Everyone- I am a Smalltalker from a few years back, and I'm looking for an environment to teach my 9-year-old daughter the basics of programming. Squeak was an obvious choice to me. Since I had never used it before, I downloaded it and played around for awhile, particularly focusing on morphic programming since I'd never seen it before. After I'd played around for awhile and gotten the feel of the place, I decided to move from chasing stars around my world to more prosaic things. First, I decided to do the old Counter example, so I coded up my Counter and tested it in a workspace, then tried to add the UI. Doing everything with Smalltalk, I finally got it to work, although it was a little more painful than I thought it would be. Then I tried to do the same thing using only the morphic interfaces. I couldn't figure it out. I created a button and a text field, stuck a '0' in the text field, and tried to create a scriptlet that would increment the field value everytime I pressed the button. I could make that text field croak, chirp, run around in circles and turn purple, but I couldn't figure out for the life of me how to change that '0' into a '1'. The Principle of Least Astonishment informed me that surely there was some property in the TextField's interface that I could use to manipulate the contents of the field, but I couldn't find it. Frustrated, I dropped down to Smalltalk and inspected and explored my way down to the value, but I couldn't figure out a way to change it from a scriptlet. I know this must be trivially simple to solve, right? Can someone help before I'm forced to teach my daughter Java ;-) ??? Thanks, ...Jim _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com

3 2

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

Jump to page: