SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

Mantis - Squeak
Viewing Issue Advanced Details
6486 Morphic major sometimes 05-14-07 03:06 04-18-10 21:51
closed 3.10  
none trunk  
0006486: In 7097 Resizing the objects flaptab can result in a infinite loop (i.e. squeak freezes)
This one only happens under certain circumstanses which don't always occur.

For this one
In a fresh 3.10 7097
put halos around the objects flap tab.

Use the resize handle . try to expand the flap tab.
Often nothing happens. the flap tab stays the same size.

However, sometimes squeak does not respond at all.

Typing Cmd-. user interupt stops the infinite loop.

The problem, rather the difference, is that the extent for the textmorph

is sometimes not quite integral. (the width is off by 0.53-14)

The stop test for the layout recursion fails and the recursion continues.

The problem is not always apparent and it is probable that it arises more frequently when you are fooling with tabs on the left or top. The other sides discourage the movement of a bottom right resize handle. :-)

So my curiosity wonders how old this bug might be?

And what would be a good fix.

extent: aPoint

    bounds extent = aPoint ifTrue: [^ self]. "***this test can come out false***"
    self changed.
    bounds _ (bounds topLeft extent: aPoint) rounded.
    self layoutChanged.
    self changed.

duplicate of 0007213closed laza [big bug] morph>>extent: now does rounding and that can lead to infinite loops. 
related to 0007635closed andreas Graphics primitives will raise errors when rectangles have widths in fractions. 
child of 0006511new  Mother of all Morphic Graphical off-by-one/fencepost -error reports. 
child of 0007212new  Mother for flaptab issues 
 FlaptapEdgeFix-wiz.2.cs [^] (2,791 bytes) 06-11-07 04:19 [^] (1,727 bytes) 06-11-07 23:20

06-11-07 01:31   
Some analysis,

Ho this is a fun one.

First historical research shows there was an attempt to fix this in the past


"Change Set: RoundedMorphBounds
Date: 25 March 2004

Prevents an infinite loop in some cases when FlapTab Morphs have floats in their boundry"
extent: aPoint

    bounds extent = aPoint ifTrue: [^ self].
    self changed.
    bounds _ (bounds topLeft extent: aPoint) rounded.
    self layoutChanged.
    self changed.

The fix was adding "rounded".

Since this did not actually fix the problem I want to recommend the change to morph be reverted. See the parent report on off by one errs for my reasons. This is an early rounding bug. Bad medicine. Also rounding is not the right remedy.

Some flap tab extent tests are going to be needed.

And flaptab may want to define its own version of extent.
06-11-07 01:33   
Reminder sent to: laza

Hi laza,

this seems to have been your fix.
Folklore and guidance of flaptabs would be of help.


Yours in curiosity and service, --Jeorme Peace
06-11-07 04:27   
Uploaded FlaptapEdgeFix-wiz.2.cs for evaluation.

It reverts 6183RoundedMorphBounds.1.cs and
tries to do a better job when computing the edgeFraction.

The problem with the old calc could be seen when the objects flap is repostioned all the way to the right or the tools flap all the way to the bottom.
With the old calculation the fraction rather than being 1.0 was only 0.99+ at full range. The width of the objects flap is an odd number of pixels as is the height of the tools flap. This seemed to cause a minor but sufficient difficulty when applying the fraction.

Tests are next but not tonite.

Yours in curiosity and service, --Jerome Peace
06-11-07 05:53   
This might be of help: [^] [^]
06-11-07 05:55   
Ups, [^]
06-11-07 21:39   
Hi Alex,

Thanks for the help and folklore.

verbatim from the post laza's formula for seeing the problem was:

| a b tab |
"Create a float close to 466.700581395349"
a _ (1.1 at: 1 put: 1081944885; at: 2 put: 2497074009; yourself).
b _ 105.
a + b - a = b. "This evaluates to false"

tab _ Flaps newFlapTitled: 'Test' onEdge: #top.
tab left: a.
"next line will run into an infinite loop"
tab extent: b <at> b

I haven't tried it. Just looking I don't see how the assignment to a would work. But its a useful start for an Sunit test.

Cheers -Jer
06-11-07 23:27   
which tests for recursion based on laza's example.

(The example worked as stated. I didn't know you could hack floats in that way. Quite interesting)

Anyway the test fails before the fix and passes after.

A cautious updater would should run all tests once the fix is in place.

The fix reverts Morph>>extent: to dan ingalls simpler code (w/o rounding).

This should not cause problems BUT. The old "fix" was made in 2004; Morph>>extent: is used extensively by many and some may have written poor code based on the presumtion of rounding. So better to test than assume.

Cheers, --Jerome Peace
06-11-07 23:34   
"fix begin"
Installer mantis bug: 6486 fix: 'FlaptapEdgeFix-wiz.2.cs'.
"fix test"
Installer mantis bug: 6486 fix: ''.
"fix end"

10-13-08 02:09   
Note: fix did NOT get into 3.10.2
Problem still exists.
10-14-08 01:02   
"fix begin"
Installer mantis bug: 6486 fix: 'FlaptapEdgeFix-wiz.2.cs'.
"fix test"
Installer mantis bug: 6486 fix: ''.
"fix end"
01-09-10 03:00   
This bug still exists in Squeak3.11-8720-alpha.image !!!

Yours in curiosity and service, --Jerome Peace
04-08-10 09:41   
This is a duplicate of 0007213 which got resolved