=== Top of the Swiki === Attachments ===
Simple Bug Tracking
How do Smalltalk folk keep track of their bug ToDo lists?
From SqueakList: 4 Aug 1998
Bug Tracking
A long time ago, Scott Wallace came up with a simple, yet effective way to mark methods for further attention, using the leverage of Squeak's existing search mechanisms.
If a method has a bug, add the line
self flag: #knownBug. "Brief comment about the problem"
Then, at any time you can (type if necessary and) select the text 'knownBug', and hit cmd-n. This fools the find-all-senders code into showing all methods that refer to this literal, and -- poof -- you have a browsable list of all methods flagged as having known bugs.
This same mechanism can be used to tie a number of methods together. For instance, in the current Squeak, there is a hack that allows instances to have up to 254 named variables, by merging the old 6-bit field with an extra 2-bit extension. Several different methods will have to be changed when this is cleaned up. To aid in making this future change, these methods are each flagged with
self flag: #instSizeChange. "Browse references from related methods"
[I just checked and this wasn't done quite so cleanly, but it should be]
Finally, within our group, depending on how closely-coupled we are working, we have used this mechanism to impute a request for attention, by patterns such as
self flag: #noteToJohn. "Will this work OK with flexed coordinates?"
In this way whenever we are looking for more problems to think about (;-), we browse the image for such references to our names. This can be very effective in a small workgroup.
This mechanism has the nice property that you can put as many such flags on a given method as you wish, with the only cost being a very small run-time overhead. Also, being part of the code itself, these flags can be updated appropriately by all the existing fileOut/fileIn/update mechanisms.
It all works in Squeak right now, and it has served us well for years.
-- Dan Ingalls
From SqueakList: 4 Aug 1998
Use of flag:
Using "flag:" is just a stylistic choice, which arguably has the following two benefits over just mentioning a naked symbol on a line:
(1) When you get in the habit of using this kind mechanism seriously (such as to mark methods that you absolutely *must* return to before shipping some code. or to mark methods that you want to be certain are brought to the attention of a colleague, as in "self flag: #noteToFred"), you can end up with quite a few different kinds of flags, and can easily lose track of your own conventions as time goes on. By looking at all senders of #flag: you can survey all methods flagged in any way.
Also, since there is no spell-check done on the declaration of a symbol constant, if you happen to type the naked line
#knownBu
when in fact you meant #knownBug but you misspelled it, you might never find this again except by serendipity. If you occasionally survey senders of #flag:, you'll at least have a deterministic path to relocating such strays.
(2) From the point of view of documentation, it may be more self-explanatory and less off-putting to a user coming upon some such code, if he sees that the mention of the symbol is for the purpose of "flagging". The novice user who wonders what this is all about might then browse implementors of #flag:, where he would find a direct explanation of the convention.
-- Scott Wallace