Anonymous | Login | 03-07-2021 09:15 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 | |||||||
0007639 | [Squeak] Kernel | block | always | 05-31-11 14:12 | 05-31-11 14:12 | |||||||
Reporter | wiz | View Status | public | |||||||||
Assigned To | ||||||||||||
Priority | urgent | Resolution | open | |||||||||
Status | new | Product Version | trunk | |||||||||
Summary | 0007639: [BUG] [] storeString goes into a tight infinite loop. | |||||||||||
Description |
For this one in a fresh disposable image, in a work space evaluate: [] storeString on a cog vm it will go into a tight infinite loop. requiring the job to be killed. In 3.9 the same infinte behavior but the loop was user interuptable. |
|||||||||||
Additional Information |
As I understand it storeString is supposed to be like but more precise that printString allowing its output to be re-evaluated. Ideally the reevaluation would give you an object similar to the receiver. For simple block closures the decompile message will produce a text that has this property. Eliot informs me this only work as long as the closure doesn't close over anything. The critical part of this bug is where the machine freezes if a closure is sent #storeString. This can trivially be fixed by causing storeString to fail with an error. Is that what should be done? Yours in curiosity and service, --Jerome Peace |
|||||||||||
Attached Files | ||||||||||||
|
There are no notes attached to this issue. |
![]() |
|||
Date Modified | Username | Field | Change |
05-31-11 14:12 | wiz | New Issue | |
05-31-11 14:32 | wiz | Relationship added | child of 0007640 |
Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
32 total queries executed. 26 unique queries executed. |