October 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] we will rollback until 12160
by StÃ©phane Ducasse Oct. 1, 2010

Oct. 1, 2010

Hi guys sorry for the mess but the weakarray changes are putting the system on his knees. :) we cannot merge anymore. So I suggest that we rollback until 12160 and let igor happily fix it. Stef

1 0

Re: [Pharo-project] [update 1.2] #12161 - #12172
by StÃ©phane Ducasse Oct. 1, 2010

Oct. 1, 2010

Igor Can you have a look because right now in 12174 I cannot do any update anymore so - either we fix it now or we have to rollbakc to 12161. Thanks. On Oct 1, 2010, at 12:49 PM, Igor Stasenko wrote: > 2010/10/1 Levente Uzonyi <leves(a)elte.hu>: >> On Fri, 1 Oct 2010, Igor Stasenko wrote: >> >>> On 1 October 2010 12:06, Levente Uzonyi <leves(a)elte.hu> wrote: >>> On Fri, 1 Oct 2010, Marcus Denker wrote: >>> >>>> Issue 3002: A new finalization code ready for integration in Pharo >>>> Issue 3026: after 12172, sync with repository and reload >>> >>> If you didn't fix the migration code, then WeakFinalizationRegistry is >>> still >>> in the system. Details here: >>> >>> >>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-September/15400… >>> >> You mean this not work: >> Smalltalk forgetClass: #WeakFinalizationRegistry logged: false. >> >> should be >> Smalltalk forgetClass: WeakFinalizationRegistry logged: false. >> >> right? >> >> >> Yes. >> >> > Thanks for noticing. > >> Levente >> >>> >>> Levente >>> >>>> >>>> -- >>>> Marcus Denker -- http://www.marcusdenker.de >>>> INRIA Lille -- Nord Europe. Team RMoD. >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2 1

[Pharo-project] Fix of Create button in Debugger (#3010 and #3011)
by Luc Fabresse Oct. 1, 2010

Oct. 1, 2010

Hi all, We integrate the fix proposed by Hernan for #3010 and #3011. Hernan, thanks a lot for your fix proposal. Next time, just test it before on the latest Pharo (curently 1.2 and not 1.1) to make the integration easier. Thanks, Luc

1 0

[Pharo-project] PharoCorePackageDependenciesTests make tests with packages not presents in pharo 1.2
by Cyrille Delaunay Oct. 1, 2010

Oct. 1, 2010

Several tests from PharoCorePackageDependenciesTests raise errors because it specify packages not present in pharo 1.2: 'AST-Tests-Core' 'AST-Core' 'AST-Semantic' The error come from: referencesInPackageNamed: pkgNameAsString | pi | pi := PackageOrganizer default packageNamed: pkgNameAsString ifAbsent: [^ self]. .... The package is not found, therefore it returns 'self', later in the code we iterate on that 'self', it raise a DNU Message. Maybe rather that returning self, we should return a more explicit error so that we know directly where does the problem comes from? Anyway, I guess the main problem here is that the packages specified are not present in the image? I opened an issue:http://code.google.com/p/pharo/issues/detail?id=3033

1 0

Re: [Pharo-project] [Vm-dev] Re: is it possible to know the memory occupation (bytes) of an object?
by Mariano Martinez Peck Oct. 1, 2010

Oct. 1, 2010

Ok...I have just commited. If you want to review: http://code.google.com/p/pharo/issues/detail?id=3032 cheers Mariano On Tue, Sep 28, 2010 at 1:45 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Tue, Sep 28, 2010 at 11:11 AM, Henrik Johansen < > henrik.s.johansen(a)veloxit.no> wrote: > >> >> >> On Sep 28, 2010, at 9:36 27AM, Mariano Martinez Peck wrote: >> >> >> >> On Tue, Sep 28, 2010 at 6:46 AM, Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >>> >>> 2010/9/27 Eliot Miranda <eliot.miranda(a)gmail.com>: >>> > >>> > >>> > >>> > On Mon, Sep 27, 2010 at 12:20 PM, Mariano Martinez Peck < >>> marianopeck(a)gmail.com> wrote: >>> >> >>> >> >>> >> >>> >> >>> >> On Wed, Sep 22, 2010 at 12:34 PM, Mariano Martinez Peck < >>> marianopeck(a)gmail.com> wrote: >>> >>> >>> >>> >>> >>> On Wed, Sep 22, 2010 at 12:12 PM, Henrik Johansen < >>> henrik.s.johansen(a)veloxit.no> wrote: >>> >>>> >>> >>>> On Sep 22, 2010, at 9:59 40AM, Adrian Lienhard wrote: >>> >>>> >>> >>>> > Some notes: >>> >>>> > >>> >>>> > - What should be answered for small ints? 1 sizeInMemory -->8. >>> That's wrong. Shouldn't this answer 0? >>> >>>> >>> >>>> Philosophical question really, imo both 4 (Again, in 32bit images at >>> least) and 0 would be "correct" answers in their own ways. 8 is definitely >>> wrong though :) >>> >>>> The method comment should probably highlight which definition is >>> used. >>> >>>> >>> >> >>> >> >>> >> So....what should we consider for SmallInteger ? 4 bytes or 0 bytes? >>> > >>> > 0 bytes, obviously. The only space occupied by a SmallInteger is the >>> space of the slot containing it. There is no SmallInteger object beyond the >>> slot. >>> > >>> >>> Or from another POV, it's 4, the size of the slot. But we don't count >>> the size of the slots, they are already counted in the containing >>> object, that's why it should answer 0. >>> >> >> >> Thanks for the answers. I finally let this: >> >> sizeInMemory >> "Answer the number of bytes consumed by this instance including object >> header." >> | isCompact headerBytes contentBytes | >> >> "SmallInteger occupy 0 bytes since the only space occupied by a >> SmallInteger is the space of the slot containing it. There is no >> SmallInteger object beyond the slot. From another POV, it could be 4, the >> size of the slot. But we don't count the size of the slots, they are already >> counted in the containing object, that's why it should answer 0." >> (self isMemberOf: SmallInteger) ifTrue: [^0]. >> >> contentBytes := self class instSize * Smalltalk wordSize. "inst vars" >> >> self class isVariable ifTrue:[ |bytesPerElement| >> bytesPerElement := self class isBytes ifTrue: [1] ifFalse: >> [4]. >> contentBytes := contentBytes + (self basicSize * >> bytesPerElement)]. >> >> isCompact := self class indexIfCompact > 0. >> headerBytes := >> contentBytes > 255 >> ifTrue: [ 3 * Smalltalk wordSize ] >> ifFalse: [isCompact ifTrue: [Smalltalk wordSize] >> ifFalse: [2 * Smalltalk wordSize]]. >> ^ headerBytes + contentBytes >> >> >> Now I wonder...maybe instead of doing this it is easier to have a >> primitive that just calls #internalByteSize: ? >> The problem of course is that it needs changes in the vm... >> >> cheers >> >> Mariano >> >> >> isMemberOf: is so quaint... >> >> Why not >> SmallInteger>>sizeInMemory >> "SmallInteger occupy 0 bytes since the only space occupied by a >> SmallInteger is the space of the slot containing it. >> There is no SmallInteger object beyond the slot. >> From another POV, it could be 4, the size of the slot. But we don't >> count the size of the slots, they are already counted in the containing >> object, that's why it should answer 0." >> ^0 >> >> and remove that part from the Object implementation. >> >> > Uffff thanks Henrik for enlight me and teach me. Shame on me. I think that > too much paper writting, ppt and admin tasks are killing me :( > But don't worry, now I will come to code again! Hope to recover... :) > > > >> Cheers, >> Henry >> >> >

1 0

[Pharo-project] NativeBoost and Cog. A working protype.
by Igor Stasenko Oct. 1, 2010

Oct. 1, 2010

Hello, just wanna tell you that i adopted NativeBoost under Cog and have a first running prototype. It still lacks callbacks support, but its already can be used for callouts and to run native code. NativeBoost-CogPlugin does not requires patched for platform-specific code. Just load it into Cog VMMaker image, generate & build vm and you done! Thanks Eliot for providing necessary bits for controlling memory execution protection. The NativeBoost-CogPlugin will have some additional functionality, comparing to its Squeak VM cousin. - it using a primitive failure codes, so when primitive fails , you can determine why and where your native call fails. The primitive error codes still not handled/used by language side, so its a work to do: - a marchalling code can use error codes to report that primitive fails due to coercion error, and it even will tell which exactly argument failed to coerce. - of course, you will be able to add own custom error codes, and handle them as you like to. By default, a plugin could report following problems: "execution of native code is not enabled by plugin" ErrNotEnabled "failed to find a native code for primitive method" ErrNoNativeCodeInMethod "native code generated for different platform" ErrInvalidPlatformId I wanna say thanks to Eliot for providing primitive fail codes in VM. A proper error handling is an important part of infrastructure-level project (such as NativeBoost), since then people who using it, can quickly determine what's wrong with their code. -- Best regards, Igor Stasenko AKA sig.

8 16

[Pharo-project] [update 1.2] #12161 - #12172
by Marcus Denker Oct. 1, 2010

Oct. 1, 2010

Issue 3002: A new finalization code ready for integration in Pharo Issue 3026: after 12172, sync with repository and reload -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

3 4

[Pharo-project] [update 1.2] #12174
by Marcus Denker Oct. 1, 2010

Oct. 1, 2010

12174 ----- Issue 2713: Changelist deserves some fixes Issue 3030: Remove Explain... code (again) Issue 3023: change the initial windows position strategy Issue 3028: PluggableListMorphByItem >> getCurrentSelectionIndex access directly a non-initailized instance variable -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

Oct. 1, 2010

mariano can you open a bug entry. Stef On Sep 26, 2010, at 6:21 PM, Mariano Martinez Peck wrote: > Hi. I am loading OCompletion in PharoCore 1.1 while building the Dev image. If I just take a core image, load OCompletion and run tests, they take a lot of time, not acceptable. > > Now....if I build a Dev image (with OB, RB, etc) and at the end I try to run OCompletion tests, the tests takes HOURS. The image seems frozen, but actually is working. If I interrupt I see the problem is in > > ECUntypedModel >> initializeSelectors > > the part of > > > [ Smalltalk environment keysDo: > [ :each | > selectors add: (ECGlobalEntry > contents: each > type: #globalVar) ]. > > > takes a lot of time > > and it seems related to "ECPreferences caseSensitive" and "ECUntypedModel >> resetSelectors" > > I don't know what else to say. To reproduce, take a PharoCore 1.1 and evaluate: > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfOCompletion'; > load. > > (ConfigurationOfOCompletion project version: '1.2') load: 'Core Tests' > > Then, run all the tests inside OCompletionTests. You will see that after running some threads....it will look like frozen. There, do an interrupt and analize. > > IF you do that for a Dev image, it takes muuuuch more. I guess this is because "Smalltalk environment keys" will have muuuuuch more elements than a simple core. > > Anyway, help is appreciated. > > Cheers > > Mariano > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

5 15

Oct. 1, 2010

12173 ----- - Issue 3003: handleDisabledKey: is missing in Editor and subclasses - Issue 2963: systemOrganizer fixes. Thanks German Leiva and James Foester Stef

1 0