This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Odd little Bf bug
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
I've had a few reports over the last month or two of BottomFeeder's update loop inexplicable stopping, requiring the user to toggle the application through online/offline to restart it. I was baffled for awhile, but got some help this morning from one of our engineers who runs the application in his VW development environment (as opposed to the packaged application). It turns out there there were some poor assumptions in the code that checked for "too many" timeouts during the update loop.
There's a setting that allows you to ignore timeouts during the update loop. I always have that set, so I wasn't even seeing the problem. Now, say you have that unset (the default). The update loop keeps track of how many timeouts have occured during the current cycle, and takes notice when "too many" have occurred. How many is "too many"? Well, the code was set for 10%. This works fine for me and my 244 subscribed feeds. It works less well for someone subscribed to, say, 20-30 feeds - 2 or 3 timeouts can trigger the event. Now, the trigger was supposed to launch a dialog notifying you of the problem. This is where the second part of my error came into play
The action on too many timeouts is to suspend the update loop and then pop a dialog. The problem was, the dialog firing code was after the code that terminated the loop - and thus, never ran. Dohh! That's now addressed, and I've also put a lower bound on "too many" timeouts - it's now 10% of total or 10, whichever is larger. That should fix that problem. Now I'm off to create a new potential 3.4 build...
Previous Topic
