Squeak-dev October 2003

squeak-dev@lists.squeakfoundation.org

178 participants
791 discussions

[FIX] Re: [BUG][et] Notifier window fadeout ( [closed] )
by marcus＠ira.uka.de 02 Oct '03

02 Oct '03

[closed] empty message (and allready included, I think). < I'm a bug-fixing machine! > This post brought to you by the BugFixArchiveViewer, a handy tool that makes it easy to comment on proposed fixes and enhancements for Squeak. For more information, check out the Web page for the BugFixArchiveViewer project: http://minnow.cc.gatech.edu/squeak/3214 < I'm a bug-fixing machine! >

1 0

[FIX] IfUnhandledError-nk
by ned＠bike-nomad.com 02 Oct '03

02 Oct '03

A changeset that is sure to be somewhat controversial. from preamble: "Change Set: IfUnhandledError-nk Date: 27 June 2003 Author: Ned Konz This changeset: - edits all callers of BlockContext>>ifError: to use something else, usually #ifUnhandledError: - adds BlockContext>>ifUnhandledError: (see below) - marks BlockContext>>ifError: as deprecated - edits all callers of Semaphore>>critical:ifError: to use something else. - marks Semaphore>>critical:ifError: as deprecated - edits most callers of on: Error do: [ ... ] to use something else, mostly #ifUnhandledError: - restores the behavior of removing step messages from the WorldState step list when the step messages have an error (the 'start stepping again' debug menu choice will restart them) I wrote #ifUnhandledError:, which allows enclosing scopes to handle exceptions. This behaves exactly the same as #ifError:, except that: - if there is an outer exception handler, that handler gets to handle the exception instead, and - there is now a one-argument form as well as the 0 and 2 argument forms that gets passed the exception itself. "!

2 2

[ENH] Speech Removal
by Brent Vukmer 02 Oct '03

02 Oct '03

Registered on SqueakMap by Luciano Notarfresco. The changeset is currently a one-liner!

2 1

Re: Idea: "Timeout" submissions?
by Richard A. O'Keefe 02 Oct '03

02 Oct '03

Marcus Denker <marcus(a)ira.uka.de> proposes automatically deleting bug fixes that have not been harvested. 1) remove clutter from the Archive 2) We have a third way to decide about changes: "yes" "no" and "nobody cares, thus: no". 3) The image is a moving target. Especially refactorings tend to change lots of methods, and old fixes rot. This way we make sure that we only have to harvest changes that are reasonably old. 4) Maybe this will help to bring some urgency into harvesting "I need to get this in or it will be lost". Any negative effects? Yes. It amounts to taking items that should have high priority (because they have been waiting for a long time) and saying "nyaa nyaa, WON'T!" This will only remove clutter from the Archive if old fixes are clutter. I see no reason to believe that, considering how long some bugs have been in the system. There is the completely false assumption that "nobody responds to the deletion" means the same as "nobody cares". I for one am completely snowed under with e-mail; I routinely delete BugFix messages after only the most cursory skimming. For the next couple of weeks I expect to be extremely busy indeed, and I shall have to skim my mail at the highest speed I can manage. That doesn't mean I won't _care_ if any fixes I've submitted are spat into the wastebin, it means that I won't _know_. The fact that old fixes "rot" is precisely why they should be given the highest priority and cleaned up before new fixes are put in. The absence of a fix can occasionally give a false impression about what can be done to the rest of the system. Just because a fix hasn't been *harvested* doesn't mean it isn't being *used*. I don't see this change bringing any urgency into harvesting. A rather more typical human response will be "if I don't bother with this it will go away".

1 0

[FIX][DOC] Fix comment buglet in Dictionary>>valuesDo:
by David T. Lewis 02 Oct '03

02 Oct '03

This fixes the method comment for Dictionary>>valuesDo: which appears to have been incorrectly cut-n-pasted. Comment was: Evaluate aBlock for each of the receiver's keys. Changed to: Evaluate aBlock for each of the receiver's values. Dave

3 2

[FIX] SqueakMap ( [closed] )
by marcus＠ira.uka.de 02 Oct '03

02 Oct '03

[closed] old stuff... < I'm a bug-fixing machine! > This post brought to you by the BugFixArchiveViewer, a handy tool that makes it easy to comment on proposed fixes and enhancements for Squeak. For more information, check out the Web page for the BugFixArchiveViewer project: http://minnow.cc.gatech.edu/squeak/3214 < I'm a bug-fixing machine! >

1 0

[FIX][KCP] KCP-0096-SwapByte
by ducasse＠iam.unibe.ch 02 Oct '03

02 Oct '03

from preamble: "Change Set: KCP-0096-SwapByte Date: 28 June 2003 Author: stephane ducasse Deprecate swapByte as suggested by andreas and move it into Bitmap"!

4 3

[FIX] [KCP]KCP-0097-NewPointOrNil
by bergel＠iam.unibe.ch 02 Oct '03

02 Oct '03

from preamble: "Change Set: KCP-0097-PointOrNil Date: 2 October 2003 Author: Stephane Ducasse and Alexandre Bergel VERSION 2 Move obtainArrowheadFor:defaultValue: from Utilities to Morph as it was the only sender with morph. Update morph accordingly. Note that now obtainArrowheadFor:defaultValue: only accept point and not coma separated number as it was the only way it was used. Refactor a bit the magic number that represent the default arrow head size and introduce a method for it."!

1 0

[MC] Monticello update
by Avi Bryant 02 Oct '03

02 Oct '03

I've just updated the Monticello package on SqueakMap. The major change is the introduction of a new RepositoryInspector, contributed by Lukas Renggli. It now comes up instead of a menu when you press Open in the Monticello Browser. Among other things, this makes it much easier to keep many different packages in the same directory. I'll probably be reorganizing the http://beta4/mc repositories to take advantage of this soon. Avi

1 0

Not received list
by Karl Ramberg 02 Oct '03

02 Oct '03

Since early yesterday no messages received from the list. Karl

1 0

Jump to page: