Squeak-dev November 2002

squeak-dev@lists.squeakfoundation.org

189 participants
695 discussions

[BUG] Refactoring Browser disables "Transcript flush"
by Ned Konz 29 Nov '02

29 Nov '02

For some reason, Refactoring Browser re-defines TranscriptStream>>flush to do nothing. Of course, this breaks any code that depended on flush to actually flush the Transcript. Is this necessary? -- Ned Konz http://bike-nomad.com GPG key ID: BEEA7EFE

1 0

[FIX][ENH] FileListFixes2-nk
by Ned Konz 29 Nov '02

29 Nov '02

from preamble: "Change Set: FileListFixes2-nk Date: 26 November 2002 Author: Ned Konz Version: 3.4a After decompressing gzip files in the FileList, the file list wasn't updated. This change set fixes that, without unnecessarily updating the file list (which can be slow via FTP, for instance). I've added a FileModifyingSimpleServiceEntry class that is the same as SimpleServiceEntry but also updates the contents of the file list. This is then used in four places where files actually change, including decompression and linefeed removal. This CS also updates the class comment in FileList to be up to date with the current design. This also removes the compression services from FileList itself (thereby removing some dependencies) and puts them into ArchiveViewer and GzipWriteStream. Also it adds balloon help to the file list menu. Also stops offering to compress already-compressed files. "!

3 5

Re: "Pattern Hatching"
by Daniel Altman (Da Vinci) 29 Nov '02

29 Nov '02

Hi Richard! >> - variables --> internal collaborators >> - parameters --> external collaborators >The collaborators are NOT the variables, they are the VALUES of the variables. Of course! You won´t expect an object to send a message to a computer memory area! ;-P Maybe I wasn´t clear enough, as you said in another post, we usually don´t say exactly (formaly) what we mean, which is impossible because spoken language is not formal. So, please don´t take things too literally. We call "collaborators" to the objects, not to their memory storage. More important than this is that an object really don´t "know" its collaborators, it only knows that behind a certain "role" (or "variable name", or "collaborator name", or simply "name") there is someone that is expected to complain to some protocol. > The distinction between 'internal collaborators' and 'external collaborators' is also a bad one. > The distinction between instance variables and method arguments is one of BINDING TIME only, having nothing whatsoever to do with internal/external The concept is that an external collaborator is one that the object "knows" only in the context of a certain collaboration. An internal collaborator is one "known" along the entire lifetime of the object. >What I find very serious here is that someone (almost certainly NOT Daniel Altman, but perhaps someone who taught him) has tried to LEGITIMISE the distinction between primitive values and objects that we find in C++ and Java. We find no such distinction in Eiffel or Smalltalk. In both Eiffel and Smalltalk, *everything* is an object. >It has been conventional to call the boxes that hold references to objects "variables" That´s a very unfair conclusion...I was taught that in OOP we only have objects and messages, nothing else. May also be that there are things I didn´t catch, so please don´t put my teachers in the middle. One of the reasons we don´t use the word "variable" is that it sounds too imperative, thus making more difficult to switch our minds to OO.

1 0

[FIX][VM][2] SLANG zapping warning messages fum does not return int, or variable foo not used
by John M McIntosh 29 Nov '02

29 Nov '02

GCC is generates a lot more warnings. So I'm issuing some corrections to the voidIsVoidNotInt change set. I had to add self cCode: 'return' inSmalltalk: [^self] in a lot more places, to allow a guard clause to return early without a value, or on a failure to terminate early. The GCC compiler was kind enough to complain a lot more than Code Warrior did. I also realized that GCC 2.95.x for the powerpc is still quite stupid with global structure code and when you refer to foo->someField it loads the value for foo, then the offset in most cases. However having "register struct foo * foo = &fum;" in each method that uses fum, causes the compiler to load the address of fum into a working register, then on average you require one less instruction per reference to a field in fum. Some thinking and fiddling was required to identify methods that use a global structure so it would only insert the statement if needed so I avoid warnings about unused variable foo. This results in about a 5% improvement on the macro benchmarks (Both for os-x and classic os-9). (or as much as 6% for a full GC). We throw away about 8K of load instructions, good to see that on a 604e and a G3 removal of these instructions do make a difference. -- ======================================================================== === John M. McIntosh <johnmci(a)smalltalkconsulting.com> 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===

1 0

Re: A big teacher wish
by Richard A. O'Keefe 29 Nov '02

29 Nov '02

Stephan Rudlof <sr(a)evolgo.de> wrote: [stuff that had me purring] For me even #instanceVariableNames: in *meta* classes (accessible in the class pane of a browser) are a concept, which is easy to understand: each instance of the corresponding meta class (the class with its subclasses) has its own class instance variable (which is then accessible like a class var in all of *its* instances). This concept highly corresponds to the concept of instance vars of instances of ordinary classes. What is difficult to understand here? 1. First, there is an interface issue. Setting class variable names is done in the "instance" pane; setting class instance variable names is done in the "class" pane. If you don't already know what these things are, it is far from obvious that FooBar class instanceVariableNames: '' is talking about a third kind of variable. It is common for students to think that it is an alternative interface for setting class variable names. 2. Second, to get your head around this, you have to be good at thinking a particular way. Just for now I'll call it "algebraic" thinking. You have to be able to say to yourself, "what if I take this literally? What if I try to apply the 'instanceVariableNames' concept to the 'metaclass' concept? OH, these things are like instance variables but they belong to instances of the metaclass instead of instances of the class." Many people, as this thread has painfully demonstrated, DON'T think that way. They think in a "verbal analogy" way. They are happy using the same word for variables and the values of variables. They talk about excluding ideas, and think that just excluding words is sufficient to do this. THIS IS NOT A MATTER OF BETTER OR WORSE THINKING. Each kind of thinking is effective in its own sphere. A really good criminal lawyer, for example, will need to be very good at both kinds of thinking: "algebraic" thinking to understand expert witnesses, "verbal" thinking to understand others and influence the jury. People are generally pretty imprecise in what they say, leaving it to their (intelligent) hearer to figure out what they really mean. When you see transcripts of actual speech, it's horrifying. We're so good at figuring out at what people MEAN that we don't pay much attention to what they SAY, as a rule. So this kind of thinking works WITH people. It's highly persuasive, and it's highly effective for dealing with the strange things people say. This kind of thinking DOESN'T work with technology. If you try to tell an electric light bulb that 240 volts is pretty much the same as 110 volts, it's all volts, just a few more of them, it isn't going to be persuaded. If you use the same word for a video cassette as for a video cassette recorder, that doesn't alter the fact that one of them plugs into a wall socket and the other doesn't. So the thing that is difficult to understand here is that the Squeak interface is using *technical* language *precisely* and you should take it *literally*. It's very important, of course, that Squeak is not about preserving the status quo. Squeak is a work in progress. Just because Squeak currently uses certain terms and interfaces doesn't mean that _anyone_ thinks those are the best terms or interfaces. I for one am drooling at the thought of having Traits, and to use them the way you declare a class will _have_ to change somehow. One possibility, for example, would be to construct class declarations by drawing pictures. UML diagrams are one possibility, although UML doesn't really fit Smalltalk all that well. Perhaps one could find a ClassMorph, ask it to make a new subclass, edit the name, drop TraitsMorphs onto it, I don't know what. Perhaps you would create a VariableMorph with a name box and a description box and drop that onto a ClassMorph. I don't know. Maybe Connectors can become a browser.

2 1

Re: A big teacher wish
by Richard A. O'Keefe 29 Nov '02

29 Nov '02

Stephane Ducasse <ducasse(a)iam.unibe.ch> wrote: I can live with the argument of richard about lifetime because this is right. Great. What I do not like with classVariable is that it does not express that variables are shared between a class and its instances. I may have misunderstood what you wrote before. Then I thought you were saying that you don't like the FACT that the scope of a class variable includes instances. That of course is something that could be taken care of by, oh, the refactoring browser or lint checker? What if the template read Object subclass: #NameOfSubclass "instance lifetime, instance scope" instanceVariableNames: '' "class lifetime, class and instance scope" classVariableNames: '' "dictionaries, image lifetime, shared with other classes & instances" poolDictionaries: '' "where to catalogue the class" category: 'Kernel-ST80 Remnants' (perhaps under the control of a Preference)? It is in general *impossible* for a name in a program to express the whole truth. If it expresses nothing but the truth, it has done more for us than most names. I don't think the keyword should be expected to bear the burden of explaining EVERYTHING about class variables.

1 0

Re: [Update] Faure 0.3 (Play release)
by Russell Allen 29 Nov '02

29 Nov '02

Hi Tim, Good idea! The images are now available as zipped files. Russell Tim Rowledge <tim(a)sumeru.stanford.edu> wrote: > Russell, you might like to consider putting your premade image in a > zipfile.... > > tim > > -- > Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim > Strange OpCodes: BYEBYE: Store in Write-Only Storage

1 0

Re: "Pattern Hatching"
by Richard A. O'Keefe 29 Nov '02

29 Nov '02

"Daniel Altman (Da Vinci)" <Daniel.Altman(a)disco.com.ar> wrote: In OOP (at Univ. of Buenos Aires) we learn to call them this way: - variables --> internal collaborators - parameters --> external collaborators Trouble is, it's wrong. There are three things we can distinguish between. (The classic "Informal Introduction to Algol 68" had a diagrammatic notation that made this all clear.) 1. There is the NAME of a variable. This is the thing you type in. It is made of letters. 2. There is the VARIABLE itself. This is a box. It is made of storage units in a computer's memory. 3. There is the current VALUE of a variable. This is an abstract computational thingie, determined by interpreting the contents of the box in the context of the rules of the language, the structure of the program, and the contents of other boxes. The collaborators are NOT the variables, they are the VALUES of the variables. Given Object subclass: #Point instanceVariableNames: 'x y' classVariableNames: '' poolDictionaries: '' category: 'Graphics-Primitives' and p := 27(a)2.4 Then 'x' is a variable name. p's x is a variable 27 is one of p's acquaintances. I prefer the term "acquaintances" here because having been exposed to Class-Responsibility-Collaborator cards, I think of a *class* having collaborators which are *classes*. The distinction between 'internal collaborators' and 'external collaborators' is also a bad one. If I have p := x @ y. q := y @ x. then in what sense is x "internal" to p? If I have "Complex >>" - other ^Complex re: re - other re im: im - other im negated ^Complex zero - self then in what sense is a complex number "external" to *itself* when passed to Complex>> - by aComplex negated? The distinction between instance variables and method arguments is one of BINDING TIME only, having nothing whatsoever to do with internal/external. My opinion is that it's more OO thinking an object as having collaborators (and interacting with them sending messages) rather than thinking those collaborators as variables, Anyone who confuses a collaborator (an object) with a variable (NOT an object in Smalltalk) is about as seriously confused as someone who confuses a person with a house just because a person lives in a house. Smalltalk objects have instance variables *SO THAT* they can have acquaintances. [variables are] a concept that is usually associated with a value that you can directly manipulate. You can "directly manipulate" something if and only if you can physically grab it, move it around, and change it with your hands ('manes' in Latin). Now, suppose I do this: (BorderedStringMorph contents: 'Boojum!') openInWorld. then take the mouse, place it over the morph, Command-click, select the red menu, choose "change font", and change the font. The morph changes. It _feels_ as if I made this change happen with my hands. That's "direct manipulation". So by this definition, a BorderedStringMorph is a variable. That can't be right. If I translate this into less metaphoric terms, "a value that you can directly manipulate" appears to mean "some kind of value for which your programming language provides built in operations." But then an array would not count as a variable in C. Given typedef int ia10[10]; ia10 x, y; ... x = y; is illegal in C. (Actually, the C standard would probably agree that an array isn't a variable. The C standard thinks it's an "object".) What I find very serious here is that someone (almost certainly NOT Daniel Altman, but perhaps someone who taught him) has tried to LEGITIMISE the distinction between primitive values and objects that we find in C++ and Java. We find no such distinction in Eiffel or Smalltalk. In both Eiffel and Smalltalk, *everything* is an object. ALL variables (notionally) hold references to objects. (Eiffel has the idea of 'expanded' variables, which are born initialised and cannot be reassigned. It's basically a nicely thought out efficiency hack which makes integers at one and the same time perfectly good objects AND just bits that work exactly like C number.) It has been conventional to call the boxes that hold references to objects "variables" for as long as there have _been_ object-oriented languages. (We've also had 'slots' (Lisp), 'features' (Eiffel), 'members' (C++), and a lot of other linguistic innovation whose chief purpose seems to have been to distinguish Us from Them.)

1 0

RE: A big teacher wish
by Richard A. O'Keefe 29 Nov '02

29 Nov '02

"Hernan Galante" <galanteh(a)smalltalking.net> wrote: I have been reading this track and I like the idea to change the names. The goal of this is to exclude the idea of "Variables" from Smalltalk. It is only honest to try 'to exclude the idea of "Variables" from Smalltalk' if you *first* actually exclude variables themselves from Smalltalk. Of course, if you do *that*, you end up excluding objects as conventionally understood, which might not be such a good idea. Let me try to make this clear. The programming language Mercury, Clean, and Haskell all have a notion of 'typeclass'. (Haskell had it first, but the Clean and Mercury designers knew a good thing when they saw it.) Here are some examples from the Haskell standard prelude. class Eq a where (==), (/=) :: a -> a -> Bool -- Minimal complete definition: (==) or (/=) x == y = not (x/=y) x /= y = not (x==y) If you declare that a type T belongs to type class Eq, then (a) you are asserting that it has functions (==) and (/=) which take two arguments of type T and return a Bool result; (b) you inherit definitions from the class; (c) you may override any of the operations with type-specific ones. (In this case you _must_ override one or the other.) instance Eq a => Eq [a] where [] == [] = True (x:xs) == (y:ys) = x==y && xs==ys _ == _ = False If T is a type, [T] is the type "list of T". This instance declaration says that if type T is an instance of the Eq type class, then [T] is also an instance of the Eq type class. It also defines equality for lists in terms of equality of elements: - an empty list is equal to an empty list - two non-empty lists are equal if and only if they have equal first elements and their tails are equal - any other combination of lists comes out unequal. Note that *values* (like the number 1) are not instances of classes in Haskell, *types* (like the type Int) are. class (Eq a) => Ord a where compare :: a -> a -> Ordering (<), (<=), (>=), (>) :: a -> a -> Bool max, min :: a -> a -> a -- Minimal complete definition: (<=) or compare -- using compare can be more efficient for complex types compare x y | x==y = EQ | x<=y = LT | otherwise = GT x <= y = compare x y /= GT x < y = compare x y == LT x >= y = compare x y /= LT x > y = compare x y == GT max x y | x >= y = x | otherwise = y min x y | x <= y = x | otherwise = y Type classes can inherit from other type classes. In this case, if you declare that a type T is an instance of the Ord type class, you must first have declared that it is an instance of the Eq type class, so the functions in the body of Ord may use all the functions in the Eq type class (as `compare` does). As before, the type class provides default implementations for its operations, which can be overridden by subclasses and instances. instance Ord a => Ord [a] where compare [] (_:_) = LT compare [] [] = EQ compare (_:_) [] = GT compare (x:xs) (y:ys) = case compare x y of EQ -> compare xs ys lg -> lg The instance declaration which says that "list of T belongs to Ord whenever T belongs to Ord" does override `compare`: an empty list is less than a non-empty list; empty lists are equal; non-empty lists should check their first elements and recur only if the first elements are equal. The classic OO trinity is Identity State Behaviour Well, Haskell (and Clean and Mercury) have Behaviour all right. In fact, the distinction between type classes and types is strongly reminiscent of the distinction between traits and classes. Just like traits, type classes have nothing to say about data, they merely provide chunks of behaviour for reuse. Just like classes, types DO describe data. What's NOT there is any notion of identity or state. In Haskell there are only values. There is no distinction between identity and equality. Above all, there is no mutation of state. If the expression e is legal and defined and the result is of a type that belongs to the Eq typeclass, then e == e MUST be true. *THAT* is what you get when you 'exclude the idea of "Variables" from Smalltalk'. It's useful. It is even, to my mind, beautiful. But it is not Smalltalk, and it is not object-oriented. State in the "OO trinity" refers to MUTABLE state. Identity refers to an object retaining some uniquely identifying property even though its state might change. Mutable state is variables. You can only exclude the IDEA of variables from Smalltalk if you exclude mutable state. If you leave mutable state in there, the IDEA of variables _has_ to remain even if you exercise the power of the Orwellian state and rule that from now on the word 'variable' is to be replaced in Newspeak by the word 'constant'. In the original Actors stuff, we were told that Actors had 'scripts' and 'acquaintances'. Lo and behold, 'scripts' meant something very much like 'methods' and references to 'acquaintances' were held in something indistinguishable from instance variables. We can have powerful expressions, not only for newbies programmers, Yes, we do. Already. we can have a powerful tool for people who are interesting in the use of squeak like a "virtual laboratory". Yes, we do. What else is E-Toys? My brother, for example use Squeak to study maths. Good to hear it. But to *USE* Squeak he doesn't have to be able to *PROGRAM* Squeak. And if he does program Squeak, he can, for example, attach behaviour to objects without once encountering a class declaration. Morph are a very good way to explore Arithmetic problems. That's good. But Morph is chock full of variables. Even at the user interface level, what is a StringMorph but a visible variable? (I note that Clean, despite being a pure functional language with no mutable state whatsoever in its semantics, nevertheless manages to provide a GUI kit that provides the *appearance* on the screen of boxes that can hold strings which can be changed. Though you may expell variables with a pitchfork, they will return.) He don't like "strutured" programs like Mathematica I am not sure what is particularly "structured" about Mathematica or why your brother is looking at the source code. The Mathematica *language* is, um, quirky. Understanding _Mathematica_ variables is tricky, but that does not mean that variables in Smalltalk are tricky. or to experiencie problems with languajes like Fortran. I don't like to experience problems with languages like Fortran either. Although it must be said that modern Fortran has much to commend it; I'd say that it's easier to get a Fortran 90 program right than the corresponding C++... One of the sticks you can beat Fortran with, of course, is that (due to the fact that some antique computers had weak and bizarre subroutine calling conventions) it is ambigious about the lifetime of variables. Smalltalk is NOT ambiguous about the lifetime of variables, it as about as clear as it could get. think it will be very useful to have: Morph subclass: #BioMorph objectKnowledge: ' myTarget lastTime ' classMembersKnowledge: ' CloseBoxImage ' dictionaryOfVocableKnows: 'Colors ' category: 'Morphic-Samples'! BUT THIS IN NO WAY EXCLUDES THE IDEA OF VARIABLES! All it does is eliminate the *WORD*. 'myTarget lastTime' are NOT object knowledge, they are VARIABLE NAMES. 'CloseBoxImage' is not the knowledge of some class member, it is a VARIABLE NAME. 'Colors' is not a dictionary of vocables, it's a dictionary of VARIABLES whose values are colours. The things that an instance "knows" (how pretentious it is to use "knows" and "knowledge" here; Dijkstra, why did you die when we still need you?) "Vocable" is a moderately rare word in English. The definition in www.webster.com is "a word composed of various sounds or letters without regard to its meaning". "Brekekekek-koash-koash" (the sound Aristophanes' Frogs make) is a vocable. Not only is it morally wrong to replace clear technical terms with gibberish, it is FUTILE to change words when your purported aim is to eliminate an idea.

1 0

Re: Recent Morphic/Alice changes?
by Bill Schwab 29 Nov '02

29 Nov '02

Andreas, A little profiling confirms your suspicion: it's full gc's. It even (especially!!!<g>) explains a pause from something that does not create new objects. There is good and bad in this for me. The good new is that I don't need the affected application. It's an old game concept that I revived as a test of Squeak. The bad news is that this is a situation in which lack of performance equates to lack of functionality. With the current perfomance hits, I doubt the game would be playable. I realize that I could bypass Alice, but then I'd end up with my own buggy version of WonderlandActor. I would not argue for removal of essential gc's from the class builder, but is there a way to refactor Alice so the classes would not be necessary, and therefore would not need to be recompiled? The only other thing that comes to mind would be to allow bundles of activity so that multiple changes could be followed by one full gc at the end of block. But, I think it would be better to elminate the dependence on creating new classes, or to find another fix of the classbuilder that does not require the gc's. Thanks! Bill Wilhelm K. Schwab, Ph.D. bills(a)anest4.anest.ufl.edu (352) 846-1285

2 1

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

Jump to page: