Squeak-dev January 1999

squeak-dev@lists.squeakfoundation.org

143 participants
293 discussions

Squeak 2.3 news?
by David LeBlanc 03 Jan '99

03 Jan '99

I recall reading 2 weeks or so ago that a production release of 2.3 was due within a few days. I was wondering if I missed a later announcement or did the holidays intervene? Sincerely, Dave LeBlanc

3 3

Re: How difficult is multiple inheritance?
by Vassili Bykov 03 Jan '99

03 Jan '99

From: Stefan Matthias Aust <sma(a)kiel.netsurf.de> >I wondered how easy (or difficult) it would be to add support for multiple >superclasses (aka parents) to Squeak. I think, there's just one method >Interpreter>>lookupMethodInClass: which would be affected by the change. It is not that simple, at least not for the general case (i.e. with no limitations on the superclasses). The trickiest thing is the instance layout. Traditionally, instance variable access is compiled as direct indexing into an instance. MI requires more hoops to jump. Here is an example: Suppose you have two subclasses of Object: A, with an instance variable a; and B, with an instance variable b. Access to both these variables in methods of A and B is compiled as accessing an instance variable at index 1. In instances of C, one of the two inherited variables ends up at index 2, meaning the compiled methods of the class it comes from cannot be used. Perhaps the simplest image-level solution would be to copy the inherited compiled methods into the subclass'es own method dictionary, adjusting the instance variable indices in the methods. (This "method propagation" also has to be done later as the superclass's methods are added or modified). Alternative solutions would need the VM support. One possibility would be for instance variable access to use, instead of an absolute index into an instance, an index relative to some base value. The base would be determined at the runtime depending on the actual class of the instance, and on the class where the method that accesses the variable was defined. --Vassili -- Vassili Bykov The Object People www.objectpeople.com

5 5

Re: Float Question
by Tim Olson 03 Jan '99

03 Jan '99

Oops, correction: > 11 bits - value minus 1023 to produce an exponent in the range > -1023 .. +1024 [should be -1023 .. +1023, emax=1023] > - 16r000: > significand = 0: Float zero > significand ~= 0: Denormalized number > (exp = -1024, no hidden '1' bit) [should be exp = -1023] >> fmax Definition: Report the largest value allowed by the >>characterized floating point object representation. This satisfies the >>ISO/IEC 10967 floating point characterization requirement fmax, and is >>equal to: > (1 - (self radix raisedTo: self precision negated)) * > (self radix raisedTo: self emax) I think this equation is off by a power of 2, or the definition of "emax" is wrong: (1 - (2 raisedTo: 53 negated)) => number slightly less than 1.0 if we multiply this by (2 raisedTo: 1023) we get 8.98846567431157e307 which is exactly half the correct value (1.797693134862315e308) -- tim

2 1

Newbie help request: Bad BitBlt arg (Fraction?); proceed to convert
by John-Reed Maffeo 03 Jan '99

03 Jan '99

I thought that it would be an interesting exercise to add color: to the Form class method dotOfSize:. When I add depth: to the form I start geting the Bad BitBlt message. When I proceed, I get a primitive failed error. depth: seems to be causing the problem, but I don't know where to start looking for an answer. Thanks, John-Reed Maffeo PS I am converting a program called Ropes which is fun to play with, but only comes in black and white. I have Ropes running, but the color part is stuck on this problem.

1 0

Re: Float Question
by Tim Olson 03 Jan '99

03 Jan '99

Richard Harmon writes: [exponent field] > 11 bits - value minus 1023 (16r3FF) to produce an exponent > of -1022 (-16r3FE) through +1023 (16r3FF) > - 16r000 reserved for Float zero (mantissa is ignored) > - 16r7FF reserved for Float underflow/overflow (mantissa >is ignored) These are not quite right; they should be: 11 bits - value minus 1023 to produce an exponent in the range -1023 .. +1024 - 16r000: significand = 0: Float zero significand ~= 0: Denormalized number (exp = -1024, no hidden '1' bit) - 16r7FF: significand = 0: Infinity significand ~= 0: Not A Number (NaN) representation > fmax Definition: Report the largest value allowed by the >characterized floating point object representation. This satisfies the >ISO/IEC 10967 floating point characterization requirement fmax, and is >equal to: > > (1 - (self radix raisedTo: self precision negated)) > * self radix raisedTo: self emax I think you forgot some parenthesis, here; it should be: (1 - (self radix raisedTo: self precision negated)) * (self radix raisedTo: self emax) > precision (52) [should be 53, there are 53 bits of precision including the hidden '1' bit] > emax (1023) [should be 1024] With the correct values, I get: ((1 - (2 raisedTo: 53 negated)) * (2 raisedTo: 1024)) asFloat => 1.797693134862315e308 -- tim

1 0

Re: How difficult is multiple inheritance?
by Stephen Pope 03 Jan '99

03 Jan '99

Hello all, Stefan's note is interesting, but overlooks the two big questions in implementing multiple inheritance (MI): 1) How do you handle multiply-inherited methods (i.e., if I inherit a method through more than one inheritance path, how can the user specify which one to use?), and 2) Do you allow multiply-defined instance variables? David LeBlanc wrote: > > ParcPlace tried MI about 10 years ago - lasted one or two minor revisions > and then they gave it up. > > I think interfaces would be a better idea. On the first point, I believe he's referring to the MI system developed by Alan Borning and Dan Inalls for ThingLab, which ParcPlace indeed shipped with several of the ObjectWorks 2.X releases and then discontinued (due to general lack of interest). It worked quite well, and I for one used it heavily for my first few years as a Smalltalk programmer (having come from Flavors/LISP, I was used to MI, but then learned to use species relationships and delegation instead). I fully agree with David's second point. Alan Kay wrote > There is a cooler and most interesting way to approach all this. > [...] > it was called PIE: Personal Information Environment > [...] > The basic idea is to have an object made up of multiple perspectives... PIE was much more of a frames-like knowledge representation [KR] framework, rather than a concrete OO implementation platform. I believe it's quite important to differentiate between the two. OO ~= KR! (ByTheWay, the best of the PARC Blue Books on the subject is Danny bobrow's "Knowledge Representation," which was still available from PARC when last I asked.) There are times when "real" MI is handy (e.g., Sea-plane is-a Plane, is-a Boat), and other times when composition/delegation (e.g., EventList is-a Event, has-a Event-collection) or class/species differentiation (e.g., HertzPitch is-a NumericalMagnitude, species-is-a Pitch) work better and result in cleaner, more reusable, code. Remember also that the Smalltalk class library is not structured as "mix-ins," so it's not set up for MI of (e.g.,) magnitude, collection, or stream protocols. -- stp Stephen Travis Pope stp(a)create.ucsb.edu -- http://www.create.ucsb.edu/~stp/

3 2

How difficult is multiple inheritance?
by Stefan Matthias Aust 03 Jan '99

03 Jan '99

Hi! I wondered how easy (or difficult) it would be to add support for multiple superclasses (aka parents) to Squeak. I think, there's just one method Interpreter>>lookupMethodInClass: which would be affected by the change. Let's say, I create a new subclass of Behavior (called MapClass) which has an additional instance variable called "parents" that can contain nil or an (possible empty) array of other Behavior instances. Then I'd modify the first part of the lookup method as follows currentClass := class. [currentClass ~= nilObj] whileTrue: [ "{ new/replaced code" mapClass := self lookupWithParentMaps: currentClass. mapClass ~= nilObj ifTrue: [^ mapClass]. "}" currentClass := self superclassOf: currentClass]. and write a new method (things in {{}} are pseudo code) lookupWithParentMaps: aClass | dictionary found parents mapClass dictionary | self inline: true. "{ copied from old method" dictionary := self fetchPointer: MessageDictionaryIndex ofObject: currentClass. found := self lookupMethodInDictionary: dictionary. found ifTrue: [^ currentClass]. "}" (self isMapClass: aClass) ifFalse: [^ nilObj]. parents := self fetchPointer: {{indexOf('parents')}} ofObject: aClass. parents ~= nilObj ifTrue: [ 1 to: {{parents size}} do: [:index | mapClass := {{parents at: index}}. mapClass := self lookupParentMaps: mapClass. mapClass ~= nilObj ifTrue: [^ mapClass]]]. ^ nilObj and finally invent some solution for the #isMapClass: method (are there any format bits left?! Does anybody know?) then, well, then would this already add multiple inheritance? I'd like to hear your comments before I'll actually start some VM hacking. I'd even gracefully accept a patched and newly compiled Windows VM :-) bye -- Stefan Matthias Aust // Are you ready to discover the twilight zone?

3 2

Re: How difficult is multiple inheritance?
by Alan Kay 03 Jan '99

03 Jan '99

Andrew -- I would first try to contact Xerox PARC. Cheers, Alan At 4:15 AM -0000 1/3/99, Andrew C. Greenberg wrote: >So how do we find these papers?

1 0

Re: Dangling SystemWindow's in 2.3Beta
by Pennell's 02 Jan '99

02 Jan '99

Scott, >The five windows that are eluding you are all related to the default "standard parts bin". >Squeak maintains a prototype of the parts bin in >memory so that one can be quickly >produced upon request via "veryDeepCopy" of this prototype. Aha, those MorphThumbnail's pointing to them should have been a clue. >(For those that may not have noticed, if you bring up a parts bin [via the "authoring tools" >menu in a morphic project] and look through its pages, you'll come upon a page that >offers a browser, a workspace, a file-browser, etc. If it suits your style to keep a parts >bin up, you may find this to be a convenient way to launch such tools.) Wow, they launch very, very fast! This should be a useful technique for launching large applications. -david

1 0

Squeak: Events, Modularity, Exceptions
by Paul Fernhout 02 Jan '99

02 Jan '99

Squeakers - With the awesome 2.3 beta release proving beyond a shadow of a doubt how cool Squeak is, it may now be time to think about some underlying Squeak "plumbing" issues. In my opinion the issues of events, modularity, and exceptions are the leaky plumbing that needs to be addressed to make Squeak a great programming system (beyond merely good). I'll even go further: these need to be addressed (and soon) if Squeak is to grow and prosper. They need to be addressed to make Squeak ready for prime-time limelight -- into which it seems (ready or not) about to head. Each of these issues also makes a big difference in embedding a headless Squeak (my current interest). However, they also make a big difference in terms of making Squeak more changeable in other ways (thus addressing "pink" and "blue" planes simultaneously). Exception handling allows one to more easily remove GUI dependence. It also is becoming accepted practice. This is because use of exception handling leads to cleaner code, helps one to securely manage unique resources, and supports modules working together more cleanly (i.e. you don't have to know what a bad return code would be, just that a call could fail). I know you can replace the error handler for a process, but this isn't really a complete solution. For an example of what I am talking about, compiler code should not launch windows on detecting a syntax error -- it should throw an exception. The top level exception handler could open a window, in response to a compiler related exception. Or, your code that calls the compiler could catch that exception and process it itself. Events allow Squeak to cooperate better with an OS (i.e. as a component) and removes any tendency towards a high idle cycle stealing from polling. Base Squeak still relies at the heart of it on polling loops. I know Morphic addresses these, but Morphic brings along its own set of performance and use issues. One needs to have events in the base system without Morphic. I use "events" loosely here -- being "event driven" also means (to me) being able to call in and call out of the system in a coherent fashion (such as asking Squeak to evaluate an expression and return a result). I understand that Squeak as an OS might require some polling (ideally based on timer events). But Squeak as a component under an OS would be better if it just dealt with events (like mouse move) rather than asked hardware for them on a regular basis. Modularity allows one to deploy a Squeak system with the minimal footprint (like with only text handling classes and a compiler). Stripping out what you don't want is not good enough. One should have precise control over building an image up from modules to get exactly what you do want -- with every byte accounted for (and none accidentally left over from ST-76). Addressing modularity also entails addressing version interdependency (something ENVY is good at). Ideally, the standard image released for new versions should be as small as possible, with new code being added by end users as desired. Of course, for convenience people would create an image with everything, but that should only be as a time-saver. One might also want to load precompiled modules as object code (not source) over the web. Finally, modularity makes it easier to conceive of shrink-wrapping a Squeak product. Obviously, individuals have addressed these somewhat -- especially exceptions (in different ways). Yet these enhancements have not made it into mainline Squeak. We are all grateful for the fantastic job done by Squeak Central of integrating contributions and creating ever greater versions of Squeak. Still, in the interests of moving Squeak forward, it would be nice to know if these core issues of events, modularity, and exceptions anywhere on Squeak Central's priority list for the near future. If not, since these issues are so fundamental to the system, how could these be addressed by others in such a way as to avoid splintering off another development line of Squeak? I seems obvious (to me) that having proper solutions for these in mainline Squeak would not detract one bit from efforts at Disney to use Squeak in-house (except in the sense of time if they implemented them or merged them). Yet, every time I think of coding up something to address any of these (or using someone else's solution), I realize all that work is going to get left behind in a new release, because it entails making many fundamental changes to the system (sprinkled throughout the code). At OOPSLA '97 it was brought up that there are two main Squeak camps. The first camp is people who want to experiment. It seems this includes the mainline Disney maintainers much of the time -- after all they are not paid to provide a free Smalltalk system -- it just helps their work to be using one. Working on Squeak's plumbing isn't as convincing to top management of progress as the next cool Squeak Morphic applet/thingy, and it's not as much fun either (regardless of how essential it might be to sustained progress). The other camp is made up of people who wants an open and stable Smalltalk to do real business-like work (typically grungy, non glamorous, often text-oriented and standard widget-oriented). It's not necessarily that we wouldn't pay for Smalltalk, or don't have several purchased copies on the shelf. It's more like we want to ship the compiler, or we might want to change the VM in the future, or we want the really small footprint Squeak offers, or any of several other reasons (often related more to open source issues than money itself). Some people, like myself, are in both camps at various times. Perhaps this is common. Obviously, being able to justify Squeak use to management for grungy apps (like processing text files) would get it in the door for other fancier uses. Does this make sense at all? Is the second camp (or sentiment) present on this list to any extent? Am I the only one out here thinking Squeak could become an acceptable scripting language up there with Perl, TCL, and Python/TK? I would think many people would adore feeding program/text files to Squeak which were written in their favorite text editor (David Pennell brings this issue up in a recent "Re: Squeak book" post). As something to be concerned about, when the bulk of newbies show up as Squeak gets more publicity, I'd think they would expect Squeak to do the boring stuff, even if they other stuff (Morphic, Music, Wiki, Web, VM) wows them. But if Squeak can't do the boring stuff (i.e. the stuff Delphi does, VB does, C++ does, Python does), potential converts may not stick around (unless they got faith, like me :-). They certainly will have a hard time being able to convince their supervisor to use it for utilities or apps. Alternatively, if someone was going to maintain another line of Squeak (focusing on stability, minimal footprint, shrink-wrapping, events, modularity, exceptions, compatability like all code using := assignment, standard GUI widgets, etc.) would that do other than wither as the current mainline Squeak forged ahead? Or would experimental Squeak work reorganize around the stable version? Would people want to use such a release (beginners, servers, embedders, business types)? Would experimental Squeakers be comfortable pointing newbies to a separate line of development? I'll conclude by mentioning that Python has exceptions, and handles events and interoperation, and is modular. In fact, while I like Smalltalk syntax better, and I think Squeak's potential is greater than that of Python, availability of these features (events, modules, exceptions) are key reasons I think Python is currently a more practical development system for pure OO deployable applications. I'd like to see Squeak/Smalltalk as the better Python alternative (just like Python is the better Perl alternative). That's not going to happen if these core issues are not addressed -- no matter how many fancy things make it into a huge base image. -Paul Fernhout Kurtz-Fernhout Software ========================================================= Developers of custom software and educational simulations Creators of the GPL Garden with Insight(TM) garden simulator http://www.kurtz-fernhout.com/squeak

2 1

Jump to page: