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

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

[Pharo-project] [ANN] NativeBoost v 1.3

by Igor Stasenko

Hi, all yesteray i committed new version of NativeBoost configuration. Some details about last few months changes: NativeBoost: - introduced a NBExternalTypeValue class - introduced a NBNativeFunction class, a reification of external function generated dynamically - introduced an NBExternalResourceManager and integration with other classes - a lot of cleanup and better comments - some updates to NativeBoost-Help package (currently it is not part of configuration by default, so you have to load this package manually from NB repository) AsmJit: - the package is split on several small packages + configuration to load it - more documentation - more nicer instruction printing output - fixed some instructions (some FPU / jump instructions was non-functional) - and a lot of effort by Camillo, who made x64 assembler working. (but we cannot use it with NB since our VMs is 32bit) To load NativeBoost you can follow an instructions on project page: -- Best regards, Igor Stasenko.

Aug. 24, 2012

Re: [Pharo-project] New Text Completion suggestions

by StÃ©phane Ducasse

> what Doru says makes sense... but in the other side, all the IDEs in the world use enter for completion. may be we are talking about difference change proposition/select one. > We should also welcome newcomers... so, I vote for enter or better, a configuration.

Aug. 24, 2012

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

by Jan van de Sandt

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 - If I call the #primClose: directy with the handle as an argument my Image crashes. 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/

Aug. 24, 2012

Re: [Pharo-project] New Text Completion suggestions

by Esteban A. Maringolo

EstebanLM wrote > > what Doru says makes sense... but in the other side, all the IDEs in the > world use enter for completion. > We should also welcome newcomers... so, I vote for enter or better, a > configuration. > +1 Good default +1 "presets" (vi, emacs, other dialects, etc). The first thing I did when moving from Squeak to Visual Age was to define Squeak shortcuts in VA (alt-m, alt-n, and so on). Then we've been developing several years with Dolphin, so we added its shortcuts even to VisualSmalltalk! I.e. I love Dolphin's debugger shortcuts, they're almost the same as the ones in Chrome's JS debugger, VisualStudio, an IE9 JS debugger. When debugging I don't have to think about it, i just press press F10 to step (or Shift+F10 to step through blocks) or F11 to step into. And it is almost the same in all the debuggers I use. Regards! -- View this message in context: http://forum.world.st/New-Text-Completion-suggestions-tp4645016p4645174.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 24, 2012