Squeak-dev March 2000

squeak-dev@lists.squeakfoundation.org

131 participants
580 discussions

RE: [UPDATES] 50 more for 2.8alpha
by Raab, Andreas 27 Mar '00

27 Mar '00

Andrew, > With all due respect, the original "fix" resulted in a bug report, > and the fix to the fix resulted in a bug report, all posted to this > listServ. Although I asked several times, I'm not really sure what > the first changeset was trying to fix. Why not simply revert back to > the original code prior to all of these fixes before adding buggy > fixes to buggy fixes to the core image? Well I guess we could have done this but as it is update 1954 did a good deal of useful refactoring (about 30 messages removed or so). That's pretty good and the only thing that was actually broken was a minor oversight (though a little hard to find). I personally don't mind sending out these change sets (since this is all in the 2.8 alpha update stream we've got plenty of time to fix the remaining problems) and it's just sometimes the case that you can't find the damn bug. And then, somebody else just looks at it and says "Hey - that's obvious!" and just fixes it. It's one of the major advantages of Open Source projects that you actually can have a lot of people looking at this stuff. But, as everybody else, even the smartest people make mistakes and that's where all of us must be kicking in. Just look at the last set of updates to see how this works - Stefan worked out the refactoring of the MouseMenuController, I fixed the one remaining problem. In turn, Dan fixed one problem originating from a change set of mine (and zillions of other things as usual ;-) Lex fixed a couple of general problems, Bert fixed a couple of things, so did Duane, John, Stephen, Stefan, Torge, Henrik, Hans-Martin and so on (and last but not least - you yourself have done quite a bit over time ;-) All in all I'm tremendously happy how well this stuff works out and how much support we get from all the people on the list. You guys are just the best! - Andreas

1 0

[BUG] [FIX] theSelectorDisplatMorph is nil
by Bob Arning 26 Mar '00

26 Mar '00

On Sun, 26 Mar 2000 13:05:19 -0800 (GMT) Tim Rowledge <tim(a)sumeru.stanford.edu> wrote: >It appears theSelectorDisplatMorph is nil for some reason! There is a ColorPickerMorph in the image that was created before that variable was added. Fix below. Cheers, Bob ============ 'From Squeak2.8alpha of 13 January 2000 [latest update: #1974] on 26 March 2000 at 4:28:31 pm'! "Change Set: colorPickerFix Date: 26 March 2000 Author: Bob Arning - handle ColorPickerMorph instances which existed prior to addition of <theSelectorDisplayMorph>"! !ColorPickerMorph methodsFor: 'initialization' stamp: 'RAA 3/26/2000 16:27'! updateSelectorDisplay theSelectorDisplayMorph ifNil: [^self]. theSelectorDisplayMorph position: self bottomLeft. theSelectorDisplayMorph firstSubmorph contents: selector asString , ' ' , selectedColor printString! !

1 0

[Morphic][BUG?][Drag&Drop] mouseLeaveDragging events occure too many and these at wrong times
by Stephan Rudlof 26 Mar '00

26 Mar '00

Dear Squeakers, I have problems with mouseLeaveDragging events. They occure one time to often and then much to late. To explain the problem I have attached a small changeset. Please - open a Transcript, - file the changeset in and - 'do' DAndDAlignmentMorph2 new openInWorld . What you'll see is a DAndDAlignmentMorph2 containing two column of squares. Each of these columns is a DAndDAlignmentMorph. Nothing complicated here. After that - click on one of the squares, - move the mouse just a little bit, - release the button, - move the hand to any other window, - and click. You'll see in the Transcript a reported DAndDAlignmentMorph>>mouseLeaveDraggingEvent:morph: related to one of the DAndDAlignmentMorphs which we have left long time ago! This seems to be a bug for me. What goes wrong here? Any help is welcome, Regards, Stephan

1 0

[VM] 1929FastPrimFailures: SystemDictionary>>setNewPluginSessionID
by Stephan Rudlof 26 Mar '00

26 Mar '00

Interpreter>>setNewPluginSessionID "Set a new plugin session ID forcing all external prims to be reloaded." "Note: That's not sufficient to reload already loaded external modules, because they are cached!" "Method cache has to be flushed, since there is some 'cheating' in Interpreter..." pluginSessionID _ pluginSessionID + 1. self flushMethodCache SystemDictionary>>setNewPluginSessionID "Primitive. Install a new session ID for any external plugins. Must be done by a primitive to avoid interruption by a process at higher priority. If the primitive is successful all external primitives will be reloaded upon next invokation." <primitive: 570> "Do nothing if the primitive fails for compatibility with older VMs" I think a warning similar to the note in Interpreter>>setNewPluginSessionID should also be in SystemDictionary>>setNewPluginSessionID ! Another point: I think it is better to replace "Do nothing if the primitive fails for compatibility with older VMs" by an error popup showing something like 'Not supported by this VM!' or just by ^self primitiveFailed . This would be more bullet proof. Stephan

1 0

Re: [UPDATES] [BUG] [FIX] 2.8a -- Hand Drag in 8 bit depth
by Bruce O'Neel 26 Mar '00

26 Mar '00

HI, This plus the previous 53 are all in <ftp://st.cs.uiuc.edu//Smalltalk/Squeak/2.7/files/Squeak2.8a-beo.zip> cheers bruce Dan Ingalls <Dan.Ingalls(a)disney.com> wrote: > Folks - > > Another quick fix. Update again to get it. > > Fixed problems due to balancedPatternForDepth not working for transparent color. Also several improvements to handling of rounded corners. Screen repainting should be faster, and dragging should look nicer. > > Enjoy > - Dan > ------------------------- > 1974RoundingTweaks-di -- Dan Ingalls -- 25 March 2000 > Makes SystemWindows with rounded corners properly compute areasRemainingToFill:. > Also improves the result reported from this message, as it now only reports two strips with the four corners, rather than the entire window. > Most importantly, it fixes the general problem of canvas holes being filled with gray stipple when dragging with the Hand in 8-bit depth.

1 0

[ANN][Goodies] Dandelion 0.4 sneak preview
by Masashi Umezawa 26 Mar '00

26 Mar '00

Hi Squeakers! Dandelion, the code analysis / document generation tool, will soon be updated to 0.4. I will publish a sneak preview release. Please check it out. http://www.mars.dti.ne.jp/~umejava/smalltalk/stClasses/dendelion/ The new version supports ChangeSet analysis. You can export your project's ChangeSets to the Web. Samples are: http://www.geocities.co.jp/SiliconValley-PaloAlto/8501/ *Note* -If you encounter some bugs, please inform me. -Class comments are not completely updated yet. (though Dandelion is a documentation tool...) -The formal Dandelion 0.4 will support SMIX output(SIF in XML). Enjoy! --- [:masashi | ^umezawa]

1 0

RE: [ENH] Bob's World Gradient (was: Re: Code Challenge !!!)
by Raab, Andreas 26 Mar '00

26 Mar '00

Doug - Just to make my point, enclosed is a change set that does what you want (it'll be in the next bunch of updates). File it in, go to 8bpp display depth and execute: 0 to: 255 do:[:i| (FormCanvas on: Display) fillRectangle: (0@0 extent: 400@400) color:(Color gray: i / 255.0). i printString displayAt: 0@0. (Delay forMilliseconds: 100) wait]. [Note - for comparison you may want to try this without the update] Have fun, Andreas > -----Original Message----- > From: Raab, Andreas [mailto:Andreas.Raab@disney.com] > Sent: Friday, March 24, 2000 5:53 PM > To: squeak(a)cs.uiuc.edu > Cc: recipient list not shown > Subject: RE: [ENH] Bob's World Gradient (was: Re: Code Challenge !!!) > > > > Maybe I'll try to work on this at some point. Hmm, now where in the > > FillStyle hierarchy would HalftoneFillStyle be most appropriate... > > From my point of view - nowhere. You were talking about a > *very* specific > representation of Colors for a pixel based output device and > there is no > point in specifying a pixel pattern if you really mean a > color (that's what > you mean, isn't it?!) If you want to do halftoning on the fly > the right > place to do this is in class FormCanvas and nowhere else. So that, for > instance, a PostScriptCanvas gets what is intended - the > color - rather than > some yet-to-be-guessed-at pixel pattern. In fact, I have > already submitted a > change set that tries to get rid of such a usage (for colors > as well as > combination rules) because it is absolutely necessary to > state what you > -mean- rather than handing in some obscure bits. If you mean > a color, then > pass a color. The canvas is the thing you want to make smart enough to > realize that on an 8bit form it might be a good idea to use a > dither pattern > rather than the nearest color. > > - Andreas >

4 3

RE: [BUG][VM] 1929FastPrimFailures.cs
by Raab, Andreas 26 Mar '00

26 Mar '00

Stephan, > I'm very concerned (think it's a bug) about one aspect of the > implementation, it is the initialization of pluginSessionID in > Interpreter>>initializeInterpreter: : > > It will be initialized by > pluginSessionID _ self ioMicroMSecs. > ; where > - ioMicroMSecs returns a milliseconds value in spite of its name, > - starting by zero at startup. The latter is not true - at least not for any implementation I'm aware of. ioMicroMSecs() is usually implemented by a call to the underlying OS timer functions and should be an equivalent for the time since system (read OS) startup and not Squeak startup. It should therefore be very hard to start Squeak even remotely close for this to be a problem. > P.S.: Last but not least, my surname is 'Rudlof'; in preamble it is: > Author: Stephan Rudloff & Andreas Raab Sorry - that was a typo. - Andreas

2 1

[FIX] SystemWindow>>extent:
by Stephan Rudlof 26 Mar '00

26 Mar '00

Squeakers, this changeset is the same as BugFixSystemWindow>>extent: posted earlier (14.1.). But because it has been ignored so far and I've met this point again while improving BetterPlacementOfCollapsingWinBars, I repost it. Don't know if this problem is a signal for refactoring: I've just made it working... "Change Set: FIX_SystemWindow Date: 26 March 2000 Author: Stephan Rudlof This changeset fixes SystemWindow>>extent: : It updates inst vars 'fullFrame' and 'collapsedFrame' now (similar to SystemWindow>>position:). " BTW: Would there arise a problem on some platforms if I'd have named this changeset as 'FIX_SystemWindow>>extent:'? Greetings, Stephan -- Stephan Rudlof (sr(a)evolgo.de) "Genius doesn't work on an assembly line basis. You can't simply say, 'Today I will be brilliant.'" -- Kirk, "The Ultimate Computer", stardate 4731.3

1 0

RE: {UPDATES] Re: [BUG] 2.8a -- Hand Morph problem?
by Raab, Andreas 26 Mar '00

26 Mar '00

Gee, what a mess - Thanks Dan! I've totally overlooked this. - A. > -----Original Message----- > From: Dan Ingalls [mailto:Dan.Ingalls@disney.com] > Sent: Saturday, March 25, 2000 10:28 AM > To: squeak(a)cs.uiuc.edu > Cc: recipient list not shown > Subject: {UPDATES] Re: [BUG] 2.8a -- Hand Morph problem? > > > >Squeak 2.8a, updated to 1972, on Win NT 4.0, service pack 5 > >Squeak 2.7 VM (release build 8) from Jan 15, 2000 > > > >1. In a new morphic project, bring up the World menu and > choose "keep this > >menu up". > >2. click on the label area of the menu (the blue part at > the top) and drag > >it around your project (I just sort of swirled it around, like I was > >stirring my coffee) > >3. I got a walkback UndefinedObject: Error: > UndefinedObjects are not > >indexable > > Thanks for the alert. > > Yes this was a problem, and I have just added another update > -- my chance to pay Andreas back for his help last night. > > There's the scoop: > > 1973ColorCacheFix -- Dan Ingalls -- 25 March 2000 > The method balancedPatternForDepth: was leaving colors with > cachedDepth defined but cachedBitPattern == nil, a violation > of the cache conditions. > > Update again if you updated before this came out. > > - Dan > >

2 1

← Newer
1
...
6
7
8
9
10
11
12
...
58
Older →

Jump to page: