Re: [Pharo-project] Process stuck in 10156+OB?
2008/11/18 Simon Denier <Simon.Denier@inria.fr>:
Good luck
Actually, I dont know where to start, I cant open a window or interrupt the vm.
Hmm, an image, which you just sent me (10157ready.image), starts without any problems on my windoze box. No 100% CPU load, all is just working as always. Looks like the bug is VM/platform dependent, or you gave me wrong image?.
On 18 nov. 08, at 19:58, Igor Stasenko wrote:
2008/11/18 Simon Denier <Simon.Denier@inria.fr>:
On 18 nov. 08, at 18:32, Alexandre Bergel wrote:
Let us know Igor, this triggered my curiosity.
Alexandre
On 18 Nov 2008, at 14:25, Igor Stasenko wrote:
2008/11/18 Marcus Denker <denker@iam.unibe.ch>:
On 18.11.2008, at 17:11, Simon Denier wrote:
If I dowload the latest 10156 image, do a ScriptLoader loadOB, save it as new image, quit and then relaunch the new image, my new image is unusable because almost unresponsive: something is eating 100% CPU time.
- problem is the same if I upgrade to 10157 - however there seems to be no problem if I just continue to work in the image without quitting.
It's a weird behaviour.
Yes, I will undo some process related changes... maybe removing Process from the specialObjectsArray was a dunb idea ;-) I will put it back in.
Don't be so haste :) I'd rather try to reproduce the problem and find solution.
Should be easy to reproduce :) but I can send my image to whoever is able to work on it.
send it to me, i'll try to figure out what is wrong
a 100% cpu hog at startup time could be a problem with Delays, or different semaphores which has dropped during #clearExternalObjects but not correctly reinstantiated again at following startup phase.
Marcus
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Simon
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Simon
-- Best regards, Igor Stasenko AKA sig.
2008/11/18 Igor Stasenko <siguctua@gmail.com>:
2008/11/18 Simon Denier <Simon.Denier@inria.fr>:
Good luck
Actually, I dont know where to start, I cant open a window or interrupt the vm.
Hmm, an image, which you just sent me (10157ready.image), starts without any problems on my windoze box. No 100% CPU load, all is just working as always. Looks like the bug is VM/platform dependent, or you gave me wrong image?.
moreover, i tried to do ScriptLoader loadOB then save / save&quit.. no problems at all.
On 18 nov. 08, at 19:58, Igor Stasenko wrote:
2008/11/18 Simon Denier <Simon.Denier@inria.fr>:
On 18 nov. 08, at 18:32, Alexandre Bergel wrote:
Let us know Igor, this triggered my curiosity.
Alexandre
On 18 Nov 2008, at 14:25, Igor Stasenko wrote:
2008/11/18 Marcus Denker <denker@iam.unibe.ch>:
On 18.11.2008, at 17:11, Simon Denier wrote:
If I dowload the latest 10156 image, do a ScriptLoader loadOB, save it as new image, quit and then relaunch the new image, my new image is unusable because almost unresponsive: something is eating 100% CPU time.
- problem is the same if I upgrade to 10157 - however there seems to be no problem if I just continue to work in the image without quitting.
It's a weird behaviour.
Yes, I will undo some process related changes... maybe removing Process from the specialObjectsArray was a dunb idea ;-) I will put it back in.
Don't be so haste :) I'd rather try to reproduce the problem and find solution.
Should be easy to reproduce :) but I can send my image to whoever is able to work on it.
send it to me, i'll try to figure out what is wrong
a 100% cpu hog at startup time could be a problem with Delays, or different semaphores which has dropped during #clearExternalObjects but not correctly reinstantiated again at following startup phase.
Marcus
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Simon
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Simon
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
so it is worth to publish the image somewhere so that others can try. Stef On Nov 18, 2008, at 8:52 PM, Igor Stasenko wrote:
2008/11/18 Simon Denier <Simon.Denier@inria.fr>:
Good luck
Actually, I dont know where to start, I cant open a window or interrupt the vm.
Hmm, an image, which you just sent me (10157ready.image), starts without any problems on my windoze box. No 100% CPU load, all is just working as always. Looks like the bug is VM/platform dependent, or you gave me wrong image?.
On 18 nov. 08, at 19:58, Igor Stasenko wrote:
2008/11/18 Simon Denier <Simon.Denier@inria.fr>:
On 18 nov. 08, at 18:32, Alexandre Bergel wrote:
Let us know Igor, this triggered my curiosity.
Alexandre
On 18 Nov 2008, at 14:25, Igor Stasenko wrote:
2008/11/18 Marcus Denker <denker@iam.unibe.ch>:
On 18.11.2008, at 17:11, Simon Denier wrote:
If I dowload the latest 10156 image, do a ScriptLoader loadOB, save it as new image, quit and then relaunch the new image, my new image is unusable because almost unresponsive: something is eating 100% CPU time.
- problem is the same if I upgrade to 10157 - however there seems to be no problem if I just continue to work in the image without quitting.
It's a weird behaviour.
Yes, I will undo some process related changes... maybe removing Process from the specialObjectsArray was a dunb idea ;-) I will put it back in.
Don't be so haste :) I'd rather try to reproduce the problem and find solution.
Should be easy to reproduce :) but I can send my image to whoever is able to work on it.
send it to me, i'll try to figure out what is wrong
a 100% cpu hog at startup time could be a problem with Delays, or different semaphores which has dropped during #clearExternalObjects but not correctly reinstantiated again at following startup phase.
Marcus
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
-- Simon
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Simon
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 18.11.2008, at 20:52, Igor Stasenko wrote:
2008/11/18 Simon Denier <Simon.Denier@inria.fr>:
Good luck
Actually, I dont know where to start, I cant open a window or interrupt the vm.
Hmm, an image, which you just sent me (10157ready.image), starts without any problems on my windoze box. No 100% CPU load, all is just working as always. Looks like the bug is VM/platform dependent, or you gave me wrong image?.
The only platform dependend thing I added is the native menu on mac (for mac users: try to click on the "File" menu in the mac meny bar...). Marcus -- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
Hmm, an image, which you just sent me (10157ready.image), starts without any problems on my windoze box. No 100% CPU load, all is just working as always. Looks like the bug is VM/platform dependent, or you gave me wrong image?.
The only platform dependend thing I added is the native menu on mac (for mac users: try to click on the "File" menu in the mac meny bar...).
The problem of Simon indeed seems to be related to this change. He gets an endless loop in HostSystemMenusMacOSX >> modifySqueakMenu: aString. When 'results' points to 'Universe Browser (basic)', 'fixIndex' is always greater than 0, so the whileTrue: loop will never end. The problem seems to be the $( in this menu entry. It's no clear to me what this method is supposed to do? Replacing the character between '(x)' with '/X '? But for what reason? This code obviously doesn't work when x is more than one character long. This problem probably happened because when Simon loaded OB, it changes the menu, although the defect entry is not one added by OB, but by the Universe Browser. Adding any new entry probably triggers in any case the new generation of this menu. Cheers, David
Ya it's my bug, however it's way too late tonight for me to tackle it. The problem is that if the menu contains (x) and we attempt to convert that into a macintosh menu the older os-9 menu logic has specialized meanings for character strings of the form (x) so we attempt to fix it. http://developer.apple.com/documentation/mac/Toolbox/Toolbox-144.html I think in this case the morphic menus use (x) to mean x is a command key, but that would disable the menu on the macintosh. So I was fixing up usages of (x) Obviously not correctly since it fails on strings of the form (x1...) On 19-Nov-08, at 1:13 AM, David Röthlisberger wrote:
Hmm, an image, which you just sent me (10157ready.image), starts without any problems on my windoze box. No 100% CPU load, all is just working as always. Looks like the bug is VM/platform dependent, or you gave me wrong image?. The only platform dependend thing I added is the native menu on mac (for mac users: try to click on the "File" menu in the mac meny bar...).
The problem of Simon indeed seems to be related to this change. He gets an endless loop in HostSystemMenusMacOSX >> modifySqueakMenu: aString. When 'results' points to 'Universe Browser (basic)', 'fixIndex' is always greater than 0, so the whileTrue: loop will never end. The problem seems to be the $( in this menu entry. It's no clear to me what this method is supposed to do? Replacing the character between '(x)' with '/X '? But for what reason? This code obviously doesn't work when x is more than one character long.
This problem probably happened because when Simon loaded OB, it changes the menu, although the defect entry is not one added by OB, but by the Universe Browser. Adding any new entry probably triggers in any case the new generation of this menu.
Cheers, David
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
Morning on the west coast of Canada, let me write up a few SUnits... On 19-Nov-08, at 1:45 AM, John M McIntosh wrote:
Ya it's my bug, however it's way too late tonight for me to tackle it. The problem is that if the menu contains (x) and we attempt to convert that into a macintosh menu the older os-9 menu logic has specialized meanings for character strings of the form (x) so we attempt to fix it.
http://developer.apple.com/documentation/mac/Toolbox/Toolbox-144.html
I think in this case the morphic menus use (x) to mean x is a command key, but that would disable the menu on the macintosh.
So I was fixing up usages of (x)
Obviously not correctly since it fails on strings of the form (x1...)
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
Ok, I think the fix is below, someone can field test it? I did write an Sunit The idea is that we want to change (x) to /X which means it's cmd key x But also handle the case of ( ) and (() which are aren't allowed by the api we are using. Also we change ';' '^' '!' '<' '/' to ' ' and if '(' doesn't follow the proper patter of (*) then it becomes a space too. testCharacterChanging | testString item shouldBe resultingString where | #(';' '^' '!' '<' '/' '(' ) do: [:c | #('*' '* ' '* ' '**' '** ' '** ' ')' '*)' '* )' '* )' '**)' '** )' '** )' ')' '*)' '*X)' '*XX)' '**)' '**X)' '**XX)' '))' '*))' '*X))' '*XX))' '**))' '**X))' '**XX))' '(' '*(' '*X(' '*XX(' '**)' '**X(' '**XX(' '((' '*((' '*X((' '*XX((' '**((' '**X((' '**XX((' ) do: [:template | testString := template copyReplaceAll: '*' with: c. testString permutationsDo: [:mixedUp | item := mixedUp copy. shouldBe := self calculateShouldBeFrom: item using: c. resultingString := self modifySqueakMenu: item copy. self should: [shouldBe = resultingString]. (where := resultingString indexOf: $/) > 0 ifTrue: [self should: [(mixedUp at: where) = $(]. self should: [(mixedUp at: where+2) = $)]. self should: [(mixedUp at: where+1) asUppercase = (resultingString at: where+1)]]]]] where calculateShouldBeFrom: using: runs off and guess at the proper string with a different algorithm, an exercise for the user... Fix is below. modifySqueakMenu: aString | results fixIndex middleCharacter | results := aString. results replaceAll: $; with: Character space. results replaceAll: $^ with: Character space. results replaceAll: $! with: Character space. results replaceAll: $< with: Character space. results replaceAll: $/ with: Character space. fixIndex := results indexOf: $(. [fixIndex > 0] whileTrue: [ [(results at: fixIndex + 2) = $) ifTrue: [middleCharacter := results at: fixIndex + 1. (middleCharacter = Character space or: [middleCharacter = $(]) ifTrue: [results at: fixIndex put: Character space] ifFalse: [results at: fixIndex put: $/.]. results at: fixIndex + 1 put: middleCharacter asUppercase. results at: fixIndex + 2 put: Character space] ifFalse: [results at: fixIndex put: Character space]] ifError: [results at: fixIndex put: Character space]. fixIndex := results indexOf: $(]. ^ results On 19-Nov-08, at 1:45 AM, John M McIntosh wrote:
Ya it's my bug, however it's way too late tonight for me to tackle it. The problem is that if the menu contains (x) and we attempt to convert that into a macintosh menu the older os-9 menu logic has specialized meanings for character strings of the form (x) so we attempt to fix it.
http://developer.apple.com/documentation/mac/Toolbox/Toolbox-144.html
I think in this case the morphic menus use (x) to mean x is a command key, but that would disable the menu on the macintosh.
So I was fixing up usages of (x)
Obviously not correctly since it fails on strings of the form (x1...)
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
It works for me, thanks John, it's cool to have this feeling of integration with mac os On 20 nov. 08, at 00:03, John M McIntosh wrote:
Ok, I think the fix is below, someone can field test it?
I did write an Sunit
The idea is that we want to change (x) to /X which means it's cmd key x But also handle the case of ( ) and (() which are aren't allowed by the api we are using. Also we change ';' '^' '!' '<' '/' to ' ' and if '(' doesn't follow the proper patter of (*) then it becomes a space too.
testCharacterChanging | testString item shouldBe resultingString where | #(';' '^' '!' '<' '/' '(' ) do: [:c | #('*' '* ' '* ' '**' '** ' '** ' ')' '*)' '* )' '* )' '**)' '** )' '** )' ')' '*)' '*X)' '*XX)' '**)' '**X)' '**XX)' '))' '*))' '*X))' '*XX))' '**))' '**X))' '**XX))' '(' '*(' '*X(' '*XX(' '**)' '**X(' '**XX(' '((' '*((' '*X((' '*XX((' '**((' '**X((' '**XX((' ) do: [:template | testString := template copyReplaceAll: '*' with: c. testString permutationsDo: [:mixedUp | item := mixedUp copy. shouldBe := self calculateShouldBeFrom: item using: c. resultingString := self modifySqueakMenu: item copy. self should: [shouldBe = resultingString]. (where := resultingString indexOf: $/) > 0 ifTrue: [self should: [(mixedUp at: where) = $(]. self should: [(mixedUp at: where+2) = $)]. self should: [(mixedUp at: where+1) asUppercase = (resultingString at: where+1)]]]]]
where calculateShouldBeFrom: using: runs off and guess at the proper string with a different algorithm, an exercise for the user...
Fix is below.
modifySqueakMenu: aString | results fixIndex middleCharacter | results := aString. results replaceAll: $; with: Character space. results replaceAll: $^ with: Character space. results replaceAll: $! with: Character space. results replaceAll: $< with: Character space. results replaceAll: $/ with: Character space. fixIndex := results indexOf: $(. [fixIndex > 0] whileTrue: [ [(results at: fixIndex + 2) = $) ifTrue: [middleCharacter := results at: fixIndex + 1. (middleCharacter = Character space or: [middleCharacter = $(]) ifTrue: [results at: fixIndex put: Character space] ifFalse: [results at: fixIndex put: $/.]. results at: fixIndex + 1 put: middleCharacter asUppercase. results at: fixIndex + 2 put: Character space] ifFalse: [results at: fixIndex put: Character space]] ifError: [results at: fixIndex put: Character space]. fixIndex := results indexOf: $(]. ^ results
On 19-Nov-08, at 1:45 AM, John M McIntosh wrote:
Ya it's my bug, however it's way too late tonight for me to tackle it. The problem is that if the menu contains (x) and we attempt to convert that into a macintosh menu the older os-9 menu logic has specialized meanings for character strings of the form (x) so we attempt to fix it.
http://developer.apple.com/documentation/mac/Toolbox/Toolbox-144.html
I think in this case the morphic menus use (x) to mean x is a command key, but that would disable the menu on the macintosh.
So I was fixing up usages of (x)
Obviously not correctly since it fails on strings of the form (x1...)
-- = = = = = ====================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = ======================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Simon
john do you have a new version of the package since the method calculateShouldBeFrom:using: is missing On Nov 20, 2008, at 12:03 AM, John M McIntosh wrote:
testCharacterChanging | testString item shouldBe resultingString where | #(';' '^' '!' '<' '/' '(' ) do: [:c | #('*' '* ' '* ' '**' '** ' '** ' ')' '*)' '* )' '* )' '**)' '** )' '** )' ')' '*)' '*X)' '*XX)' '**)' '**X)' '**XX)' '))' '*))' '*X))' '*XX))' '**))' '**X))' '**XX))' '(' '*(' '*X(' '*XX(' '**)' '**X(' '**XX(' '((' '*((' '*X((' '*XX((' '**((' '**X((' '**XX((' ) do: [:template | testString := template copyReplaceAll: '*' with: c. testString permutationsDo: [:mixedUp | item := mixedUp copy. shouldBe := self calculateShouldBeFrom: item using: c. resultingString := self modifySqueakMenu: item copy. self should: [shouldBe = resultingString]. (where := resultingString indexOf: $/) > 0 ifTrue: [self should: [(mixedUp at: where) = $(]. self should: [(mixedUp at: where+2) = $)]. self should: [(mixedUp at: where+1) asUppercase = (resultingString at: where+1)]]]]]
participants (6)
-
David Röthlisberger -
Igor Stasenko -
John M McIntosh -
Marcus Denker -
Simon Denier -
Stéphane Ducasse