Hi all,
Good bug find Rodney.
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@280 corner: 425@320) insetBy: (3/4)).
The alternate form: box bounds: ((375@280 corner: 425@320) insetBy: (0.75))
will work without error.
Yours in curiosity and service, --Jerome Peace
On Fri, May 20, 2011 at 10:17:29PM -0700, Jerome Peace wrote:
Hi all,
Good bug find Rodney.
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@280 corner: 425@320) insetBy: (3/4)).
The alternate form: box bounds: ((375@280 corner: 425@320) insetBy: (0.75))
will work without error.
Thanks, this is fixed in trunk now.
Dave
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@280 corner: 425@320) insetBy: (3/4)).
The alternate form: box bounds: ((375@280 corner: 425@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
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@280 corner: 425@320) insetBy: (3/4)).
The alternate form: box bounds: ((375@280 corner: 425@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.
- Bert -
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@280 corner: 425@320) insetBy: (3/4)).
The alternate form: box bounds: ((375@280 corner: 425@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
squeak-dev@lists.squeakfoundation.org