- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [NativeBoost] not happy with too many references to NBFFICallout & its public API

by Camillo Bruni

>> no need to hack the compiler >> - on the first call check if there is the primitive >> - if there is none, check if the method contains any other primitive >> - if not, add the primitive to the second line of the method sources >> - recompile the method with the same primitive >> - call that method again >> >> so you got a solution that works already now, I don't see what opal will >> add you here? >> > > what i was wanted to say that instead of using long cryptic string, > with opal i could use a very simple pragma , like <native>. > > modifying source code is a slippery road, with a lot of pitfalls down > the sides.... > i am one, who thinks that automatic tools should not interfere with > what author(s) > wanted to say. sure, but it's a solution that works for now and that can and should be changed once our infrastructure is ready. waiting for perfect solution is silly when you have something around the corner that will work.... > i prefer to leave source as it was written, but we can instruct the > compiler to insert primitive > once we discover that it is not there but without modifying source code. it's funny to see, but even when you gave your demo even you couldn't type the pragma definition yourself, so how do you except this to affect newcomers?

Nov. 26, 2012

Re: [Pharo-project] [NativeBoost] not happy with too many references to NBFFICallout & its public API

by Igor Stasenko

On 26 November 2012 01:35, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2012-11-25, at 21:28, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 25 November 2012 23:11, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> And don't forget to make the primitive declaration automatic, nobody can >>> remember that cryptic string :) >>> >> once we'll have opal on board.. not before that. i don't want to hack >> current compiler. > > no need to hack the compiler > - on the first call check if there is the primitive > - if there is none, check if the method contains any other primitive > - if not, add the primitive to the second line of the method sources > - recompile the method with the same primitive > - call that method again > > so you got a solution that works already now, I don't see what opal will > add you here? > what i was wanted to say that instead of using long cryptic string, with opal i could use a very simple pragma , like <native>. modifying source code is a slippery road, with a lot of pitfalls down the sides.... i am one, who thinks that automatic tools should not interfere with what author(s) wanted to say. i prefer to leave source as it was written, but we can instruct the compiler to insert primitive once we discover that it is not there but without modifying source code. -- Best regards, Igor Stasenko.

Nov. 26, 2012

Re: [Pharo-project] [NativeBoost] not happy with too many references to NBFFICallout & its public API

by Camillo Bruni

On 2012-11-25, at 21:28, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 25 November 2012 23:11, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> And don't forget to make the primitive declaration automatic, nobody can >> remember that cryptic string :) >> > once we'll have opal on board.. not before that. i don't want to hack > current compiler. no need to hack the compiler - on the first call check if there is the primitive - if there is none, check if the method contains any other primitive - if not, add the primitive to the second line of the method sources - recompile the method with the same primitive - call that method again so you got a solution that works already now, I don't see what opal will add you here?

Nov. 26, 2012

Re: [Pharo-project] [NativeBoost] not happy with too many references to NBFFICallout & its public API

by Igor Stasenko

On 25 November 2012 23:11, Camillo Bruni <camillobruni(a)gmail.com> wrote: > And don't forget to make the primitive declaration automatic, nobody can > remember that cryptic string :) > once we'll have opal on board.. not before that. i don't want to hack current compiler. > > On 2012-11-25, at 18:20, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 25 November 2012 21:59, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Igor your proposal looks nice. >>> >> it's not a proposal anymore.. >> i already made the changes :) >> >>> Stef >>> >>> On Nov 22, 2012, at 2:47 PM, Igor Stasenko wrote: >>> >>>> Hi, >>>> >>>> i am thinking about redesign of FFI top-level api, because it not very good. >>>> >>>> First thing is that NBFFICallout referenced in too many places (187 in >>>> my image). >>>> So, from one side, we should encourage using a convenience syntax, using >>>> >>>> self nbCall: .. >>>> instead of >>>> NBFFICallout ... >>>> >>>> but there's one more thing: >>>> - a code generator has many different ways of use, and i actually >>>> going to add another one, >>>> but i see that it will explode the protocol(s) without make it >>>> convenient to use. >>>> >>>> Imagine that you want to generate a callout to function, which address >>>> cannot be obtained directly from external library. >>>> This is actually a real issue, which Esteban met when implementing >>>> bindings to Chipmunk library: >>>> - some functions are not exposed directly by dynamic library, but indirectly: >>>> the symbol(s) which library exports is not direct pointer(s) to >>>> functions but instead >>>> a pointers to variable, where the function pointer is stored. >>>> So, in order to get function pointer , one needs first to get a >>>> pointer to symbol, and then read the pointer value at that address. >>>> >>>> So, i thought that i would simply add new protocol to NBFFICallout: >>>> >>>> call: anonFunctionSignature convention: callConvention >>>> functionAddress: aFunctionAddressBlock >>>> >>>> Then, one could use it like: >>>> >>>> myMethod >>>> <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode > >>>> >>>> ^ NBFFICallout >>>> call: #( int () ) >>>> convention: #cdecl functionAddress: [ self >>>> getPointerTo: 'functionname' ] >>>> >>>> but it is too elaborate.. >>>> you can imagine that if one would like to implement a more convenient >>>> form, he could just do: >>>> >>>> myMethod >>>> <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode > >>>> >>>> ^ self indirectCall: #( int () ) name: 'functionname' >>>> >>>> or even: >>>> >>>> myMethod >>>> <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode > >>>> >>>> ^ self indirectCall: #( int functionname () ) >>>> >>>> now the problem is that you cannot wrap the NBFFICallout method in >>>> order to implement convenience method, because of use of thisContext. >>>> >>>> I also concerned about exploding NBFFICallout public API.. which imo >>>> doesn't makes much sense, because we should encourage the use of >>>> convenience methods. >>>> >>>> So, i looking for improving public API: >>>> >>>> - First thing is getting rid of direct references to NBFFICallout.. >>>> - second thing is avoid tying public API with thisContext (so you can >>>> create own convenience methods without much hassle). >>>> >>>> So, lets imagine what and how we can do it: >>>> >>>> >>>> foo >>>> <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> >>>> >>>> ^ NBFFICallout cdecl: #( int foo() ) module: 'bar' >>>> >>>> 1. getting rid of global: >>>> >>>> foo >>>> <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> >>>> >>>> ^ self nbCallout cdecl: #( int foo() ) module: 'bar' >>>> >>>> 2. separating the call convention from signature: >>>> >>>> foo >>>> <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> >>>> >>>> ^ self nbCallout cdecl call: #( int foo() ) module: 'bar' >>>> >>>> 3. as a bonus, since cdecl is most used, we can assume it is default: >>>> >>>> foo >>>> <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> >>>> >>>> ^ self nbCallout call: #( int foo() ) module: 'bar' >>>> >>>> 4. avoid hardcoding module: >>>> >>>> foo >>>> <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> >>>> >>>> ^ self nbCallout call: #( int foo() ) module: self module >>>> >>>> 5. pass code generation options as a separate message, instead of >>>> additional keyword: >>>> >>>> foo >>>> <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> >>>> >>>> ^ self nbCallout >>>> options: #( +optFoo - optBar); >>>> call: #( int foo() ) module: self module >>>> >>>> 6. finally users would want to do it in most convenient way: >>>> >>>> foo >>>> <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> >>>> >>>> ^ self call: #( int foo() ) >>>> >>>> Which means that #call: is convenience method which they implement by >>>> themselves. >>>> Here how i think it should look like: >>>> >>>> call: fnSpec >>>> >>>> ^ (self nbCalloutIn: thisContext sender) >>>> cdecl; >>>> options: #(+optFoo - optBar); >>>> call: fnSpec module: self module. >>>> >>>> If you look at current implementation of Object>>nbCall: >>>> >>>> nbCall: fnSpec >>>> " you can override this method if you need to" >>>> >>>> | sender | >>>> sender := thisContext sender. >>>> >>>> ^ NBFFICallout >>>> handleFailureIn: sender >>>> nativeCode: [ :gen | >>>> gen >>>> sender: sender; >>>> callType: self nbCallingConvention; >>>> generateCall: fnSpec module: self nbLibraryNameOrHandle] >>>> >>>> it is almost the same, except from cryptic use of blocks, and private >>>> internal NBFFICallout methods which doing the job. >>>> >>>> So, basicly, i want to get rid of NBFFICallout class >> >>>> [cdecl/stdcall]: module: [options:] >>>> [cdecl/stdcall]: emitCall: [options:] >>>> >>>> and replace them with #call:module: and #call: emit: >>>> and also add new one: >>>> #call:address: >>>> >>>> which can be used for passing a function pointer directly. >>>> >>>> And any future extensions to public API will be a single method. Not >>>> 2,3 or more, like today.. >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

Nov. 26, 2012

Re: [Pharo-project] [NativeBoost] not happy with too many references to NBFFICallout & its public API

by Camillo Bruni

And don't forget to make the primitive declaration automatic, nobody can remember that cryptic string :) On 2012-11-25, at 18:20, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 25 November 2012 21:59, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Igor your proposal looks nice. >> > it's not a proposal anymore.. > i already made the changes :) > >> Stef >> >> On Nov 22, 2012, at 2:47 PM, Igor Stasenko wrote: >> >>> Hi, >>> >>> i am thinking about redesign of FFI top-level api, because it not very good. >>> >>> First thing is that NBFFICallout referenced in too many places (187 in >>> my image). >>> So, from one side, we should encourage using a convenience syntax, using >>> >>> self nbCall: .. >>> instead of >>> NBFFICallout ... >>> >>> but there's one more thing: >>> - a code generator has many different ways of use, and i actually >>> going to add another one, >>> but i see that it will explode the protocol(s) without make it >>> convenient to use. >>> >>> Imagine that you want to generate a callout to function, which address >>> cannot be obtained directly from external library. >>> This is actually a real issue, which Esteban met when implementing >>> bindings to Chipmunk library: >>> - some functions are not exposed directly by dynamic library, but indirectly: >>> the symbol(s) which library exports is not direct pointer(s) to >>> functions but instead >>> a pointers to variable, where the function pointer is stored. >>> So, in order to get function pointer , one needs first to get a >>> pointer to symbol, and then read the pointer value at that address. >>> >>> So, i thought that i would simply add new protocol to NBFFICallout: >>> >>> call: anonFunctionSignature convention: callConvention >>> functionAddress: aFunctionAddressBlock >>> >>> Then, one could use it like: >>> >>> myMethod >>> <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode > >>> >>> ^ NBFFICallout >>> call: #( int () ) >>> convention: #cdecl functionAddress: [ self >>> getPointerTo: 'functionname' ] >>> >>> but it is too elaborate.. >>> you can imagine that if one would like to implement a more convenient >>> form, he could just do: >>> >>> myMethod >>> <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode > >>> >>> ^ self indirectCall: #( int () ) name: 'functionname' >>> >>> or even: >>> >>> myMethod >>> <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode > >>> >>> ^ self indirectCall: #( int functionname () ) >>> >>> now the problem is that you cannot wrap the NBFFICallout method in >>> order to implement convenience method, because of use of thisContext. >>> >>> I also concerned about exploding NBFFICallout public API.. which imo >>> doesn't makes much sense, because we should encourage the use of >>> convenience methods. >>> >>> So, i looking for improving public API: >>> >>> - First thing is getting rid of direct references to NBFFICallout.. >>> - second thing is avoid tying public API with thisContext (so you can >>> create own convenience methods without much hassle). >>> >>> So, lets imagine what and how we can do it: >>> >>> >>> foo >>> <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> >>> >>> ^ NBFFICallout cdecl: #( int foo() ) module: 'bar' >>> >>> 1. getting rid of global: >>> >>> foo >>> <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> >>> >>> ^ self nbCallout cdecl: #( int foo() ) module: 'bar' >>> >>> 2. separating the call convention from signature: >>> >>> foo >>> <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> >>> >>> ^ self nbCallout cdecl call: #( int foo() ) module: 'bar' >>> >>> 3. as a bonus, since cdecl is most used, we can assume it is default: >>> >>> foo >>> <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> >>> >>> ^ self nbCallout call: #( int foo() ) module: 'bar' >>> >>> 4. avoid hardcoding module: >>> >>> foo >>> <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> >>> >>> ^ self nbCallout call: #( int foo() ) module: self module >>> >>> 5. pass code generation options as a separate message, instead of >>> additional keyword: >>> >>> foo >>> <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> >>> >>> ^ self nbCallout >>> options: #( +optFoo - optBar); >>> call: #( int foo() ) module: self module >>> >>> 6. finally users would want to do it in most convenient way: >>> >>> foo >>> <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> >>> >>> ^ self call: #( int foo() ) >>> >>> Which means that #call: is convenience method which they implement by >>> themselves. >>> Here how i think it should look like: >>> >>> call: fnSpec >>> >>> ^ (self nbCalloutIn: thisContext sender) >>> cdecl; >>> options: #(+optFoo - optBar); >>> call: fnSpec module: self module. >>> >>> If you look at current implementation of Object>>nbCall: >>> >>> nbCall: fnSpec >>> " you can override this method if you need to" >>> >>> | sender | >>> sender := thisContext sender. >>> >>> ^ NBFFICallout >>> handleFailureIn: sender >>> nativeCode: [ :gen | >>> gen >>> sender: sender; >>> callType: self nbCallingConvention; >>> generateCall: fnSpec module: self nbLibraryNameOrHandle] >>> >>> it is almost the same, except from cryptic use of blocks, and private >>> internal NBFFICallout methods which doing the job. >>> >>> So, basicly, i want to get rid of NBFFICallout class >> >>> [cdecl/stdcall]: module: [options:] >>> [cdecl/stdcall]: emitCall: [options:] >>> >>> and replace them with #call:module: and #call: emit: >>> and also add new one: >>> #call:address: >>> >>> which can be used for passing a function pointer directly. >>> >>> And any future extensions to public API will be a single method. Not >>> 2,3 or more, like today.. >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > > > > -- > Best regards, > Igor Stasenko. >

Nov. 25, 2012

Re: [Pharo-project] dumpfs - inspecting floating point numbers

by Tudor Girba

Hi Sven, I would be interested integrating something like this in the GTInspector, as well. I just have not much of an idea of what should be done :) Cheers, Doru On 25 Nov 2012, at 19:53, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 25 Nov 2012, at 18:11, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> Good idea >> >> 2012/11/25 Camillo Bruni <camillobruni(a)gmail.com>: >>> just adding a little custom inspector would do the job ;) >>> define Float>>#inspectorClass and add a new Inspector.. > > OK, I will try something simple to start with. -- www.tudorgirba.com "Speaking louder won't make the point worthier."

Nov. 25, 2012

Re: [Pharo-project] [NativeBoost] not happy with too many references to NBFFICallout & its public API

by Igor Stasenko

On 25 November 2012 21:59, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Igor your proposal looks nice. > it's not a proposal anymore.. i already made the changes :) > Stef > > On Nov 22, 2012, at 2:47 PM, Igor Stasenko wrote: > >> Hi, >> >> i am thinking about redesign of FFI top-level api, because it not very good. >> >> First thing is that NBFFICallout referenced in too many places (187 in >> my image). >> So, from one side, we should encourage using a convenience syntax, using >> >> self nbCall: .. >> instead of >> NBFFICallout ... >> >> but there's one more thing: >> - a code generator has many different ways of use, and i actually >> going to add another one, >> but i see that it will explode the protocol(s) without make it >> convenient to use. >> >> Imagine that you want to generate a callout to function, which address >> cannot be obtained directly from external library. >> This is actually a real issue, which Esteban met when implementing >> bindings to Chipmunk library: >> - some functions are not exposed directly by dynamic library, but indirectly: >> the symbol(s) which library exports is not direct pointer(s) to >> functions but instead >> a pointers to variable, where the function pointer is stored. >> So, in order to get function pointer , one needs first to get a >> pointer to symbol, and then read the pointer value at that address. >> >> So, i thought that i would simply add new protocol to NBFFICallout: >> >> call: anonFunctionSignature convention: callConvention >> functionAddress: aFunctionAddressBlock >> >> Then, one could use it like: >> >> myMethod >> <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode > >> >> ^ NBFFICallout >> call: #( int () ) >> convention: #cdecl functionAddress: [ self >> getPointerTo: 'functionname' ] >> >> but it is too elaborate.. >> you can imagine that if one would like to implement a more convenient >> form, he could just do: >> >> myMethod >> <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode > >> >> ^ self indirectCall: #( int () ) name: 'functionname' >> >> or even: >> >> myMethod >> <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode > >> >> ^ self indirectCall: #( int functionname () ) >> >> now the problem is that you cannot wrap the NBFFICallout method in >> order to implement convenience method, because of use of thisContext. >> >> I also concerned about exploding NBFFICallout public API.. which imo >> doesn't makes much sense, because we should encourage the use of >> convenience methods. >> >> So, i looking for improving public API: >> >> - First thing is getting rid of direct references to NBFFICallout.. >> - second thing is avoid tying public API with thisContext (so you can >> create own convenience methods without much hassle). >> >> So, lets imagine what and how we can do it: >> >> >> foo >> <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> >> >> ^ NBFFICallout cdecl: #( int foo() ) module: 'bar' >> >> 1. getting rid of global: >> >> foo >> <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> >> >> ^ self nbCallout cdecl: #( int foo() ) module: 'bar' >> >> 2. separating the call convention from signature: >> >> foo >> <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> >> >> ^ self nbCallout cdecl call: #( int foo() ) module: 'bar' >> >> 3. as a bonus, since cdecl is most used, we can assume it is default: >> >> foo >> <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> >> >> ^ self nbCallout call: #( int foo() ) module: 'bar' >> >> 4. avoid hardcoding module: >> >> foo >> <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> >> >> ^ self nbCallout call: #( int foo() ) module: self module >> >> 5. pass code generation options as a separate message, instead of >> additional keyword: >> >> foo >> <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> >> >> ^ self nbCallout >> options: #( +optFoo - optBar); >> call: #( int foo() ) module: self module >> >> 6. finally users would want to do it in most convenient way: >> >> foo >> <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> >> >> ^ self call: #( int foo() ) >> >> Which means that #call: is convenience method which they implement by >> themselves. >> Here how i think it should look like: >> >> call: fnSpec >> >> ^ (self nbCalloutIn: thisContext sender) >> cdecl; >> options: #(+optFoo - optBar); >> call: fnSpec module: self module. >> >> If you look at current implementation of Object>>nbCall: >> >> nbCall: fnSpec >> " you can override this method if you need to" >> >> | sender | >> sender := thisContext sender. >> >> ^ NBFFICallout >> handleFailureIn: sender >> nativeCode: [ :gen | >> gen >> sender: sender; >> callType: self nbCallingConvention; >> generateCall: fnSpec module: self nbLibraryNameOrHandle] >> >> it is almost the same, except from cryptic use of blocks, and private >> internal NBFFICallout methods which doing the job. >> >> So, basicly, i want to get rid of NBFFICallout class >> >> [cdecl/stdcall]: module: [options:] >> [cdecl/stdcall]: emitCall: [options:] >> >> and replace them with #call:module: and #call: emit: >> and also add new one: >> #call:address: >> >> which can be used for passing a function pointer directly. >> >> And any future extensions to public API will be a single method. Not >> 2,3 or more, like today.. >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

Nov. 25, 2012

Re: [Pharo-project] Morph on focus lost

by Sebastian Sastre

okay, for the record: 1. announcements are exclusive to instances and don't bubble through morph parents/owners* and 2. it works Pharo 2.0 only but I'm okay with that (I've ported the app from 1.4 in ~20min) thanks! sebastian o/ PD: BTW, that thing about making all morphs having its own announcer in the extension, great move! * sounds like it works like that as a feature, I just say it because I found most of the times is convenient that events "bubble" in any case adding bubble to morphs is as simple as: announce: anAnnouncement "Announces anAnnouncement from this morph and, if anAnnouncement is still bubbling, tell its parent to do the same" | aParent | self announcer announce: anAnnouncement. anAnnouncement isBubbling ifTrue:[ aParent := self getBubblingParent. aParent ifNotNil:[ aParent announce: anAnnouncement ]] On Nov 25, 2012, at 5:43 PM, Benjamin wrote: > morphToSpy announcer weak > on: MorphLostFocus send: #spyingMethod to: #spyingReceiver > > :) > > > Ben > On Nov 25, 2012, at 8:35 PM, Sebastian Sastre wrote: > >> Hi guys, >> >> quick question, >> >> what's the equivalent event of blur on morphs? >> >> What event you need to observe in a morph if you need to react to the focus lost in that morph? >> >> sebastian >> >> o/ >> >> >> >> >> >

Nov. 25, 2012

Re: [Pharo-project] [NativeBoost] not happy with too many references to NBFFICallout & its public API

by StÃ©phane Ducasse

Igor your proposal looks nice. Stef On Nov 22, 2012, at 2:47 PM, Igor Stasenko wrote: > Hi, > > i am thinking about redesign of FFI top-level api, because it not very good. > > First thing is that NBFFICallout referenced in too many places (187 in > my image). > So, from one side, we should encourage using a convenience syntax, using > > self nbCall: .. > instead of > NBFFICallout ... > > but there's one more thing: > - a code generator has many different ways of use, and i actually > going to add another one, > but i see that it will explode the protocol(s) without make it > convenient to use. > > Imagine that you want to generate a callout to function, which address > cannot be obtained directly from external library. > This is actually a real issue, which Esteban met when implementing > bindings to Chipmunk library: > - some functions are not exposed directly by dynamic library, but indirectly: > the symbol(s) which library exports is not direct pointer(s) to > functions but instead > a pointers to variable, where the function pointer is stored. > So, in order to get function pointer , one needs first to get a > pointer to symbol, and then read the pointer value at that address. > > So, i thought that i would simply add new protocol to NBFFICallout: > > call: anonFunctionSignature convention: callConvention > functionAddress: aFunctionAddressBlock > > Then, one could use it like: > > myMethod > <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode > > > ^ NBFFICallout > call: #( int () ) > convention: #cdecl functionAddress: [ self > getPointerTo: 'functionname' ] > > but it is too elaborate.. > you can imagine that if one would like to implement a more convenient > form, he could just do: > > myMethod > <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode > > > ^ self indirectCall: #( int () ) name: 'functionname' > > or even: > > myMethod > <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode > > > ^ self indirectCall: #( int functionname () ) > > now the problem is that you cannot wrap the NBFFICallout method in > order to implement convenience method, because of use of thisContext. > > I also concerned about exploding NBFFICallout public API.. which imo > doesn't makes much sense, because we should encourage the use of > convenience methods. > > So, i looking for improving public API: > > - First thing is getting rid of direct references to NBFFICallout.. > - second thing is avoid tying public API with thisContext (so you can > create own convenience methods without much hassle). > > So, lets imagine what and how we can do it: > > > foo > <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> > > ^ NBFFICallout cdecl: #( int foo() ) module: 'bar' > > 1. getting rid of global: > > foo > <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> > > ^ self nbCallout cdecl: #( int foo() ) module: 'bar' > > 2. separating the call convention from signature: > > foo > <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> > > ^ self nbCallout cdecl call: #( int foo() ) module: 'bar' > > 3. as a bonus, since cdecl is most used, we can assume it is default: > > foo > <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> > > ^ self nbCallout call: #( int foo() ) module: 'bar' > > 4. avoid hardcoding module: > > foo > <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> > > ^ self nbCallout call: #( int foo() ) module: self module > > 5. pass code generation options as a separate message, instead of > additional keyword: > > foo > <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> > > ^ self nbCallout > options: #( +optFoo - optBar); > call: #( int foo() ) module: self module > > 6. finally users would want to do it in most convenient way: > > foo > <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> > > ^ self call: #( int foo() ) > > Which means that #call: is convenience method which they implement by > themselves. > Here how i think it should look like: > > call: fnSpec > > ^ (self nbCalloutIn: thisContext sender) > cdecl; > options: #(+optFoo - optBar); > call: fnSpec module: self module. > > If you look at current implementation of Object>>nbCall: > > nbCall: fnSpec > " you can override this method if you need to" > > | sender | > sender := thisContext sender. > > ^ NBFFICallout > handleFailureIn: sender > nativeCode: [ :gen | > gen > sender: sender; > callType: self nbCallingConvention; > generateCall: fnSpec module: self nbLibraryNameOrHandle] > > it is almost the same, except from cryptic use of blocks, and private > internal NBFFICallout methods which doing the job. > > So, basicly, i want to get rid of NBFFICallout class >> > [cdecl/stdcall]: module: [options:] > [cdecl/stdcall]: emitCall: [options:] > > and replace them with #call:module: and #call: emit: > and also add new one: > #call:address: > > which can be used for passing a function pointer directly. > > And any future extensions to public API will be a single method. Not > 2,3 or more, like today.. > > > -- > Best regards, > Igor Stasenko. >

Nov. 25, 2012

Re: [Pharo-project] [Pharo-Project] About new TxText text model

by Igor Stasenko

On 25 November 2012 21:27, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Yes. you are right. It was bad password. > I not think about it because when I load code from smalltalkhub system was > ask me for password. But It was not check it correctness. > > I uploaded version with class comment and refactored tests. Good.! THanks a lot. > > 2012/11/25 Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> >> >> When i got a 400 Bad request it's because of wrong password. >> >> >> Ben >> >> On Nov 25, 2012, at 8:05 PM, StÃ©phane Ducasse wrote: >> >> > are you sure that you are using your account? >> > Because it happened to me too. >> > >> > Stef >> > >> > On Nov 25, 2012, at 3:08 PM, Denis Kudriashov wrote: >> > >> >> 2012/11/22 Igor Stasenko <siguctua(a)gmail.com> >> >>>> Hello. >> >>>> >> >>>> Can you add me as project contributor. I try to upload version with >> >>>> detailed comment from my first mail but can't. >> >>> >> >>> >> >>> My smalltalkhub nickname "dionisiy" >> >> >> >> done >> >> >> >> I try to commit version (with comment) but 400 bad request error >> >> raised. >> >> But I see myself as contributor at smalltalkhub project page. >> >> Any ideas? >> >> >> >> >> > >> > >> >> > -- Best regards, Igor Stasenko.

Nov. 25, 2012