June 2013 - Pharo-dev - lists.pharo.org

[update 3.0] #30228

by Marcus Denker

â¦ old class builder tests might fail after this one. 30228 ----- 11047 Integrate new class builder step 2 https://pharo.fogbugz.com/f/cases/11047 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Support-MarcusDenker.8… http://smalltalkhub.com/mc/Pharo/Pharo30/main/SlotTests-MarcusDenker.24.diff

June 27, 2013

[update 3.0] #30227

by Marcus Denker

30227 ----- 10398 Integrate new class builder step 1 https://pharo.fogbugz.com/f/cases/10398 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Slot-MarcusDenker.317.diff

June 27, 2013

Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL

by Igor Stasenko

On 27 June 2013 17:14, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Jun 27, 2013, at 4:11 , Igor Stasenko wrote: > >> >>> Or is a disclaimer not to use the class for, say, 'char*' elements more >>> appropriate? >>> >> no , it should be fine. > > Was thinking of that in conjunction with putting ST object refs in the External arrays, the trying to pass as parameters, it could be a recipe for disaster :) > Like, say: > > "Add a null at end so ExternalArrays basic #readString won't keep on readin'" > string := 'Hello world!' copyWith: (Character value: 0). > extArray := (NBExternalArray ofType: 'char*') new: 1. > "Tenure the string first, lest we invalidate on next scavenge" > Smalltalk garbageCollectMost. > extArray at:1 put: string. > > "X our fingers, and hope GC doesn't move string. > Often serves as a nice example that it will :)" > (extArray at: 1) readString > string at: 7 put: $W. > (extArray at: 1) readString > hehe.. that certainly a recipe for disaster. That's why there should be no NBExternalValue>>address (pointing at Ciprian), which answers a pointer to oop's first byte, like that given test: testOutVoidArg |x value| NBTestExternalValue initialize. value := 12345678. x := NBTestExternalValue new. self outputVoidArg: x address value: value. self assert: x value = value. may work. But actually it will not. And this is **WRONG** in same way as your example. > Cheers, > Henry -- Best regards, Igor Stasenko.

June 27, 2013

Re: [Pharo-dev] Boolean

by Marcus Denker

On Jun 27, 2013, at 5:17 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Thu, 27 Jun 2013, Marcus Denker wrote: > >> >> On Jun 27, 2013, at 8:16 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >>> >>> In Pharo 3 we will support conditional optimized messages ( #ifTrue:, #ifFalse:, #ifTrue:ifFalse: and #ifFalse:ifTrue: ) sent on non boolean receiver. However, this feature will be slow, so one should not use it too much (as #become:, #isKindOf:, ...). Basically Opal compiles on the fly without optimizing it the conditional messageNode as a DoIt, run it, and jump in the context to the pc corresponding to the next ast node. We don't generate extra bytecode as you suggested, because it will grow the size of the image a lot and slow down the system with extra conditions. >>> >> >> It's actually not a lot of code. We need to debug/fix it for all the cases, though, this might add some more complexity: > > So Opal generates the same code as the old compiler. It's just a different implementation of #mustBeBoolean, what makes the difference. > IIUC whenever the receiver of the optimized conditional message is not true or false, the code is decompiled, then a new CompiledMethod is created without the optimization, it's injected onto the stack, and the execution is continued from before where the jumpTrue: or jumpFalse: was in the original method. > > As ClÃ©ment wrote, this is rather slow. Maybe even too slow to be useful. A possible improvement would be to permanently replace the original compiled method with the deoptimized one, since the receiver is likely to be not one of the unique Boolean instances during futher executions of the method. This way the decompilation has to be done only once. > Though these kind of code mutations behind the scene can cause some headache for someone who's trying to optimize the code. The question is if it makes sense to invest in these things on top of the current infrastructure. Marcus

June 27, 2013

[update 3.0] #30226

by Marcus Denker

30226 ----- 11030 #defaultLabel is uncategorized in Number https://pharo.fogbugz.com/f/cases/11030 11033 notObsolete IS obselete https://pharo.fogbugz.com/f/cases/11033 11034 HandMorph>>startUp should be removed https://pharo.fogbugz.com/f/cases/11034 11039 Start to define default values https://pharo.fogbugz.com/f/cases/11039 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Core-MarcusDenker.136.di… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-MarcusDenker.24.… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-MarcusDenker.1502.diff

June 27, 2013

Re: [Pharo-dev] Boolean

by Levente Uzonyi

On Thu, 27 Jun 2013, Marcus Denker wrote: > > On Jun 27, 2013, at 8:16 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> >> In Pharo 3 we will support conditional optimized messages ( #ifTrue:, #ifFalse:, #ifTrue:ifFalse: and #ifFalse:ifTrue: ) sent on non boolean receiver. However, this feature will be slow, so one should not use it too much (as #become:, #isKindOf:, ...). Basically Opal compiles on the fly without optimizing it the conditional messageNode as a DoIt, run it, and jump in the context to the pc corresponding to the next ast node. We don't generate extra bytecode as you suggested, because it will grow the size of the image a lot and slow down the system with extra conditions. >> > > It's actually not a lot of code. We need to debug/fix it for all the cases, though, this might add some more complexity: So Opal generates the same code as the old compiler. It's just a different implementation of #mustBeBoolean, what makes the difference. IIUC whenever the receiver of the optimized conditional message is not true or false, the code is decompiled, then a new CompiledMethod is created without the optimization, it's injected onto the stack, and the execution is continued from before where the jumpTrue: or jumpFalse: was in the original method. As ClÃ©ment wrote, this is rather slow. Maybe even too slow to be useful. A possible improvement would be to permanently replace the original compiled method with the deoptimized one, since the receiver is likely to be not one of the unique Boolean instances during futher executions of the method. This way the decompilation has to be done only once. Though these kind of code mutations behind the scene can cause some headache for someone who's trying to optimize the code. Levente > > mustBeBooleanInMagic: context > "Permits to redefine methods inlined by compiler. > Take the ast node corresponding to the mustBeBoolean error, compile it on the fly with Opal and executes it as a DoIt. Then resume the execution of the context." > > | proceedValue sendNode selector expression arguments methodNode method offset position | > context skipBackBeforeJump. > > sendNode := context sourceNode sourceNodeForPC: context pc. > position := sendNode irInstruction bytecodeOffset. > offset := sendNode irInstruction nextBytecodeOffsetAfterJump - position. > > expression := sendNode copy asSequenceNode transformLastToReturn. > selector := #ExecuteUnOptimzedIn:. arguments := {(RBVariableNode named:'ThisContext')}. > methodNode := RBMethodNode selector: selector arguments: arguments body: expression. > > context tempNames do: [:tempName | > methodNode :=methodNode rewriteTempNamedWrite: tempName forContext: context. > methodNode :=methodNode rewriteTempNamedRead: tempName forContext: context. > ]. > methodNode compilationContext: sendNode methodNode compilationContext. > methodNode compilationContext > class: UndefinedObject; > compilerOptions: #(+ optIlineNone). > > method := methodNode generateWithSource. > > context jump: offset. > > proceedValue := self withArgs: {context} executeMethod: method. > ^proceedValue > > >

June 27, 2013

Re: [Pharo-dev] looking at the code of PasteUpMorph

by StÃ©phane Ducasse

thanks a lot alain I confirm that it works. I will start pushing down behavior and try to remove all these worldstate ifNilâ¦. I would really appreciate if you can review my code because it is a sensitive area :). I will create an issue. In particular I would like to remove World global variable and create a singleton what do you think? Stef On Jun 27, 2013, at 9:46 AM, plantec <alain.plantec(a)yahoo.com> wrote: > Hi all, > > After a lot of freezes :) > To create a new world and make it be the current world, > thanks to PasteUpMorph>>install methods and to the MultiWorld code of sean (found in the bugtracker), > I've implemented PasteUpMorph>> beCurrentWorld. > Now I guess we are able to design a new clean world class and switch to it more smoothly :) > > PasteUpMorph subclass: #WorldMorph > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: 'Morphic-Worlds'. > (Smalltalk at: #WorldMorph) new beCurrentWorld. > > But, I don't understand everything. > maybe something is missing or bad. > maybe part of this code is not useful. > > It would be cool is someone could comment this code that we understand and make it cleaner. > > Thanks > Alain > > > ---------- > PasteUpMorph>> beCurrentWorld > | morphs | > owner := nil. > morphs := World submorphs. > Sensor > flushNonKbdEvents; > flushKeyboard; > flushEvents; > shutDown. > self class shutDown. > worldState := WorldState new. > self addHand: HandMorph new. > self borderWidth: 0. > self viewBox: Display boundingBox. > self borderWidth: 0. "default" > self color: self class defaultWorldColor. > self addAllMorphs: morphs. > SystemWindow noteTopWindowIn: self. > World := self. > ActiveWorld := self. > ActiveHand := self hands first. "default" > ActiveEvent := nil. > worldState handsDo: [:h | h releaseCachedState]. > Sensor startUp. > self class startUp. > self displayWorldSafely. > --------- > > > > > > Le 26 juin 2013 Ã 15:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> a Ã©crit : > >> Hi >> >> I think that it would be good to have >> >> PasteUpMorph (a morph in which we can drop morph) >> subclass World (the world = a morph in which we can drop morph and that have a worldstate) >> >> This would remove a lot of ifNil: everywhere. >> >> Stef >> >> > >

June 27, 2013

Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL

by Henrik Johansen

On Jun 27, 2013, at 4:11 , Igor Stasenko wrote: > >> Or is a disclaimer not to use the class for, say, 'char*' elements more >> appropriate? >> > no , it should be fine. Was thinking of that in conjunction with putting ST object refs in the External arrays, the trying to pass as parameters, it could be a recipe for disaster :) Like, say: "Add a null at end so ExternalArrays basic #readString won't keep on readin'" string := 'Hello world!' copyWith: (Character value: 0). extArray := (NBExternalArray ofType: 'char*') new: 1. "Tenure the string first, lest we invalidate on next scavenge" Smalltalk garbageCollectMost. extArray at:1 put: string. "X our fingers, and hope GC doesn't move string. Often serves as a nice example that it will :)" (extArray at: 1) readString string at: 7 put: $W. (extArray at: 1) readString Cheers, Henry

June 27, 2013

[update 3.0] #30225

by Marcus Denker

30225 ----- 11044 Undeclare ref to ConfigurationOfAthens https://pharo.fogbugz.com/f/cases/11044 11041 CompiledMethod class>>#cleanUp should embedd source in trailer https://pharo.fogbugz.com/f/cases/11041 11028 Fix a failing string test https://pharo.fogbugz.com/f/cases/11028 11045 Cannot use isSuper on RBProgramNode https://pharo.fogbugz.com/f/cases/11045 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-MarcusDenker.1501.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/CollectionsTests-MarcusDenker… http://smalltalkhub.com/mc/Pharo/Pharo30/main/AST-Core-MarcusDenker.171.diff

June 27, 2013

Re: [Pharo-dev] SqueakSource3 with new server name

by Martin Dias

June 27, 2013