13017 Class renaming does not update textual class definition
In reviewing issues that I have opened to clean out for Pharo 4 release, I have isolated a bug further, but don't know how to proceed from there. Essentially, the Changes Browser forks using openWithSpec, and so falls through to the a #changed: call before the change occurs. Opening modal might be a bit extreme, but is there a standard way to pause code execution in the sender of #openWithSpec until the window is closed? https://pharo.fogbugz.com/default.asp?13017 cheers -ben
Ben Coman wrote
is there a standard way to pause code execution in the sender of #openWithSpec until the window is closed?
Something like "model openDialogWithSpec okAction: [ self doNextThing ]"? ----- Cheers, Sean -- View this message in context: http://forum.world.st/13017-Class-renaming-does-not-update-textual-class-def... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On Mon, Mar 2, 2015 at 11:59 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Ben Coman wrote
is there a standard way to pause code execution in the sender of #openWithSpec until the window is closed?
Something like "model openDialogWithSpec okAction: [ self doNextThing ]"?
I'm not sure. A code example may help. The problem is we have... AbstractNautilusUI >>renameClass self okToChange ifFalse: [ ^ self ]. self selectedClass ifNil: [ ^ self ]. self basicRenameClass: self selectedClass theNonMetaClass. self changed: #sourceCodeFrom:. and 12 levels deep into #basicRenameClass: we have... NautilusRefactoring>>internalPerformRefactorings: ... (ChangesBrowser changes: aCollectionRefactoring) openWithSpec which forks such that execution returns to perform the #changed: before you get a chance to click the <Ok> button. So the problem is how to make it pause at #basicRenameClass: until the ChangesBrowser is closed (either ok cancel), such that #changed: is not executed before the changes are applied. The complication is the existing code operating on the ChangesBrowser <Ok> button, and the stack distance of #internalPerformRefactorings: from #renameClass. I am thinking of some synchronisation like the following would be least impact... NautilusRefactoring>>internalPerformRefactorings: ... (ChangesBrowser changes: aCollectionRefactoring) openDialogWithSpec windowClosedAction: [ refactoringDoneSemaphore signal]. refactoringDoneSemaphore wait. or maybe that could be pushed into SpecDialogWindow as a convenience method available to others. cheers -ben
Ben Coman wrote
which forks...
AFAICT part of the problem is that it /doesn't/ fork. It just returns control to Morphic, so if you're in the UI thread a Semaphore would freeze the UI. Ben Coman wrote
windowClosedAction: [ refactoringDoneSemaphore signal]. refactoringDoneSemaphore wait.
There is okAction:, but see above about the Semaphore ----- Cheers, Sean -- View this message in context: http://forum.world.st/13017-Class-renaming-does-not-update-textual-class-def... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
and 12 levels deep into #basicRenameClass: we have...
NautilusRefactoring>>internalPerformRefactorings: ... (ChangesBrowser changes: aCollectionRefactoring) openWithSpec
which forks such that execution returns to perform the #changed: before you get a chance to click the <Ok> button.
I do not understand why the fork is needed. The author of nautilus was sometimes to prompt at using fork. Did you see if the behavior is acceptable when we remove the fork?
So the problem is how to make it pause at #basicRenameClass: until the ChangesBrowser is closed (either ok cancel), such that #changed: is not executed before the changes are applied. The complication is the existing code operating on the ChangesBrowser <Ok> button, and the stack distance of #internalPerformRefactorings: from #renameClass.
I am thinking of some synchronisation like the following would be least impact...
NautilusRefactoring>>internalPerformRefactorings: ... (ChangesBrowser changes: aCollectionRefactoring) openDialogWithSpec windowClosedAction: [ refactoringDoneSemaphore signal]. refactoringDoneSemaphore wait.
or maybe that could be pushed into SpecDialogWindow as a convenience method available to others.
cheers -ben
participants (3)
-
Ben Coman -
Sean P. DeNigris -
stepharo