[squeak-dev] [BUG][M7635] Fraction class co-ordinates

David T. Lewis lewis at mail.msen.com
Mon May 23 10:44:14 UTC 2011


On Mon, May 23, 2011 at 12:19:38PM +0200, Bert Freudenberg wrote:
> 
> On 23.05.2011, at 05:04, David T. Lewis wrote:
> 
> > On Sun, May 22, 2011 at 04:37:24PM -0400, David T. Lewis wrote:
> >> On Fri, May 20, 2011 at 10:17:29PM -0700, Jerome Peace wrote:
> >>> 
> >>> http://bugs.squeak.org/view.php?id=7635
> >>> Summary 	0007635: Graphics primitives will raise errors when rectangles have widths in fractions.
> >>> Description 	For this one in a work space evaluate
> >>> 
> >>> box :=
> >>> RectangleMorph new openCenteredInWorld .
> >>> 
> >>> box bounds: ((375 at 280 corner: 425 at 320) insetBy: (3/4)).
> >>> 
> >>> The alternate form:
> >>> box bounds: ((375 at 280 corner: 425 at 320) insetBy: (0.75))
> >>> 
> >>> will work without error.
> >> 
> >> Thanks, this is fixed in trunk now.
> >> 
> > 
> > In Mantis 7635 (Graphics primitives will raise errors when rectangles have
> > widths in fractions), Jerome points out quite rightly that the "self error:"
> > in BitBlt>>copyBits is a bad thing (indeed it crashes the image when updating
> > a morph with bounds containing a fraction), and suggests that the problem be
> > fixed in #copyBits. Removing the error notification in #copyBits resolves
> > the problem, because this is fallback code for the failed primitive which
> > does the right thing by fixing the parameters and calling the primitive a
> > second time. However, removing the error notifier also masks a real problem
> > that would otherwise have gone undetected (which I presume is the reason
> > the notifier was put there in the first place).
> > 
> > Summary: The potential for crashing the image in this case is a long-standing
> > problem. We could make it go away to removing the problematic error notifier
> > (which crashes the image when invoked from the morphic update loop). However,
> > this fix would allow problems such as that reported in Mantis 7635 to go
> > undetected.
> > 
> > Opinions?
> > 
> > Background at <http://bugs.squeak.org/view.php?id=7635>
> > 
> > I am somewhat inclined to think that it is better to leave the error
> > notifier in place, even though it can and will crash the image in
> > some circumstances. But better yet would be if someone can think
> > of a way of detecting the problem in some way that does not involve
> > potentially crashing the image.
> > 
> > Dave
> 
> This should have worked fine. Errors during the Morphic draw loop normally are caught. I'd not take out the error notification, but rather bullet-proof drawErrorOn:. 
> 
> In fact, I just committed Morphic-bf.543 to do that. For testing you can revert Morph>>extent: and try the fraction example again. You now simply get a debugger rather than a fatal error, just like the Morphic Gods intended ;)
> 
> There is a problem that some classes overriding fullDrawOn: do not check for the errorOnDraw property. E.g. I just had to add the check to HandMorph's override, otherwise I'd get the same fatal error when picking up the broken morph. I did not fix the other implementors.
> 

Thanks Bert,

This works perfectly. I opened a RectangleMorph and, from an inspector,
changed the bounds origin to a point containing a fraction. Previously
this crashed the image, now it brings up the debugger as intended.
Proceeding from the debugger without fixing the bounds results in
a red-X display in the morph, exactly as it should do.

Dave




More information about the Squeak-dev mailing list