[Pharo-dev] [update30] #30323
30323 - 11200 Repeated methods in superclasses, explicit requirement no implemented, repeated methods in traits https://pharo.fogbugz.com/f/cases/11200 (pass 1)
[Pharo-dev] [update 3.0] #30324
30324 - 11200 Repeated methods in superclasses, explicit requirement no implemented, repeated methods in traits https://pharo.fogbugz.com/f/cases/11200 (pass 2... fiuuu :P) Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Traits-EstebanLorenzano.554.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/ToolsTest-EstebanLorenzano.denker.53.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-EstebanLorenzano.1203.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Text-Edition-EstebanLorenzano.4.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tests-EstebanLorenzano.604.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Widgets-EstebanLorenzano.221.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Tools-EstebanLorenzano.124.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/SmartSuggestions-EstebanLorenzano.102.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Slot-EstebanLorenzano.368.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Shout-EstebanLorenzano.192.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/SUnit-UITesting-EstebanLorenzano.12.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/SUnit-Core-EstebanLorenzano.87.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Ring-Core-Kernel-EstebanLorenzano.130.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Regex-Core-EstebanLorenzano.24.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Tests-Critics-EstebanLorenzano.14.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Tests-Core-EstebanLorenzano.71.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Critics-EstebanLorenzano.50.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/RPackage-SystemIntegration-EstebanLorenzano.168.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-EstebanLorenzano.878.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Tools-Diff-EstebanLorenzano.98.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-TaskbarIcons-EstebanLorenzano.24.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/PackageInfo-EstebanLorenzano.105.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Nautilus-EstebanLorenzano.504.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/NativeBoost-Win32-EstebanLorenzano.37.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/NativeBoost-Mac-EstebanLorenzano.10.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/NativeBoost-Core-EstebanLorenzano.133.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/NOCompletion-EstebanLorenzano.38.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Examples-EstebanLorenzano.6.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-EstebanLorenzano.64.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Monticello-EstebanLorenzano.847.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Metacello-MC-EstebanLorenzano.670.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Metacello-Core-EstebanLorenzano.500.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Manifest-CriticBrowser-EstebanLorenzano.101.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Manifest-Core-EstebanLorenzano.149.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/KeyChain-EstebanLorenzano.47.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/KernelTests-EstebanLorenzano.540.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-EstebanLorenzano.1550.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/GroupManager-EstebanLorenzano.47.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Graphics-Primitives-EstebanLorenzano.106.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Gofer-Core-EstebanLorenzano.198.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/FileSystem-Core-EstebanLorenzano.106.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Compiler-EstebanLorenzano.510.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/CollectionsTests-EstebanLorenzano.619.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Unordered-EstebanLorenzano.162.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Strings-EstebanLorenzano.275.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Streams-EstebanLorenzano.142.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Sequenceable-EstebanLorenzano.149.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Abstract-EstebanLorenzano.218.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Athens-Examples-EstebanLorenzano.24.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Athens-Cairo-EstebanLorenzano.47.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Athens-Balloon-EstebanLorenzano.13.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/AsmJit-x86-EstebanLorenzano.7.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/AsmJit-StackManagement-EstebanLorenzano.4.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/AsmJit-Instructions-EstebanLorenzano.5.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Announcements-Tests-Core-EstebanLorenzano.14.diff
[Pharo-dev] [regression reporter]regression occurred
https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=linux-stable-worker/407/ 1 regressions found. KernelTests.Numbers.LargePositiveIntegerTest.testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses
Re: [Pharo-dev] [update 3.0] #30324
I don't understand all those UsersManagerinitialize + Initialization code for UsersManager isn't that pretty obvious that the initialize method contains the initialization code? :POr are they autogenerated or something? sorry for the silly question :) Guille On Tue, Aug 6, 2013 at 2:46 PM, Esteban Lorenzano esteba...@gmail.comwrote: 30324 - 11200 Repeated methods in superclasses, explicit requirement no implemented, repeated methods in traits https://pharo.fogbugz.com/f/cases/11200 (pass 2... fiuuu :P) Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Traits-EstebanLorenzano.554.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/ToolsTest-EstebanLorenzano.denker.53.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-EstebanLorenzano.1203.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Text-Edition-EstebanLorenzano.4.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tests-EstebanLorenzano.604.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Widgets-EstebanLorenzano.221.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Tools-EstebanLorenzano.124.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/SmartSuggestions-EstebanLorenzano.102.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Slot-EstebanLorenzano.368.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Shout-EstebanLorenzano.192.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/SUnit-UITesting-EstebanLorenzano.12.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/SUnit-Core-EstebanLorenzano.87.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Ring-Core-Kernel-EstebanLorenzano.130.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Regex-Core-EstebanLorenzano.24.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Tests-Critics-EstebanLorenzano.14.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Tests-Core-EstebanLorenzano.71.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Critics-EstebanLorenzano.50.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/RPackage-SystemIntegration-EstebanLorenzano.168.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-EstebanLorenzano.878.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Tools-Diff-EstebanLorenzano.98.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-TaskbarIcons-EstebanLorenzano.24.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/PackageInfo-EstebanLorenzano.105.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Nautilus-EstebanLorenzano.504.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/NativeBoost-Win32-EstebanLorenzano.37.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/NativeBoost-Mac-EstebanLorenzano.10.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/NativeBoost-Core-EstebanLorenzano.133.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/NOCompletion-EstebanLorenzano.38.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Examples-EstebanLorenzano.6.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-EstebanLorenzano.64.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Monticello-EstebanLorenzano.847.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Metacello-MC-EstebanLorenzano.670.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Metacello-Core-EstebanLorenzano.500.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Manifest-CriticBrowser-EstebanLorenzano.101.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Manifest-Core-EstebanLorenzano.149.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/KeyChain-EstebanLorenzano.47.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/KernelTests-EstebanLorenzano.540.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-EstebanLorenzano.1550.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/GroupManager-EstebanLorenzano.47.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Graphics-Primitives-EstebanLorenzano.106.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Gofer-Core-EstebanLorenzano.198.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/FileSystem-Core-EstebanLorenzano.106.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Compiler-EstebanLorenzano.510.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/CollectionsTests-EstebanLorenzano.619.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Unordered-EstebanLorenzano.162.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Strings-EstebanLorenzano.275.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Streams-EstebanLorenzano.142.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Sequenceable-EstebanLorenzano.149.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Abstract-EstebanLorenzano.218.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Athens-Examples-EstebanLorenzano.24.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Athens-Cairo-EstebanLorenzano.47.diff
[Pharo-dev] [regression reporter]regression occurred
https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=win/407/ 1 regressions found. KernelTests.Numbers.LargePositiveIntegerTest.testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses
Re: [Pharo-dev] [update 3.0] #30324
Hi Guille, It is a merging problem, this issue was made using changesets, and it seems that someone modified the method after the changesets were created. Doing the integration now, the method went back to its original code. I'll take a look at the changes for possible bugs. 2013/8/6 Guillermo Polito guillermopol...@gmail.com I don't understand all those UsersManagerinitialize + Initialization code for UsersManager isn't that pretty obvious that the initialize method contains the initialization code? :POr are they autogenerated or something? sorry for the silly question :) Guille On Tue, Aug 6, 2013 at 2:46 PM, Esteban Lorenzano esteba...@gmail.comwrote: 30324 - 11200 Repeated methods in superclasses, explicit requirement no implemented, repeated methods in traits https://pharo.fogbugz.com/f/cases/11200 (pass 2... fiuuu :P) Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Traits-EstebanLorenzano.554.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/ToolsTest-EstebanLorenzano.denker.53.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-EstebanLorenzano.1203.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Text-Edition-EstebanLorenzano.4.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tests-EstebanLorenzano.604.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Widgets-EstebanLorenzano.221.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Tools-EstebanLorenzano.124.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/SmartSuggestions-EstebanLorenzano.102.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Slot-EstebanLorenzano.368.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Shout-EstebanLorenzano.192.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/SUnit-UITesting-EstebanLorenzano.12.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/SUnit-Core-EstebanLorenzano.87.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Ring-Core-Kernel-EstebanLorenzano.130.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Regex-Core-EstebanLorenzano.24.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Tests-Critics-EstebanLorenzano.14.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Tests-Core-EstebanLorenzano.71.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Critics-EstebanLorenzano.50.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/RPackage-SystemIntegration-EstebanLorenzano.168.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-EstebanLorenzano.878.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Tools-Diff-EstebanLorenzano.98.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-TaskbarIcons-EstebanLorenzano.24.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/PackageInfo-EstebanLorenzano.105.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Nautilus-EstebanLorenzano.504.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/NativeBoost-Win32-EstebanLorenzano.37.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/NativeBoost-Mac-EstebanLorenzano.10.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/NativeBoost-Core-EstebanLorenzano.133.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/NOCompletion-EstebanLorenzano.38.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Examples-EstebanLorenzano.6.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-EstebanLorenzano.64.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Monticello-EstebanLorenzano.847.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Metacello-MC-EstebanLorenzano.670.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Metacello-Core-EstebanLorenzano.500.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Manifest-CriticBrowser-EstebanLorenzano.101.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Manifest-Core-EstebanLorenzano.149.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/KeyChain-EstebanLorenzano.47.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/KernelTests-EstebanLorenzano.540.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-EstebanLorenzano.1550.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/GroupManager-EstebanLorenzano.47.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Graphics-Primitives-EstebanLorenzano.106.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Gofer-Core-EstebanLorenzano.198.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/FileSystem-Core-EstebanLorenzano.106.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Compiler-EstebanLorenzano.510.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/CollectionsTests-EstebanLorenzano.619.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Unordered-EstebanLorenzano.162.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Strings-EstebanLorenzano.275.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Streams-EstebanLorenzano.142.diff
[Pharo-dev] Fwd: Keyboard events is broken.
I changed this method to see better what happens: HandMorph classshowDebugEvent: evt ShowEvents == true ifTrue: [ | ofs| Display fill: (0@0 extent: 500@120) rule: Form over fillColor: Color white. ofs := (owner hands indexOf: self) - 1 * 60. evt printString displayAt: (0@ofs) + (evt isKeyboard ifTrue: [0@30] ifFalse: [0@0]). self keyboardFocus printString displayAt: (0@ofs)+(0@45). evt isKeyboard ifTrue: [ Transcript show: evt printString;cr ] ]. KeyboardEvent printOn: aStream Print the receiver on a stream aStream nextPut: $[. aStream nextPutAll: type; nextPutAll: ' '''. self printKeyStringOn: aStream. aStream nextPut: $'. aStream space; nextPutAll: 'keyValue: ', self keyValue asString. aStream nextPut: $] set HandMorph showEvents:true Now, pressing single space, gives me this: [keyDown ' ' keyValue: 49] [keystroke ' ' keyValue: 32] [keyUp ' ' keyValue: 49] [keyUp ' ' keyValue: 49] Pressing delete key (or fn-backspace , for those who having a lot of spare fingers to use bad keyboards): [keyDown ' ' keyValue: 117] [keystroke '⌦' keyValue: 188] [keyUp ' ' keyValue: 117] [keyUp ' ' keyValue: 117] now, can someone tell me , why there is 2 keyUp events for each keyDown? and of course, main question is why key values are different for keydown and keystroke events? (and why delete key is not 127, but 117 or 188?) Editor expecting 127: cmdMap at: (127 + 1) put: #forwardDelete:. del key -- Best regards, Igor Stasenko.
[Pharo-dev] [update 3.0] #30325
30325 - 11294 Bugs in refactoring when using traits https://pharo.fogbugz.com/f/cases/11294 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Environment-EstebanLorenzano.21.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Core-EstebanLorenzano.185.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/NautilusRefactoring-EstebanLorenzano.108.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Nautilus-EstebanLorenzano.506.diff
[Pharo-dev] [regression reporter]regression occurred
https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=linux-stable-worker/408/ 1 regressions found. KernelTests.Numbers.LargePositiveIntegerTest.testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses
[Pharo-dev] [regression reporter]regression occurred
https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=mac/408/ 1 regressions found. KernelTests.Numbers.LargePositiveIntegerTest.testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses
[Pharo-dev] [regression reporter]regression occurred
https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=win/408/ 1 regressions found. KernelTests.Numbers.LargePositiveIntegerTest.testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses
Re: [Pharo-dev] Fwd: Keyboard events is broken.
On Tue, Aug 6, 2013 at 3:40 PM, Igor Stasenko siguc...@gmail.com wrote: I changed this method to see better what happens: HandMorph classshowDebugEvent: evt ShowEvents == true ifTrue: [ | ofs| Display fill: (0@0 extent: 500@120) rule: Form over fillColor: Color white. ofs := (owner hands indexOf: self) - 1 * 60. evt printString displayAt: (0@ofs) + (evt isKeyboard ifTrue: [0@30] ifFalse: [0@0]). self keyboardFocus printString displayAt: (0@ofs)+(0@45). evt isKeyboard ifTrue: [ Transcript show: evt printString;cr ] ]. KeyboardEvent printOn: aStream Print the receiver on a stream aStream nextPut: $[. aStream nextPutAll: type; nextPutAll: ' '''. self printKeyStringOn: aStream. aStream nextPut: $'. aStream space; nextPutAll: 'keyValue: ', self keyValue asString. aStream nextPut: $] set HandMorph showEvents:true Now, pressing single space, gives me this: [keyDown ' ' keyValue: 49] [keystroke ' ' keyValue: 32] [keyUp ' ' keyValue: 49] [keyUp ' ' keyValue: 49] Pressing delete key (or fn-backspace , for those who having a lot of spare fingers to use bad keyboards): [keyDown ' ' keyValue: 117] [keystroke '⌦' keyValue: 188] [keyUp ' ' keyValue: 117] [keyUp ' ' keyValue: 117] now, can someone tell me , why there is 2 keyUp events for each keyDown? That I don't know and of course, main question is why key values are different for keydown and keystroke events? That I'll dive right now into the vm to see what it is :). (and why delete key is not 127, but 117 or 188?) Editor expecting 127: cmdMap at: (127 + 1) put: #forwardDelete:. del key -- Best regards, Igor Stasenko.
[Pharo-dev] moose build - pharo vm crash
Hi, It seems that the Moose build crashes the VM since yesterday evening due to a failing test. The image is based on Pharo 2.0 and is running a stable VM on Ubuntu. See some details here: https://ci.inria.fr/moose/job/Moose-latest-dev-4.8/804/console The script to reproduce the problem (on Ubuntu) is: #--- wget --quiet -O - http://get.pharo.org/20+vm | bash ./pharo Pharo.image save $JOB_NAME REPO=http://www.smalltalkhub.com/mc/Moose/Moose/main ./pharo $JOB_NAME.image config $REPO ConfigurationOfMoose --install=development ./pharo $JOB_NAME.image mooseimagesetup ./pharo $JOB_NAME.image moosetest --junit-xml-output mv ./pharo-vm/PharoV20.sources ./ zip $JOB_NAME.zip $JOB_NAME.image $JOB_NAME.changes PharoV20.sources #--- Cheers, Doru -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Flamel Update
thanks for the update.. Stef On Aug 6, 2013, at 3:00 PM, Gisela Decuzzi giseladecu...@gmail.com wrote: Hi, I'm working for the Gsoc project: better rw rule tools and my mentors suggested me to send the weekly progress to the mailing list because other people can be interested. Work done: - defining a basic UI that admit - write an example expression - write the matching / transforming pattern - restrict the scope where running the rule (now select classes or packages) - run a rule for matching / transforming This week progress: - Show / Navigate the result after matching: FlamelUI-WithResultInMatch.png - blog post about defining the matching expression: http://pharorwrules.wordpress.com/2013/08/06/just-want-to-match/ - bugfixing - middle term evaluation - fixing repository and package mess (that I've done...) For next week: - correct problems when transforming - vitualize the result after a transformation (rehuse part of the search result for this) - add tests for transforming - blog post about rw engine (how to define a rule from the scratch and why I implemented my own rule that matchs and transforms) - (if time) define the matching pattern for the expression (is an expression, is a method? Should try with the best?), right now is matching as a method pattern and sometimes is confusing. If someone wants to see more planed task can have a look to the Trello board in: https://trello.com/b/XqfJGqeB/flamel If someone wants to give a try and give me some feedback the code is in smalltalkhub: MCSmalltalkhubRepository owner: 'gisela' project: 'Flamel' user: '' password: '' The blog for this project is: http://pharorwrules.wordpress.com Cheers, Gise.
Re: [Pharo-dev] [Pharo-fuel] Fuel API bug
#when:do: is there already ;) even better then :) #when:send:to: and #when:do:for: should be added though. sounds good. Cheers, Henry
Re: [Pharo-dev] moose build - pharo vm crash
Hi Doru, join the club: https://swing.fit.cvut.cz/jenkins/view/CalipeL/job/calipel_s_pharo20_benchmarks/label=Linux/19/console I reported presumably same issue 21/06/13, update 10/07/13 :-) Best, Jan On 06/08/13 15:43, Tudor Girba wrote: Hi, It seems that the Moose build crashes the VM since yesterday evening due to a failing test. The image is based on Pharo 2.0 and is running a stable VM on Ubuntu. See some details here: https://ci.inria.fr/moose/job/Moose-latest-dev-4.8/804/console The script to reproduce the problem (on Ubuntu) is: #--- wget --quiet -O - http://get.pharo.org/20+vm | bash ./pharo Pharo.image save $JOB_NAME REPO=http://www.smalltalkhub.com/mc/Moose/Moose/main ./pharo $JOB_NAME.image config $REPO ConfigurationOfMoose --install=development ./pharo $JOB_NAME.image mooseimagesetup ./pharo $JOB_NAME.image moosetest --junit-xml-output mv ./pharo-vm/PharoV20.sources ./ zip $JOB_NAME.zip $JOB_NAME.image $JOB_NAME.changes PharoV20.sources #--- Cheers, Doru -- www.tudorgirba.com http://www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Keyboard events is broken.
thanks guillermo :) Cleaning events at VM level is important. On Aug 6, 2013, at 4:32 PM, Guillermo Polito guillermopol...@gmail.com wrote: On Tue, Aug 6, 2013 at 3:40 PM, Igor Stasenko siguc...@gmail.com wrote: I changed this method to see better what happens: HandMorph classshowDebugEvent: evt ShowEvents == true ifTrue: [ | ofs| Display fill: (0@0 extent: 500@120) rule: Form over fillColor: Color white. ofs := (owner hands indexOf: self) - 1 * 60. evt printString displayAt: (0@ofs) + (evt isKeyboard ifTrue: [0@30] ifFalse: [0@0]). self keyboardFocus printString displayAt: (0@ofs)+(0@45). evt isKeyboard ifTrue: [ Transcript show: evt printString;cr ] ]. KeyboardEvent printOn: aStream Print the receiver on a stream aStream nextPut: $[. aStream nextPutAll: type; nextPutAll: ' '''. self printKeyStringOn: aStream. aStream nextPut: $'. aStream space; nextPutAll: 'keyValue: ', self keyValue asString. aStream nextPut: $] set HandMorph showEvents:true Now, pressing single space, gives me this: [keyDown ' ' keyValue: 49] [keystroke ' ' keyValue: 32] [keyUp ' ' keyValue: 49] [keyUp ' ' keyValue: 49] Pressing delete key (or fn-backspace , for those who having a lot of spare fingers to use bad keyboards): [keyDown ' ' keyValue: 117] [keystroke '⌦' keyValue: 188] [keyUp ' ' keyValue: 117] [keyUp ' ' keyValue: 117] now, can someone tell me , why there is 2 keyUp events for each keyDown? That I don't know and of course, main question is why key values are different for keydown and keystroke events? That I'll dive right now into the vm to see what it is :). (and why delete key is not 127, but 117 or 188?) Editor expecting 127: cmdMap at: (127 + 1) put: #forwardDelete:. del key -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Flamel Update
Gisela why do you say that `anObject size. size should match a variable? you completely lost me there. Because `anObject should match self x tmp Stef
Re: [Pharo-dev] Flamel Update
ok I got it this is the difference between expression and method. Stef Gisela why do you say that `anObject size. size should match a variable? you completely lost me there. Because `anObject should match self x tmp Stef
Re: [Pharo-dev] Flamel Update
2013/8/6 Stéphane Ducasse stephane.duca...@inria.fr this is the difference between expression and method. Exactly, that's why I said that the current behavior for matching is confusing because nothing points you that I'm assuming that you are writing a pattern for a method. That example was on purpose just to show that... sometimes we give more logic to the semantics and the `name is just a variable name... And we have syntax-correct code but it's the contextual information that we are missing that completly change everything
Re: [Pharo-dev] moose build - pharo vm crash
Hi, here: Original Message Subject: Nice VM crash Date: Fri, 21 Jun 2013 18:37:18 +0100 From: Jan Vrany jan.vr...@fit.cvut.cz To: Pharo Development pharo-dev@lists.pharo.org Hi guys, getting bored? Looking for an excuse to play with GDB? Here we go: https://swing.fit.cvut.cz/jenkins/view/CalipeL/job/calipel_s_pharo20_benchmarks/label=Linux/19/console Okay, seriously: build 17 from Jun 17 did not crash - the Smalltalk code was the same. Jenkins executes following script: === export PATH=/usr/bin:$PATH IMAGE_BASE=CalipeL-S-$BUILD_NUMBER IMAGE=$IMAGE_BASE.image if [ ! -r Pharo.image ]; then wget -O- get.pharo.org | bash fi ./pharo Pharo.image save $IMAGE_BASE ./pharo $IMAGE config http://smalltalkhub.com/mc/JanVrany/CalipeL-S/main ConfigurationOfCalipeLS --install=0.1 ./pharo $IMAGE benchmark --json -o results.json BenchmarkMicro === System is running stock 32bit debian stable on VMWare ESX 5.1. I can provide more details if you like (and ask what exactly :-) Best, Jan And here: Original Message Subject: Re: Nice VM crash - UPDATE Date: Wed, 10 Jul 2013 14:24:58 +0100 From: Jan Vrany jan.vr...@fit.cvut.cz To: Pharo Development pharo-dev@lists.pharo.org, Eliot Miranda eliot.mira...@gmail.com Hi, a small update to my VM crash. Actually, sometimes it does not crash :-) (see [1] - the VM is the same all the time). My wild guess is some GC related problem, depending on timing and actual memory contents/layout, maybe? Cheers, Jan [1]: https://swing.fit.cvut.cz/jenkins/view/CalipeL/job/calipel_s_pharo20_benchmarks/ On 06/08/13 16:12, Esteban Lorenzano wrote: where is the report? On Aug 6, 2013, at 4:50 PM, Jan Vrany jan.vr...@fit.cvut.cz wrote: Hi Doru, join the club: https://swing.fit.cvut.cz/jenkins/view/CalipeL/job/calipel_s_pharo20_benchmarks/label=Linux/19/console I reported presumably same issue 21/06/13, update 10/07/13 :-) Best, Jan On 06/08/13 15:43, Tudor Girba wrote: Hi, It seems that the Moose build crashes the VM since yesterday evening due to a failing test. The image is based on Pharo 2.0 and is running a stable VM on Ubuntu. See some details here: https://ci.inria.fr/moose/job/Moose-latest-dev-4.8/804/console The script to reproduce the problem (on Ubuntu) is: #--- wget --quiet -O - http://get.pharo.org/20+vm | bash ./pharo Pharo.image save $JOB_NAME REPO=http://www.smalltalkhub.com/mc/Moose/Moose/main ./pharo $JOB_NAME.image config $REPO ConfigurationOfMoose --install=development ./pharo $JOB_NAME.image mooseimagesetup ./pharo $JOB_NAME.image moosetest --junit-xml-output mv ./pharo-vm/PharoV20.sources ./ zip $JOB_NAME.zip $JOB_NAME.image $JOB_NAME.changes PharoV20.sources #--- Cheers, Doru -- www.tudorgirba.com http://www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] moose build - pharo vm crash
where is the report? On Aug 6, 2013, at 4:50 PM, Jan Vrany jan.vr...@fit.cvut.cz wrote: Hi Doru, join the club: https://swing.fit.cvut.cz/jenkins/view/CalipeL/job/calipel_s_pharo20_benchmarks/label=Linux/19/console I reported presumably same issue 21/06/13, update 10/07/13 :-) Best, Jan On 06/08/13 15:43, Tudor Girba wrote: Hi, It seems that the Moose build crashes the VM since yesterday evening due to a failing test. The image is based on Pharo 2.0 and is running a stable VM on Ubuntu. See some details here: https://ci.inria.fr/moose/job/Moose-latest-dev-4.8/804/console The script to reproduce the problem (on Ubuntu) is: #--- wget --quiet -O - http://get.pharo.org/20+vm | bash ./pharo Pharo.image save $JOB_NAME REPO=http://www.smalltalkhub.com/mc/Moose/Moose/main ./pharo $JOB_NAME.image config $REPO ConfigurationOfMoose --install=development ./pharo $JOB_NAME.image mooseimagesetup ./pharo $JOB_NAME.image moosetest --junit-xml-output mv ./pharo-vm/PharoV20.sources ./ zip $JOB_NAME.zip $JOB_NAME.image $JOB_NAME.changes PharoV20.sources #--- Cheers, Doru -- www.tudorgirba.com http://www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] moose build - pharo vm crash
you know that what is not in the bug tracker does not exists? ;) I'm sorry, I want to take all problems into consideration, but I cannot make email archeology each time I'm going to tackle something :( https://pharo.fogbugz.com under project Pharo VM thanks, and do not hesitate on asking for an account if you need it :) Esteban On Aug 6, 2013, at 5:17 PM, Jan Vrany jan.vr...@fit.cvut.cz wrote: Hi, here: Original Message Subject: Nice VM crash Date: Fri, 21 Jun 2013 18:37:18 +0100 From: Jan Vrany jan.vr...@fit.cvut.cz To: Pharo Development pharo-dev@lists.pharo.org Hi guys, getting bored? Looking for an excuse to play with GDB? Here we go: https://swing.fit.cvut.cz/jenkins/view/CalipeL/job/calipel_s_pharo20_benchmarks/label=Linux/19/console Okay, seriously: build 17 from Jun 17 did not crash - the Smalltalk code was the same. Jenkins executes following script: === export PATH=/usr/bin:$PATH IMAGE_BASE=CalipeL-S-$BUILD_NUMBER IMAGE=$IMAGE_BASE.image if [ ! -r Pharo.image ]; then wget -O- get.pharo.org | bash fi ./pharo Pharo.image save $IMAGE_BASE ./pharo $IMAGE config http://smalltalkhub.com/mc/JanVrany/CalipeL-S/main ConfigurationOfCalipeLS --install=0.1 ./pharo $IMAGE benchmark --json -o results.json BenchmarkMicro === System is running stock 32bit debian stable on VMWare ESX 5.1. I can provide more details if you like (and ask what exactly :-) Best, Jan And here: Original Message Subject: Re: Nice VM crash - UPDATE Date: Wed, 10 Jul 2013 14:24:58 +0100 From: Jan Vrany jan.vr...@fit.cvut.cz To: Pharo Development pharo-dev@lists.pharo.org, Eliot Miranda eliot.mira...@gmail.com Hi, a small update to my VM crash. Actually, sometimes it does not crash :-) (see [1] - the VM is the same all the time). My wild guess is some GC related problem, depending on timing and actual memory contents/layout, maybe? Cheers, Jan [1]: https://swing.fit.cvut.cz/jenkins/view/CalipeL/job/calipel_s_pharo20_benchmarks/ On 06/08/13 16:12, Esteban Lorenzano wrote: where is the report? On Aug 6, 2013, at 4:50 PM, Jan Vrany jan.vr...@fit.cvut.cz wrote: Hi Doru, join the club: https://swing.fit.cvut.cz/jenkins/view/CalipeL/job/calipel_s_pharo20_benchmarks/label=Linux/19/console I reported presumably same issue 21/06/13, update 10/07/13 :-) Best, Jan On 06/08/13 15:43, Tudor Girba wrote: Hi, It seems that the Moose build crashes the VM since yesterday evening due to a failing test. The image is based on Pharo 2.0 and is running a stable VM on Ubuntu. See some details here: https://ci.inria.fr/moose/job/Moose-latest-dev-4.8/804/console The script to reproduce the problem (on Ubuntu) is: #--- wget --quiet -O - http://get.pharo.org/20+vm | bash ./pharo Pharo.image save $JOB_NAME REPO=http://www.smalltalkhub.com/mc/Moose/Moose/main ./pharo $JOB_NAME.image config $REPO ConfigurationOfMoose --install=development ./pharo $JOB_NAME.image mooseimagesetup ./pharo $JOB_NAME.image moosetest --junit-xml-output mv ./pharo-vm/PharoV20.sources ./ zip $JOB_NAME.zip $JOB_NAME.image $JOB_NAME.changes PharoV20.sources #--- Cheers, Doru -- www.tudorgirba.com http://www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] moose build - pharo vm crash
ah, but in this case... probably the latest vm already fixes that :) problem is that is still not stable (the vm) so we cannot release it, but well... we'll get there soon :) On Aug 6, 2013, at 5:36 PM, Esteban Lorenzano esteba...@gmail.com wrote: you know that what is not in the bug tracker does not exists? ;) I'm sorry, I want to take all problems into consideration, but I cannot make email archeology each time I'm going to tackle something :( https://pharo.fogbugz.com under project Pharo VM thanks, and do not hesitate on asking for an account if you need it :) Esteban On Aug 6, 2013, at 5:17 PM, Jan Vrany jan.vr...@fit.cvut.cz wrote: Hi, here: Original Message Subject: Nice VM crash Date: Fri, 21 Jun 2013 18:37:18 +0100 From: Jan Vrany jan.vr...@fit.cvut.cz To: Pharo Development pharo-dev@lists.pharo.org Hi guys, getting bored? Looking for an excuse to play with GDB? Here we go: https://swing.fit.cvut.cz/jenkins/view/CalipeL/job/calipel_s_pharo20_benchmarks/label=Linux/19/console Okay, seriously: build 17 from Jun 17 did not crash - the Smalltalk code was the same. Jenkins executes following script: === export PATH=/usr/bin:$PATH IMAGE_BASE=CalipeL-S-$BUILD_NUMBER IMAGE=$IMAGE_BASE.image if [ ! -r Pharo.image ]; then wget -O- get.pharo.org | bash fi ./pharo Pharo.image save $IMAGE_BASE ./pharo $IMAGE config http://smalltalkhub.com/mc/JanVrany/CalipeL-S/main ConfigurationOfCalipeLS --install=0.1 ./pharo $IMAGE benchmark --json -o results.json BenchmarkMicro === System is running stock 32bit debian stable on VMWare ESX 5.1. I can provide more details if you like (and ask what exactly :-) Best, Jan And here: Original Message Subject: Re: Nice VM crash - UPDATE Date: Wed, 10 Jul 2013 14:24:58 +0100 From: Jan Vrany jan.vr...@fit.cvut.cz To: Pharo Development pharo-dev@lists.pharo.org, Eliot Miranda eliot.mira...@gmail.com Hi, a small update to my VM crash. Actually, sometimes it does not crash :-) (see [1] - the VM is the same all the time). My wild guess is some GC related problem, depending on timing and actual memory contents/layout, maybe? Cheers, Jan [1]: https://swing.fit.cvut.cz/jenkins/view/CalipeL/job/calipel_s_pharo20_benchmarks/ On 06/08/13 16:12, Esteban Lorenzano wrote: where is the report? On Aug 6, 2013, at 4:50 PM, Jan Vrany jan.vr...@fit.cvut.cz wrote: Hi Doru, join the club: https://swing.fit.cvut.cz/jenkins/view/CalipeL/job/calipel_s_pharo20_benchmarks/label=Linux/19/console I reported presumably same issue 21/06/13, update 10/07/13 :-) Best, Jan On 06/08/13 15:43, Tudor Girba wrote: Hi, It seems that the Moose build crashes the VM since yesterday evening due to a failing test. The image is based on Pharo 2.0 and is running a stable VM on Ubuntu. See some details here: https://ci.inria.fr/moose/job/Moose-latest-dev-4.8/804/console The script to reproduce the problem (on Ubuntu) is: #--- wget --quiet -O - http://get.pharo.org/20+vm | bash ./pharo Pharo.image save $JOB_NAME REPO=http://www.smalltalkhub.com/mc/Moose/Moose/main ./pharo $JOB_NAME.image config $REPO ConfigurationOfMoose --install=development ./pharo $JOB_NAME.image mooseimagesetup ./pharo $JOB_NAME.image moosetest --junit-xml-output mv ./pharo-vm/PharoV20.sources ./ zip $JOB_NAME.zip $JOB_NAME.image $JOB_NAME.changes PharoV20.sources #--- Cheers, Doru -- www.tudorgirba.com http://www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Keyboard events is broken.
And the removal of the debugging code is here https://gitorious.org/cogvm/blessed/commit/9e2a77928edf0144f0d5c42ada66eb18918af64b/diffs/506febc8184dfd6c764d8d8fbc5b08dca8f998c0;) On Tue, Aug 6, 2013 at 5:47 PM, Guillermo Polito guillermopol...@gmail.comwrote: ah, forgot to say. Latest vms from jenkins should be ready in a while, not yet :). On Tue, Aug 6, 2013 at 5:46 PM, Guillermo Polito guillermopol...@gmail.com wrote: On Tue, Aug 6, 2013 at 4:53 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: thanks guillermo :) Cleaning events at VM level is important. Cleaning is not so easy :). I've been able to reproduce some of these problems (the delete key and the double keyUp:). I've tried to fix them, bah, actually I did in here, but I'd like someone else tests in their keyboard layouts in their homes :). Regarding the difference of the keyValues between keyUp and keyDown, I did not address it, and it kinda orthogonal, nothing to do with this particular issue. To see my changes, people can have a look at the diff in here: https://gitorious.org/cogvm/blessed/commit/2214cee58a5c5266b8ab2322b98471553b1b11c2/diffs/9e2a77928edf0144f0d5c42ada66eb18918af64b I'd like to start putting this in some issue tracker. Cog issue tracker or Pharo one? :) Esteban? On Aug 6, 2013, at 4:32 PM, Guillermo Polito guillermopol...@gmail.com wrote: On Tue, Aug 6, 2013 at 3:40 PM, Igor Stasenko siguc...@gmail.comwrote: I changed this method to see better what happens: HandMorph classshowDebugEvent: evt ShowEvents == true ifTrue: [ | ofs| Display fill: (0@0 extent: 500@120) rule: Form over fillColor: Color white. ofs := (owner hands indexOf: self) - 1 * 60. evt printString displayAt: (0@ofs) + (evt isKeyboard ifTrue: [0@30] ifFalse: [0@0]). self keyboardFocus printString displayAt: (0@ofs)+(0@45 ). evt isKeyboard ifTrue: [ Transcript show: evt printString;cr ] ]. KeyboardEvent printOn: aStream Print the receiver on a stream aStream nextPut: $[. aStream nextPutAll: type; nextPutAll: ' '''. self printKeyStringOn: aStream. aStream nextPut: $'. aStream space; nextPutAll: 'keyValue: ', self keyValue asString. aStream nextPut: $] set HandMorph showEvents:true Now, pressing single space, gives me this: [keyDown ' ' keyValue: 49] [keystroke ' ' keyValue: 32] [keyUp ' ' keyValue: 49] [keyUp ' ' keyValue: 49] Pressing delete key (or fn-backspace , for those who having a lot of spare fingers to use bad keyboards): [keyDown ' ' keyValue: 117] [keystroke '⌦' keyValue: 188] [keyUp ' ' keyValue: 117] [keyUp ' ' keyValue: 117] now, can someone tell me , why there is 2 keyUp events for each keyDown? That I don't know and of course, main question is why key values are different for keydown and keystroke events? That I'll dive right now into the vm to see what it is :). (and why delete key is not 127, but 117 or 188?) Editor expecting 127: cmdMap at: (127 + 1) put: #forwardDelete:. del key -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Keyboard events is broken.
On Tue, Aug 6, 2013 at 4:53 PM, Stéphane Ducasse stephane.duca...@inria.frwrote: thanks guillermo :) Cleaning events at VM level is important. Cleaning is not so easy :). I've been able to reproduce some of these problems (the delete key and the double keyUp:). I've tried to fix them, bah, actually I did in here, but I'd like someone else tests in their keyboard layouts in their homes :). Regarding the difference of the keyValues between keyUp and keyDown, I did not address it, and it kinda orthogonal, nothing to do with this particular issue. To see my changes, people can have a look at the diff in here: https://gitorious.org/cogvm/blessed/commit/2214cee58a5c5266b8ab2322b98471553b1b11c2/diffs/9e2a77928edf0144f0d5c42ada66eb18918af64b I'd like to start putting this in some issue tracker. Cog issue tracker or Pharo one? :) Esteban? On Aug 6, 2013, at 4:32 PM, Guillermo Polito guillermopol...@gmail.com wrote: On Tue, Aug 6, 2013 at 3:40 PM, Igor Stasenko siguc...@gmail.com wrote: I changed this method to see better what happens: HandMorph classshowDebugEvent: evt ShowEvents == true ifTrue: [ | ofs| Display fill: (0@0 extent: 500@120) rule: Form over fillColor: Color white. ofs := (owner hands indexOf: self) - 1 * 60. evt printString displayAt: (0@ofs) + (evt isKeyboard ifTrue: [0@30] ifFalse: [0@0]). self keyboardFocus printString displayAt: (0@ofs)+(0@45). evt isKeyboard ifTrue: [ Transcript show: evt printString;cr ] ]. KeyboardEvent printOn: aStream Print the receiver on a stream aStream nextPut: $[. aStream nextPutAll: type; nextPutAll: ' '''. self printKeyStringOn: aStream. aStream nextPut: $'. aStream space; nextPutAll: 'keyValue: ', self keyValue asString. aStream nextPut: $] set HandMorph showEvents:true Now, pressing single space, gives me this: [keyDown ' ' keyValue: 49] [keystroke ' ' keyValue: 32] [keyUp ' ' keyValue: 49] [keyUp ' ' keyValue: 49] Pressing delete key (or fn-backspace , for those who having a lot of spare fingers to use bad keyboards): [keyDown ' ' keyValue: 117] [keystroke '⌦' keyValue: 188] [keyUp ' ' keyValue: 117] [keyUp ' ' keyValue: 117] now, can someone tell me , why there is 2 keyUp events for each keyDown? That I don't know and of course, main question is why key values are different for keydown and keystroke events? That I'll dive right now into the vm to see what it is :). (and why delete key is not 127, but 117 or 188?) Editor expecting 127: cmdMap at: (127 + 1) put: #forwardDelete:. del key -- Best regards, Igor Stasenko.
Re: [Pharo-dev] moose build - pharo vm crash
Good, I can wait. It's not a show-stopper for me :-) On 06/08/13 16:37, Esteban Lorenzano wrote: ah, but in this case... probably the latest vm already fixes that :) problem is that is still not stable (the vm) so we cannot release it, but well... we'll get there soon :) On Aug 6, 2013, at 5:36 PM, Esteban Lorenzano esteba...@gmail.com wrote: you know that what is not in the bug tracker does not exists? ;) I'm sorry, I want to take all problems into consideration, but I cannot make email archeology each time I'm going to tackle something :( https://pharo.fogbugz.com under project Pharo VM thanks, and do not hesitate on asking for an account if you need it :) Esteban On Aug 6, 2013, at 5:17 PM, Jan Vrany jan.vr...@fit.cvut.cz wrote: Hi, here: Original Message Subject: Nice VM crash Date: Fri, 21 Jun 2013 18:37:18 +0100 From: Jan Vrany jan.vr...@fit.cvut.cz To: Pharo Development pharo-dev@lists.pharo.org Hi guys, getting bored? Looking for an excuse to play with GDB? Here we go: https://swing.fit.cvut.cz/jenkins/view/CalipeL/job/calipel_s_pharo20_benchmarks/label=Linux/19/console Okay, seriously: build 17 from Jun 17 did not crash - the Smalltalk code was the same. Jenkins executes following script: === export PATH=/usr/bin:$PATH IMAGE_BASE=CalipeL-S-$BUILD_NUMBER IMAGE=$IMAGE_BASE.image if [ ! -r Pharo.image ]; then wget -O- get.pharo.org | bash fi ./pharo Pharo.image save $IMAGE_BASE ./pharo $IMAGE config http://smalltalkhub.com/mc/JanVrany/CalipeL-S/main ConfigurationOfCalipeLS --install=0.1 ./pharo $IMAGE benchmark --json -o results.json BenchmarkMicro === System is running stock 32bit debian stable on VMWare ESX 5.1. I can provide more details if you like (and ask what exactly :-) Best, Jan And here: Original Message Subject: Re: Nice VM crash - UPDATE Date: Wed, 10 Jul 2013 14:24:58 +0100 From: Jan Vrany jan.vr...@fit.cvut.cz To: Pharo Development pharo-dev@lists.pharo.org, Eliot Miranda eliot.mira...@gmail.com Hi, a small update to my VM crash. Actually, sometimes it does not crash :-) (see [1] - the VM is the same all the time). My wild guess is some GC related problem, depending on timing and actual memory contents/layout, maybe? Cheers, Jan [1]: https://swing.fit.cvut.cz/jenkins/view/CalipeL/job/calipel_s_pharo20_benchmarks/ On 06/08/13 16:12, Esteban Lorenzano wrote: where is the report? On Aug 6, 2013, at 4:50 PM, Jan Vrany jan.vr...@fit.cvut.cz wrote: Hi Doru, join the club: https://swing.fit.cvut.cz/jenkins/view/CalipeL/job/calipel_s_pharo20_benchmarks/label=Linux/19/console I reported presumably same issue 21/06/13, update 10/07/13 :-) Best, Jan On 06/08/13 15:43, Tudor Girba wrote: Hi, It seems that the Moose build crashes the VM since yesterday evening due to a failing test. The image is based on Pharo 2.0 and is running a stable VM on Ubuntu. See some details here: https://ci.inria.fr/moose/job/Moose-latest-dev-4.8/804/console The script to reproduce the problem (on Ubuntu) is: #--- wget --quiet -O - http://get.pharo.org/20+vm | bash ./pharo Pharo.image save $JOB_NAME REPO=http://www.smalltalkhub.com/mc/Moose/Moose/main ./pharo $JOB_NAME.image config $REPO ConfigurationOfMoose --install=development ./pharo $JOB_NAME.image mooseimagesetup ./pharo $JOB_NAME.image moosetest --junit-xml-output mv ./pharo-vm/PharoV20.sources ./ zip $JOB_NAME.zip $JOB_NAME.image $JOB_NAME.changes PharoV20.sources #--- Cheers, Doru -- www.tudorgirba.com http://www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] moose build - pharo vm crash
Hi, On 06/08/13 16:36, Esteban Lorenzano wrote: you know that what is not in the bug tracker does not exists? ;) I'm sorry, I want to take all problems into consideration, but I cannot make email archeology each time I'm going to tackle something :( I completely understand and I certainly don't ask nor expect you to do so. https://pharo.fogbugz.com under project Pharo VM thanks, and do not hesitate on asking for an account if you need it :) I'm sorry but I'm so stupid that I couldn't figure out how to register last time I tried get an account. And, I have dot in my email address, apparently this is an issue too. Anyway, if I find time and courage, I'll certainly try again :-) Best, Jan Esteban On Aug 6, 2013, at 5:17 PM, Jan Vrany jan.vr...@fit.cvut.cz wrote: Hi, here: Original Message Subject: Nice VM crash Date: Fri, 21 Jun 2013 18:37:18 +0100 From: Jan Vrany jan.vr...@fit.cvut.cz To: Pharo Development pharo-dev@lists.pharo.org Hi guys, getting bored? Looking for an excuse to play with GDB? Here we go: https://swing.fit.cvut.cz/jenkins/view/CalipeL/job/calipel_s_pharo20_benchmarks/label=Linux/19/console Okay, seriously: build 17 from Jun 17 did not crash - the Smalltalk code was the same. Jenkins executes following script: === export PATH=/usr/bin:$PATH IMAGE_BASE=CalipeL-S-$BUILD_NUMBER IMAGE=$IMAGE_BASE.image if [ ! -r Pharo.image ]; then wget -O- get.pharo.org | bash fi ./pharo Pharo.image save $IMAGE_BASE ./pharo $IMAGE config http://smalltalkhub.com/mc/JanVrany/CalipeL-S/main ConfigurationOfCalipeLS --install=0.1 ./pharo $IMAGE benchmark --json -o results.json BenchmarkMicro === System is running stock 32bit debian stable on VMWare ESX 5.1. I can provide more details if you like (and ask what exactly :-) Best, Jan And here: Original Message Subject: Re: Nice VM crash - UPDATE Date: Wed, 10 Jul 2013 14:24:58 +0100 From: Jan Vrany jan.vr...@fit.cvut.cz To: Pharo Development pharo-dev@lists.pharo.org, Eliot Miranda eliot.mira...@gmail.com Hi, a small update to my VM crash. Actually, sometimes it does not crash :-) (see [1] - the VM is the same all the time). My wild guess is some GC related problem, depending on timing and actual memory contents/layout, maybe? Cheers, Jan [1]: https://swing.fit.cvut.cz/jenkins/view/CalipeL/job/calipel_s_pharo20_benchmarks/ On 06/08/13 16:12, Esteban Lorenzano wrote: where is the report? On Aug 6, 2013, at 4:50 PM, Jan Vrany jan.vr...@fit.cvut.cz wrote: Hi Doru, join the club: https://swing.fit.cvut.cz/jenkins/view/CalipeL/job/calipel_s_pharo20_benchmarks/label=Linux/19/console I reported presumably same issue 21/06/13, update 10/07/13 :-) Best, Jan On 06/08/13 15:43, Tudor Girba wrote: Hi, It seems that the Moose build crashes the VM since yesterday evening due to a failing test. The image is based on Pharo 2.0 and is running a stable VM on Ubuntu. See some details here: https://ci.inria.fr/moose/job/Moose-latest-dev-4.8/804/console The script to reproduce the problem (on Ubuntu) is: #--- wget --quiet -O - http://get.pharo.org/20+vm | bash ./pharo Pharo.image save $JOB_NAME REPO=http://www.smalltalkhub.com/mc/Moose/Moose/main ./pharo $JOB_NAME.image config $REPO ConfigurationOfMoose --install=development ./pharo $JOB_NAME.image mooseimagesetup ./pharo $JOB_NAME.image moosetest --junit-xml-output mv ./pharo-vm/PharoV20.sources ./ zip $JOB_NAME.zip $JOB_NAME.image $JOB_NAME.changes PharoV20.sources #--- Cheers, Doru -- www.tudorgirba.com http://www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Keyboard events is broken.
On 6 August 2013 17:47, Guillermo Polito guillermopol...@gmail.com wrote: ah, forgot to say. Latest vms from jenkins should be ready in a while, not yet :). yes, and that's why i want you to answer a following question: why you think the repository was named 'blessed' as in [1]? [1] https://gitorious.org/cogvm/blessed/ On Tue, Aug 6, 2013 at 5:46 PM, Guillermo Polito guillermopol...@gmail.com wrote: On Tue, Aug 6, 2013 at 4:53 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: thanks guillermo :) Cleaning events at VM level is important. Cleaning is not so easy :). I've been able to reproduce some of these problems (the delete key and the double keyUp:). I've tried to fix them, bah, actually I did in here, but I'd like someone else tests in their keyboard layouts in their homes :). Regarding the difference of the keyValues between keyUp and keyDown, I did not address it, and it kinda orthogonal, nothing to do with this particular issue. To see my changes, people can have a look at the diff in here: https://gitorious.org/cogvm/blessed/commit/2214cee58a5c5266b8ab2322b98471553b1b11c2/diffs/9e2a77928edf0144f0d5c42ada66eb18918af64b I'd like to start putting this in some issue tracker. Cog issue tracker or Pharo one? :) Esteban? On Aug 6, 2013, at 4:32 PM, Guillermo Polito guillermopol...@gmail.com wrote: On Tue, Aug 6, 2013 at 3:40 PM, Igor Stasenko siguc...@gmail.com wrote: I changed this method to see better what happens: HandMorph classshowDebugEvent: evt ShowEvents == true ifTrue: [ | ofs| Display fill: (0@0 extent: 500@120) rule: Form over fillColor: Color white. ofs := (owner hands indexOf: self) - 1 * 60. evt printString displayAt: (0@ofs) + (evt isKeyboard ifTrue: [0@30] ifFalse: [0@0]). self keyboardFocus printString displayAt: (0@ofs)+(0@45). evt isKeyboard ifTrue: [ Transcript show: evt printString;cr ] ]. KeyboardEvent printOn: aStream Print the receiver on a stream aStream nextPut: $[. aStream nextPutAll: type; nextPutAll: ' '''. self printKeyStringOn: aStream. aStream nextPut: $'. aStream space; nextPutAll: 'keyValue: ', self keyValue asString. aStream nextPut: $] set HandMorph showEvents:true Now, pressing single space, gives me this: [keyDown ' ' keyValue: 49] [keystroke ' ' keyValue: 32] [keyUp ' ' keyValue: 49] [keyUp ' ' keyValue: 49] Pressing delete key (or fn-backspace , for those who having a lot of spare fingers to use bad keyboards): [keyDown ' ' keyValue: 117] [keystroke '⌦' keyValue: 188] [keyUp ' ' keyValue: 117] [keyUp ' ' keyValue: 117] now, can someone tell me , why there is 2 keyUp events for each keyDown? That I don't know and of course, main question is why key values are different for keydown and keystroke events? That I'll dive right now into the vm to see what it is :). (and why delete key is not 127, but 117 or 188?) Editor expecting 127: cmdMap at: (127 + 1) put: #forwardDelete:. del key -- Best regards, Igor Stasenko. -- Best regards, Igor Stasenko.
Re: [Pharo-dev] moose build - pharo vm crash
yeah according to stack dump, this should be already fixed in new vms (once we fix other problems and release it) On 6 August 2013 17:17, Jan Vrany jan.vr...@fit.cvut.cz wrote: Hi, here: Original Message Subject: Nice VM crash Date: Fri, 21 Jun 2013 18:37:18 +0100 From: Jan Vrany jan.vr...@fit.cvut.cz To: Pharo Development pharo-dev@lists.pharo.org Hi guys, getting bored? Looking for an excuse to play with GDB? Here we go: https://swing.fit.cvut.cz/jenkins/view/CalipeL/job/calipel_s_pharo20_benchmarks/label=Linux/19/console Okay, seriously: build 17 from Jun 17 did not crash - the Smalltalk code was the same. Jenkins executes following script: === export PATH=/usr/bin:$PATH IMAGE_BASE=CalipeL-S-$BUILD_NUMBER IMAGE=$IMAGE_BASE.image if [ ! -r Pharo.image ]; then wget -O- get.pharo.org | bash fi ./pharo Pharo.image save $IMAGE_BASE ./pharo $IMAGE config http://smalltalkhub.com/mc/JanVrany/CalipeL-S/main ConfigurationOfCalipeLS --install=0.1 ./pharo $IMAGE benchmark --json -o results.json BenchmarkMicro === System is running stock 32bit debian stable on VMWare ESX 5.1. I can provide more details if you like (and ask what exactly :-) Best, Jan And here: Original Message Subject: Re: Nice VM crash - UPDATE Date: Wed, 10 Jul 2013 14:24:58 +0100 From: Jan Vrany jan.vr...@fit.cvut.cz To: Pharo Development pharo-dev@lists.pharo.org, Eliot Miranda eliot.mira...@gmail.com Hi, a small update to my VM crash. Actually, sometimes it does not crash :-) (see [1] - the VM is the same all the time). My wild guess is some GC related problem, depending on timing and actual memory contents/layout, maybe? Cheers, Jan [1]: https://swing.fit.cvut.cz/jenkins/view/CalipeL/job/calipel_s_pharo20_benchmarks/ On 06/08/13 16:12, Esteban Lorenzano wrote: where is the report? On Aug 6, 2013, at 4:50 PM, Jan Vrany jan.vr...@fit.cvut.cz wrote: Hi Doru, join the club: https://swing.fit.cvut.cz/jenkins/view/CalipeL/job/calipel_s_pharo20_benchmarks/label=Linux/19/console I reported presumably same issue 21/06/13, update 10/07/13 :-) Best, Jan On 06/08/13 15:43, Tudor Girba wrote: Hi, It seems that the Moose build crashes the VM since yesterday evening due to a failing test. The image is based on Pharo 2.0 and is running a stable VM on Ubuntu. See some details here: https://ci.inria.fr/moose/job/Moose-latest-dev-4.8/804/console The script to reproduce the problem (on Ubuntu) is: #--- wget --quiet -O - http://get.pharo.org/20+vm | bash ./pharo Pharo.image save $JOB_NAME REPO=http://www.smalltalkhub.com/mc/Moose/Moose/main ./pharo $JOB_NAME.image config $REPO ConfigurationOfMoose --install=development ./pharo $JOB_NAME.image mooseimagesetup ./pharo $JOB_NAME.image moosetest --junit-xml-output mv ./pharo-vm/PharoV20.sources ./ zip $JOB_NAME.zip $JOB_NAME.image $JOB_NAME.changes PharoV20.sources #--- Cheers, Doru -- www.tudorgirba.com http://www.tudorgirba.com Every thing has its own flow -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Keyboard events is broken.
On Tue, Aug 6, 2013 at 8:06 PM, Igor Stasenko siguc...@gmail.com wrote: On 6 August 2013 17:47, Guillermo Polito guillermopol...@gmail.com wrote: ah, forgot to say. Latest vms from jenkins should be ready in a while, not yet :). yes, and that's why i want you to answer a following question: why you think the repository was named 'blessed' as in [1]? I don't know... That some saint has come and blessed it? :) If not, point me to where it is explained, is there a wiki page or something? Igor, I do not know how to read that question. Now, really: - I thought that moving the VM repository to gitorious was meant to open it. If only a couple of people (lets say you, Camilo and Esteban) have the rights to commit, then I feel it defeats the purpose - Maybe I should make a pull-request, but you can see that there are three there, one for at least one year, waiting for integration and probably out of date [1] - to me one benefit of using a CVS is that it gives you the ability to revert and going back in the history, and there are not much commits in cog to traverse... So, if it is really broken we go back and there are no problems. Should I be afraid of committing something? - As Stef says, you only can break if you do... - Now, maybe I should continue not trying to fix some stuff in the vm if people get pissed off when using latest and a bug is found [1] https://gitorious.org/cogvm/blessed/merge_requests [1] https://gitorious.org/cogvm/blessed/ On Tue, Aug 6, 2013 at 5:46 PM, Guillermo Polito guillermopol...@gmail.com wrote: On Tue, Aug 6, 2013 at 4:53 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: thanks guillermo :) Cleaning events at VM level is important. Cleaning is not so easy :). I've been able to reproduce some of these problems (the delete key and the double keyUp:). I've tried to fix them, bah, actually I did in here, but I'd like someone else tests in their keyboard layouts in their homes :). Regarding the difference of the keyValues between keyUp and keyDown, I did not address it, and it kinda orthogonal, nothing to do with this particular issue. To see my changes, people can have a look at the diff in here: https://gitorious.org/cogvm/blessed/commit/2214cee58a5c5266b8ab2322b98471553b1b11c2/diffs/9e2a77928edf0144f0d5c42ada66eb18918af64b I'd like to start putting this in some issue tracker. Cog issue tracker or Pharo one? :) Esteban? On Aug 6, 2013, at 4:32 PM, Guillermo Polito guillermopol...@gmail.com wrote: On Tue, Aug 6, 2013 at 3:40 PM, Igor Stasenko siguc...@gmail.com wrote: I changed this method to see better what happens: HandMorph classshowDebugEvent: evt ShowEvents == true ifTrue: [ | ofs| Display fill: (0@0 extent: 500@120) rule: Form over fillColor: Color white. ofs := (owner hands indexOf: self) - 1 * 60. evt printString displayAt: (0@ofs) + (evt isKeyboard ifTrue: [0@30] ifFalse: [0@0]). self keyboardFocus printString displayAt: (0@ofs)+(0@45). evt isKeyboard ifTrue: [ Transcript show: evt printString;cr ] ]. KeyboardEvent printOn: aStream Print the receiver on a stream aStream nextPut: $[. aStream nextPutAll: type; nextPutAll: ' '''. self printKeyStringOn: aStream. aStream nextPut: $'. aStream space; nextPutAll: 'keyValue: ', self keyValue asString. aStream nextPut: $] set HandMorph showEvents:true Now, pressing single space, gives me this: [keyDown ' ' keyValue: 49] [keystroke ' ' keyValue: 32] [keyUp ' ' keyValue: 49] [keyUp ' ' keyValue: 49] Pressing delete key (or fn-backspace , for those who having a lot of spare fingers to use bad keyboards): [keyDown ' ' keyValue: 117] [keystroke '⌦' keyValue: 188] [keyUp ' ' keyValue: 117] [keyUp ' ' keyValue: 117] now, can someone tell me , why there is 2 keyUp events for each keyDown? That I don't know and of course, main question is why key values are different for keydown and keystroke events? That I'll dive right now into the vm to see what it is :). (and why delete key is not 127, but 117 or 188?) Editor expecting 127: cmdMap at: (127 + 1) put: #forwardDelete:. del key -- Best regards, Igor Stasenko. -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Keyboard events is broken.
I imagine that having a branch is the way to go. Like that esteban can integrate the fixes of eliot and you do not stress to finish. Once this is ready there is a merge. At least this is what I was thinking the process was: one main blessed stream several others at different level of maturity with the ultimate goal to avoid bottleneck. Stef On Tue, Aug 6, 2013 at 8:06 PM, Igor Stasenko siguc...@gmail.com wrote: On 6 August 2013 17:47, Guillermo Polito guillermopol...@gmail.com wrote: ah, forgot to say. Latest vms from jenkins should be ready in a while, not yet :). yes, and that's why i want you to answer a following question: why you think the repository was named 'blessed' as in [1]? I don't know... That some saint has come and blessed it? :) If not, point me to where it is explained, is there a wiki page or something? Igor, I do not know how to read that question. Now, really: - I thought that moving the VM repository to gitorious was meant to open it. If only a couple of people (lets say you, Camilo and Esteban) have the rights to commit, then I feel it defeats the purpose - Maybe I should make a pull-request, but you can see that there are three there, one for at least one year, waiting for integration and probably out of date [1] - to me one benefit of using a CVS is that it gives you the ability to revert and going back in the history, and there are not much commits in cog to traverse... So, if it is really broken we go back and there are no problems. Should I be afraid of committing something? - As Stef says, you only can break if you do... - Now, maybe I should continue not trying to fix some stuff in the vm if people get pissed off when using latest and a bug is found [1] https://gitorious.org/cogvm/blessed/merge_requests [1] https://gitorious.org/cogvm/blessed/ On Tue, Aug 6, 2013 at 5:46 PM, Guillermo Polito guillermopol...@gmail.com wrote: On Tue, Aug 6, 2013 at 4:53 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: thanks guillermo :) Cleaning events at VM level is important. Cleaning is not so easy :). I've been able to reproduce some of these problems (the delete key and the double keyUp:). I've tried to fix them, bah, actually I did in here, but I'd like someone else tests in their keyboard layouts in their homes :). Regarding the difference of the keyValues between keyUp and keyDown, I did not address it, and it kinda orthogonal, nothing to do with this particular issue. To see my changes, people can have a look at the diff in here: https://gitorious.org/cogvm/blessed/commit/2214cee58a5c5266b8ab2322b98471553b1b11c2/diffs/9e2a77928edf0144f0d5c42ada66eb18918af64b I'd like to start putting this in some issue tracker. Cog issue tracker or Pharo one? :) Esteban? On Aug 6, 2013, at 4:32 PM, Guillermo Polito guillermopol...@gmail.com wrote: On Tue, Aug 6, 2013 at 3:40 PM, Igor Stasenko siguc...@gmail.com wrote: I changed this method to see better what happens: HandMorph classshowDebugEvent: evt ShowEvents == true ifTrue: [ | ofs| Display fill: (0@0 extent: 500@120) rule: Form over fillColor: Color white. ofs := (owner hands indexOf: self) - 1 * 60. evt printString displayAt: (0@ofs) + (evt isKeyboard ifTrue: [0@30] ifFalse: [0@0]). self keyboardFocus printString displayAt: (0@ofs)+(0@45). evt isKeyboard ifTrue: [ Transcript show: evt printString;cr ] ]. KeyboardEvent printOn: aStream Print the receiver on a stream aStream nextPut: $[. aStream nextPutAll: type; nextPutAll: ' '''. self printKeyStringOn: aStream. aStream nextPut: $'. aStream space; nextPutAll: 'keyValue: ', self keyValue asString. aStream nextPut: $] set HandMorph showEvents:true Now, pressing single space, gives me this: [keyDown ' ' keyValue: 49] [keystroke ' ' keyValue: 32] [keyUp ' ' keyValue: 49] [keyUp ' ' keyValue: 49] Pressing delete key (or fn-backspace , for those who having a lot of spare fingers to use bad keyboards): [keyDown ' ' keyValue: 117] [keystroke '⌦' keyValue: 188] [keyUp ' ' keyValue: 117] [keyUp ' ' keyValue: 117] now, can someone tell me , why there is 2 keyUp events for each keyDown? That I don't know and of course, main question is why key values are different for keydown and keystroke events? That I'll dive right now into the vm to see what it is :). (and why delete key is not 127, but 117 or 188?) Editor expecting 127: cmdMap at: (127 + 1) put: #forwardDelete:. del key -- Best regards, Igor Stasenko. -- Best regards, Igor Stasenko.
Re: [Pharo-dev] [update 3.0] #30324
That's the default comment when the method is generated by Nautilus Ben On Aug 6, 2013, at 3:15 PM, Guillermo Polito guillermopol...@gmail.com wrote: I don't understand all those UsersManagerinitialize + Initialization code for UsersManager isn't that pretty obvious that the initialize method contains the initialization code? :P Or are they autogenerated or something? sorry for the silly question :) Guille On Tue, Aug 6, 2013 at 2:46 PM, Esteban Lorenzano esteba...@gmail.com wrote: 30324 - 11200 Repeated methods in superclasses, explicit requirement no implemented, repeated methods in traits https://pharo.fogbugz.com/f/cases/11200 (pass 2... fiuuu :P) Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Traits-EstebanLorenzano.554.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/ToolsTest-EstebanLorenzano.denker.53.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-EstebanLorenzano.1203.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Text-Edition-EstebanLorenzano.4.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tests-EstebanLorenzano.604.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Widgets-EstebanLorenzano.221.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Tools-EstebanLorenzano.124.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/SmartSuggestions-EstebanLorenzano.102.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Slot-EstebanLorenzano.368.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Shout-EstebanLorenzano.192.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/SUnit-UITesting-EstebanLorenzano.12.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/SUnit-Core-EstebanLorenzano.87.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Ring-Core-Kernel-EstebanLorenzano.130.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Regex-Core-EstebanLorenzano.24.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Tests-Critics-EstebanLorenzano.14.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Tests-Core-EstebanLorenzano.71.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Critics-EstebanLorenzano.50.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/RPackage-SystemIntegration-EstebanLorenzano.168.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-EstebanLorenzano.878.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Tools-Diff-EstebanLorenzano.98.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-TaskbarIcons-EstebanLorenzano.24.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/PackageInfo-EstebanLorenzano.105.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Nautilus-EstebanLorenzano.504.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/NativeBoost-Win32-EstebanLorenzano.37.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/NativeBoost-Mac-EstebanLorenzano.10.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/NativeBoost-Core-EstebanLorenzano.133.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/NOCompletion-EstebanLorenzano.38.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Examples-EstebanLorenzano.6.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-EstebanLorenzano.64.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Monticello-EstebanLorenzano.847.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Metacello-MC-EstebanLorenzano.670.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Metacello-Core-EstebanLorenzano.500.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Manifest-CriticBrowser-EstebanLorenzano.101.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Manifest-Core-EstebanLorenzano.149.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/KeyChain-EstebanLorenzano.47.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/KernelTests-EstebanLorenzano.540.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-EstebanLorenzano.1550.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/GroupManager-EstebanLorenzano.47.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Graphics-Primitives-EstebanLorenzano.106.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Gofer-Core-EstebanLorenzano.198.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/FileSystem-Core-EstebanLorenzano.106.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Compiler-EstebanLorenzano.510.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/CollectionsTests-EstebanLorenzano.619.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Unordered-EstebanLorenzano.162.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Strings-EstebanLorenzano.275.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Streams-EstebanLorenzano.142.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Sequenceable-EstebanLorenzano.149.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Abstract-EstebanLorenzano.218.diff
Re: [Pharo-dev] Keyboard events is broken.
ok, jumping in... :) so... there are some problems with the recommended approach. 1) having a branch/trunk whatever that contains just blessed versions in the meaning of stable is a nonsense. For that, is easier to have a zip somewhere. One thing that is complete wrong is to keep VMMaker version and Platform Sources separated. That's bad for many reasons, but the principal one is that we cannot TAG a version and be sure that everything, platform + vmmaker are in sync. 2) CI is built against blessed repository. Since we cannot know if a commit is ok (and therefore, blessed) until after the build is done and the tests are run (and green), one of both is wrong: - the repository is actually not blessed, or - the CI is taking bad sources (again, this can be solved by tagging, but well...) 3) at beginning of year we decided to take stable versions of VMs precisely to avoid this problems and give us time to stabilize. Now I understand people want to get over the SmallInteger bug, but well, we are all humans and our days is still 24hs. So, as a conclusion: - blessed, for me, does not means stable... is more like a trunk - working with pull requests would be ideal, but also time consuming, and no-one here has many of that, who put the bell in the cat's neck? - sure we can have branches for experiments, etc... but the key stuff is not that, is a very long time needed work (and for me, since is needed to build real key combinations, is also essential). - we really need to improve the process. First step is to have all sources in one single repository. - I would like to review the use we give to CI process, because IMHO, now we are using it more like a builder than a real continuous integration tool. Esteban out On Tue, Aug 6, 2013 at 9:51 PM, Guillermo Polito guillermopol...@gmail.comwrote: On Tue, Aug 6, 2013 at 9:33 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: I imagine that having a branch is the way to go. To me, a branch is a fork in the code. That is, you split and they evolve differently. If you want to tag a version as stable, you use a tag :). And git already supports all that. But we don't use it ;). However, branches make sense to me if we have for example - vm for pharo2 - vm for pharo3 - vm With that setup, in the pharo2 branch we can backport fixes from the pharo3 branch, but they may evolve differently. And more importantly, we do not need to maintain all the compatibility with the world. Whoever wants a pharo2 vm, they go to the pharo2 branch, which on release is freezed (as well as the image). Now, in Git, I do not think there is a need for having many repositories for that. It's enough with branches and tags... Like that esteban can integrate the fixes of eliot and you do not stress to finish. Yes, but esteban has already lots of things to do :). And every time I made a pull request, a had to push it myself into the main branch because if not, nobody did it. And ask Camillo, he was in the same situation... In the image side we have Stef, Marcus and Esteban that integrate fixes. In the vm side it's only Esteban :/. Once this is ready there is a merge. But that's what happen today, only the naming is bad in the git branch :). - We have a stable VM, which you can download as stable. That VM does not have the latest changes. I do not know if there is a tag, but there should be. - We have a unstable VM, which we call latest. It has the latest sources which we should test and prove before blessing it as the stable. At least this is what I was thinking the process was: one main blessed stream several others at different level of maturity with the ultimate goal to avoid bottleneck. Yes, but with that we lack also a good management of the issue tracking and stuff :). Above in this thread I was asking where do I submit an issue. Maybe we should put everything in the pharo issue tracker and be happy with only one tool. BTW, tomorrow I go to lille, we can discuss if you have some minutes :). Stef On Tue, Aug 6, 2013 at 8:06 PM, Igor Stasenko siguc...@gmail.com wrote: On 6 August 2013 17:47, Guillermo Polito guillermopol...@gmail.com wrote: ah, forgot to say. Latest vms from jenkins should be ready in a while, not yet :). yes, and that's why i want you to answer a following question: why you think the repository was named 'blessed' as in [1]? I don't know... That some saint has come and blessed it? :) If not, point me to where it is explained, is there a wiki page or something? Igor, I do not know how to read that question. Now, really: - I thought that moving the VM repository to gitorious was meant to open it. If only a couple of people (lets say you, Camilo and Esteban) have the rights to commit, then I feel it defeats the purpose - Maybe I should make a pull-request, but you can see that there are three there, one for at least one year, waiting for integration and probably out of date
