Anonymous | Login | 04-12-2021 13:14 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Issue History ] [ Print ] | ||||||||
ID | Category | Severity | Reproducibility | Date Submitted | Last Update | ||||
0006486 | [Squeak] Morphic | major | sometimes | 05-14-07 03:06 | 04-18-10 21:51 | ||||
Reporter | wiz | View Status | public | ||||||
Assigned To | laza | ||||||||
Priority | normal | Resolution | fixed | ||||||
Status | closed | Product Version | 3.10 | ||||||
Summary | 0006486: In 7097 Resizing the objects flaptab can result in a infinite loop (i.e. squeak freezes) | ||||||||
Description |
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. |
||||||||
Additional Information |
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. Flaptab>> 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. |
||||||||
Attached Files |
![]() ![]() |
||||||||
|
![]() |
|||||||||||||||||||||
SYSTEM WARNING: Creating default object from empty value SYSTEM WARNING: Creating default object from empty value
|
![]() |
|
(0010790 - 915 - 1236 - 1281 - 1281 - 1281 - 1281) wiz 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 6183RoundedMorphBounds.1.cs preamble: "Change Set: RoundedMorphBounds Date: 25 March 2004 Author: Alexander@Lazarevic.de Prevents an infinite loop in some cases when FlapTab Morphs have floats in their boundry" Morph>> 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. |
(0010791 - 159 - 201 - 201 - 201 - 201 - 201) wiz 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. Thanx, Yours in curiosity and service, --Jeorme Peace |
(0010792 - 663 - 729 - 729 - 729 - 729 - 729) wiz 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 |
(0010793 - 170 - 188 - 572 - 572 - 572 - 572) laza 06-11-07 05:53 |
This might be of help: http://article.gmane.org/gmane.comp.lang.smalltalk.squeak.general/32193 [^] http://article.gmane.org/gmane.comp.lang.smalltalk.squeak.general/32193 [^] |
(0010794 - 79 - 91 - 283 - 283 - 283 - 283) laza 06-11-07 05:55 |
Ups, http://article.gmane.org/gmane.comp.lang.smalltalk.squeak.general/32210 [^] |
(0010796 - 569 - 725 - 725 - 725 - 725 - 725) wiz 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 |
(0010797 - 635 - 735 - 735 - 735 - 735 - 735) wiz 06-11-07 23:27 |
Uploaded FlapTabTests.st 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 |
(0010798 - 148 - 214 - 214 - 214 - 214 - 214) wiz 06-11-07 23:34 edited on: 06-11-07 23:40 |
"fix begin" Installer mantis bug: 6486 fix: 'FlaptapEdgeFix-wiz.2.cs'. "fix test" Installer mantis bug: 6486 fix: 'FlapTabTests.st'. "fix end" |
(0012734 - 56 - 62 - 62 - 62 - 62 - 62) wiz 10-13-08 02:09 |
Note: fix did NOT get into 3.10.2 Problem still exists. |
(0012739 - 146 - 200 - 200 - 200 - 200 - 200) wiz 10-14-08 01:02 |
"fix begin" Installer mantis bug: 6486 fix: 'FlaptapEdgeFix-wiz.2.cs'. "fix test" Installer mantis bug: 6486 fix: 'FlapTabTests.st'. "fix end" |
(0013460 - 106 - 118 - 118 - 118 - 118 - 118) wiz 01-09-10 03:00 |
This bug still exists in Squeak3.11-8720-alpha.image !!! Yours in curiosity and service, --Jerome Peace |
(0013638 - 47 - 47 - 47 - 184 - 184 - 184) laza 04-08-10 09:41 |
This is a duplicate of 0007213 which got resolved |
Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
114 total queries executed. 63 unique queries executed. |