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

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=ma… 1 regressions found. KernelTests.Numbers.NumberTest.testUnCategorizedMethods

June 27, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=li… 1 regressions found. KernelTests.Numbers.NumberTest.testUnCategorizedMethods

June 27, 2013

Re: [Pharo-dev] cleaning pasteUpMorph

by StÃ©phane Ducasse

We will have also to clarify the invariant between hands first and currentHand (pointing to the global ActiveHand). Stef On Jun 27, 2013, at 6:45 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > there is currentHand, primaryHandâ¦.. > and lovely code like that > > primaryHand > > | outer | > outer := self outermostWorldMorph ifNil: [^ nil]. > ^ outer activeHand ifNil: [outer firstHand]

June 27, 2013

cleaning pasteUpMorph

by StÃ©phane Ducasse

there is currentHand, primaryHandâ¦.. and lovely code like that primaryHand | outer | outer := self outermostWorldMorph ifNil: [^ nil]. ^ outer activeHand ifNil: [outer firstHand]

June 27, 2013

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

by StÃ©phane Ducasse

Igor we should document such mistakes This is important can you add such comments in class comment? On Jun 27, 2013, at 5:26 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 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] [update 3.0] #30228

by Marcus Denker

On Jun 27, 2013, at 6:09 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > â¦ old class builder tests might fail after this one. > They actually failed so hard that the build did bot succeedâ¦ we will try again tomorrow with a slice that removes the tests. > 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

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