Squeak-dev July 1999

squeak-dev@lists.squeakfoundation.org

139 participants
367 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

Article in Wired
by Andrew C. Greenberg 11 Oct '99

11 Oct '99

The July 1999 Wired has a brief piece on Squeak on page 158, entitled "Exquisite Computing." Missing the point entirely as the media so often does, the article observes that Squeak has "text-wrapping and manipulation features that would make PageMaker green with envy." But hey, the piece, at least, has a screen shot and encourages folks to visit http://www.squeak.org. Just so long as they spell our name right. So, in anticipation of the new raft of newbies this is bound to engender, let's polish up the help pages and welcome them to the world of real computing. Its time -- what can we do to help?

2 1

HELLO, I AM NEW,
by Ardolino Horacio Luis 08 Sep '99

08 Sep '99

4 4

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

What's coming in 2.5 [LONG]
by Dan Ingalls 08 Aug '99

08 Aug '99

Folks - I apologize for such a long message, but it will give you an idea of what's out there now for test pilots, and coming in 2.5. There are a number of updates yet to come, but this covers the bulk of them. - Dan ---------------------------------- Numerous enhancements related to Flash graphics... 1214FlashEditing-ar -- Andreas Raab -- 20 May 1999 Adds simple editing capabilities for Flash animations. You can open up a sorter from a flash player and use it for creating smaller chunks of movies out of the biggies. 1225FlashProjectZoom-ar -- Andreas Raab -- 2 June 1999 1229FlashZoomFix-ar -- Andreas Raab -- 5 June 1999 1229FlashZoomFix-ar -- Andreas Raab -- 5 June 1999 Adds Flash animations for project transitions. Details in preamble. 1273FlashFixes-ar -- Andreas Raab -- 28 June 1999 A bunch of fixes related to transparent gradient fills and undocumented (sigh!) alpha in color transformations Numerous improvements to morphic flaps... 1220flapTweaks-sw -- Scott Wallace -- 27 May 1999 Avoids instantiating default global flaps unnecessarily when entering morphic projects. 1258window&FlapMenu-sw -- Scott Wallace -- 21 June 1999 Combines the world's flap menu with the window menu -- more in preamble. 1262flapAdvances-sw -- Scott Wallace -- 21 June 1999 Numerous improvements and bug fixes relating to flaps, of which some are: Flap tabs can now be dragged for positioning and flap-resizing whether or not open. When switching among textual, graphical, and solid choices, former choices are honored. (e.g. when you switch back to using a textual tab, the wording deployed when the tab last was textual is restored.) When you dismiss a flap tab via its halo, the corresponding flap is also dismissed. Flap-explanation window contents rewritten. Flap menu changes: * Can now be persistent (very useful!) * Menu items and title are self-updating. * Tab-color and flap-color can both be changed. * 'Slide' and 'Inboard' options removed from the UI. 1295flapFixes-sw -- Scott Wallace -- 6 July 1999 Preserve tab color upon switching back to textual form. Constrain tab to fit on screen when user tries to drag it out of view in its orthogonal direction." Numerous piano roll improvements... 1222pianoRoll-jhm -- John Maloney -- 30 May 1999 Better performance (achievedby moving the cursor, rather than the notes Ability to hide muted parts. Also adds a bassoon sound and a cool new FM clarinet (clarinet2). Check it out! 1252F2KDemoPreps-di -- Dan Ingalls -- 15 June 1999 This changeSet adds the ability to scroll MidiScores and their PianoRolls. Allows dragging pitch of notes in the score. Plays all notes vertically if you click outside a note but within 30 pix vertically. Adds a note edit menu and a score edit menu. Allows selection of multiple notes in a track, and basic cut copy paste functions. 1255F2KDemoPreps2-di -- Dan Ingalls -- 20 June 1999 Adds ability to change time signature and enable display of measure lines Fixed a bug with slow backward scroling of the PianoRoll. Will play wherever you click (and drag!). Defines KeyboardMorphForInput for entering simple melodies. Autoscrolling is supported for both play along with the cursor, and melody selection. New 'paste...' command is like paste, but it will transpose the entire selection up or down. Numerous improvements to Alice/Wonderland 3D... 1226WnldMorphicTextures-ar -- Andreas Raab -- 3 June 1999 This change set adds 'active' textures to WonderlandActors. See details in preamble -- you can actually project morphic onto a surface in 3D. 1228WnldInitFix-jsp -- Jeff Pierce -- 4 June 1999 A small fix so that the camera's name shows up in the actor browser 1275Alice2Pool-jsp -- Jeff Pierce -- 29 June 1999 Define the pool dictionary for Alice v2.0." 1276Alice2-jsp -- Jeff Pierce -- 29 June 1999 Some initial classes for Alice v2.0." 1277WnldCamClass-jsp -- Jeff Pierce -- 29 June 1999 Alter change logging for Cameras so that I can introduce a new subclass." 1280WnldCamClass2-jsp -- Jeff Pierce -- 29 June 1999 Ok, this actually does what the last change set should've done. =)" 1281WnldStillCamera-jsp -- Jeff Pierce -- 29 June 1999 Implements a still camera for Wonderlands (for use in the Actor Info tab)." 1282WnldUpdates-jsp -- Jeff Pierce -- 29 June 1999 Changes to Wonderland classes to improve the ActorViewer." 1304WnldActView-jsp -- Jeff Pierce -- 7 July 1999 This change set continues the development of the Actor Info tab for Wonderlands. Specifically, this change set adds some smarts so that the object the user is currently focusing on is correctly framed and at a suitable distance. This change set also changes rendering for WonderlandStillCameras so that they only return the object they're focusing on (and its children) from the scene graph." 1306WnldActorInfo-jsp -- Jeff Pierce -- 8 July 1999 Adds the first version of the WonderlandActorData morph to display information about an actor. Also integrates this morph into the WonderlandActorViewer (the Actor Info tab in the editor)." 1307WnldChanges-jsp -- Jeff Pierce -- 8 July 1999 This change set primarily makes the ActorViewer update its information every second. It also changes the way WonderlandCameras and WonderlandStillCameras determine change logging so that I can start using protoclasses for Cameras." 1308WnldProtoClasses-jsp -- Jeff Pierce -- 8 July 1999 Change the creation process for both lights and cameras so that both are created using prototype classes. Among other things, this means that becomeChild: works correctly when a camera or light is involved. Name changes also occur for these objects when reparenting just like other Actors now. This change set also modifies change logging for lights so that protoclasses aren't logged." 1309WnldUndoFix-jsp -- Jeff Pierce -- 9 July 1999 Prevents the act of the WonderlandStillCamera positioning itself and taking a snapshot from stomping on the UndoStack." 1312WnldRotInfo-jsp -- Jeff Pierce -- 9 July 1999 Adds the actor rotation data to the Actor Info tab. Also fixes the Actor Info tab to clear the selected actor on reset, and fixes reset so that prototype classes are created correctly for lights and cameras." Major change that eliminates the distinction between WorldMorphs and PasteUpMorphs. 1235NewWorld1-di -- Dan Ingalls -- 7 June 1999 1236NewWorld2-di -- Dan Ingalls -- 8 June 1999 1237NewWorld3-di -- Dan Ingalls -- 10 June 1999 1238activeHandFix-sw -- Scott Wallace -- 10 June 1999 Henceforth, a world is simply a pasteUpMorph with no owner. Moves hand, canvas, and stepping logic to Project. While WorldMorph remains, it should not be used. The plan is that PasteUpMorph is the unit of storage on web pages, and the unit viewed by projects, books, and nested worlds Numerous changes to Morphic Menus... 1246smartMenuItems-sw -- Scott Wallace -- 11 June 1999 1251SmartFlashMenus-ar -- Andreas Raab -- 16 June 1999 Adds a new kind of MenuItemMorph that updates its wording as necessary. 1259menuStuff-sw -- Scott Wallace -- 21 June 1999 A variety of improvements and fixes regarding menus in Morphic. See preamble. 1260playfieldMenu-sw -- Scott Wallace -- 21 June 1999 Considerable reworking of the playfield menu. See preamble 1286menuEnhancements-sw -- Scott Wallace -- 29 June 1999 Allows any individual menu item in a MorphicMenu to operate correctly -- as a stand-alone button, as it were -- even when not in a menu. To use, bring up the halo on any menu item and tear off a copy via the green 'duplication' handle; the item should then be usable on a stand-alone basis. Also, implements a personalizable morphic screen menu, brought up when you click on the desktop with the mac option key (or equivalent) held down." Numerous changes to Scripting... 1248scriptCleanup-sw -- Scott Wallace -- 15 June 1999 See details in preamble. 1297newEtoyEnv-sw -- Scott Wallace -- 6 July 1999 Revised etoy UI as per Alan's 6/99 suggestions: * If preference #viewersInFlaps is true, then viewers for objects appear in flaps adhering to the right edge of the screen, with tabs derived from the object's own appearance. * If preference #oneViewerFlapAtATime is true, then when you open up one viewer flap, any currently-open viewer flap is closed, so that you see at most one at a time. * #automaticViewing option available in world. * Adds a protocol for determining whether a given morph is a likely candidate for automatic viewing (windows and menus and viewers themselves are good examples of things that are NOT). * Some fresh heuristics for mouse-over halos. Special rules apply for the World -- if it has mouse-over-halos turned on, they only pop up over objects that reside on the world at large and which are either SketchMorphs or have players. For smaller-than-the-world playfields, the existing rules prevail. 1301playfieldOrigin-sw -- Scott Wallace -- 7 July 1999 Adds an playfield option to have the center of a playfield as its origin, rather than the usual bottom-left corner, when figuring cartesian coordinates. By default, the origin is the bottom left of a playfield. But if you set the new origin-at-center option to true, then the origin of the playfield will be its current center." 1302viewerFlapTweaks-sw -- Scott Wallace -- 7 July 1999 The graphical tabs of viewer flaps are now active thumbnails that always reflect the current appearance of the viewee. Viewer flaps are preset to have the 'automaticPhraseExpansion' property, making them excellent places not only to view an object but also to script it. Now that the thumbnail is held in the flap tab, the viewer itself no longer needs to have one, so the thumbnail in a viewer-flap-resident viewer is replaced by a menu icon. Menus for viewer flaps are customized to have only appropriate items -- some items had been misleading or downright damaging." Important change to the representation of Behaviors 1243SubclassesChange-di -- Dan Ingalls -- 10 June 1999 Moves the redundant structure, subclasses, down from Behavior to ClassDescription. It would have been moved down to Class, but that would have changed the order of variables in every class and metaclass. The slot is no longer used in Metaclasses. This simplifies operations on class structure. It also frees other subclasses of Behavior from carrying this burden as, for example, in lightweight behaviors for experiments with prototypes. Major changes to morphic canvases and drawing. 1267CanvasPart1-ar -- Andreas Raab -- 17 June 1999 The first part of the changes to Morphic drawing. All of this stuff is (or at least should be ;-) *purely* structural - nothing at all should change in the way stuff looks or behaves. See preamble for an overview of the major changes 1271CanvasPart2Again -- Andreas Raab -- 22 June 1999 This is the second part of the Canvas changes. It introduces two new canvases: a ColorPatchCanvas used to replace the #fullDrawOn:without:andStopThere: methods and a ShadowDrawingCanvas which can (and eventually will) replace the shadow drawing in FormCanvas. Right now, shadow drawing is still part of the FormCanvas itself (see it as an 'optimization' ;-) but we might get rid of it for a cleaner structure. 1271CanvasPart2Again -- Andreas Raab -- 22 June 1999 This is the second part of the Canvas changes. It introduces two new canvases: a ColorPatchCanvas used to replace the #fullDrawOn:without:andStopThere: methods and a ShadowDrawingCanvas which can (and eventually will) replace the shadow drawing in FormCanvas. Right now, shadow drawing is still part of the FormCanvas itself (see it as an 'optimization' ;-) but we might get rid of it for a cleaner structure. 1272MorphicFillStyles-ar -- Andreas Raab -- 18 June 1999 This change set replaces colors by fill styles in the basic morphs: * Morph/BorderedMorph/RectangleMorph * EllipseMorph * PolygonMorph/CurveMorph After you have filed in this change set, create any of the above guys and start playing with the 'fill style' submenu (replacing the old 'change color'). Numerous changes to Preferences 1287prefSpruce-sw -- Scott Wallace -- 29 June 1999 (1) Removes reliance on the doesNotUnderstand mechanism for Preferences; instead, each defined preference is represented by an explicit retrieval method. The old mechanism remains in place, but could now be removed, or replaced by something that has the same effect but logs the call to the Transcript as a warning that an undefined preference is being invoked. (2) Adds a way that default values for new preferences, and help messages for preferences, can be added or changed without needing to modify huge monolithic methods. (3) Adds a method you can call to get hard-coded preferences compiled simply." 1296initPrefValues-sw -- Scott Wallace -- 1 July 1999 Allows specification of initial values for preferences to be distributed across multiple methods. Each method in category 'initial values' of Preferences class is expected to return a collection of pairs of the form: <prefSymbol> <initialValue> To make sure added preferences are propertly initialized in the dictionary, call Preferences initializeAddedPreferences .... this will set initial values for any preference not yet defined in the dictionary, while leaving any existing values unchanged. And it will also compile preference-accessor methods for all preferences mentioned in the initial-values category which lack them. Renames the pref formerly known as 'objectConversionMethodsAtFileOut' to be simply 'conversionMethodsAtFileOut' because the former was too long to fit in the standard prefs window." Isolated projects - a new (and untested) modularity feature 1298isolateCng-tkKQ 1299activateIso-tkKQ Allows certain projects to have different methods from the rest of the system. When you accept a method, the entire system feels the change, except projects that are "isolated". In an "isolated" project, changes are revoked when you leave the project. When you enter another project, that project's changes are installed. To make a project be isolated, choose "isolate changes of this project" from the "changes..." section of the screen menu. You can use an isolated project for making a dangerous change to a system, and you can get out if it crashes. An imported application can have the separate environment it wants. An isolated project shares methods with all subprojects inside it, unless they are isolated themselves. Each isolated project is the head of a tree of projects it shares all methods with. You can also 'assert' all changes ever made in the current project to take effect everywhere. You are first informed if there are any direct method conflicts with other projects. The conflicts are presented in a ChangeList Browser. [Later: A project may be 'frozen'. Asserts do not apply to it after that. (Great for demos.) You should be informed when an assert was blocked in a frozen project] Class definitions are global. If you add an instance variable, it happens in all projects. All versions of the methods are recompiled, in all projects. If you remove an inst var that is in use in another isolated project, it will become an Undeclared global. It is best not to remove an inst var when it is being used in another isolated project. Senders and Implementors do not see other versions of a method in other isolated projects. When you ask for versions of a method, you will not get the history in other isolated projects. Moving methods and classes between changeSets, and merging changeSets has no effect on which methods are in force. But, when you look at a changeSet from a different isolated project, the methods will contain the 'wrong' code. A changeSet is just a list of method names, and has no code of its own. Plus lots of other little things, many not listed... 1209MacFileDirectoryCase Refixes file name case match bug 1210connOpen-tkKI 1211FileListKeepOpen-ditk -- Dan Ingalls, Ted Kaehler -- 10 May 1999 Keeps sockets open across FTP transactions in the fileList. The socket is closed when you leave the window, and re-opened when you re-enter it. The net effect is to allow browsing remote files instantly, rather than waiting 10 seconds each time. Makes it much easier to browse goodies on servers. 1215ImageMorphWithSpotlight Cute visual effect 1217allCatFix-cncg -- Chris Norton and Carl Gundel -- 21 May 1999 1218allCatTweak-sw -- Scott Wallace -- 26 May 1999 Fixes some bugs that were introduced to the Browser when the '-- all --' category was introduced. 1223MovieSoundTrack-di -- Dan Ingalls -- 31 May 1999 Adds the ability for a moviePlayerMorph to add a sound track from a .wav or .aif file. Skip frames as appropriate when falling behind a sound track. 1224FreeUnusedPlayers-di Finally does an effective job of reclaiming unreferenced Players 1230ScreenMorphTweaks-di -- Dan Ingalls -- 3 June 1999 Improvements to ScreeningMorph -- another cute visual effect. 1232StrikeFontBuilder-di Assistance for building a StrikeFont from a bunch of forms 1256standardFile-acg Andrew Greenberg's nifty File chooser. 1257directFileEdit-sw -- Scott Wallace -- 9 June 1999 Exploiting the StandardFile capability kindly contributed by Andrew Greenberg, adds a direct way that a file can be open for editing from the screen menu." 1261alphaNewMorph-sw -- Scott Wallace -- 17 June 1999 Adds to the 'new morph' menu a new command allowing you to choose from an alphabetical list of morph types. The list is of course long, but at least this gives you a deterministic way to locate a morph without needing to know what category it is in." 1265betterAlphaNew-ar -- Andreas Raab -- 21 June 1999 Extends the alphabetical new morph menu to be dynamically split into 8 (roughly) equal groups." 1264WaveEditTweaks-di -- Dan Ingalls -- 21 June 1999 Adds a keyboard to the wave editor for trying out sounds at different pitches. Also fixes a couple of bugs (thanks to JM) relating to keyboard events and looped frequency. 1269TextOnCurveFix-di 1270EllipseDrawing-ar -- Andreas Raab -- 28 June 1999 Fixes ellipse drawing in the form canvas in several ways by using the Bresenham midpoint algorithms for ellipses; avoiding the extra pass for translucent ovals, drawing accurate wide borders and speeding up things a bit." 1274EllipseFix-ar -- Andreas Raab -- 28 June 1999 Fixes a problem introduced by resubmitting the CanvasPart2 change set." 1278menuFix-sw -- Scott Wallace -- 28 June 1999 Resolves a conflict in menus between updates 1259 and 1271" 1279versionsFix-sw -- Scott Wallace -- 28 June 1999 Fixes the bug manifested when you request versions for a method that has no logged source." 1283Shadows8bit -- Andreas Raab -- 29 June 1999 Fixes shadow drawing for an 8 bit deep Display." 1284flashSndLevel-jhm -- John Maloney -- 7 June 1999 Adds a global volume control for sounds played by Flash. The level is held in a class variable of FlashMorph. Does not apply to streamed sounds." 1285gcPolicy-jhm -- John Maloney -- 7 June 1999 Adds a mechanism for tweaking the default GC rate and tenuring threshold. This can be used to reduce tenuring in the (fairly rare) cases when the default VM tenuring threshold causes over-eager tenuring. This change set adds the mechanism, but does not actually change the defaults. To do so, you would edit SystemDictionary>setGCParameters (for example, 7000 allocations between GCs, 6000 survivor tenure threshold)." 1288bulletproofing-sw -- Scott Wallace -- 29 June 1999 Provides a mechanism for masking off all the programmers' facilities from a user who finds himself in morphic project, including: * halos * haloless morphic drag (cmd-drag, cmd-shift drag) * morph meta-menu (ctrl key) * world meta-menu (click on desktop) * cmd-dot * no-sources & no-changes warning * evaluation of expressions from keyboard * command characters in text Intended to provide a one-touch way that an end-user application (e.g. a web experience) can be configured to be bulletproofed against breaking and entering, and against unusual surprises such as the appearance of halos. For complete instructions, refer to the comment in the Preferences class method #disableProgrammerFacilities" 1289MenuColor-di -- Dan Ingalls -- 28 June 1999 Introduces a new preference, #menuColorFromWorld. When ennabled, this preference causes menus to appear raised, and with a color that is lighter or darker than the World color, depending on whether it is dark or light. 1290RoundedCorners-di -- Dan Ingalls -- 26 June 1999 A slightly dirty implementation of rounded window corners. See the comment in CornerRounder. Controlled by a new preference, #roundedWindowCorners. 1291roundedFlaps-sw -- Scott Wallace -- 1 July 1999 Makes the corners of textual flaps be rounded." 1293bmFillFix-ar -- Andreas Raab -- 2 July 1999 Fixes Morphs that have InfiniteForms as colors." 1294paintFixes-sw -- Scott Wallace -- 6 July 1999 * Paintbox position appropriate even when painting world in unlimitedPaintArea mode. * Only one painting experience allowed at a time. * If no paintbox is found when a painting gesture is received (because it got dismissed by halo, for example), one is hastily put up. * There is now support for keeping the paintbox in a flap, though the resulting effect was not very satisfactory and hence you need to perform a magical incantation to set things up for this to happen. 1300formTrimTweaks-jhm -- John Maloney -- 2 July 1999 Faster trimming of Forms. Also removes some unused and unneeded Form manipulation methods, adds a handy instance creation method for UpdatingStringMorph, and makes ADPCM compressAndDecompress: work for any of the supported bits-per-sample." 1303threeUnrelated-sw -- Scott Wallace -- 7 July 1999 ThumbnailMorph now correctly renders even when the object it represents is not in a world. This fixes a bug at least two years old. Locations of the debug & authoring menus in the menu flap are swapped, in order to accommodate the two new items Ted just added to the changes menu. When menus are stacked one upon the other, they are now centered within the stack. (Anyone object? I *think* this is nicer.) Uniclasses no longer show up in change sets (fixes bug introduced in update 1242convMeth. 1305haloFixes -- Doug Way -- 28 May 1999 Another fix to the Morphic Halo: If the halo reaches the bottom of the screen, the name of the morph will still be visible at the bottom. (original title: haloNameFix2) Also contains a fix to the placement of the debug halo handle by sw 7/7/99, merged in with Doug's fix for the name placement." 1310chgSorterAdditions-sw -- Scott Wallace -- 8 July 1999 Adds a new feature (accessible through the shifted change-set-list menu) which allows you to check for conflicts between the change-sets on the two sides of the sorter. (Formerly, you could only check for conflicts between one change set and *all other* change sets in the system; this new command lets you compare two change sets head to head. The other command is of course also still available.) In a dual change sorter, checks whether both sides of the sorter are pointing at the same change set before carrying out actions which, to be meaningful, require that the change sets on the two sides be different. While at it, reorders the shifted change set menu, and uses the more modern protocol to construct it, and also adds balloon help for all items in it." 1311optionalButtons-sw -- Scott Wallace -- 11 May 1999 Adds a few buttons to the morphic incarnations of changelist browser, debugger, and filelist. They only appear if you have the preference #optionalMorphicButtons set to true." 1313server-tkKS -- Ted Kaehler -- 9 July 1999 [ ] When you are putting out an update, and one of the servers is down, it gives you a simple message asking you to contact the administrator. [ ] When you get a secondary menu, like ""Open..."", and immediately drag it, it now stays up (if it can) rather than just going away. The old way was very frustrating. [ ] When you are prompted for a password for an FTP server (in the fileList), and its wrong, now you can enter another one. Or give up trying. This used to put you into an infinite loop of trying the bad password again." 1314menuII-tkKT 1315XguessDOLProxy -- John Maloney -- 10 July 1999 Code suppressed for external release." 1316reserveVMmem-jhm -- John Maloney and Andrew C. Greenberg -- 10 July 1999 Adds a VM parameter that allows you to specify an additional amount of memory to be reserved for use by the VM for things like plugins, file and socket buffers, etc. (This is especially useful on the Macintosh.) The memory request is recorded in the image header when the image is saved and is honored when the image is restarted. Many thanks to Andrew C. Greenberg for the original version of this facility." 1317sampledSndFix-jhm -- John Maloney -- 9 July 1999 Fixes a bug in SampledSound that caused a VM crash if the sound exceeded about 49 seconds. SampledSound now allows sounds up to 2^30 samples long. Add checks to prevent creating LoopedSampledSounds longer than the primitive supports. Typically, LoopedSampledSounds are used for sampled instruments, which are fairly short. For playing long sampled sounds (minutes or hours), use a SampledSound. Note: SampledSound's now play via a new primitive. The old primitive is still supported for backward compatability." 1318nextPrevFix-sw -- Scott Wallace -- 10 July 1999 Fixes the action of the 'smart' yellow next/prev buttons available in the supplies flap, etc; these had stopped working after the 'new world' transformation." 1319pastelColors-dwh -- Dwight Hughes -- 8 July 1999 Adds ten new pastel color constants, for use as background colors for the standard windows in a pastel scheme." 1320threeTiny-sw -- Scott Wallace -- 13 July 1999 (1) Adapted from a fix provided by Leandro Caniglia: Bulletproofs against a bug that could show up when a system window got dragged to the trashcan. (2) Puts life back into project-navigation buttons that became damaged when an inst variable was added to Project in a recent update, making the preexisting Project class object obsolete. (3) Bulletproofs Controller.viewHasCursor against the case that occasionally arises in which the view is nil." 1321windowColors-sw -- Scott Wallace -- 13 July 1999 Adds a little panel allowing user to choose from a set of window color schemes and to tune the color of any particular window type Places the menu item for opening such a panel, together with other appearance-related items, in a new 'appearance' branch of the screen menu." 1322menuTweaks-sw -- Scott Wallace -- 14 July 1999 (1) Restores visible lines to morphic menus for the case where menuColorFromWorld is false. (2) Keeps menus from failing when menuColorFromWorld is true and the world's color is an InfiniteForm." 1323wildDates-AL Alan Lovejoy's fixes to date arithmetic.

7 7

Re: dumping ALL the docs [newbie]
by Luciano Notarfrancesco 06 Aug '99

06 Aug '99

> er, ah, i hate to ask another newbie questions, but after i file in it, i > can't get it work. is there some initialization i need to do? what class of > object does #allCommentsOn look for? > > sorry, but i'mma learnin'. > jason Jason, the argument for #allCommentsOn: must be an HtmlFileStream. You can create one of those just sending a FileStream the message asHtml. For instace, try the folloing in a workspace: file _ (FileStream newFileNamed: 'comments.html') asHtml. Number allCommentsOn: file. file close This should write all the comments of the Number hierarchy on the file comments.html (in the Squeak working directory). Luciano.-

3 2

RE: [Interval Problem] 2 cents
by Raab, Andreas 02 Aug '99

02 Aug '99

And get from late binding (which is the entire point of Smalltalk) to early binding (which is the entire point of C) since you can't override any immediate inst var accesses. Argh! How I hate this... Sorry, couldn't resist. Andreas -- +===== Andreas Raab ========= (andreasr(a)wdi.disney.com) ==+ | Walt Disney Imagineering Phone: +1 818 544 5016 I I Glendale, CA Fax: +1 818 544 4544 I +======< http://isgwww.cs.uni-magdeburg.de/~raab >========+ > ---------- > From: Andres Valloud > Reply To: squeak(a)cs.uiuc.edu > Sent: Friday, July 30, 1999 2:47 PM > To: Squeak > Cc: recipient list not shown > Subject: [Interval Problem] 2 cents > > Hi. > > I think it would be a good idea to remove the self sends from any fix, > and replace > > self someInstanceVariablePlainAccessorMethodNamedTheSame > > with > > theInstanceVariableItself. > > Because then you start adding message sends and that is time expensive. > > Andres. > >

7 8

re: Please use accessors!
by Carl Gundel 01 Aug '99

01 Aug '99

>From: Alan Lovejoy <sourcery(a)pacbell.net> >Reply-To: squeak(a)cs.uiuc.edu <big snip> >8. Given the above, I would avoid being dogmatic on this >issue. I think the fact that so many good Smalltalk programmers >still access instance variables directly, and that code that commits >this "sin" has lasted unchanged for so long, should cause one to >at least question whether or not it's all that sinful. <snip> Thanks for the brain dump Alan! :-) I understand the pragmatics of this issue well, but I feel compelled to make a counterpoint about the above. Code that accesses ivars directly can be brittle. In particular, code which uses both direct access and accessor methods on the same ivars can behave in unpredictable ways. Sometimes such code survives for a very long time because it is brittle and hard to understand, and no one wants to touch it for fear of breaking it. I tend to defer writing code which accesses ivars directly until performance tuning time. I wish I never had to write such code because it hurt the maintainability and extensibility of my design, but I live in the real world (oh Bah!). Thanks again! -Carl _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com

4 3

re: Please use accessors!
by Alan Lovejoy 01 Aug '99

01 Aug '99

> ** Original Sender: Helge Horch <Helge.Horch(a)munich.netsurf.de> > > At 18:55 30.07.99 -0400, Chris Norton wrote: > >I will admit to having used i-vars directly in the past. At the time, it > >seemed like a good way to ensure privacy, but upon reflection I decided that > >this was silly. Any developer can just add his/her own accessor. So now my > >practice is to create accessors, but label them as "private" and put them > >into "private" method categories. Since Smalltalk does not enforce privacy, > >we have to assume that our fellows will adhere to our "code of conduct". > ></Soapbox> > > <DÈjý vu> I like the way Kent Beck reasons about it. In [SBPP] he lists > *both* "Direct Variable Access" (p.89) and "Indirect Variable Access" > (p.91) as valid coding patterns, alluding to the obvious schizophrenia, and > mentioning encapsulation and dogmatism. ([SWS] is leaning towards > indirect-only, IIRC.) In his recent [GTBS], featuring a reprint of his 1993 > SmalltalkReport column "To Accessor or Not to Accessor", I found his > leading remarks from today's view most interesting: "[...] It wasn't until > I rewrote the while thing as patterns for the book [SBPP] that I realized > the key issue here is communication." (The column itself stresses the > importance of consistency in one's ways.) > His conclusive remark: "Anyway, if this one bugs you, ignore it, all except > the part about making accessors private by default." Helge: I am very glad you posted the Kent Beck quotes. I was fully intending to do the same, but for once I remembered to read to the end of the message list before prematurely responding. All: I fully agree with KB's position (squarely on the fence, judging each case on its merits). But I would like to add the following observations: 1. Finding all references to an instance variable in a class hierarchy is even easier than finding all senders of some message, because there is no ambiguity with respect to which class implements the name (when renaming methods, care must be taken to only rename those message sends where the receiver will be an instance of a class where the method was renamed). Since this is so, changing the name or structure of the slots of an object is easier than changing its interface. A design change that would require renaming or removing an instance variable would very likely also require renaming or removing the associated accessor and mutator methods. So the debate centers on those few cases where the accessors/mutators would remain, but the instance variable(s) would not (e.g., the Point example already mentioned). 2. All classes in Smalltalk can be changed by any programmer. If an instance variable offends thee, thou mayest rename or remove it. Same goes for methods. Similarly, any programmer can add methods to a class to access otherwise encapsulated instance varibles--and can also use #instVarAt: and #instVarAt:put: to defeat any message-based encapsulation of an instance variable. However, this does not mean that one should give up on the attempt to use method-mediated encapsulation of state in order to enforce invariants and/or constraints. If object encapsulation had no value, then OOP would be pointless. 3. Barbara Liskov, in her speech at OOPSLA '87 in Orlando, noted that Smalltalk-style class inheritance (where any subclass has full access to the internals of its superclasses) breaks encapsulation. The issue here is that one source may provide a framework class meant to be subclassed, another programmer may create a subclass, which then breaks when the code is ported to a new version of the framework where one or more instance variables (for example) have been renamed or removed (perhaps due to a design change, such as converting Point from cartesian to polar). This is where the issue of direct access to instance variables may bite the hardest. On the other hand, the same issue is present with respect to methods, whether public or private. 4. The Point example is actually bogus. The right approach is to have an abstract superclass with CartesianPoint and PolarPoint subclasses. There is no valid argument for defending against some future wholesale replacement of the x and y instance variables of the CartesianPoint class. Those instance variables would inherently have to be there. One might want to rename them, but the same issue would exist with respect to accessor/mutator methods (only more strongly, given point #1 above). The only problem (unfortunately) is that a solution analogous to the one for Point/CartesianPoint/PolarPoint may not be applicable in all cases. 5. Beware lazy initialization. It has valid uses, but there are also invalid ones, and traps for the unwary. The best use of lazy initialization is for "caching" variables. A caching variable holds a value that can be recomputed from other data at any time. If lazy initialization is used to compute then cache the value of a variable, then setting the variable to nil at some random moment should not change the behavior of the program (other than time to execute). If setting the variable to nil at any random moment would be incorrect, then the variable is NOT a caching variable. Another case where lazy initialization is a good thing is class variables, but only because of the likelyhood that a class will be filed in without the #initialize message being sent to it (it's amazing how often this seems to happen). Finally, lazy initialization is a necessary technique for solving certain transitive closure and resource usage problems (where fully initializing everything either never ends, or does way more work and/or resource allocation than is actually necessary). One case where one would not use lazy initialization is for setting the value of "identity variables," which serve to specify the identity of a domain object in its domain. "Identity" variables are usually set once (usually when the object is first instantiated), and then never changed. An identity variable must be explicitly set, usually to a value specified by some source external to the object (e.g, the primary key of a domain object). By their very nature, they should not be lazily initialized. Using lazy initialization to set the social security number of aPerson just makes no sense, so this mistake is not common. In fact, one can use the fact that there is no good default value for a variable to spot an identity variable. State variables present a more difficult case. A "state" variable is one that holds some changeable state of an object, such as the mailing address of a Person. Lazy initialization of "state" variables seems to work fine, until you need to return an object to its initial and/or default state. One would like to do this by sending the object the message #initialize, but it often turns out that a) there is no such message, because lazy initialization was used exclusively, or b) there is such a message, but for a variety of reasons it does not put the object into the desired state (either because it was never fully implemented, or because it was not kept in sync with the lazy initialization system). Another problem is debugging. When state variables are lazily initialized, then one can easily come to false conclusions about object state during a debugging session, when "nil" doesn't really mean "nil". But the worst problem arises when lazy initialization causes a transitive closure and/or resource usage problem, instead of helping to solve one. This is classic: You religiously send accessor messages to fetch state. The accessors use lazy initialization, and gleefully create unneeded objects. You asked for the object, there wasn't one there, so it got created and retured to you by the oh-so- helpful accessor (not!). My favorite is #release code that reinitializes an instance variable just so it can send #release to its value (e.g, "self controller release"). Don't go there. (And this is one case where it is probably better to access the instance variable directly). For these reasons, it is better to have an #initialize method that sets all state variables to their default values, sets all caching variables to nil, and leaves all identity variables unchanged. The #new method of the root class in the hierarchy should then answer "self basicNew initialize" (#basicNew instead of "super new," because of the posibility that the superclass may someday be doing the same thing!). 6. I like the way that Self deals with this issue. Very elegant. Kudos to David Ungar, et al. But I must caution that Smalltalk is not Self, and that always using accessors and mutators to access state does not change Smalltalk into Self, and does not provide the same benefits Until we change the language, we have to deal with what we have, not with what we wish we had. 7. Whether Andres was wrong or right about direct instance variable access, it was not cool to come down on him like a ton of bricks. Andres, on the other hand, should have simply questioned why the instance variables were not being accessed directly, instead of boldly asserting they should be. We need to treat each other with respect and diplomacy. We are ambassadors for Smalltalk, and should act accordingly when communicating in an open forum, one of whose purposes is spreading the Smalltalk gospel. Andres: you stepped on a hornets nest with this issue. Don't let it bother you. Score it as a learning experience, and be assured it's not the only subject that may cause a religious war to erupt among Smalltalkers. 8. Given the above, I would avoid being dogmatic on this issue. I think the fact that so many good Smalltalk programmers still access instance variables directly, and that code that commits this "sin" has lasted unchanged for so long, should cause one to at least question whether or not it's all that sinful. I think this is a good issue for the language designers to deal with. Those just trying to code in the Smalltalk of today should consider the pros and cons, formulate a consistent strategy, and then stick with it. 9. I really hadn't intended to write such a long sermon, but the issue is complex and non-trivial. Have a good weekend! --Alan

4 3

Jump to page: