- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo-users] How do can we set up a crowdsourcing for pharo

by Esteban Lorenzano

I told you: 2 man/month (not taking NB-FFI into account) On Jun 27, 2013, at 6:26 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > so much? > how many men/months? > > Stef > > On Jun 27, 2013, at 3:02 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 27 June 2013 14:16, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Hi >>> >>> we got this discussion about the VM on 64 bits so do we try to take the opportunity >>> to get a crowdsource donate button for it? >>> >>> Esteban/igor what is your estimate for such task? >>> >> >> depends what you put into it: >> - interpreter + plugins >> - new object/image format (64bit) >> - 64-bit jit >> >>> Stef >> >> >> -- >> Best regards, >> Igor Stasenko. >> > >

June 27, 2013

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

by StÃ©phane Ducasse

On Jun 2 > > Yes, you right. > (NBFFICallout new resolveType: 'byte*') valueSize => 1 > (NBFFICallout new resolveType: 'byte*') storageSize => 4 > > apparently, if one wants array with 'byte*' element type (or any other) > it should use a pointer size (4), not byte size (1) for it. > >> Or is a disclaimer not to use the class for, say, 'char*' elements more >> appropriate? >> > no , it should be fine. > The difference between valueSize and storageSize is a bit confusing, > and easy to confuse which to use.. > Perhaps they need different naming. +1 consider that people will use that during 10 years so good comments + names is KEY > There also stackSize, which means "how many bytes a value of given type > will take, if pushed on stack , and aligned accordingly" > > ... after some more investigation, i found that actually > storageSize should not be used. There is typeSize instead. > > So, the final expression should be: > > elementType := aTypeName. > elementSize := (NBFFICallout new requestor: self; resolveType: > elementType) typeSize. > > > and #sizeOf: method should also use typeSize apparently. > > >> Cheers, >> Henry > > > -- > Best regards, > Igor Stasenko. >

June 27, 2013

Re: [Pharo-dev] [Pharo-users] How do can we set up a crowdsourcing for pharo

by StÃ©phane Ducasse

so much? how many men/months? Stef On Jun 27, 2013, at 3:02 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 27 June 2013 14:16, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Hi >> >> we got this discussion about the VM on 64 bits so do we try to take the opportunity >> to get a crowdsource donate button for it? >> >> Esteban/igor what is your estimate for such task? >> > > depends what you put into it: > - interpreter + plugins > - new object/image format (64bit) > - 64-bit jit > >> Stef > > > -- > Best regards, > Igor Stasenko. >

June 27, 2013

Re: [Pharo-dev] Boolean

by Levente Uzonyi

On Thu, 27 Jun 2013, Marcus Denker wrote: > > 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. Not really, but it seems like you've already started implementing it. Levente > > Marcus >

June 27, 2013

[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