- Pharo-dev - lists.pharo.org

Re: [Pharo-project] why do we have methods with trailer EmbeddedSourceZip ?

by Igor Stasenko

On 24 August 2012 16:08, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 24 August 2012 15:49, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> >> >> On Fri, Aug 24, 2012 at 3:39 PM, Mariano Martinez Peck >> <marianopeck(a)gmail.com> wrote: >>> >>> >>> >>> On Thu, Aug 23, 2012 at 5:44 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> >>>> no idea :/ >>>> you can just resave them to go back to normal >>>> >>> >>> http://code.google.com/p/pharo/issues/detail?id=6599 >>> And now there is a test under ReleaseTest. So next time they are >>> generated, we should know in which update this test failed. >>> >> >> grrrr we have even more >> >> ((CompiledMethod allInstances select: [:each | (#(#NoTrailer #SourcePointer >> #VarLengthSourcePointer) includes: each trailer kind) not and: [ each >> isInstalled ] ])) size -> 18 >> > VarLengthSourcePointer is OK. > this source pointer is used for entries when .changes file goes over 32MB size. > NoTrailer is used for anonymous methods and methods which bypass the > logging their source into .changes file > for one or another reason (so, of course you cannot have pointer to > source , if you didn't stored the source in a first place). > ah, sorry, your code snippet was actually to show those methods which are NOT using those trailer kinds.. > -- > Best regards, > Igor Stasenko. -- Best regards, Igor Stasenko.

Aug. 24, 2012

Re: [Pharo-project] why do we have methods with trailer EmbeddedSourceZip ?

by Mariano Martinez Peck

On Fri, Aug 24, 2012 at 4:08 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 24 August 2012 15:49, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > > > > On Fri, Aug 24, 2012 at 3:39 PM, Mariano Martinez Peck > > <marianopeck(a)gmail.com> wrote: > >> > >> > >> > >> On Thu, Aug 23, 2012 at 5:44 PM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >>> > >>> no idea :/ > >>> you can just resave them to go back to normal > >>> > >> > >> http://code.google.com/p/pharo/issues/detail?id=6599 > >> And now there is a test under ReleaseTest. So next time they are > >> generated, we should know in which update this test failed. > >> > > > > grrrr we have even more > > > > ((CompiledMethod allInstances select: [:each | (#(#NoTrailer > #SourcePointer > > #VarLengthSourcePointer) includes: each trailer kind) not and: [ each > > isInstalled ] ])) size -> 18 > > > VarLengthSourcePointer is OK. > this source pointer is used for entries when .changes file goes over 32MB > size. > NoTrailer is used for anonymous methods and methods which bypass the > logging their source into .changes file > for one or another reason (so, of course you cannot have pointer to > source , if you didn't stored the source in a first place). > So, actually, we should not have NoTrailer for installed methods either. > > -- > Best regards, > Igor Stasenko. > > -- Mariano http://marianopeck.wordpress.com

Aug. 24, 2012

Re: [Pharo-project] [NB] Problem with releasing a NBExternalObject

by Sven Van Caekenberghe

Igor, On 24 Aug 2012, at 16:01, Igor Stasenko <siguctua(a)gmail.com> wrote: > this can be solved by adding an extra pharo-14-compat package and > writing a configuration > in a way that it will load that package in 1.4 but not in 2.0.. > but this is tedious, and frankly i didn't learned well, how to do that > trick with metacello. Next week we are going to build such a package (that adds methods to 1.3 or 1.4 so that lib writers can better follow new 2.0 api, I need it for Zn too). Sven

Aug. 24, 2012

Re: [Pharo-project] why do we have methods with trailer EmbeddedSourceZip ?

by Igor Stasenko

On 24 August 2012 15:49, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Fri, Aug 24, 2012 at 3:39 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: >> >> >> >> On Thu, Aug 23, 2012 at 5:44 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>> no idea :/ >>> you can just resave them to go back to normal >>> >> >> http://code.google.com/p/pharo/issues/detail?id=6599 >> And now there is a test under ReleaseTest. So next time they are >> generated, we should know in which update this test failed. >> > > grrrr we have even more > > ((CompiledMethod allInstances select: [:each | (#(#NoTrailer #SourcePointer > #VarLengthSourcePointer) includes: each trailer kind) not and: [ each > isInstalled ] ])) size -> 18 > VarLengthSourcePointer is OK. this source pointer is used for entries when .changes file goes over 32MB size. NoTrailer is used for anonymous methods and methods which bypass the logging their source into .changes file for one or another reason (so, of course you cannot have pointer to source , if you didn't stored the source in a first place). -- Best regards, Igor Stasenko.

Aug. 24, 2012

Re: [Pharo-project] [NB] Problem with releasing a NBExternalObject

by Igor Stasenko

On 24 August 2012 15:55, Jan van de Sandt <jvdsandt(a)gmail.com> wrote: > Hello Igor, > > Thanks for the explanation. Closing via the class method now works fine! > > But I still notice that the #finalizeResourceData doesn't get called. The > instance is already gone because the #allInstances method returns an empty > collection. Strange .... > i will write a test for finalization registry to see if it works.. should be working, but who knows :) > Jan. > > PS: I installed NB in a new 1.4 image this afternoon. Some tests failed > because the Integer>>#& method was missing. Probably is should be part of > the AsmJit-Extension package. After I added this method the tests worked > again. > rrrrrr.... this is because some very nice guy put those methods into Pharo 2.0 kernel. now things are messy, since in 1.4 you still need those methods as extension, but in 2.0 you don't need them, because if they present, loading NB will mark kernel package dirty :( this can be solved by adding an extra pharo-14-compat package and writing a configuration in a way that it will load that package in 1.4 but not in 2.0.. but this is tedious, and frankly i didn't learned well, how to do that trick with metacello. -- Best regards, Igor Stasenko.

Aug. 24, 2012

Re: [Pharo-project] [NB] Problem with releasing a NBExternalObject

by Jan van de Sandt

Hello Igor, Thanks for the explanation. Closing via the class method now works fine! But I still notice that the #finalizeResourceData doesn't get called. The instance is already gone because the #allInstances method returns an empty collection. Strange .... Jan. PS: I installed NB in a new 1.4 image this afternoon. Some tests failed because the Integer>>#& method was missing. Probably is should be part of the AsmJit-Extension package. After I added this method the tests worked again. On Fri, Aug 24, 2012 at 3:38 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 24 August 2012 14:54, Jan van de Sandt <jvdsandt(a)gmail.com> wrote: > > Hello, > > > > I have a subclass of NBExternalObject to refer to an external object > (from > > the ICU library). When I'm done with the object I need to close it. The > > following instance method takes care of this: > > > > primClose > > <primitive: #primitiveNativeCall module: #NativeBoostPlugin> > > self nbCall: #( void ucal_close( ICUCalendarNB self ) ) > > > > > > This works fine. But now I want to make use of the > NBExternalResourceManager > > so that external objects are closed automatically when they are no longer > > referenced. For this I have implemented the required instance method: > > > > resourceData > > > > ^ handle > > > > > > And the class methods: > > > > finalizeResourceData: aHandle > > > > Transcript show: 'Closing ', aHandle printString ; cr. > > aHandle isNull > > ifFalse: [ self primClose: aHandle ] > > > > > > and > > > > primClose: aHandle > > <primitive: #primitiveNativeCall module: #NativeBoostPlugin> > > ^ self nbCall: #( void ucal_close( void* aHandle ) ) > > > > > > > But now two things are going wrong: > > - The #finalizeResourceData: doesn't seem to get called > > perhaps because you still got a strong references to that object somewhere? > > > - If I call the #primClose: directy with the handle as an argument my > Image > > crashes. > > > Ok it looks like a typical mistake, (which i also do from time to time ;) > .. > by passing a pointer to value instead of value itself. > Here, a handle is a variable-byte object, holding a value (4 bytes) > so, if you pass it as argument of following type: > > void* aHandle > > you will actually not pass the value of handle itself, but a pointer > to a first byte in memory where that value held. > > To fix that try following: > > resourceData > ^ handle value > > primClose: aHandleValue > <primitive: #primitiveNativeCall module: #NativeBoostPlugin> > ^ self nbCall: #( void ucal_close( uint aHandleValue ) ) > > > > Is the signature of the #nbCall: message wrong? > > > > Jan. > > > > PS: I'm using the latest NB-Cog-VM from > > https://ci.lille.inria.fr/pharo/view/Cog/ > > > > > > > > > > > > -- > Best regards, > Igor Stasenko. > >

Aug. 24, 2012

Re: [Pharo-project] why do we have methods with trailer EmbeddedSourceZip ?

by Mariano Martinez Peck

On Fri, Aug 24, 2012 at 3:39 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Thu, Aug 23, 2012 at 5:44 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> no idea :/ >> you can just resave them to go back to normal >> >> > http://code.google.com/p/pharo/issues/detail?id=6599 > And now there is a test under ReleaseTest. So next time they are > generated, we should know in which update this test failed. > > grrrr we have even more ((CompiledMethod allInstances select: [:each | (#(#NoTrailer #SourcePointer #VarLengthSourcePointer) includes: each trailer kind) not and: [ each isInstalled ] ])) size -> 18 > > >> On 23 August 2012 16:15, Mariano Martinez Peck <marianopeck(a)gmail.com> >> wrote: >> > In Pharo 2.0 >> > >> > (CompiledMethod allInstances select: [:each | each trailer kind = >> > #EmbeddedSourceZip ]) size -> 15 >> > >> > (CompiledMethod allInstances select: [:each | each trailer kind = >> > #EmbeddedSourceZip ]) >> > >> > -> >> > >> > {(Dictionary>>#keysAndValuesDo: "a CompiledMethod(578289664)"). >> > (Morph>>#extent: "a CompiledMethod(691011584)"). (Morph>>#initialExtent >> "a >> > CompiledMethod(450101248)"). (Object>>#at:put: "a >> > CompiledMethod(784859136)"). (Object>>#printOn: "a >> > CompiledMethod(589299712)"). (Object>>#windowIsClosing "a >> > CompiledMethod(476839936)"). (Object>>#is: "a >> CompiledMethod(798752768)"). >> > (Object>>#at: "a CompiledMethod(660078592)"). (Object >> class>>#initialize "a >> > CompiledMethod(184549376)"). (Stream>>#nextPutAll: "a >> > CompiledMethod(881328128)"). (Stream>>#next: "a >> CompiledMethod(841744384)"). >> > (Stream>>#upToEnd "a CompiledMethod(483393536)"). >> (SystemWindow>>#delete "a >> > CompiledMethod(222035968)"). (SystemWindow>>#initialExtent "a >> > CompiledMethod(28835840)"). (SystemWindow>>#update: "a >> > CompiledMethod(521928704)")} >> > >> > Any idea why we have that instead of a regular one with a source >> pointer? >> > >> > >> > -- >> > Mariano >> > http://marianopeck.wordpress.com >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

Aug. 24, 2012

Re: [Pharo-project] [ANN] NativeBoost v 1.3

by Igor Stasenko

> To load NativeBoost you can follow an instructions on project page: > http://code.google.com/p/nativeboost/wiki/Installation -- Best regards, Igor Stasenko.

Aug. 24, 2012

Re: [Pharo-project] why do we have methods with trailer EmbeddedSourceZip ?

by Mariano Martinez Peck

On Thu, Aug 23, 2012 at 5:44 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > no idea :/ > you can just resave them to go back to normal > > http://code.google.com/p/pharo/issues/detail?id=6599 And now there is a test under ReleaseTest. So next time they are generated, we should know in which update this test failed. > On 23 August 2012 16:15, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > In Pharo 2.0 > > > > (CompiledMethod allInstances select: [:each | each trailer kind = > > #EmbeddedSourceZip ]) size -> 15 > > > > (CompiledMethod allInstances select: [:each | each trailer kind = > > #EmbeddedSourceZip ]) > > > > -> > > > > {(Dictionary>>#keysAndValuesDo: "a CompiledMethod(578289664)"). > > (Morph>>#extent: "a CompiledMethod(691011584)"). (Morph>>#initialExtent > "a > > CompiledMethod(450101248)"). (Object>>#at:put: "a > > CompiledMethod(784859136)"). (Object>>#printOn: "a > > CompiledMethod(589299712)"). (Object>>#windowIsClosing "a > > CompiledMethod(476839936)"). (Object>>#is: "a > CompiledMethod(798752768)"). > > (Object>>#at: "a CompiledMethod(660078592)"). (Object class>>#initialize > "a > > CompiledMethod(184549376)"). (Stream>>#nextPutAll: "a > > CompiledMethod(881328128)"). (Stream>>#next: "a > CompiledMethod(841744384)"). > > (Stream>>#upToEnd "a CompiledMethod(483393536)"). (SystemWindow>>#delete > "a > > CompiledMethod(222035968)"). (SystemWindow>>#initialExtent "a > > CompiledMethod(28835840)"). (SystemWindow>>#update: "a > > CompiledMethod(521928704)")} > > > > Any idea why we have that instead of a regular one with a source pointer? > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > > -- > Best regards, > Igor Stasenko. > > -- Mariano http://marianopeck.wordpress.com

Aug. 24, 2012

Re: [Pharo-project] [NB] Problem with releasing a NBExternalObject

by Igor Stasenko

On 24 August 2012 14:54, Jan van de Sandt <jvdsandt(a)gmail.com> wrote: > Hello, > > I have a subclass of NBExternalObject to refer to an external object (from > the ICU library). When I'm done with the object I need to close it. The > following instance method takes care of this: > > primClose > <primitive: #primitiveNativeCall module: #NativeBoostPlugin> > self nbCall: #( void ucal_close( ICUCalendarNB self ) ) > > > This works fine. But now I want to make use of the NBExternalResourceManager > so that external objects are closed automatically when they are no longer > referenced. For this I have implemented the required instance method: > > resourceData > > ^ handle > > > And the class methods: > > finalizeResourceData: aHandle > > Transcript show: 'Closing ', aHandle printString ; cr. > aHandle isNull > ifFalse: [ self primClose: aHandle ] > > > and > > primClose: aHandle > <primitive: #primitiveNativeCall module: #NativeBoostPlugin> > ^ self nbCall: #( void ucal_close( void* aHandle ) ) > > But now two things are going wrong: > - The #finalizeResourceData: doesn't seem to get called perhaps because you still got a strong references to that object somewhere? > - If I call the #primClose: directy with the handle as an argument my Image > crashes. > Ok it looks like a typical mistake, (which i also do from time to time ;) .. by passing a pointer to value instead of value itself. Here, a handle is a variable-byte object, holding a value (4 bytes) so, if you pass it as argument of following type: void* aHandle you will actually not pass the value of handle itself, but a pointer to a first byte in memory where that value held. To fix that try following: resourceData ^ handle value primClose: aHandleValue <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^ self nbCall: #( void ucal_close( uint aHandleValue ) ) > Is the signature of the #nbCall: message wrong? > > Jan. > > PS: I'm using the latest NB-Cog-VM from > https://ci.lille.inria.fr/pharo/view/Cog/ > > > > -- Best regards, Igor Stasenko.

Aug. 24, 2012