August 2012 - Pharo-dev - lists.pharo.org

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

by Igor Stasenko

On 24 August 2012 16:52, Jan van de Sandt <jvdsandt(a)gmail.com> wrote: > > > On Fri, Aug 24, 2012 at 4:29 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> 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 .... >> > >> btw did you added a call to #registerAsExternalResource >> in instance initialization method somewhere (once you have initialized >> handle of course)? >> because of course, if you don't register it, a finalization will never >> be called. >> > > Yes I did. If I inspect the registry instVar of > NBExternalResourceManager>>#soleInstance than there are a lot of items > present. > Okay, there is a bug indeed.. stupid wrong selector (as usual).. try replacing 'item finalize' with 'item finalizeValues' in NBFinalizationRegistry>>finalizeValues method i will upload a fix and tests meanwhile. Thanks for pointing out! -- Best regards, Igor Stasenko.

Aug. 24, 2012

[Pharo-project] [NB] Passing a null value to a const char* parameter

by Jan van de Sandt

Hello, NativeBoost doesn't allow me to pass a nil value instead of a String as a parameter for a 'const char*' function argument. When I use nil I get a failure with lastError=1 Is this by design? If so, is there an alternative? Jan.

Aug. 24, 2012

[Pharo-project] RGMethodDefininition

by Camillo Bruni

How can I figure out whether an RGMethodDefininition is coming from a Trait? method := (DatePrintFormatTester >> #shouldFix:). method origin isTrait "returns true". how can I do the same with Ring?

Aug. 24, 2012

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

by Jan van de Sandt

On Fri, Aug 24, 2012 at 4:29 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 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 .... > > > btw did you added a call to #registerAsExternalResource > in instance initialization method somewhere (once you have initialized > handle of course)? > because of course, if you don't register it, a finalization will never > be called. > > Yes I did. If I inspect the registry instVar of NBExternalResourceManager>>#soleInstance than there are a lot of items present. > > > 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. > >> > > > > > > -- > 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 .... > btw did you added a call to #registerAsExternalResource in instance initialization method somewhere (once you have initialized handle of course)? because of course, if you don't register it, a finalization will never be called. > 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. >> > -- Best regards, Igor Stasenko.

Aug. 24, 2012

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

by Igor Stasenko

On 24 August 2012 16:10, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > 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. > hard to say.. IIRC, by default a compiler generates the method with no trailer. and only after method's source is successfully logged the trailer kind is changed to be a source pointer. if there's an error happens which prevents method from being logged, i don't know how, but you still might have a method installed into class without being logged into .changes file. Also, if i remember there is places which ZAPs things, clean things, they also may clear the trailers. -- Best regards, Igor Stasenko.

Aug. 24, 2012

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