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

[Pharo-project] [ANN] NativeBoost v 1.7

by Igor Stasenko

Hi, there i'd like to announce new version of NativeBoost - 1.7. Here's an overview of changes comparing to previous version: - indirect argument in signatures. You can now use special syntax to indicate that argument to external function should be taken from n-th element of variable object (like Array) from method's argument or instance variable. Syntax: myMethod: args <primitive: .... > ^ self nbCall: #( void funFoo( int args@1 , float args@2 )) Usage: self myMethod: { 1 . 1.2 } Thanks to Ciprian Teodorov who proposed and implemented it. - Win32, features and examples: NBWin32Shell - an interface to use windows shell api (executing commands, showing control panel settings) different examples for using HDC, message box etc. Thanks to Torsten Bergmann for contribution! And last bits, from me: A public API changes to avoid use of NBFFICallout global, and instead use message(s) to denote FFI callout. Old syntax: NBFFICallout cdecl: #(...) emitCall: [ â¦ ] New syntax: self nbCallout function: #(â¦) emit: [â¦] Old syntax: NBFFICallout cdecl: #(...) module: .. New syntax: self nbCallout cdecl function: #(â¦) module: â¦ or: self nbCallout function: #(â¦) module: â¦ because cdecl is default Old syntax: NBFFICallout cdecl: #(...) module: .. options: #(â¦) New syntax: self nbCallout cdecl; options: #(â¦); function: #(â¦) module: â¦ Old syntax: NBFFICallout stdcall: #(...) module: .. options: #(â¦) New syntax: self nbCallout stdcall; options: #(â¦); function: #(â¦) module: â¦ ---- New API and syntax: self nbCallout function: <signature> address: [ address block ] generate code for calling a function located at given address with given signature. The address of function is provided by user in address block, which should return a pointer to the function (NBExternalAddress or Unsigned integer value, representing an absolute address of function). This API is useful, when you need to call some function which is not exported by via DLL symbol directly, but indirectly. The old NBFFICallout API is still there, but use of it is strongly discouraged. And it will be removed eventually. So be warned! :) -- Best regards, Igor Stasenko.

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 04:20, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> 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? no need to convince me. of course i can type it.. but most of the time you copy/paster it from method to method. -- Best regards, Igor Stasenko.

Nov. 26, 2012

Re: [Pharo-project] Internship

by Goubier Thierry

Le 23/11/2012 19:04, StÃ©phane Ducasse a Ã©crit : > thierry > > we will publish this offer. > Now did you look at dave mason work on C header parsing. Hi Stef, no I haven't but I can have a look if you had any pointer. I started doing C parsing out of Lex/Yacc and studying C implementations (pcc, gcc before 4.0, gcc 4+, CLANG/LLVM) and ocaml (CIL, Frama-C) (looked a bit at ANTLR as well). After a few years of C/Flex/Bison, I moved to Pharo/SMACC. One of my C-based parser has been modified for use in the toolchain of Kalray (http://www.kalray.eu/products/mppa-accesscore/) Thierry > Stef > > On Nov 22, 2012, at 3:42 PM, Goubier Thierry wrote: > >> Hi all, >> >> I'm looking for some help in parsing C files (and the opportunity to use Petit Parser (Parseur?)) so I'm looking for an internship candidate (Master level). >> >> The objective is to do a C preprocessor with a targeted integration in an existing C parser, and, in particular, provide high-level information about applied macros/defines for the tokens provided to the C parser itself. Platform should be Pharo (2.0:)). >> >> Place is Saclay, SW of Paris. The lab has a strong team on compilation tool chains for embedded manycores, from programming language design down to micro-kernel and mapping, and is able to select good interns for further work opportunities. >> >> http://www.cea.fr/ressources-humaines/stages-et-formation-en-alternance/les… >> >> Regards, >> >> Thierry >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Nov. 26, 2012

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