May 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] can or: be redefined?

by Marcus Denker

> On 30 Apr 2015, at 22:57, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 30 Apr 2015, at 21:47, stepharo <stepharo(a)free.fr> wrote: >> >> In nautilus I get an error MNU: RBBlockNode>>method >> When I select several groups and select merge >> >> >> mergeGroups: aCollection >> >> aCollection >> ifNotEmpty: [:groups || group | >> group := groups reduce: [:a :b | a or: [b]]. >> ^^^^^^^^^^^^ >> >> a is a dynamicClassGroup and its superclass defines or: >> > The mistake is the block around the b. > > or: in DynamicGroup is defined as > > or: aGroup > > and if you do not put a block, the compiler will not optimise or: â> it will be send. > (and the or: in DynamicGroup will just raise an error when it gets passed a block, it > expects a group). > > But there is a second error: the mustBeBooleanInMagic: normally should work. > (the VM executes the optimised construct â> raised an exception â> we recompile > the expression with no optimisation -> execute. > > There is tiny bug there (it should be #methodNode). > I will commit a fix for thatâ¦ > > (I hope this is understandable.. as two bugs are involved this might be a bit complex. > To make the whole thing easier to understand we need to distinguish the two bugs. 1) or: is somehow special. No, it is not. We fixed that, but the fix was broken. This is now fixed in 50026. 2) someone wrote or: [] where no block was supposed to be. The reason for that is lint rule RBIfTrueBlocksRule, which statically enforces blocks as parameters for all of or: and: and ifTrue:â¦ we should: - remove the [] in that method - remove the rule RBIfTrueBlocksRule as it makes no sense anymore, it is from a time when or: was special. DONE. Marcus

May 1, 2015

Re: [Pharo-dev] can or: be redefined?

by Marcus Denker

> On 01 May 2015, at 10:17, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 01 May 2015, at 10:10, stepharo <stepharo(a)free.fr> wrote: >> >> Clement >> >> thanks for the information. I thought about that. >> >> From a language perspective what you describe is plain bad. Implementation should not creep in the language semantics. > > Yes, this is why we implemented the #mustBebooleanMagic. > > It now just works: when the optimised contruct is used on a non-boolean, we recompile the expression and execute is > without optimization. > >> As a normal developer I do not want to know how I can redefine special optimized selectors. > > Yes, you canâ¦ this was the whole point of the mustBebooleanMagic machinery. Maybe I explain again. Historically, Smalltalk makes interpretation fast by cheating: come selectors are just hard coded into jumps. (ifTrue:, or: â¦). But not always (e.g. not when the parameter is not a block). This is very confusing. Therefore, we implemented a fall-back: when the VM executes the optimised construct on a non-boolean, it raises an exception. We catch that and just do what the expression was supposed to do: send the message. This means now there is no problem anymore in overriding all these. The problem has been fixed. Marcus

May 1, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50026 Home: https://github.com/pharo-project/pharo-core

May 1, 2015

[pharo-project/pharo-core] f707f5: 50026

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: f707f55ef5d8cd787ced538afba81e1b6088737f https://github.com/pharo-project/pharo-core/commit/f707f55ef5d8cd787ced538a… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-05-01 (Fri, 01 May 2015) Changed paths: A FileSystem-Core.package/AbstractFileReference.class/instance/accessing/basenameWithoutExtension_.st A FileSystem-Core.package/Path.class/instance/accessing/basenameWithoutExtension_.st M FileSystem-Tests-Core.package/FileReferenceTest.class/instance/tests/testBasenameWithoutExtension.st M FileSystem-Tests-Core.package/PathTest.class/instance/tests/testBasenameWithoutExtension.st M Morphic-Core.package/WorldState.class/class/world menu items/saveAs.st M OpalCompiler-Core.package/extension/RBBlockNode/instance/sourceNodeForPC_.st A OpalCompiler-Tests.package/MustBeBooleanTests.class/instance/as yet unclassified/testAnd.st A OpalCompiler-Tests.package/MustBeBooleanTests.class/instance/as yet unclassified/testOr.st R OpalCompiler-Tests.package/MyBooleanObject.class/instance/as yet unclassified/ifTrue_.st A OpalCompiler-Tests.package/MyBooleanObject.class/instance/controlling/and_.st A OpalCompiler-Tests.package/MyBooleanObject.class/instance/controlling/ifTrue_.st A OpalCompiler-Tests.package/MyBooleanObject.class/instance/controlling/or_.st A OpalCompiler-Tests.package/MyBooleanObject.class/instance/logical operations/not.st M RPackage-SystemIntegration.package/extension/String/instance/asPackage.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script634.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script635.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50025.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50026.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50026 15164 Misleading error message for nonexisting Package (String>>asPackage) https://pharo.fogbugz.com/f/cases/15164 15373 forward port 15322 "Save As" does not properly save filenames with dots in them, like "one.two" or "one.two.image" https://pharo.fogbugz.com/f/cases/15373 15458 fix #mustBeBoolean handling for #or: https://pharo.fogbugz.com/f/cases/15458 http://files.pharo.org/image/50/50026.zip

May 1, 2015

Re: [Pharo-dev] can or: be redefined?

by Marcus Denker

> On 01 May 2015, at 10:10, stepharo <stepharo(a)free.fr> wrote: > > Clement > > thanks for the information. I thought about that. > > From a language perspective what you describe is plain bad. Implementation should not creep in the language semantics. Yes, this is why we implemented the #mustBebooleanMagic. It now just works: when the optimised contruct is used on a non-boolean, we recompile the expression and execute is without optimization. > As a normal developer I do not want to know how I can redefine special optimized selectors. Yes, you canâ¦ this was the whole point of the mustBebooleanMagic machinery. Marcus

May 1, 2015

Re: [Pharo-dev] can or: be redefined?

by Marcus Denker

> On 01 May 2015, at 10:08, stepharo <stepharo(a)free.fr> wrote: > > Marcus we who > uld add a rule for the or: [b] > Not possible as it is correct if the receiver is a boolean. Marcus

May 1, 2015

Re: [Pharo-dev] can or: be redefined?

by stepharo

https://pharo.fogbugz.com/default.asp?15459

May 1, 2015

Re: [Pharo-dev] can or: be redefined?

by stepharo

Clement thanks for the information. I thought about that. From a language perspective what you describe is plain bad. Implementation should not creep in the language semantics. As a normal developer I do not want to know how I can redefine special optimized selectors. either the compiler should raise a warning when I redefine them or forbid it. As a normal developer I should not have to deal and understand such issues. Stef Le 30/4/15 22:31, ClÃ©ment Bera a Ã©crit : > You cannot easily redefine these selectors: > > #(#caseOf: #to:do: #ifNotNil: #ifNil:ifNotNil: #whileTrue: > #ifNotNil:ifNil: #ifFalse: #timesRepeat: #whileTrue #caseOf:otherwise: > #whileFalse: #ifNil: #to:by:do: #ifTrue: #ifFalse:ifTrue: #or: > #whileFalse #ifTrue:ifFalse: #and:) > > You can redefine those selectors but depending on the send site, the > redefined method is used or not. > > One trick is to have the send site in a method / class with > compilation options disabling the inlining of the selectors you want. > > Another trick is to use a pattern different slightly that the > optimized pattern, for example, I believe that Marcus changed #and: so: > a and: [ b ] -> and: is optimized at compile time, send site won't use > overridden method. > a and: [ :x | b ] -> and: is not optimized at compile time, send site > will use overridden method. > > Maybe it works with #or: too. > > > 2015-04-30 21:47 GMT+02:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > In nautilus I get an error MNU: RBBlockNode>>method > When I select several groups and select merge > > > mergeGroups: aCollection > > aCollection > ifNotEmpty: [:groups || group | > group := groups reduce: [:a :b | a or: [b]]. > ^^^^^^^^^^^^ > > a is a > dynamicClassGroup and its superclass defines or: > > groups do: [:gp | > gp removable > ifTrue: [self groupsManager > removeAGroupSilently: gp]]. > ^ group]. > ^ nil > > RBBlockNode(Object)>>doesNotUnderstand: #method > RBBlockNode>>sourceNodeForPC: > DynamicClassGroup(Object)>>mustBeBooleanInMagic: > DynamicClassGroup(Object)>>mustBeBoolean > [ :a :b | a or: [ b ] ] in [ :groups | > | group | > group := groups reduce: [ :a :b | a or: [ b ] ]. > groups > do: [ :gp | > gp removable > ifTrue: [ self groupsManager removeAGroupSilently: gp ] ]. > ^ group ] in PackageTreeNautilusUI(AbstractTool)>>mergeGroups: in > Block: [ :a :b | a or: [ b ] ] > [ :index | > arguments > replaceFrom: 2 > to: arguments size > with: self > startingAt: index; > at: 1 put: (aBlock valueWithArguments: arguments) ] in > Array(SequenceableCollection)>>reduceLeft: in Block: [ :index | ... > SmallInteger(Number)>>to:by:do: > Array(SequenceableCollection)>>reduceLeft: > Array(SequenceableCollection)>>reduce: > [ :groups | > | group | > group := groups reduce: [ :a :b | a or: [ b ] ]. > groups > do: [ :gp | > gp removable > ifTrue: [ self groupsManager removeAGroupSilently: gp ] ]. > ^ group ] in PackageTreeNautilusUI(AbstractTool)>>mergeGroups: in > Block: [ :groups | ... > BlockClosure>>cull: > Array(Collection)>>ifNotEmpty: > PackageTreeNautilusUI(AbstractTool)>>mergeGroups: > PackageTreeNautilusUI(AbstractNautilusUI)>>mergeGroups > [ target mergeGroups ] in AbstractNautilusUI class>>groupsMenu: in > Block: [ target mergeGroups ] > BlockClosure>>cull: > [ > | selArgCount | > "show cursor in case item opens a new MVC window" > (selArgCount := selector numArgs) = 0 > ifTrue: [ target perform: selector ] > ifFalse: [ > selArgCount = arguments size > ifTrue: [ target perform: selector withArguments: > arguments ] > ifFalse: [ target perform: selector withArguments: > (arguments copyWith: evt) ] ]. > self changed ] in > ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: in Block: [ ... > BlockClosure>>ensure: > CursorWithMask(Cursor)>>showWhile: > ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: > ToggleMenuItemMorph(MenuItemMorph)>>mouseUp: > ToggleMenuItemMorph(MenuItemMorph)>>handleMouseUp: > MouseButtonEvent>>sentTo: > ToggleMenuItemMorph(Morph)>>handleEvent: > MorphicEventDispatcher>>dispatchDefault:with: > MorphicEventDispatcher>>handleMouseUp: > MouseButtonEvent>>sentTo: > [ ^ anEvent sentTo: self ] in > MorphicEventDispatcher>>dispatchEvent:with: in Block: [ ^ anEvent > sentTo: self ] > BlockClosure>>ensure: > MorphicEventDispatcher>>dispatchEvent:with: > > >

May 1, 2015

Re: [Pharo-dev] can or: be redefined?

by stepharo

Marcus we should add a rule for the or: [b] Stef Le 30/4/15 22:57, Marcus Denker a Ã©crit : >> On 30 Apr 2015, at 21:47, stepharo <stepharo(a)free.fr> wrote: >> >> In nautilus I get an error MNU: RBBlockNode>>method >> When I select several groups and select merge >> >> >> mergeGroups: aCollection >> >> aCollection >> ifNotEmpty: [:groups || group | >> group := groups reduce: [:a :b | a or: [b]]. >> ^^^^^^^^^^^^ >> >> a is a dynamicClassGroup and its superclass defines or: >> > The mistake is the block around the b. > > or: in DynamicGroup is defined as > > or: aGroup > > and if you do not put a block, the compiler will not optimise or: â> it will be send. > (and the or: in DynamicGroup will just raise an error when it gets passed a block, it > expects a group). > > But there is a second error: the mustBeBooleanInMagic: normally should work. > (the VM executes the optimised construct â> raised an exception â> we recompile > the expression with no optimisation -> execute. > > There is tiny bug there (it should be #methodNode). > I will commit a fix for thatâ¦ > > (I hope this is understandable.. as two bugs are involved this might be a bit complex. > >> RBBlockNode(Object)>>doesNotUnderstand: #method >> RBBlockNode>>sourceNodeForPC: >> DynamicClassGroup(Object)>>mustBeBooleanInMagic: >> D > > Marcus >

May 1, 2015

Re: [Pharo-dev] can or: be redefined?

by stepharo

Thanks. Le 30/4/15 22:57, Marcus Denker a Ã©crit : >> On 30 Apr 2015, at 21:47, stepharo <stepharo(a)free.fr> wrote: >> >> In nautilus I get an error MNU: RBBlockNode>>method >> When I select several groups and select merge >> >> >> mergeGroups: aCollection >> >> aCollection >> ifNotEmpty: [:groups || group | >> group := groups reduce: [:a :b | a or: [b]]. >> ^^^^^^^^^^^^ >> >> a is a dynamicClassGroup and its superclass defines or: >> > The mistake is the block around the b. > > or: in DynamicGroup is defined as > > or: aGroup > > and if you do not put a block, the compiler will not optimise or: â> it will be send. > (and the or: in DynamicGroup will just raise an error when it gets passed a block, it > expects a group). > > But there is a second error: the mustBeBooleanInMagic: normally should work. > (the VM executes the optimised construct â> raised an exception â> we recompile > the expression with no optimisation -> execute. > > There is tiny bug there (it should be #methodNode). > I will commit a fix for thatâ¦ > > (I hope this is understandable.. as two bugs are involved this might be a bit complex. > >> RBBlockNode(Object)>>doesNotUnderstand: #method >> RBBlockNode>>sourceNodeForPC: >> DynamicClassGroup(Object)>>mustBeBooleanInMagic: >> D > > Marcus >

May 1, 2015