Squeak-dev September 1998

squeak-dev@lists.squeakfoundation.org

108 participants
197 discussions

Polymorphism and language
by Adam Bridge 02 Aug '00

02 Aug '00

I wonder if we're not asking the wrong question here. Language, it seems to me, is for expression. If we design a language (as opposed to allowing it to evolve) then we should have a goal for that language. What's the goal here? Although polymorphism is certainly an interesting capability shouldn't we be looking at the kinds of tasks we wish to perform? Would we demand an artist work in tempra when water color is what expresses the mood best? Personally I like the idea of small languages that do some things very very well. They are easy to learn because their concepts are clear. If languages can agree on ways to intermingle so I can write my image manipulation in one language and my text in another and my GUI in yet another -- and have them work together intimately and EASILY -- then I think we have a software system which is about expression first and language second. I'd love to easily, trivially, combine Smalltalk, Perl, Fortran, Obj-C and be able to easily explore other languages in this same context: it becomes easy to grow. Adam Bridge

2 1

unsubscribe
by Alek 09 Jun '00

09 Jun '00

2 1

Re: Re: Float bug toolkit: what the hash is this?
by Tim Olson 31 Aug '99

31 Aug '99

>>"[1]" (10 raisedToInteger: 600) = (10.0 raisedToInteger: 800) "alt-p" >>These are equal since both expressions end up answering a float with a >>special value indicating positive infinity. Positive infinities are always >>equal. > >Nonono.... (10 raisedToInteger: 600) is anInteger, while the other (if >finished correctly) is aFloat. Correct. The problem occurs when the #= message is sent to the LargePositiveInteger with the argument a Float (+Infinity). This causes the LargePositiveInteger to be adapted to a Float (resulting in +Infinity, as well). >If aFloat turns out to be infinite, an error >should be posted. This would have to be tested in the Float primitives in the VM whenever an overflow (or NaN, I suppose) is generated. However, I *think* (VM experts correct me, here) that all they can do is fail rather than returning a succesful value, so all of the Float code that invokes primitives would have to be rewritten to test and reflect this overflow/exception failure. The IEEE "default" operation is to silently return the default values (Inf or NaN), rather than generating an exception. What should the standard for Squeak be? -- tim

3 2

CrLfFileStream as default?
by Lex Spoon 06 Nov '98

06 Nov '98

If a file has a CRLF pair in it, and CrLfFileStream converts that to a CR, then the idea of "position" gets messed up. It looks like 1 character, but "file position" will act like 2 characters have gone by. For CrLfFileStream to go the final mile, it should probably have some code to make positions truly transparent to the user. Other than that, CrLfFileStream seems very nice. I've been using it as the default for several months now and found it nothing but convenient. Lex "Pennell" <pennell(a)tiac.net> wrote: > Dan - thanks for adding this in 2.2. Is there any reason not to make this > the default? > If you don't change the default for 2.2, can you add it as a preference? > > - david

4 3

Re: Updating old 2.1 images to 2.2 (limited interest)
by Dan Ingalls 26 Oct '98

26 Oct '98

Folks - The beta release should be on its way this evening. For those of you who are updating old versions of Squeak, I have just put out another 40 or so updates on the update servers. These are tied to the new version name, so in order to see them, you will have to reset the version number of your image. Here's the full procedure, if you want to move a 2.1 image forward with continuity, * get all updates (the last of 2.1) ...the last should be number 227 * execute... EToySystem eToyVersion: 'Squeak2.2beta' date: '10 September 1998'. * get all updates again (the current set for 2.2) ...this should get you up to around 268 Good luck, and please let me know offline if you have any problems /or/ if it works for you (I am curious if anyone is trying to maintain independent forks). Thanks - Dan

4 5

Meta-concept (was: Confusion over basic Array new:)
by Mark Wai 17 Oct '98

17 Oct '98

Warning: This is a long note and you might find the content completely useless. At 11:41 AM 9/17/98 -0700, you wrote: >guzdial(a)cc.gatech.edu wrote: <snip> > So where's the method that is being called on this message? > >You should be searching through > Array class > ArrayedCollection class > SequentialCollection class > Collection class >and Object class > >Then you find that Object class's superclass is not nil, since its a >Class, but Class. So the search is actually: > > Array class > ArrayedCollection class > SequentialCollection class > Collection class > Object class > Class > ClassDescription > Behavior (voila!) > Object > <snip> Based on my experience in the past on teaching people on the concept of metaclass, with the aid of the very nice diagram from the purple book, most of the time people still don't understand it. Even for the students who claimed they understand it, I later found out that they (most of them) actually don't understand it. But I don't want to give up on getting more people to understand one of the most basic meta-concept of all meta-concepts because I think this meta space is one of the most interesting and useful area in computer science. I think some of the difficulties on understanding this meta-relationship is due to the fact that Smalltalk has implicit metaclasses and hidden metaclasses hierarchy (which I can't do anything). And I noticed that a good portion of people just can not "see through" certain thing. So no matter how hard I try to illustrate the meta-circularity and the metaclasses hierarchy, I didn't have a lot of success. Therefore, I started to go with another approach. Instead of having the students to "see through" this meta-relationship, I have them "experiment" it first, and then reconstruct this relationship by themselves. So, I abandoned all the diagrams and drawing that I have done before. And surprisingly, the result is pretty good and that's why I wanted to share here. To use the original question as an example, to find out where the >>new method is implementated when send this message to the Array object. I asked them to do the following: 1) Find out what class this receiver belongs to because the class of the receiver dictate what it can understands. Simple enough: Array class 2) Find out if the resulting object from 1) implements the method or not. If not, go up the hierarchy and start search from its superclass. In step 2), the following constraint must be applied: If the resulting object is a metaclass, keep sending >>superclass until the resulting object is not a metaclass. P.S. In order to find out whether an object is a metaclass or not, inspect the resulting object to see whether the inspector labelled with 'Metaclass' or not. Alternatively, print the resulting object and if the string has the word 'class' as the last word, it is a metaclass. Hence, Array class superclass ---> is a metaclass, so keep sending >>superclass Array class superclass superclass --> is a metaclass, so keep sending >> superclass until Array class superclass superclass superclass superclass superclass which answers Class. Since Class is explicit (i.e. not a metaclass), they can start searching in the browser to see if Class implements >>new or not. Since it is not so keep going up to its superclass. Finally Array class superclass superclass superclass superclass superclass superclass superclass which answer the class Behavior and bingo, method located. 3) From each message send, write down the named class and draw the hierarchy from bottom up. So Array class Array class Array class superclass SequenceableCollection class Array class until Array class superclass superclass superclass superclass superclass superclass superclass Behavior ClassDescription Class -------------------------------------- Object class Collection class SequenceableCollection class ArrayedCollection class Array class --------------------------------------- Now the students can see the implicit as well as the explicit hierachy. But most importantly, they draw each level by themselve by 'experiement' it. Obviously, the above hierachy, though illustrated the parallel hierarchies, is not complete because it skips one of the most important class in question - Metaclass that is. Therefore,, 4) Reintroduce the classic purple book diagram to the student. Amazingly, after the student can 'acutally' find out the answer by experimenting it instead of spinning through the pointers in the diagram, they have a much better appreciation and understanding. At least, they understand that there are actually exist a parallel hidden meta-hierarchy which could not be seen by a standard browser. Last but not the least, they understood that the location of such method is not by magic(well, in a sense it is :-)), it is actually through perfect inheritance mechanism. Anyway, I just wanted to share my experience with this community and thanks for reading (if you are reading this far). -- Mark Wai Wator Innovision mailto: mwai(a)ibm.net or:[ mwai(a)frontiersa.com] __

2 1

Does Squeak include a generic node class?
by Jerome.Garcia＠wj.com 17 Oct '98

17 Oct '98

I have not been able to find a generic node class in Squeak. Does Squeak provide a node class similar to the TreeNode class provided by Dolphin Smalltalk? If not, is there a reason why it should not? Jerome E. Garcia jegarcia(a)adventurousmind.com

5 4

Zip decompression in Squeak
by Alejandro F. Reimondo 04 Oct '98

04 Oct '98

I need to decompress zip files in Squeak. Has anyone implemented zip decompression? Ale.

2 1

Re: [Fwd: Morphic Wrappers] (fwd)
by Gerardo Richarte 02 Oct '98

02 Oct '98

Daniel wrote: > Double click on my just dragged supposedly wrapped Form. Bummer - > Morphs aren't really wrappers. They don't give you a message menu, > they just blink dumbly. I had this problem myself, and Leandro [Caniglie] also has it. Once we use MorphicWrappers, we want everything to act as a MW, but no... As a result of this we started moving some messages in MW to Morph, this work is not finished yet, but it will be soon. We have to solve some design problems... if we move doubleClick menu, drop menu or keyboard handling to Morph then no Morph will be able to use those events anymore. As an example of this, suppose you have a GraphMorphicWrapper (one that I've done, and will post it somewhere soon) and you drop something over it. It can be a Number, as argument to some message, or it can ve a Vertex, so it can be added to the Graph. (this can be a default message... it's not a bad idea). I solved this problem checking the class of what is dropped, but this is not a good generic solution... Now I'm thinking that a default message can be sent holding shift down while dropping something in the MorphicWrapper... I'll test this, it sounds good, what do you think? (still don't know how to solve keyboard focus) > I started thinking about it, and realized that wrappers allow Objects > to live in Morphic, imitating Morphs. But by adding all that wonderful > Wrapper functionality, you leave Morphs behind, and therefore, they > don't mix. > > I was wondering whether and how you intended to address this. Ohhh, emmmm, well... one solution can be to turn everything Morphic in something MorphWrapped, and leave some Morphs as construction blocks, but I don't know if this is a good design idea. > Off the top of my head, it seems to me that the functionality in > Wrappers today might be better split between two levels, one allowing > a readable represetation on screen and the basic Morph menus, and the > next level providing the message sending interface. What do you mean with message sending interface? If you mean talking (typing) to an object, this can be moved to Morph with some work: We have to solve the problem of setting the keyboard focus by clicking on an object, because there are some morphs that need keyboard for their use (StringMorph for example) > [..] and the send level would allow all objects, Morph or wrapped, to > be sent arbitrary messages. I don't fully understand how to implement this interface on Morphs (or may be I don't understand what this message sending interface is...) > Which level is used should be decided by the World you're in. Can you expand this, please? > Waddaya think? > Anyway, thank you for Wrappers, certainly one of the coolest things > I've seen in Squeak. Ups! thanks! > What do you have in mind for version 2? + WrapperWorldMorph is gone, WorldMorph has learned all its functionallity + History (by Class) is implemented in CodeStringMorph. + A package with some interesting examples will be available, including GraphMorphicWrapper, VertexMorphicWrapper and (probably) some very interesting use of them, !!! ClassMorphicWrapper and (some kinf of) MethodMorphicWrapper (thanks to Leandro) !!! Some of them may be moved to the basic package... + Some rearrangement in classes: there is no more RoughMorphicWrapper, some methods have been moved from to MorphicWrapper, and some other to Morph. + everything I'm forgetting... Improving Bye! Richie++

2 1

Re: Getting Started with Squeak
by Mark Guzdial 01 Oct '98

01 Oct '98

>> There are very few languages well suited to creating UIs. Smalltalk may be >> the only one. > >Please explain that statement. I am a Smalltalk novice. What makes the >*language* well-suited to creating UIs. The MVC or pluggable paradigms? >They are not language specific. Dan Olsen talks about this in his new book on "Developing User Interfaces" (Morgan-Kaufman, 1998). I don't think I grok all the subtleties, but I'll try to relate the story. The self-reflective and late-binding nature of Smalltalk allows you to create views that are more de-coupled from their models. For example, when a textbox sends #getText to its model, it doesn't care what the model is, as long as it can respond to getText -- you can even swap the model at run-time, and as long as the message is answerable, it all works. Olsen contrasts this with C/C++ where the compiler requires the model and view to be linked together at compile time, the types have to match, etc. Java can do this de-coupled model-view, too, but it had to invent (overly-complex, IMHO) inner classes to make it work. Mark -------------------------- Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280 (404) 894-5618 : Fax (404) 894-0673 : guzdial(a)cc.gatech.edu http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html

5 4

Jump to page: