Re: [Pharo-users] NativeBoost replacement?

[Hernán Morales Durand]

Ok I could wait, I have a talk but in a couple of weeks and I want to show
Pharo 5 as backend.
Thanks for the reply and for taking care of this.

Cheers,

Hernan


2016-03-07 12:25 GMT-03:00 Esteban Lorenzano :

> so yes… UFFI is included in Pharo5, and the “official” replacement for NB.
> Now, NB had a lot of things that do not fit to what NB was (most of them
> were there originally as examples but they became alive…) the functionality
> you are looking for should be provided now by the package OSWindows (by
> Torsten).
>
> Torsten is working very hard to update his frameworks to Pharo 5.0
> (Thanks!)… this is good because he has tons of things windows-oriented and
> that works as test bed for the new UFFI :)
>
> Anyway… this was not finished but we made a pass today and now tests are
> green.
>
> If you can wait until tomorrow, most probably everything will be ready to
> use… if you really need to use it:
>
> http://smalltalkhub.com/#!/~TorstenBergmann/NOS (Notice that this
> repository is temporal until work is accepted and it merges back to
> official OSWindows repository).
> … and you need bleedingEdge of UFFI version to get it fully working :)
>
> cheers!
> Esteban
>
>
> On 07 Mar 2016, at 13:15, Hernán Morales Durand 
> wrote:
>
> Hi Cyril
>
> It seems the UFFI pre-loaded in the Pharo 5 does not include classes like
> "Win32Window" or NBMacShell, or contained methods.
> Are these features lost? Someone already working on that?
>
> Hernán
>
> 2016-03-07 3:46 GMT-03:00 Cyril Ferlicot :
>
>> I think that ffi-nb is now call uffi and is directly in the image.
>>
>> See: https://www.mail-archive.com/pharo-dev@lists.pharo.org/msg36699.html
>>
>>
>> On Sunday, 6 March 2016, Hernán Morales Durand 
>> wrote:
>>
>>> Hi Damien,
>>>
>>> I installed FFI-NB as follows:
>>>
>>> Gofer it
>>> smalltalkhubUser: 'Pharo' project: 'FFI-NB';
>>> configurationOf: 'FFINB';
>>> loadStable
>>>
>>> And found the following methods are missing from NBWin32Window:
>>>
>>>
>>> createWindowExA:lpClassName:lpWindowName:dwStyle:x:y:width:height:hWndParent:hMenu:hInstance:lParam:
>>>
>>> createWindowExW:lpClassName:lpWindowName:dwStyle:x:y:width:height:hWndParent:hMenu:hInstance:lParam:
>>> ffiCalloutOptions
>>> getActiveWindow
>>> getCapture
>>> getClipboardOwnerWindow
>>> getClipboardViewer
>>> getDesktopWindow
>>> getForegroundWindow
>>> getWindowFromPoint:
>>>
>>> Should I try something else?
>>>
>>> Hernán
>>>
>>>
>>>
>>> 2016-03-06 18:10 GMT-03:00 Damien Pollet 
>>> :
>>>
 The replacement is http://smalltalkhub.com/#!/~Pharo/FFI-NB

 The API should be mostly if not completely compatible. If not tell us,
 as I need to adapt my ESUG 2013 tutorial :)

 On 6 March 2016 at 21:18, Hernán Morales Durand <
 hernan.mora...@gmail.com> wrote:

> Hi guys,
>
> I am porting packages which uses NativeBoost in Pharo <= 4 to Pharo 5
> (update: #50628). Since NB is not supported anymore I would like to know
> which is the replacement of such library.
>
> I found FFI is loadable in Pharo 5, but methods like
> #getForegroundWindow are missing.
> Even worst, when I try to browse a method like
>
> #shellExecute:lpOperation:lpFile:lpPrameters:lpDirectory:nShowCmd:
>
> with any tool (Nautilus, Finder, etc) I get a MessageNotUnderstood:
> RubShoutStylerDecorator>>disableDrawingWhile:
>
> What's your recommendation?
>
> Cheers,
>
> Hernán
>
>

>>>
>>
>> --
>> Cheers
>> Cyril Ferlicot
>>
>>
>
>

Re: [Pharo-users] NativeBoost replacement?

[Cyril Ferlicot]

I think that ffi-nb is now call uffi and is directly in the image.

See: https://www.mail-archive.com/pharo-dev@lists.pharo.org/msg36699.html


On Sunday, 6 March 2016, Hernán Morales Durand 
wrote:

> Hi Damien,
>
> I installed FFI-NB as follows:
>
> Gofer it
> smalltalkhubUser: 'Pharo' project: 'FFI-NB';
> configurationOf: 'FFINB';
> loadStable
>
> And found the following methods are missing from NBWin32Window:
>
>
> createWindowExA:lpClassName:lpWindowName:dwStyle:x:y:width:height:hWndParent:hMenu:hInstance:lParam:
>
> createWindowExW:lpClassName:lpWindowName:dwStyle:x:y:width:height:hWndParent:hMenu:hInstance:lParam:
> ffiCalloutOptions
> getActiveWindow
> getCapture
> getClipboardOwnerWindow
> getClipboardViewer
> getDesktopWindow
> getForegroundWindow
> getWindowFromPoint:
>
> Should I try something else?
>
> Hernán
>
>
>
> 2016-03-06 18:10 GMT-03:00 Damien Pollet  >:
>
>> The replacement is http://smalltalkhub.com/#!/~Pharo/FFI-NB
>>
>> The API should be mostly if not completely compatible. If not tell us, as
>> I need to adapt my ESUG 2013 tutorial :)
>>
>> On 6 March 2016 at 21:18, Hernán Morales Durand > > wrote:
>>
>>> Hi guys,
>>>
>>> I am porting packages which uses NativeBoost in Pharo <= 4 to Pharo 5
>>> (update: #50628). Since NB is not supported anymore I would like to know
>>> which is the replacement of such library.
>>>
>>> I found FFI is loadable in Pharo 5, but methods like
>>> #getForegroundWindow are missing.
>>> Even worst, when I try to browse a method like
>>>
>>> #shellExecute:lpOperation:lpFile:lpPrameters:lpDirectory:nShowCmd:
>>>
>>> with any tool (Nautilus, Finder, etc) I get a MessageNotUnderstood:
>>> RubShoutStylerDecorator>>disableDrawingWhile:
>>>
>>> What's your recommendation?
>>>
>>> Cheers,
>>>
>>> Hernán
>>>
>>>
>>
>

-- 
Cheers
Cyril Ferlicot

Re: [Pharo-users] NativeBoost replacement?

[Damien Pollet]

Wait for Esteban to notice this mail :)

On 6 March 2016 at 23:54, Hernán Morales Durand 
wrote:

> Hi Damien,
>
> I installed FFI-NB as follows:
>
> Gofer it
> smalltalkhubUser: 'Pharo' project: 'FFI-NB';
> configurationOf: 'FFINB';
> loadStable
>
> And found the following methods are missing from NBWin32Window:
>
>
> createWindowExA:lpClassName:lpWindowName:dwStyle:x:y:width:height:hWndParent:hMenu:hInstance:lParam:
>
> createWindowExW:lpClassName:lpWindowName:dwStyle:x:y:width:height:hWndParent:hMenu:hInstance:lParam:
> ffiCalloutOptions
> getActiveWindow
> getCapture
> getClipboardOwnerWindow
> getClipboardViewer
> getDesktopWindow
> getForegroundWindow
> getWindowFromPoint:
>
> Should I try something else?
>
> Hernán
>
>
>
> 2016-03-06 18:10 GMT-03:00 Damien Pollet :
>
>> The replacement is http://smalltalkhub.com/#!/~Pharo/FFI-NB
>>
>> The API should be mostly if not completely compatible. If not tell us, as
>> I need to adapt my ESUG 2013 tutorial :)
>>
>> On 6 March 2016 at 21:18, Hernán Morales Durand > > wrote:
>>
>>> Hi guys,
>>>
>>> I am porting packages which uses NativeBoost in Pharo <= 4 to Pharo 5
>>> (update: #50628). Since NB is not supported anymore I would like to know
>>> which is the replacement of such library.
>>>
>>> I found FFI is loadable in Pharo 5, but methods like
>>> #getForegroundWindow are missing.
>>> Even worst, when I try to browse a method like
>>>
>>> #shellExecute:lpOperation:lpFile:lpPrameters:lpDirectory:nShowCmd:
>>>
>>> with any tool (Nautilus, Finder, etc) I get a MessageNotUnderstood:
>>> RubShoutStylerDecorator>>disableDrawingWhile:
>>>
>>> What's your recommendation?
>>>
>>> Cheers,
>>>
>>> Hernán
>>>
>>>
>>
>

Re: [Pharo-users] NativeBoost replacement?

[Hernán Morales Durand]

Hi Damien,

I installed FFI-NB as follows:

Gofer it
smalltalkhubUser: 'Pharo' project: 'FFI-NB';
configurationOf: 'FFINB';
loadStable

And found the following methods are missing from NBWin32Window:

createWindowExA:lpClassName:lpWindowName:dwStyle:x:y:width:height:hWndParent:hMenu:hInstance:lParam:
createWindowExW:lpClassName:lpWindowName:dwStyle:x:y:width:height:hWndParent:hMenu:hInstance:lParam:
ffiCalloutOptions
getActiveWindow
getCapture
getClipboardOwnerWindow
getClipboardViewer
getDesktopWindow
getForegroundWindow
getWindowFromPoint:

Should I try something else?

Hernán



2016-03-06 18:10 GMT-03:00 Damien Pollet :

> The replacement is http://smalltalkhub.com/#!/~Pharo/FFI-NB
>
> The API should be mostly if not completely compatible. If not tell us, as
> I need to adapt my ESUG 2013 tutorial :)
>
> On 6 March 2016 at 21:18, Hernán Morales Durand 
> wrote:
>
>> Hi guys,
>>
>> I am porting packages which uses NativeBoost in Pharo <= 4 to Pharo 5
>> (update: #50628). Since NB is not supported anymore I would like to know
>> which is the replacement of such library.
>>
>> I found FFI is loadable in Pharo 5, but methods like #getForegroundWindow
>> are missing.
>> Even worst, when I try to browse a method like
>>
>> #shellExecute:lpOperation:lpFile:lpPrameters:lpDirectory:nShowCmd:
>>
>> with any tool (Nautilus, Finder, etc) I get a MessageNotUnderstood:
>> RubShoutStylerDecorator>>disableDrawingWhile:
>>
>> What's your recommendation?
>>
>> Cheers,
>>
>> Hernán
>>
>>
>

[Pharo-users] NativeBoost replacement?

[Hernán Morales Durand]

Hi guys,

I am porting packages which uses NativeBoost in Pharo <= 4 to Pharo 5
(update: #50628). Since NB is not supported anymore I would like to know
which is the replacement of such library.

I found FFI is loadable in Pharo 5, but methods like #getForegroundWindow
are missing.
Even worst, when I try to browse a method like

#shellExecute:lpOperation:lpFile:lpPrameters:lpDirectory:nShowCmd:

with any tool (Nautilus, Finder, etc) I get a MessageNotUnderstood:
RubShoutStylerDecorator>>disableDrawingWhile:

What's your recommendation?

Cheers,

Hernán

Re: [Pharo-users] NativeBoost and variadic functions

[Igor Stasenko]

 
  And let me remind you that despite that NB implements FFI to speak with
 C,
  it is not obliged to implement features of C language itself. It lets you
  speak with C programs, but not lets you write programs like in C (see the
  difference? :)

 I wasn't implying that implicit type conversion was a good thing that
 needed implementing -- but just a bump if it hadn't needed attention
 to it before when C did it automagically.
 cheers -ben


Of course, Ben,  i understand that you may miss some of the feature(s), you
get used to when doing things in C.
But then consider what is involved to implement such feature because it
means determining argument types at run time (at compile time it is
impossible as well as 'compile once when it is invoked for the first time'
that NB does )
That means that no matter how well you try, the implementation will suck..
because it will be very slow comparing to one that uses fixed-type
fixed-argument number.

My philosophy , in general, for programming is avoid bloat and inefficiency
at all costs. When some feature requires bloat and going to be very
inefficient, i simply saying 'No'.
Especially at infrastructural level, which NB belongs to.
Because one thing that you (of me) as implementer knows what is fast  cool
and what is slow  inefficient, but then users come and start using things
in a way you would never think your stuff will be ever used.. and start
spreading inefficiency in their project(s). And more that that, once they
get used to it, then you would be never able to remove it because it is
there and everyone using it and some even loving it :)


-- 
Best regards,
Igor Stasenko.

Re: [Pharo-users] NativeBoost and variadic functions

[Ben Coman]

On Mon, Jul 27, 2015 at 9:56 PM, Igor Stasenko siguc...@gmail.com wrote:


 And let me remind you that despite that NB implements FFI to speak with
 C, it is not obliged to implement features of C language itself. It lets
 you speak with C programs, but not lets you write programs like in C (see
 the difference? :)

 I wasn't implying that implicit type conversion was a good thing that
 needed implementing -- but just a bump if it hadn't needed attention
 to it before when C did it automagically.
 cheers -ben


 Of course, Ben,  i understand that you may miss some of the feature(s), you
 get used to when doing things in C.

Sorry I wasn't clear so just to emphasise, I agree NB should not
implement such a feature. I was trying to say just that it should be
explicit**  that implicit type conversions are not supported.  A lot
of programmers at various levels of experience not very aware of
implicit type conversions will probably be bitten by the same error.
So to avoid the bites, I guess we need to teach this bit of C when
teaching NB.

** perhaps with an example demonstrating it, but I don't know what
that might be.

cheers -ben

 But then consider what is involved to implement such feature because it
 means determining argument types at run time (at compile time it is
 impossible as well as 'compile once when it is invoked for the first time'
 that NB does )
 That means that no matter how well you try, the implementation will suck..
 because it will be very slow comparing to one that uses fixed-type
 fixed-argument number.

 My philosophy , in general, for programming is avoid bloat and inefficiency
 at all costs. When some feature requires bloat and going to be very
 inefficient, i simply saying 'No'.
 Especially at infrastructural level, which NB belongs to.
 Because one thing that you (of me) as implementer knows what is fast  cool
 and what is slow  inefficient, but then users come and start using things
 in a way you would never think your stuff will be ever used.. and start
 spreading inefficiency in their project(s). And more that that, once they
 get used to it, then you would be never able to remove it because it is
 there and everyone using it and some even loving it :)


 --
 Best regards,
 Igor Stasenko.

Re: [Pharo-users] NativeBoost and OpenMP

[stepharo]

I blogged about you :)

Le 16/7/15 19:18, Matthieu Lacaton a écrit :

Hello,

I haven't really seen anything related to this on the Internet and 
maybe some people will find it cool so I just wanted to report one 
thing I found out today :


NativeBoost works great with OpenMP !

I wrote a C function twice, once with openMP and once without. I made 
32 bits libraries and used them from inside Pharo with NativeBoost.


When using the non - openMP library, only one core was used but when 
using the openMP library, both my cores were used and the time it took 
to run was really divided by (a little bit less than) 2 !


That's just me but i find it really cool :p

Cheers,

Matthieu

[Pharo-users] NativeBoost and OpenMP

[Matthieu Lacaton]

Hello,

I haven't really seen anything related to this on the Internet and maybe
some people will find it cool so I just wanted to report one thing I found
out today :

NativeBoost works great with OpenMP !

I wrote a C function twice, once with openMP and once without. I made 32
bits libraries and used them from inside Pharo with NativeBoost.

When using the non - openMP library, only one core was used but when using
the openMP library, both my cores were used and the time it took to run was
really divided by (a little bit less than) 2 !

That's just me but i find it really cool :p

Cheers,

Matthieu

Re: [Pharo-users] NativeBoost and variadic functions

[Matthieu Lacaton]

 Oh man...
 and why would anyone may want to use this? :)

 Sure you can do whatever it takes to implement a feature you want so badly,
 but hey..
 If something that takes so much effort and so inefficient as result, would
 you consider abandon the idea and use something else instead? :)
 Because it is straightly against the philosophy of NB: be fast and
 explicit.
 And you seem to be in favor of implicitness.
 Well, nevertheless, it is a honorable goal, so good luck :)


You are right. Actually it was just a workaround to see if I could bypass
some of the limitations but it is definitely too ugly and inefficient to
be useful.
The C code will be changed to fit Pharo and that will do the trick.

And let me remind you that despite that NB implements FFI to speak with C,
 it is not obliged to implement features of C language itself. It lets you
 speak with C programs, but not lets you write programs like in C (see the
 difference? :)


You are definitely right once again. I noticed today that lately I was
writing more C-ish code in Pharo than Smalltalk-ish code...
But I really like NativeBoost :(

2015-07-16 18:33 GMT+02:00 Igor Stasenko siguc...@gmail.com:



 On 15 July 2015 at 11:16, Matthieu Lacaton matthieu.laca...@gmail.com
 wrote:

 Hello Igor,

 Thanks for your answer.

 I implemented something like that for the printf function:
 Basically, it generates a method with matching arguments and executes it.

 *printf:* stringFormat *args:* tab

 | argNumber functionArgs functionPrototype methodCorpse
 methodSelector argsArray |

 ((tab size % 2) = 0) ifFalse: [
 Transcript show: 'error'.
 ^self.
 ].

 argNumber := 0.
 functionPrototype := 'printf: stringFormat'.
 functionArgs := ''.
 methodCorpse := ''.
 argsArray := (Array new: (tab size / 2) + 1).
 argsArray at: 1 put: stringFormat.

 1 to: tab size by: 2 do: [ :i |
 functionPrototype := functionPrototype, ' arg', argNumber
 asString, ': ', (tab at: i) asString, argNumber asString.
 functionArgs := functionArgs, ' ', (tab at: i) asString, ' ',
 (tab at: i) asString, argNumber asString, ','.
 argsArray at: argNumber + 2 put: (tab at: i + 1).
 argNumber := argNumber + 1.
 ].
 functionArgs := functionArgs allButLast.

 methodCorpse := functionPrototype, Character cr asString, '
 primitive: #primitiveNativeCall module: #NativeBoostPlugin', Character cr
 asString, Character cr asString, '^self nbCall: #( void printf ( String
 stringFormat,', functionArgs asString, ' ) )', Character cr asString, '
 module: NativeBoost CLibrary'.

 methodSelector := self class compile: methodCorpse.

 self perform: methodSelector withArguments: argsArray.



 Then you can call it like that :

 MyClass printf: 'Test of printf. String: %s, Int : %d, Long: %ld, Char:
 %c, Double: %lf' args: { 'String'. 'This is a string'. 'int'. 100. 'long'.
 1000. 'char'. 89. 'double'. 3.14159 }.


 I also tried it for some other variadic functions and, on my computer (I
 am running archlinux), it seemed to work for every type of argument except
 float. It works fine for double though.
 For char you need to pass the integer ASCII value directly for it to
 work. I tried with Character value: xxx but it didn't work.

 I know that this is very hackish and very bad, and I am aware it has some
 drawbacks. Moreover I am not even sure it will work everytime.
 But for now it seems to work ...

 Oh man...
 and why would anyone may want to use this? :)

 Sure you can do whatever it takes to implement a feature you want so badly,
 but hey..
 If something that takes so much effort and so inefficient as result, would
 you consider abandon the idea and use something else instead? :)
 Because it is straightly against the philosophy of NB: be fast and
 explicit.
 And you seem to be in favor of implicitness.
 Well, nevertheless, it is a honorable goal, so good luck :)


 2015-07-13 19:24 GMT+02:00 Igor Stasenko siguc...@gmail.com:



 On 10 July 2015 at 10:18, Matthieu Lacaton matthieu.laca...@gmail.com
 wrote:

 Hello,

 Is it possible with NativeBoost to create a binding for a variadic
 function ?

 I've seen the printf example in NBCPrinter but this implementation is
 kind of cheating since it always pass just a %s as format and one already
 formatted string to the C function.

 I've written a simple variadic function which adds every integer it
 receives as argument (first argument is for the number of following
 arguments) :

 int add(int number,...);

 In Pharo I've tried something like this :

 *add: *number *arg1: *first *arg2: *second
 primitive: #primitiveNativeCall module: #NativeBoostPlugin

 ^ self nbCall: #( int add (int number, int first, int second))
   module: 'libMyLib.so'


 and it works fine with two arguments.

 Basically, doing so, I would need one method per number of arguments so
 it's not very cool.

 I thought that maybe I could pass an array as argument to my Pharo
 

Re: [Pharo-users] NativeBoost and variadic functions

[Igor Stasenko]

On 15 July 2015 at 11:16, Matthieu Lacaton matthieu.laca...@gmail.com
wrote:

 Hello Igor,

 Thanks for your answer.

 I implemented something like that for the printf function:
 Basically, it generates a method with matching arguments and executes it.

 *printf:* stringFormat *args:* tab

 | argNumber functionArgs functionPrototype methodCorpse
 methodSelector argsArray |

 ((tab size % 2) = 0) ifFalse: [
 Transcript show: 'error'.
 ^self.
 ].

 argNumber := 0.
 functionPrototype := 'printf: stringFormat'.
 functionArgs := ''.
 methodCorpse := ''.
 argsArray := (Array new: (tab size / 2) + 1).
 argsArray at: 1 put: stringFormat.

 1 to: tab size by: 2 do: [ :i |
 functionPrototype := functionPrototype, ' arg', argNumber
 asString, ': ', (tab at: i) asString, argNumber asString.
 functionArgs := functionArgs, ' ', (tab at: i) asString, ' ',
 (tab at: i) asString, argNumber asString, ','.
 argsArray at: argNumber + 2 put: (tab at: i + 1).
 argNumber := argNumber + 1.
 ].
 functionArgs := functionArgs allButLast.

 methodCorpse := functionPrototype, Character cr asString, '
 primitive: #primitiveNativeCall module: #NativeBoostPlugin', Character cr
 asString, Character cr asString, '^self nbCall: #( void printf ( String
 stringFormat,', functionArgs asString, ' ) )', Character cr asString, '
 module: NativeBoost CLibrary'.

 methodSelector := self class compile: methodCorpse.

 self perform: methodSelector withArguments: argsArray.



 Then you can call it like that :

 MyClass printf: 'Test of printf. String: %s, Int : %d, Long: %ld, Char:
 %c, Double: %lf' args: { 'String'. 'This is a string'. 'int'. 100. 'long'.
 1000. 'char'. 89. 'double'. 3.14159 }.


 I also tried it for some other variadic functions and, on my computer (I
 am running archlinux), it seemed to work for every type of argument except
 float. It works fine for double though.
 For char you need to pass the integer ASCII value directly for it to
 work. I tried with Character value: xxx but it didn't work.

 I know that this is very hackish and very bad, and I am aware it has some
 drawbacks. Moreover I am not even sure it will work everytime.
 But for now it seems to work ...

 Oh man...
and why would anyone may want to use this? :)

Sure you can do whatever it takes to implement a feature you want so badly,
but hey..
If something that takes so much effort and so inefficient as result, would
you consider abandon the idea and use something else instead? :)
Because it is straightly against the philosophy of NB: be fast and explicit.
And you seem to be in favor of implicitness.
Well, nevertheless, it is a honorable goal, so good luck :)


 2015-07-13 19:24 GMT+02:00 Igor Stasenko siguc...@gmail.com:



 On 10 July 2015 at 10:18, Matthieu Lacaton matthieu.laca...@gmail.com
 wrote:

 Hello,

 Is it possible with NativeBoost to create a binding for a variadic
 function ?

 I've seen the printf example in NBCPrinter but this implementation is
 kind of cheating since it always pass just a %s as format and one already
 formatted string to the C function.

 I've written a simple variadic function which adds every integer it
 receives as argument (first argument is for the number of following
 arguments) :

 int add(int number,...);

 In Pharo I've tried something like this :

 *add: *number *arg1: *first *arg2: *second
 primitive: #primitiveNativeCall module: #NativeBoostPlugin

 ^ self nbCall: #( int add (int number, int first, int second))
   module: 'libMyLib.so'


 and it works fine with two arguments.

 Basically, doing so, I would need one method per number of arguments so
 it's not very cool.

 I thought that maybe I could pass an array as argument to my Pharo
 method but I didn't really find a way to figure out how to define the
 nbCall without having a Generic failure.

 *add: *number *args: *anArray
 primitive: #primitiveNativeCall module: #NativeBoostPlugin

 ^ self nbCall: #( int add (int number, ??? anArray))
   module: 'libMyLib.so'


 Do you have an idea ?


 In short, there's no marshaller for converting an array of items, to same
 number of things on stack. That could solve the problem with your example:
 passing array of objects of *same* type. But in general, it is not what C
 variadic function(s) standing for. Because they stand for any number of
 arguments, of any type.
 In C, since all program is compiled statically, compiler knows the number
 of passed arguments and their types through compiling each particular call
 site(s) to variadic function. Which means that in fact, you are still
 supplying all information needed by compiler *before* run time.

 In variadic functions, you can pass any arguments of any type,
 but for converting each of them, you must tell NB what kind of
 marshaller should be used for it , which means, that it is impossible to
 know before run time, since you cannot know how many arguments 

Re: [Pharo-users] NativeBoost and variadic functions

[Igor Stasenko]

On 15 July 2015 at 16:35, Ben Coman b...@openinworld.com wrote:

 On Wed, Jul 15, 2015 at 5:16 PM, Matthieu Lacaton
 matthieu.laca...@gmail.com wrote:
  Hello Igor,
 
  Thanks for your answer.
 
  I implemented something like that for the printf function:
  Basically, it generates a method with matching arguments and executes it.
 
  printf: stringFormat args: tab
 
  | argNumber functionArgs functionPrototype methodCorpse
 methodSelector
  argsArray |
 
  ((tab size % 2) = 0) ifFalse: [
  Transcript show: 'error'.
  ^self.
  ].
 
  argNumber := 0.
  functionPrototype := 'printf: stringFormat'.
  functionArgs := ''.
  methodCorpse := ''.
  argsArray := (Array new: (tab size / 2) + 1).
  argsArray at: 1 put: stringFormat.
 
  1 to: tab size by: 2 do: [ :i |
  functionPrototype := functionPrototype, ' arg', argNumber
  asString, ': ', (tab at: i) asString, argNumber asString.
  functionArgs := functionArgs, ' ', (tab at: i) asString, ' ',
 (tab
  at: i) asString, argNumber asString, ','.
  argsArray at: argNumber + 2 put: (tab at: i + 1).
  argNumber := argNumber + 1.
  ].
  functionArgs := functionArgs allButLast.
 
  methodCorpse := functionPrototype, Character cr asString, '
  primitive: #primitiveNativeCall module: #NativeBoostPlugin',
 Character cr
  asString, Character cr asString, '^self nbCall: #( void printf (
 String
  stringFormat,', functionArgs asString, ' ) )', Character cr asString, '
  module: NativeBoost CLibrary'.
 
  methodSelector := self class compile: methodCorpse.
 
  self perform: methodSelector withArguments: argsArray.
 
 
 
  Then you can call it like that :
 
  MyClass printf: 'Test of printf. String: %s, Int : %d, Long: %ld, Char:
 %c,
  Double: %lf' args: { 'String'. 'This is a string'. 'int'. 100. 'long'.
  1000. 'char'. 89. 'double'. 3.14159 }.
 
 
  I also tried it for some other variadic functions and, on my computer (I
 am
  running archlinux), it seemed to work for every type of argument except
  float.


 Maybe NativeBoost does not do implicit type conversions that a C
 compiler would do?


It does not.
But that's not an issue. The philosophy behind NB was to require from user
explicit information about what types to use and how.
The main reason behind that, is that the more explicit and detailed
information you got at compilation time (in case of NB - code generation) ,
the more simple and efficient generated code will be.
In general, you don't want to generate trains of machine code to handle
1000+ of cases for converting a single argument (and then repeat the same
for next function argument). It makes things slow and inefficient, not
speaking that generated code also takes memory space.
I don't want to make code generation too smart, and this is why i trying to
avoid any implicitness: because else it makes users wonder why something
works and something don't and he have no idea, because of tons and tons of
contradicting implicit rules hidden behind the scenes.

And let me remind you that despite that NB implements FFI to speak with C,
it is not obliged to implement features of C language itself. It lets you
speak with C programs, but not lets you write programs like in C (see the
difference? :)

[1] Because C will promote floats to doubles for functions that take
 variable arguments

 More info search [2] for:
 *  implicit type conversion
 *  guess wrongly when the program uses floating-point formats in
 scanf() or printf()

 [1]
 http://stackoverflow.com/questions/210590/why-does-scanf-need-lf-for-doubles-when-printf-is-okay-with-just-f

 [2] http://www.electroons.com/8051/ebooks/expert%20C%20programming.pdf

 cheers -ben


  It works fine for double though.
  For char you need to pass the integer ASCII value directly for it to
 work.
  I tried with Character value: xxx but it didn't work.
 
  I know that this is very hackish and very bad, and I am aware it has some
  drawbacks. Moreover I am not even sure it will work everytime.
  But for now it seems to work ...
 
  2015-07-13 19:24 GMT+02:00 Igor Stasenko siguc...@gmail.com:
 
 
 
  On 10 July 2015 at 10:18, Matthieu Lacaton matthieu.laca...@gmail.com
  wrote:
 
  Hello,
 
  Is it possible with NativeBoost to create a binding for a variadic
  function ?
 
  I've seen the printf example in NBCPrinter but this implementation is
  kind of cheating since it always pass just a %s as format and one
 already
  formatted string to the C function.
 
  I've written a simple variadic function which adds every integer it
  receives as argument (first argument is for the number of following
  arguments) :
 
  int add(int number,...);
 
  In Pharo I've tried something like this :
 
  add: number arg1: first arg2: second
  primitive: #primitiveNativeCall module: #NativeBoostPlugin
 
  ^ self nbCall: #( int add (int number, int first, int second))
module: 'libMyLib.so'
 
 
  and it works fine with two arguments.

Re: [Pharo-users] NativeBoost and OpenMP

[Ben Coman]

Very cool. Nice to hear you're having fun.
cheers -ben

On Fri, Jul 17, 2015 at 1:18 AM, Matthieu Lacaton
matthieu.laca...@gmail.com wrote:
 Hello,

 I haven't really seen anything related to this on the Internet and maybe
 some people will find it cool so I just wanted to report one thing I found
 out today :

 NativeBoost works great with OpenMP !

 I wrote a C function twice, once with openMP and once without. I made 32
 bits libraries and used them from inside Pharo with NativeBoost.

 When using the non - openMP library, only one core was used but when using
 the openMP library, both my cores were used and the time it took to run was
 really divided by (a little bit less than) 2 !

 That's just me but i find it really cool :p

 Cheers,

 Matthieu

Re: [Pharo-users] NativeBoost and variadic functions

[Matthieu Lacaton]

Hello Igor,

Thanks for your answer.

I implemented something like that for the printf function:
Basically, it generates a method with matching arguments and executes it.

*printf:* stringFormat *args:* tab

 | argNumber functionArgs functionPrototype methodCorpse methodSelector
 argsArray |

 ((tab size % 2) = 0) ifFalse: [
 Transcript show: 'error'.
 ^self.
 ].

 argNumber := 0.
 functionPrototype := 'printf: stringFormat'.
 functionArgs := ''.
 methodCorpse := ''.
 argsArray := (Array new: (tab size / 2) + 1).
 argsArray at: 1 put: stringFormat.

 1 to: tab size by: 2 do: [ :i |
 functionPrototype := functionPrototype, ' arg', argNumber
 asString, ': ', (tab at: i) asString, argNumber asString.
 functionArgs := functionArgs, ' ', (tab at: i) asString, ' ', (tab
 at: i) asString, argNumber asString, ','.
 argsArray at: argNumber + 2 put: (tab at: i + 1).
 argNumber := argNumber + 1.
 ].
 functionArgs := functionArgs allButLast.

 methodCorpse := functionPrototype, Character cr asString, '
 primitive: #primitiveNativeCall module: #NativeBoostPlugin', Character cr
 asString, Character cr asString, '^self nbCall: #( void printf ( String
 stringFormat,', functionArgs asString, ' ) )', Character cr asString, '
 module: NativeBoost CLibrary'.

 methodSelector := self class compile: methodCorpse.

 self perform: methodSelector withArguments: argsArray.



Then you can call it like that :

MyClass printf: 'Test of printf. String: %s, Int : %d, Long: %ld, Char: %c,
Double: %lf' args: { 'String'. 'This is a string'. 'int'. 100. 'long'.
1000. 'char'. 89. 'double'. 3.14159 }.


I also tried it for some other variadic functions and, on my computer (I am
running archlinux), it seemed to work for every type of argument except
float. It works fine for double though.
For char you need to pass the integer ASCII value directly for it to
work. I tried with Character value: xxx but it didn't work.

I know that this is very hackish and very bad, and I am aware it has some
drawbacks. Moreover I am not even sure it will work everytime.
But for now it seems to work ...

2015-07-13 19:24 GMT+02:00 Igor Stasenko siguc...@gmail.com:



 On 10 July 2015 at 10:18, Matthieu Lacaton matthieu.laca...@gmail.com
 wrote:

 Hello,

 Is it possible with NativeBoost to create a binding for a variadic
 function ?

 I've seen the printf example in NBCPrinter but this implementation is
 kind of cheating since it always pass just a %s as format and one already
 formatted string to the C function.

 I've written a simple variadic function which adds every integer it
 receives as argument (first argument is for the number of following
 arguments) :

 int add(int number,...);

 In Pharo I've tried something like this :

 *add: *number *arg1: *first *arg2: *second
 primitive: #primitiveNativeCall module: #NativeBoostPlugin

 ^ self nbCall: #( int add (int number, int first, int second))
   module: 'libMyLib.so'


 and it works fine with two arguments.

 Basically, doing so, I would need one method per number of arguments so
 it's not very cool.

 I thought that maybe I could pass an array as argument to my Pharo method
 but I didn't really find a way to figure out how to define the nbCall
 without having a Generic failure.

 *add: *number *args: *anArray
 primitive: #primitiveNativeCall module: #NativeBoostPlugin

 ^ self nbCall: #( int add (int number, ??? anArray))
   module: 'libMyLib.so'


 Do you have an idea ?


 In short, there's no marshaller for converting an array of items, to same
 number of things on stack. That could solve the problem with your example:
 passing array of objects of *same* type. But in general, it is not what C
 variadic function(s) standing for. Because they stand for any number of
 arguments, of any type.
 In C, since all program is compiled statically, compiler knows the number
 of passed arguments and their types through compiling each particular call
 site(s) to variadic function. Which means that in fact, you are still
 supplying all information needed by compiler *before* run time.

 In variadic functions, you can pass any arguments of any type,
 but for converting each of them, you must tell NB what kind of  marshaller
 should be used for it , which means, that it is impossible to know before
 run time, since you cannot know how many arguments you may pass, not
 speaking about their types.




 Thanks,

 Matthieu





 --
 Best regards,
 Igor Stasenko.

Re: [Pharo-users] NativeBoost and variadic functions

[Ben Coman]

On Wed, Jul 15, 2015 at 5:16 PM, Matthieu Lacaton
matthieu.laca...@gmail.com wrote:
 Hello Igor,

 Thanks for your answer.

 I implemented something like that for the printf function:
 Basically, it generates a method with matching arguments and executes it.

 printf: stringFormat args: tab

 | argNumber functionArgs functionPrototype methodCorpse methodSelector
 argsArray |

 ((tab size % 2) = 0) ifFalse: [
 Transcript show: 'error'.
 ^self.
 ].

 argNumber := 0.
 functionPrototype := 'printf: stringFormat'.
 functionArgs := ''.
 methodCorpse := ''.
 argsArray := (Array new: (tab size / 2) + 1).
 argsArray at: 1 put: stringFormat.

 1 to: tab size by: 2 do: [ :i |
 functionPrototype := functionPrototype, ' arg', argNumber
 asString, ': ', (tab at: i) asString, argNumber asString.
 functionArgs := functionArgs, ' ', (tab at: i) asString, ' ', (tab
 at: i) asString, argNumber asString, ','.
 argsArray at: argNumber + 2 put: (tab at: i + 1).
 argNumber := argNumber + 1.
 ].
 functionArgs := functionArgs allButLast.

 methodCorpse := functionPrototype, Character cr asString, '
 primitive: #primitiveNativeCall module: #NativeBoostPlugin', Character cr
 asString, Character cr asString, '^self nbCall: #( void printf ( String
 stringFormat,', functionArgs asString, ' ) )', Character cr asString, '
 module: NativeBoost CLibrary'.

 methodSelector := self class compile: methodCorpse.

 self perform: methodSelector withArguments: argsArray.



 Then you can call it like that :

 MyClass printf: 'Test of printf. String: %s, Int : %d, Long: %ld, Char: %c,
 Double: %lf' args: { 'String'. 'This is a string'. 'int'. 100. 'long'.
 1000. 'char'. 89. 'double'. 3.14159 }.


 I also tried it for some other variadic functions and, on my computer (I am
 running archlinux), it seemed to work for every type of argument except
 float.


Maybe NativeBoost does not do implicit type conversions that a C
compiler would do?
[1] Because C will promote floats to doubles for functions that take
variable arguments

More info search [2] for:
*  implicit type conversion
*  guess wrongly when the program uses floating-point formats in
scanf() or printf()

[1] 
http://stackoverflow.com/questions/210590/why-does-scanf-need-lf-for-doubles-when-printf-is-okay-with-just-f

[2] http://www.electroons.com/8051/ebooks/expert%20C%20programming.pdf

cheers -ben


 It works fine for double though.
 For char you need to pass the integer ASCII value directly for it to work.
 I tried with Character value: xxx but it didn't work.

 I know that this is very hackish and very bad, and I am aware it has some
 drawbacks. Moreover I am not even sure it will work everytime.
 But for now it seems to work ...

 2015-07-13 19:24 GMT+02:00 Igor Stasenko siguc...@gmail.com:



 On 10 July 2015 at 10:18, Matthieu Lacaton matthieu.laca...@gmail.com
 wrote:

 Hello,

 Is it possible with NativeBoost to create a binding for a variadic
 function ?

 I've seen the printf example in NBCPrinter but this implementation is
 kind of cheating since it always pass just a %s as format and one already
 formatted string to the C function.

 I've written a simple variadic function which adds every integer it
 receives as argument (first argument is for the number of following
 arguments) :

 int add(int number,...);

 In Pharo I've tried something like this :

 add: number arg1: first arg2: second
 primitive: #primitiveNativeCall module: #NativeBoostPlugin

 ^ self nbCall: #( int add (int number, int first, int second))
   module: 'libMyLib.so'


 and it works fine with two arguments.

 Basically, doing so, I would need one method per number of arguments so
 it's not very cool.

 I thought that maybe I could pass an array as argument to my Pharo method
 but I didn't really find a way to figure out how to define the nbCall
 without having a Generic failure.

 add: number args: anArray
 primitive: #primitiveNativeCall module: #NativeBoostPlugin

 ^ self nbCall: #( int add (int number, ??? anArray))
   module: 'libMyLib.so'


 Do you have an idea ?


 In short, there's no marshaller for converting an array of items, to same
 number of things on stack. That could solve the problem with your example:
 passing array of objects of *same* type. But in general, it is not what C
 variadic function(s) standing for. Because they stand for any number of
 arguments, of any type.
 In C, since all program is compiled statically, compiler knows the number
 of passed arguments and their types through compiling each particular call
 site(s) to variadic function. Which means that in fact, you are still
 supplying all information needed by compiler *before* run time.

 In variadic functions, you can pass any arguments of any type,
 but for converting each of them, you must tell NB what kind of  marshaller
 should be used for it , which means, that it is impossible to know before
 run time, 

Re: [Pharo-users] NativeBoost and variadic functions

[Igor Stasenko]

On 10 July 2015 at 10:18, Matthieu Lacaton matthieu.laca...@gmail.com
wrote:

 Hello,

 Is it possible with NativeBoost to create a binding for a variadic
 function ?

 I've seen the printf example in NBCPrinter but this implementation is kind
 of cheating since it always pass just a %s as format and one already
 formatted string to the C function.

 I've written a simple variadic function which adds every integer it
 receives as argument (first argument is for the number of following
 arguments) :

 int add(int number,...);

 In Pharo I've tried something like this :

 *add: *number *arg1: *first *arg2: *second
 primitive: #primitiveNativeCall module: #NativeBoostPlugin

 ^ self nbCall: #( int add (int number, int first, int second))
   module: 'libMyLib.so'


 and it works fine with two arguments.

 Basically, doing so, I would need one method per number of arguments so
 it's not very cool.

 I thought that maybe I could pass an array as argument to my Pharo method
 but I didn't really find a way to figure out how to define the nbCall
 without having a Generic failure.

 *add: *number *args: *anArray
 primitive: #primitiveNativeCall module: #NativeBoostPlugin

 ^ self nbCall: #( int add (int number, ??? anArray))
   module: 'libMyLib.so'


 Do you have an idea ?


In short, there's no marshaller for converting an array of items, to same
number of things on stack. That could solve the problem with your example:
passing array of objects of *same* type. But in general, it is not what C
variadic function(s) standing for. Because they stand for any number of
arguments, of any type.
In C, since all program is compiled statically, compiler knows the number
of passed arguments and their types through compiling each particular call
site(s) to variadic function. Which means that in fact, you are still
supplying all information needed by compiler *before* run time.

In variadic functions, you can pass any arguments of any type,
but for converting each of them, you must tell NB what kind of  marshaller
should be used for it , which means, that it is impossible to know before
run time, since you cannot know how many arguments you may pass, not
speaking about their types.




 Thanks,

 Matthieu





-- 
Best regards,
Igor Stasenko.

[Pharo-users] NativeBoost and variadic functions

[Matthieu Lacaton]

Hello,

Is it possible with NativeBoost to create a binding for a variadic function
?

I've seen the printf example in NBCPrinter but this implementation is kind
of cheating since it always pass just a %s as format and one already
formatted string to the C function.

I've written a simple variadic function which adds every integer it
receives as argument (first argument is for the number of following
arguments) :

int add(int number,...);

In Pharo I've tried something like this :

*add: *number *arg1: *first *arg2: *second
 primitive: #primitiveNativeCall module: #NativeBoostPlugin

 ^ self nbCall: #( int add (int number, int first, int second))
   module: 'libMyLib.so'


and it works fine with two arguments.

Basically, doing so, I would need one method per number of arguments so
it's not very cool.

I thought that maybe I could pass an array as argument to my Pharo method
but I didn't really find a way to figure out how to define the nbCall
without having a Generic failure.

*add: *number *args: *anArray
 primitive: #primitiveNativeCall module: #NativeBoostPlugin

 ^ self nbCall: #( int add (int number, ??? anArray))
   module: 'libMyLib.so'


Do you have an idea ?

Thanks,

Matthieu

Re: [Pharo-users] NativeBoost nested structures

[Matthieu Lacaton]

 Are you bound to exactly this structure?
 If you can define the structure, you can use a nested structure that uses
 pointers instead of values:

 NBTestNestedStructure2
 fieldsDesc

 ^ #(
 NBTestStructure1byte* oneByte;
 int otherField
 )

 Now you can create and access the innerstructure like this

 myStruct := (NBTestNestedStructure2 new oneByte: (NBTestStructure1byte
 externalNew field: 1)).
 myStruct oneByte field.  - 1 
 myStruct oneByte field: 4.
 myStruct oneByte field.  - 4 


Well I'm not bound to anything really, but what you did here seems nice and
should do the trick for me.
Initially i just got rid of the second struct and incorporated each element
of the second struct inside the first one. I guess if the size they take in
memory is the same it should work too.
But I'll use your solution cause it looks nicer :)

Whereas I don't know if the external memory is freed.


From what is written in NBExternalStructure it probably isn't but I'll just
have to remember to do so.


On the other hand, I am curious about the internal mechanisms here.

yes, self struct2 will create a copy of the struct2 and any change to
 struct2 value only applies to this copy.


If self struct2 returns a copy it means that even if it is not a struct
and simply an int it also returns me a copy right ?
However, when you call self struct2: ... or self otherField: ... it
actually modifies the object itself.
So why doesn't it let me access the actual object directly ? If I can
modify the whole object why can't I modify just a part of it ? What is the
inherent issue ?

[Pharo-users] NativeBoost nested structures

[Matthieu Lacaton]

Hello everyone,

I have a nested struct, let's say struct1 which contains struct2 which
contains an int field named field.

When I try to update the field from struct 1 directly I can't. What I mean
is if I do : struct1 struct2 field: 4 for instance, the value in field is
not updated. Even if I inspect struct1 struct2 and I manually set the
field variable by doing : self field: 4 then if I go back to my struct1
and do self struct2 field the value has not been updated.
So basically the only way I have to update a field in a nested structure is
to recreate the second struct entirely : struct1 struct2: (Struct2 new
field: 4) and now it works.

It seems odd because in C you can do struct1.struct2.field = 4; and it
works fine.

You can reproduce this with the NBTestNestedStructure class from
NativeBoost itself :

| myStruct |

myStruct := (NBTestNestedStructure new oneByte: (NBTestStructure1byte new
field: 1)).
Transcript show: myStruct oneByte field; cr.
myStruct oneByte field: 4.
Transcript show: myStruct oneByte field; cr.
myStruct oneByte: (NBTestStructure1byte new field: 4).
Transcript show: myStruct oneByte field; cr.

For me the Transcript shows 1 1 4 whereas in my opinion it should show 1 4
4.

So am I doing something wrong or is this some kind of a bug ?

Thanks,

Matthieu

Re: [Pharo-users] NativeBoost nested structures

[Nicolai Hess]

2015-06-15 17:14 GMT+02:00 Matthieu Lacaton matthieu.laca...@gmail.com:

 Hello everyone,

 I have a nested struct, let's say struct1 which contains struct2 which
 contains an int field named field.

 When I try to update the field from struct 1 directly I can't. What I mean
 is if I do : struct1 struct2 field: 4 for instance, the value in field is
 not updated. Even if I inspect struct1 struct2 and I manually set the
 field variable by doing : self field: 4 then if I go back to my struct1
 and do self struct2 field the value has not been updated.
 So basically the only way I have to update a field in a nested structure
 is to recreate the second struct entirely : struct1 struct2: (Struct2 new
 field: 4) and now it works.

 It seems odd because in C you can do struct1.struct2.field = 4; and it
 works fine.


yes, self struct2 will create a copy of the struct2 and any change to
struct2 value only applies to this copy.




 You can reproduce this with the NBTestNestedStructure class from
 NativeBoost itself :

 | myStruct |

 myStruct := (NBTestNestedStructure new oneByte: (NBTestStructure1byte new
 field: 1)).
 Transcript show: myStruct oneByte field; cr.
 myStruct oneByte field: 4.
 Transcript show: myStruct oneByte field; cr.
 myStruct oneByte: (NBTestStructure1byte new field: 4).
 Transcript show: myStruct oneByte field; cr.

 For me the Transcript shows 1 1 4 whereas in my opinion it should show 1 4
 4.

 So am I doing something wrong or is this some kind of a bug ?


I am not sure, I think there is no other way to handle this kind of nested
structures.

Are you bound to exactly this structure?
If you can define the structure, you can use a nested structure that uses
pointers instead of values:

NBTestNestedStructure2
fieldsDesc

^ #(
NBTestStructure1byte* oneByte;
int otherField
)

Now you can create and access the innerstructure like this

myStruct := (NBTestNestedStructure2 new oneByte: (NBTestStructure1byte
externalNew field: 1)).
myStruct oneByte field.  - 1 
myStruct oneByte field: 4.
myStruct oneByte field.  - 4 

Whereas I don't know if the external memory is freed.





 Thanks,

 Matthieu

Re: [Pharo-users] NativeBoost pointer and +

[Matthieu Lacaton]

Hello Henrik,

Thank you very much for your answer. However, the code you provided is some
sort of assembly right ? So does it mean that I need to learn assembly to
do what I want ?

I'm asking that because I don't know anything about assembly so it will
take me some time to learn.

Cheers,

Matthieu

2015-06-08 19:56 GMT+02:00 Henrik Johansen henrik.s.johan...@veloxit.no:


  On 08 Jun 2015, at 4:41 , Matthieu Lacaton matthieu.laca...@gmail.com
 wrote:
 
  Hello everyone,
 
  I have a small question about NativeBoost : How does the + operator
 when applied to a pointer translates into NativeBoost code ?
 
  To give a bit of context, what I want to do is to reallocate some
 non-contiguous bytes in memory to a buffer. Basically, I have an array of
 integers in a buffer and I want to copy some chunks of it in another
 buffer. The chunks are always the same size and the offset between each
 chunk is always the same too.
 
  Because a bit of actual code is easier to understand here is what I'd
 like to do in Pharo :
 
  ...
 
  int i, j;
  int *data = malloc(1000*sizeof(int));
  int *newData = malloc(50*sizeof(int));
 
  // Allocate initial data
  for (i = 0 ; i  1000, i++) {
data[i] = i;
  }
 
  //Copy desired chunks into new buffer
  for (i = 0; i  5; i++ ) {
memcpy( newData + j*10, data + 200 + j*30, 10*sizeof(int));
j++;
  }
 
  free(data);



 You can do relative addressing like this:
 (destReg ptr: dataSize) + offsetReg + constant

 So with offSetRegs containing j* 10 and j* 30, you might end up with an
 unrolled inner loop (barring using any fancier longer-than-int moves) like:

 0 to: 9 do: [:constantOffset |
 asm mov: (destReg ptr: currentPlatform sizeOfInt) + dstOffsetReg +
 constantOffset  with: (srcReg ptr: currentPlatform sizeOfInt) + 200 +
 srcOffsetReg + constantOffset]

 If the range of j is constant, you can just as easily unroll the whole
 thing in a similarly compact fashion, space and sensibilites permitting:

 0 to: 4 do: [ :j | 0 to: 9 do: [ :consOffset |
 asm mov: (destReg ptr: currentPlatform sizeOfInt) + (j* 10) +
 constOffset  with: (srcReg ptr: currentPlatform sizeOfInt) + 200 + (j * 30)
 + constOffset]

 Cheers,
 Henry

Re: [Pharo-users] NativeBoost pointer and +

[Igor Stasenko]

As i understand, in general, the problem that you described is in following:
- you want to pass an address of your buffer contents, but started not from
very first element of your buffer, but somewhere inside a buffer.

In smalltalk you cannot reference an element of array,
only the object (array in that case) as a whole.

The reason why it like so, because VM moves objects around, and you cannot
control directly when that happens,
and also VM responsible for updating all pointers (references) to moved
object(s)
for all interested parties (which could be other objects, stack etc) ,
making sure all references remain consistent upon such move.
So, with such constraints, the only way to validly point to an element
inside array
would be to store two values separately:
 - a reference to an object, that represent your buffer (which VM would
update at will)
 - an index (or offset) in that object, pointing to element in your buffer

Unfortunately, this is the only way how we could implement such, lets say
'ElementPointer' safely. Which then can be used to pass to C function(s),
converting object reference + offset into simple address just before
invoking a function (and sure thing, knowing that there's no chance
triggering GC, else it will turn into pointer to wrong place, but that's
general problem of passing pointers on object memory heap, not just
exclusively for 'element pointer' and such).

For buffers allocated externally, e.g. outside heap governed by VM,
there's nothing prevents you from having an address that pointing inside
some buffer (or even outside it :)

For NBExternalAddress:

addr := self allocate: somespace.

newAddr := NBExternalAddress value: addr value + someoffset.

or

newAddr := addr copy value: addr value + someoffset

sure, it is up to you then, how to calculate offsets and buffer size(s) as
well as allocating/deallocating memory for buffers you using.


On 8 June 2015 at 16:41, Matthieu Lacaton matthieu.laca...@gmail.com
wrote:

 Hello everyone,

 I have a small question about NativeBoost : How does the + operator when
 applied to a pointer translates into NativeBoost code ?

 To give a bit of context, what I want to do is to reallocate some
 non-contiguous bytes in memory to a buffer. Basically, I have an array of
 integers in a buffer and I want to copy some chunks of it in another
 buffer. The chunks are always the same size and the offset between each
 chunk is always the same too.

 Because a bit of actual code is easier to understand here is what I'd like
 to do in Pharo :

 ...

 int i, j;
 int *data = malloc(1000*sizeof(int));
 int *newData = malloc(50*sizeof(int));

 // Allocate initial data
 for (i = 0 ; i  1000, i++) {
   data[i] = i;
 }

 //Copy desired chunks into new buffer
 for (i = 0; i  5; i++ ) {
   memcpy( newData + j*10, data + 200 + j*30, 10*sizeof(int));
   j++;
 }

 free(data);

 ...

 Here basically I'll get in my buffer chunks of 10 integers starting at 200
 with an offset of 30 between chunks, and this 5 times. (200 201 202 ... 208
 209 230 231 ... 238 239 260 ... 328 329).

 I am okay with the malloc, memcpy and free but I don't know how to handle
 the + operator in my memcpy function.

 Thank you,

 Matthieu




-- 
Best regards,
Igor Stasenko.

Re: [Pharo-users] NativeBoost pointer and +

[stepharo]

Henrik

you amaze me :)

Stef

Le 9/6/15 14:59, Henrik Johansen a écrit :

There are many ways to Rome :)
If you just need some externally allocated objects in the formats you 
specified you can do the cache extraction using nothing but normal 
Smalltalk:


intArray := (NBExternalArray ofType: 'int').

data := intArray new: 1000.
1 to:data size do:[:i |data at:i put: i].
cache := intArray new: 50.
0 to: 4 do: [:j |
1 to: 10 do: [ :k |
cache at: (j* 10) + k put: (data at: 199 + (30 * j ) + k)] ].

But if you want to take full advantage of the performance boost NB 
offers, you'd write a NativeBoost function to do the cache 
extraction*, as I outlined last time:

MyClass class  #createCacheOf: aSource in: aDestination
createCacheOf: aSource in: aDestination
primitive: #primitiveNativeCall module: #NativeBoostPlugin
Should work on both x86 and x64, as long as sizeOf: lookups work 
correctly

^ self nbCallout
function: #(void (int * aSource, int * aDestination) )
emit: [:gen :proxy :asm | |destReg srcReg tmpReg intSize ptrSize|
intSize := NBExternalType sizeOf: 'int'.
ptrSize := NBExternalType sizeOf: 'void *'.
Only use caller-saved regs, no preservation needed
destReg := asm EAX as: ptrSize.
srcReg := asm ECX as: ptrSize.
tmpReg := asm EDX as: intSize.
asm pop: srcReg.
asm pop: destReg.
0 to: 4 do: [ :j | 0 to: 9 do: [ :offset |
asm
Displacement in bytes, not ptr element size :S, so we have to 
multiply offset by that manually :S

mov: tmpReg with: srcReg ptr + (199 + (j * 30) + offset * intSize);
mov: destReg ptr  + ((j* 10) + offset * intSize) with: tmpReg]]]

and use that;
intArray := (NBExternalArray ofType: 'int').
data := intArray new: 1000.
1 to:data size do:[:i |data at:i put: i].
cache := intArray new: 50.
MyClass createCacheOf: data in: cache.

The difference using a simple [] bench is about two orders of 
magnitude; 11million cache extractions per seconds for the inline 
assembly version, while the naive loop achieves around 110k.


Cheers,
Henry

*as: is not yet defined, could be something like:
AJx86GPRegister  #as: aSize
^ self isHighByte
ifTrue: [ self asLowByte as: aSize ]
ifFalse: [
AJx86Registers
generalPurposeWithIndex: self index
size: aSize
requiresRex: self index  (aSize  1 ifTrue: [7] ifFalse: [ 3])
prohibitsRex: false ]


On 09 Jun 2015, at 9:46 , Matthieu Lacaton 
matthieu.laca...@gmail.com mailto:matthieu.laca...@gmail.com wrote:


Hello Henrik,

Thank you very much for your answer. However, the code you provided 
is some sort of assembly right ? So does it mean that I need to learn 
assembly to do what I want ?


I'm asking that because I don't know anything about assembly so it 
will take me some time to learn.


Cheers,

Matthieu

2015-06-08 19:56 GMT+02:00 Henrik Johansen 
henrik.s.johan...@veloxit.no mailto:henrik.s.johan...@veloxit.no:



 On 08 Jun 2015, at 4:41 , Matthieu Lacaton
matthieu.laca...@gmail.com mailto:matthieu.laca...@gmail.com
wrote:

 Hello everyone,

 I have a small question about NativeBoost : How does the +
operator when applied to a pointer translates into NativeBoost code ?

 To give a bit of context, what I want to do is to reallocate
some non-contiguous bytes in memory to a buffer. Basically, I
have an array of integers in a buffer and I want to copy some
chunks of it in another buffer. The chunks are always the same
size and the offset between each chunk is always the same too.

 Because a bit of actual code is easier to understand here is
what I'd like to do in Pharo :

 ...

 int i, j;
 int *data = malloc(1000*sizeof(int));
 int *newData = malloc(50*sizeof(int));

 // Allocate initial data
 for (i = 0 ; i  1000, i++) {
   data[i] = i;
 }

 //Copy desired chunks into new buffer
 for (i = 0; i  5; i++ ) {
   memcpy( newData + j*10, data + 200 + j*30, 10*sizeof(int));
   j++;
 }

 free(data);



You can do relative addressing like this:
(destReg ptr: dataSize) + offsetReg + constant

So with offSetRegs containing j* 10 and j* 30, you might end up
with an unrolled inner loop (barring using any fancier
longer-than-int moves) like:

0 to: 9 do: [:constantOffset |
asm mov: (destReg ptr: currentPlatform sizeOfInt) +
dstOffsetReg + constantOffset  with: (srcReg ptr: currentPlatform
sizeOfInt) + 200 + srcOffsetReg + constantOffset]

If the range of j is constant, you can just as easily unroll the
whole thing in a similarly compact fashion, space and
sensibilites permitting:

0 to: 4 do: [ :j | 0 to: 9 do: [ :consOffset |
asm mov: (destReg ptr: currentPlatform sizeOfInt) + (j*
10) + constOffset  with: (srcReg ptr: currentPlatform sizeOfInt)
+ 200 + (j * 30) + constOffset]

Cheers,
Henry

Re: [Pharo-users] NativeBoost pointer and +

[Matthieu Lacaton]

*@ Igor*


 As i understand, in general, the problem that you described is in
 following:
 - you want to pass an address of your buffer contents, but started not from
 very first element of your buffer, but somewhere inside a buffer.


Yes ! Exactly that. I'm bad at explaining things :(


Unfortunately, this is the only way how we could implement such, lets say
 'ElementPointer' safely. Which then can be used to pass to C function(s),
 converting object reference + offset into simple address just before
 invoking a function (and sure thing, knowing that there's no chance
 triggering GC, else it will turn into pointer to wrong place, but that's
 general problem of passing pointers on object memory heap, not just
 exclusively for 'element pointer' and such).


Alright, thank you very much for your explanations ! By the way, is there a
way to disable the GC for a short period of time and then re-enable it ?



*@ Henrik*

I am not sure I understand every bit of your code right now but I will
definitely study it because it looks awesome.
Moreover, performance is quite important for me so your solution is very
attractive and I'll try to use it. Thanks a lot !

I find it both fun and amazing what you can do with Pharo. I never thought
I would do assembly inside Pharo !


Again, a big thanks to both of you,

Cheers,
Matthieu




2015-06-09 17:43 GMT+02:00 Igor Stasenko siguc...@gmail.com:

 As i understand, in general, the problem that you described is in
 following:
 - you want to pass an address of your buffer contents, but started not from
 very first element of your buffer, but somewhere inside a buffer.

 In smalltalk you cannot reference an element of array,
 only the object (array in that case) as a whole.

 The reason why it like so, because VM moves objects around, and you cannot
 control directly when that happens,
 and also VM responsible for updating all pointers (references) to moved
 object(s)
 for all interested parties (which could be other objects, stack etc) ,
 making sure all references remain consistent upon such move.
 So, with such constraints, the only way to validly point to an element
 inside array
 would be to store two values separately:
  - a reference to an object, that represent your buffer (which VM would
 update at will)
  - an index (or offset) in that object, pointing to element in your buffer

 Unfortunately, this is the only way how we could implement such, lets say
 'ElementPointer' safely. Which then can be used to pass to C function(s),
 converting object reference + offset into simple address just before
 invoking a function (and sure thing, knowing that there's no chance
 triggering GC, else it will turn into pointer to wrong place, but that's
 general problem of passing pointers on object memory heap, not just
 exclusively for 'element pointer' and such).

 For buffers allocated externally, e.g. outside heap governed by VM,
 there's nothing prevents you from having an address that pointing inside
 some buffer (or even outside it :)

 For NBExternalAddress:

 addr := self allocate: somespace.

 newAddr := NBExternalAddress value: addr value + someoffset.

 or

 newAddr := addr copy value: addr value + someoffset

 sure, it is up to you then, how to calculate offsets and buffer size(s) as
 well as allocating/deallocating memory for buffers you using.


 On 8 June 2015 at 16:41, Matthieu Lacaton matthieu.laca...@gmail.com
 wrote:

 Hello everyone,

 I have a small question about NativeBoost : How does the + operator
 when applied to a pointer translates into NativeBoost code ?

 To give a bit of context, what I want to do is to reallocate some
 non-contiguous bytes in memory to a buffer. Basically, I have an array of
 integers in a buffer and I want to copy some chunks of it in another
 buffer. The chunks are always the same size and the offset between each
 chunk is always the same too.

 Because a bit of actual code is easier to understand here is what I'd
 like to do in Pharo :

 ...

 int i, j;
 int *data = malloc(1000*sizeof(int));
 int *newData = malloc(50*sizeof(int));

 // Allocate initial data
 for (i = 0 ; i  1000, i++) {
   data[i] = i;
 }

 //Copy desired chunks into new buffer
 for (i = 0; i  5; i++ ) {
   memcpy( newData + j*10, data + 200 + j*30, 10*sizeof(int));
   j++;
 }

 free(data);

 ...

 Here basically I'll get in my buffer chunks of 10 integers starting at
 200 with an offset of 30 between chunks, and this 5 times. (200 201 202 ...
 208 209 230 231 ... 238 239 260 ... 328 329).

 I am okay with the malloc, memcpy and free but I don't know how to handle
 the + operator in my memcpy function.

 Thank you,

 Matthieu




 --
 Best regards,
 Igor Stasenko.

Re: [Pharo-users] NativeBoost pointer and +

[Henrik Johansen]

There are many ways to Rome :)
If you just need some externally allocated objects in the formats you specified 
you can do the cache extraction using nothing but normal Smalltalk:

intArray := (NBExternalArray ofType: 'int').

data := intArray new: 1000.
1 to:data size do:[:i |data at:i put: i].
cache := intArray new: 50.
0 to: 4 do: [:j | 
1 to: 10 do: [ :k |
cache at: (j* 10) + k put: (data at: 199 + (30 * j ) + k)] ].

But if you want to take full advantage of the performance boost NB offers, 
you'd write a NativeBoost function to do the cache extraction*, as I outlined 
last time:
MyClass class  #createCacheOf: aSource in: aDestination
createCacheOf: aSource in: aDestination
primitive: #primitiveNativeCall module: #NativeBoostPlugin
Should work on both x86 and x64, as long as sizeOf: lookups work 
correctly
^ self nbCallout 
function: #(void (int * aSource, int * aDestination) ) 
emit: [:gen :proxy :asm | |destReg srcReg tmpReg intSize 
ptrSize|
intSize := NBExternalType sizeOf: 'int'.
ptrSize := NBExternalType sizeOf: 'void *'.
Only use caller-saved regs, no preservation needed
destReg := asm EAX as: ptrSize.
srcReg := asm ECX as: ptrSize.
tmpReg := asm EDX as: intSize.
asm pop: srcReg.
asm pop: destReg.
0 to: 4 do: [ :j | 0 to: 9 do: [ :offset |
asm 
Displacement in bytes, not ptr element 
size :S, so we have to multiply offset by that manually :S
mov: tmpReg with: srcReg ptr + (199 + 
(j * 30) + offset * intSize);
mov: destReg ptr  + ((j* 10) + offset * 
intSize) with: tmpReg]]]  

and use that;
intArray := (NBExternalArray ofType: 'int').
data := intArray new: 1000. 
1 to:data size do:[:i |data at:i put: i].
cache := intArray new: 50.
MyClass createCacheOf: data in: cache.

The difference using a simple [] bench is about two orders of magnitude; 
11million cache extractions per seconds for the inline assembly version, while 
the naive loop achieves around 110k.

Cheers,
Henry

*as: is not yet defined, could be something like:
AJx86GPRegister  #as: aSize
^ self isHighByte
ifTrue: [ self asLowByte as: aSize ]
ifFalse: [ 
AJx86Registers
generalPurposeWithIndex: self index
size: aSize
requiresRex: self index  (aSize  1 ifTrue: 
[7] ifFalse: [ 3])
prohibitsRex: false ]


 On 09 Jun 2015, at 9:46 , Matthieu Lacaton matthieu.laca...@gmail.com wrote:
 
 Hello Henrik,
 
 Thank you very much for your answer. However, the code you provided is some 
 sort of assembly right ? So does it mean that I need to learn assembly to do 
 what I want ?
 
 I'm asking that because I don't know anything about assembly so it will take 
 me some time to learn.
 
 Cheers, 
 
 Matthieu
 
 2015-06-08 19:56 GMT+02:00 Henrik Johansen henrik.s.johan...@veloxit.no 
 mailto:henrik.s.johan...@veloxit.no:
 
  On 08 Jun 2015, at 4:41 , Matthieu Lacaton matthieu.laca...@gmail.com 
  mailto:matthieu.laca...@gmail.com wrote:
 
  Hello everyone,
 
  I have a small question about NativeBoost : How does the + operator when 
  applied to a pointer translates into NativeBoost code ?
 
  To give a bit of context, what I want to do is to reallocate some 
  non-contiguous bytes in memory to a buffer. Basically, I have an array of 
  integers in a buffer and I want to copy some chunks of it in another 
  buffer. The chunks are always the same size and the offset between each 
  chunk is always the same too.
 
  Because a bit of actual code is easier to understand here is what I'd like 
  to do in Pharo :
 
  ...
 
  int i, j;
  int *data = malloc(1000*sizeof(int));
  int *newData = malloc(50*sizeof(int));
 
  // Allocate initial data
  for (i = 0 ; i  1000, i++) {
data[i] = i;
  }
 
  //Copy desired chunks into new buffer
  for (i = 0; i  5; i++ ) {
memcpy( newData + j*10, data + 200 + j*30, 10*sizeof(int));
j++;
  }
 
  free(data);
 
 
 
 You can do relative addressing like this:
 (destReg ptr: dataSize) + offsetReg + constant
 
 So with offSetRegs containing j* 10 and j* 30, you might end up with an 
 unrolled inner loop (barring using any fancier longer-than-int moves) like:
 
 0 to: 9 do: [:constantOffset |
 asm mov: (destReg ptr: currentPlatform sizeOfInt) + dstOffsetReg + 
 constantOffset  with: (srcReg ptr: currentPlatform sizeOfInt) + 200 + 
 srcOffsetReg + constantOffset]
 
 If the range of j is constant, you can just as easily unroll the whole thing 
 in a similarly compact fashion, space and 

Re: [Pharo-users] NativeBoost pointer and +

[Henrik Johansen]

 On 09 Jun 2015, at 2:59 , Henrik Johansen henrik.s.johan...@veloxit.no 
 wrote:
 
 MyClass createCacheOf: data in: cache.

Forgot to change this; you need to pass in the ExternalArray addresses as 
parameters, not the ExternalArrays themselves.

MyClass createCacheOf: data address in: cache address

Cheers,
Henry

Re: [Pharo-users] NativeBoost pointer and +

[Henrik Johansen]

 On 08 Jun 2015, at 4:41 , Matthieu Lacaton matthieu.laca...@gmail.com wrote:
 
 Hello everyone, 
 
 I have a small question about NativeBoost : How does the + operator when 
 applied to a pointer translates into NativeBoost code ?
 
 To give a bit of context, what I want to do is to reallocate some 
 non-contiguous bytes in memory to a buffer. Basically, I have an array of 
 integers in a buffer and I want to copy some chunks of it in another buffer. 
 The chunks are always the same size and the offset between each chunk is 
 always the same too.
 
 Because a bit of actual code is easier to understand here is what I'd like to 
 do in Pharo : 
 
 ...
 
 int i, j;
 int *data = malloc(1000*sizeof(int));
 int *newData = malloc(50*sizeof(int));
 
 // Allocate initial data
 for (i = 0 ; i  1000, i++) {
   data[i] = i;
 }
 
 //Copy desired chunks into new buffer
 for (i = 0; i  5; i++ ) {
   memcpy( newData + j*10, data + 200 + j*30, 10*sizeof(int));
   j++;
 }
 
 free(data);



You can do relative addressing like this:
(destReg ptr: dataSize) + offsetReg + constant

So with offSetRegs containing j* 10 and j* 30, you might end up with an 
unrolled inner loop (barring using any fancier longer-than-int moves) like:

0 to: 9 do: [:constantOffset | 
asm mov: (destReg ptr: currentPlatform sizeOfInt) + dstOffsetReg + 
constantOffset  with: (srcReg ptr: currentPlatform sizeOfInt) + 200 + 
srcOffsetReg + constantOffset]

If the range of j is constant, you can just as easily unroll the whole thing in 
a similarly compact fashion, space and sensibilites permitting:

0 to: 4 do: [ :j | 0 to: 9 do: [ :consOffset | 
asm mov: (destReg ptr: currentPlatform sizeOfInt) + (j* 10) + 
constOffset  with: (srcReg ptr: currentPlatform sizeOfInt) + 200 + (j * 30) + 
constOffset]

Cheers,
Henry

[Pharo-users] NativeBoost pointer and +

[Matthieu Lacaton]

Hello everyone,

I have a small question about NativeBoost : How does the + operator when
applied to a pointer translates into NativeBoost code ?

To give a bit of context, what I want to do is to reallocate some
non-contiguous bytes in memory to a buffer. Basically, I have an array of
integers in a buffer and I want to copy some chunks of it in another
buffer. The chunks are always the same size and the offset between each
chunk is always the same too.

Because a bit of actual code is easier to understand here is what I'd like
to do in Pharo :

...

int i, j;
int *data = malloc(1000*sizeof(int));
int *newData = malloc(50*sizeof(int));

// Allocate initial data
for (i = 0 ; i  1000, i++) {
  data[i] = i;
}

//Copy desired chunks into new buffer
for (i = 0; i  5; i++ ) {
  memcpy( newData + j*10, data + 200 + j*30, 10*sizeof(int));
  j++;
}

free(data);

...

Here basically I'll get in my buffer chunks of 10 integers starting at 200
with an offset of 30 between chunks, and this 5 times. (200 201 202 ... 208
209 230 231 ... 238 239 260 ... 328 329).

I am okay with the malloc, memcpy and free but I don't know how to handle
the + operator in my memcpy function.

Thank you,

Matthieu

Re: [Pharo-users] NativeBoost : optimisation of the machine code generation

[Thomas Bany]

Okey, I found the issue and it was me doing lazy benchmark: I had forgot a
debug printing function in the C code, that I had removed between the
benchs.

Thanks again for your time !

Thomas.


2014-08-07 21:56 GMT+02:00 stepharo steph...@free.fr:

 NativeBoost methods compiles native code only once (the first time they
 are executed) and when sessionId changes (because you may be on a different
 platform).
 So this is already like that. The assembly code is cached in the method
 literal.

 Stef

 On 7/8/14 17:25, Thomas Bany wrote:

 Hi everyone,

 I'm trying to reduce the computation time of the following pseudo-code:

 - memory allocation (~40 doubles)
 - object heap to C heap copying
 - NativeBoost call (nbCall:)
 - memory freeing

 The time profiling results are bellow:

 - 24*3600 calls :  1 minute
 - 24*3600 calls with only memory allocation and copying :  1 second
 - 1 call with a 24*3600 loop inside de C code :  1 second

 So it appears that the very coslty step is the transition from Pharo to
 C. And I was wondering if it was possible to drasticly reduce this time by
 doing something like, generate the the machine code once and call it
 multiple time ?

 Thanks in advance !

 Thomas.

[Pharo-users] NativeBoost : optimisation of the machine code generation

[Thomas Bany]

Hi everyone,

I'm trying to reduce the computation time of the following pseudo-code:

- memory allocation (~40 doubles)
- object heap to C heap copying
- NativeBoost call (nbCall:)
- memory freeing

The time profiling results are bellow:

- 24*3600 calls :  1 minute
- 24*3600 calls with only memory allocation and copying :  1 second
- 1 call with a 24*3600 loop inside de C code :  1 second

So it appears that the very coslty step is the transition from Pharo to C.
And I was wondering if it was possible to drasticly reduce this time by
doing something like, generate the the machine code once and call it
multiple time ?

Thanks in advance !

Thomas.

Re: [Pharo-users] NativeBoost : optimisation of the machine code generation

[Luc Fabresse]

Hi Thomas,

2014-08-07 17:25 GMT+02:00 Thomas Bany mun.sys...@gmail.com:

 Hi everyone,

 I'm trying to reduce the computation time of the following pseudo-code:

 - memory allocation (~40 doubles)
 - object heap to C heap copying
 - NativeBoost call (nbCall:)
 - memory freeing

 The time profiling results are bellow:

 - 24*3600 calls :  1 minute
 - 24*3600 calls with only memory allocation and copying :  1 second
 - 1 call with a 24*3600 loop inside de C code :  1 second

 So it appears that the very coslty step is the transition from Pharo to C.
 And I was wondering if it was possible to drasticly reduce this time by
 doing something like, generate the the machine code once and call it
 multiple time ?


the machine code for the marshalling of the arguments is generated one time
for all.
so the penalty does not come from there.

please send the code you wrote for these micro-benchs so I can better
understand what happens.

Luc



 Thanks in advance !

 Thomas.

Re: [Pharo-users] NativeBoost : optimisation of the machine code generation

[kilon alios]

I think that if you posted the code , preferably that contains only the
problem would be easier to test , debug and investigate.



On Thu, Aug 7, 2014 at 6:25 PM, Thomas Bany mun.sys...@gmail.com wrote:

 Hi everyone,

 I'm trying to reduce the computation time of the following pseudo-code:

 - memory allocation (~40 doubles)
 - object heap to C heap copying
 - NativeBoost call (nbCall:)
 - memory freeing

 The time profiling results are bellow:

 - 24*3600 calls :  1 minute
 - 24*3600 calls with only memory allocation and copying :  1 second
 - 1 call with a 24*3600 loop inside de C code :  1 second

 So it appears that the very coslty step is the transition from Pharo to C.
 And I was wondering if it was possible to drasticly reduce this time by
 doing something like, generate the the machine code once and call it
 multiple time ?

 Thanks in advance !

 Thomas.

Re: [Pharo-users] NativeBoost : optimisation of the machine code generation

[Thomas Bany]

@ Alexandre: sure, no problem !

@ Luc:

I'm not sure how much code I can provide without being to specific, but
here is how it goes :


   - *Let's say I have the Smalltalk code bellow:*

*MyClass*withNBCall
   externalArray := *NBExternalArrayOfDoubles *new: *self *internalArray
size.
   output := *NBExternalArrayOfDoubles *new: 4.
   [*self *actualNBCallWith: externalArray adress storeResultIn: output adress]
ensure: [externalArray free. output free].

*MyClass*withNBCallCommented
   externalArray := *NBExternalArrayOfDoubles *new: *self *internalArray
size.
   output := *NBExternalArrayOfDoubles *new: 4.
   [self actualNBCallWith: externalArray adress storeResultIn: output
adress] ensure: [externalArray free. output free].

*MyClass*actualNBCallWith: externalArray storeResultIn: output
   primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin' error:
errorCode
   ^*self *nbCall: #(void callToC(double * externalArray, double * output))
module: 'lib/myModule.dll'


   - *And the C code bellow:*

*void *callToC(*double ** externalArray, *double ** output) {
   computationWith(externalArray, output);
}

*void *specialCallToC(*double ** externalArray, *double ** output) {
  * unsigned int* i;
   *for *(i = 0; i  24*3600; i++)
  computationWith(externalArray, output);
}


   - *Now I have the following code typed in Time Profiler tool :*

object := (*MyClass *new) variousInitialization; yourself
24*3600 timesRepeat: [object withNBCall]
 Over 1 minute computation time of which over 99% are primitives. Also I
don't see the nbCall: in the tree.

object := (*MyClass *new) variousInitialization; yourself
24*3600 timesRepeat: [object withNBCallCommented]
 Less than 1 second.

object := (*MyClass *new) variousInitialization; yourself
object withNBCall
 Less than 1 millisecond.

object := (*MyClass *new) variousInitialization; yourself
object withNBSpecialCall This time, I use the specialCallToC() function
 Arround 20 millisecond.


Allright, that's a pile of code but I hope it help :)

On a side note:

   - Pharo 3, Win 7 32-bit
   - I'm not at work anymore and don't have my code with me. So I will
   double check tomorow that I didn't provided false informations but I think
   it's accurate of what I do.


Again, thanks for the interest on my issue !

Thomas.



2014-08-07 18:39 GMT+02:00 kilon alios kilon.al...@gmail.com:

 I think that if you posted the code , preferably that contains only the
 problem would be easier to test , debug and investigate.



 On Thu, Aug 7, 2014 at 6:25 PM, Thomas Bany mun.sys...@gmail.com wrote:

 Hi everyone,

 I'm trying to reduce the computation time of the following pseudo-code:

 - memory allocation (~40 doubles)
 - object heap to C heap copying
 - NativeBoost call (nbCall:)
 - memory freeing

 The time profiling results are bellow:

 - 24*3600 calls :  1 minute
 - 24*3600 calls with only memory allocation and copying :  1 second
 - 1 call with a 24*3600 loop inside de C code :  1 second

 So it appears that the very coslty step is the transition from Pharo to
 C. And I was wondering if it was possible to drasticly reduce this time by
 doing something like, generate the the machine code once and call it
 multiple time ?

 Thanks in advance !

 Thomas.

Re: [Pharo-users] NativeBoost : optimisation of the machine code generation

[Thomas Bany]

I forgot the copying of the data from the object heap to C heap:

*MyClass*withNBCall
   externalArray := *NBExternalArrayOfDoubles *new: *self *internalArray
size.
   output := *NBExternalArrayOfDoubles *new: 4.
   1 to: *self *internalArray size. do: [ :index | externalArray at: index
(put: *self *internalArray at: index) ].
   [*self *actualNBCallWith: externalArray adress storeResultIn: output adress]
ensure: [externalArray free. output free].

*MyClass*withNBCallCommented
   externalArray := *NBExternalArrayOfDoubles *new: *self *internalArray
size.
   output := *NBExternalArrayOfDoubles *new: 4.
   1 to: *self *internalArray size. do: [ :index | externalArray at: index
(put: *self *internalArray at: index) ].
   [self actualNBCallWith: externalArray adress storeResultIn: output
adress] ensure: [externalArray free. output free].

Thomas.



2014-08-07 19:15 GMT+02:00 Thomas Bany mun.sys...@gmail.com:

 @ Alexandre: sure, no problem !

 @ Luc:

 I'm not sure how much code I can provide without being to specific, but
 here is how it goes :


- *Let's say I have the Smalltalk code bellow:*

 *MyClass*withNBCall
externalArray := *NBExternalArrayOfDoubles *new: *self *internalArray
 size.
output := *NBExternalArrayOfDoubles *new: 4.
[*self *actualNBCallWith: externalArray adress storeResultIn: output 
 adress]
 ensure: [externalArray free. output free].

 *MyClass*withNBCallCommented
externalArray := *NBExternalArrayOfDoubles *new: *self *internalArray
 size.
output := *NBExternalArrayOfDoubles *new: 4.
[self actualNBCallWith: externalArray adress storeResultIn: output
 adress] ensure: [externalArray free. output free].

 *MyClass*actualNBCallWith: externalArray storeResultIn: output
primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin' error:
 errorCode
^*self *nbCall: #(void callToC(double * externalArray, double *
 output)) module: 'lib/myModule.dll'


- *And the C code bellow:*

 *void *callToC(*double ** externalArray, *double ** output) {
computationWith(externalArray, output);
 }

 *void *specialCallToC(*double ** externalArray, *double ** output) {
   * unsigned int* i;
*for *(i = 0; i  24*3600; i++)
   computationWith(externalArray, output);
 }


- *Now I have the following code typed in Time Profiler tool :*

 object := (*MyClass *new) variousInitialization; yourself
 24*3600 timesRepeat: [object withNBCall]
  Over 1 minute computation time of which over 99% are primitives. Also I
 don't see the nbCall: in the tree.

 object := (*MyClass *new) variousInitialization; yourself
 24*3600 timesRepeat: [object withNBCallCommented]
  Less than 1 second.

 object := (*MyClass *new) variousInitialization; yourself
 object withNBCall
  Less than 1 millisecond.

 object := (*MyClass *new) variousInitialization; yourself
 object withNBSpecialCall This time, I use the specialCallToC() function
  Arround 20 millisecond.


 Allright, that's a pile of code but I hope it help :)

 On a side note:

- Pharo 3, Win 7 32-bit
- I'm not at work anymore and don't have my code with me. So I will
double check tomorow that I didn't provided false informations but I think
it's accurate of what I do.


 Again, thanks for the interest on my issue !

 Thomas.



 2014-08-07 18:39 GMT+02:00 kilon alios kilon.al...@gmail.com:

 I think that if you posted the code , preferably that contains only the
 problem would be easier to test , debug and investigate.



 On Thu, Aug 7, 2014 at 6:25 PM, Thomas Bany mun.sys...@gmail.com wrote:

 Hi everyone,

 I'm trying to reduce the computation time of the following pseudo-code:

 - memory allocation (~40 doubles)
 - object heap to C heap copying
 - NativeBoost call (nbCall:)
 - memory freeing

 The time profiling results are bellow:

 - 24*3600 calls :  1 minute
 - 24*3600 calls with only memory allocation and copying :  1 second
 - 1 call with a 24*3600 loop inside de C code :  1 second

 So it appears that the very coslty step is the transition from Pharo to
 C. And I was wondering if it was possible to drasticly reduce this time by
 doing something like, generate the the machine code once and call it
 multiple time ?

 Thanks in advance !

 Thomas.

Re: [Pharo-users] NativeBoost : optimisation of the machine code generation

[stepharo]

NativeBoost methods compiles native code only once (the first time they 
are executed) and when sessionId changes (because you may be on a 
different platform).
So this is already like that. The assembly code is cached in the method 
literal.


Stef
On 7/8/14 17:25, Thomas Bany wrote:

Hi everyone,

I'm trying to reduce the computation time of the following pseudo-code:

- memory allocation (~40 doubles)
- object heap to C heap copying
- NativeBoost call (nbCall:)
- memory freeing

The time profiling results are bellow:

- 24*3600 calls :  1 minute
- 24*3600 calls with only memory allocation and copying :  1 second
- 1 call with a 24*3600 loop inside de C code :  1 second

So it appears that the very coslty step is the transition from Pharo 
to C. And I was wondering if it was possible to drasticly reduce this 
time by doing something like, generate the the machine code once and 
call it multiple time ?


Thanks in advance !

Thomas.

Re: [Pharo-users] NativeBoost: use of array

[Pierce Ng]

On Mon, Aug 04, 2014 at 04:45:46PM +0200, Thomas Bany wrote:
 self nbCall: #( void propagateTLE(orbit_t orbit, NBExternalAddress
  secondSince, NBExternalAddress out, size_t nbEpoch) )
 
 But it feels like I'm cheating my way trough, by pretty much avoiding any
 type check. Any clue as to why the typecheck of NB is refusing to call my
 function ?

I'm not sure if this addresses (heh) your issue, but in NBSQLite3, I do what
Punqlite does:

NBSQLite3FFI classinitializeTypeMap

TypeMap := Dictionary newFromPairs: #(
sqlite3  NBExternalObject
sqlite3_stmt NBExternalObject
sqlite_int64 NBInt64
)

NBSQLite3FFI classnbBindingOf: aTypeName
^ TypeMap at: aTypeName ifAbsent: [ super nbBindingOf: aTypeName ]

NBSQLite3FFIapiOpen: filename via: handle
int sqlite3_open(const char*, sqlite3**)
primitive: #primitiveNativeCall module: #NativeBoostPlugin error: 
errorCode
^ self nbCall: #(int sqlite3_open (String filename, sqlite3* handle))
module: self library

handle is the out parameter in sqlite3_open().

NBSQLite3 is at http://ss3.gemtalksystems.com/ss/NBSQLite3.

Punqlite is on Smalltalk Hub.

-- 
Pierce Ng
http://www.samadhiweb.com/blog/

Re: [Pharo-users] NativeBoost: use of array

[Igor Stasenko]

On 4 August 2014 16:45, Thomas Bany mun.sys...@gmail.com wrote:

 Hi again !


 I'm having trouble to call the function with the following prototype :

 void propagateTLE(orbit_t orb, double secondSince[], xyz_t * out, size_t
 nbEpoch)


 with the corresponding NB call:

 self nbCall: #( void propagateTLE(orbit_t orbit, double * secondSince,
 xyz_t * out, size_t nbEpoch) )


 The argument *secondSince* is an input and the argument *out* is the
 output pointer that the function should fill. I have made 2 subclass of
 NBExternalArray to feed this function, (allmost) namely: *ArrayOfDoubles *and
 *ArrayOfXYZ*. Should I mention that type *xyz_t* is a struct that I
 modeled with an *NBExternalStructure*.

 I face 2 issues:

- The type *ArrayOfXYZ* is refused as an *xyz_t** type. However, the 
 *ArrayOfDoubles
*is accepted as a *double** type.
- If a get rid of the *out* argument to test the array *secondSince*,
I get an undefined error (Error durring FFI call: nil).



 My current solution is to use the adress of my arrays and the following NB
 call:

 self nbCall: #( void propagateTLE(orbit_t orbit, NBExternalAddress
 secondSince, NBExternalAddress out, size_t nbEpoch) )


 if you explicitly specify NBExternalAddress, then it won't accept any
other argument than instance of NBExternalAddress.

Also, note there's no marshallers for (sub)instances of NBExternalArray,
and thus you cannot pass them directly, but only by passing pointer to its
elements using #address method.

I.e, if you using 'whatever *', you can pass a pointer to array by:
myArray address.



 But it feels like I'm cheating my way trough, by pretty much avoiding any
 type check. Any clue as to why the typecheck of NB is refusing to call my
 function ?


 Thanks in advance,

 Thomas.




-- 
Best regards,
Igor Stasenko.

Re: [Pharo-users] NativeBoost: use of array

[Thomas Bany]

All right !

Tanks again for you answers and kudos for the NB plugin ! I was kinda
scared of doing stuff outside of the image but everything went super smooth.


2014-08-05 16:45 GMT+02:00 Igor Stasenko siguc...@gmail.com:




 On 4 August 2014 16:45, Thomas Bany mun.sys...@gmail.com wrote:

 Hi again !


 I'm having trouble to call the function with the following prototype :

 void propagateTLE(orbit_t orb, double secondSince[], xyz_t * out, size_t
 nbEpoch)


 with the corresponding NB call:

 self nbCall: #( void propagateTLE(orbit_t orbit, double * secondSince,
 xyz_t * out, size_t nbEpoch) )


 The argument *secondSince* is an input and the argument *out* is the
 output pointer that the function should fill. I have made 2 subclass of
 NBExternalArray to feed this function, (allmost) namely: *ArrayOfDoubles
 *and *ArrayOfXYZ*. Should I mention that type *xyz_t* is a struct that I
 modeled with an *NBExternalStructure*.

 I face 2 issues:

- The type *ArrayOfXYZ* is refused as an *xyz_t** type. However, the 
 *ArrayOfDoubles
*is accepted as a *double** type.
- If a get rid of the *out* argument to test the array *secondSince*,
I get an undefined error (Error durring FFI call: nil).



 My current solution is to use the adress of my arrays and the following
 NB call:

 self nbCall: #( void propagateTLE(orbit_t orbit, NBExternalAddress
 secondSince, NBExternalAddress out, size_t nbEpoch) )


 if you explicitly specify NBExternalAddress, then it won't accept any
 other argument than instance of NBExternalAddress.

 Also, note there's no marshallers for (sub)instances of NBExternalArray,
 and thus you cannot pass them directly, but only by passing pointer to its
 elements using #address method.

 I.e, if you using 'whatever *', you can pass a pointer to array by:
 myArray address.



 But it feels like I'm cheating my way trough, by pretty much avoiding any
 type check. Any clue as to why the typecheck of NB is refusing to call my
 function ?


 Thanks in advance,

 Thomas.




 --
 Best regards,
 Igor Stasenko.

[Pharo-users] NativeBoost: structure with different types

[Thomas Bany]

Hi everyone !

I experience troubles with NBExternalStructure in NativeBoost when the
structure modeled contains fields with different types. For example,
manipulating the following structure poses no problem and I can manipulate
the fields correctly:

typedef struct abc_s {
double a;
double b;
double c;
} abc;

However, setting field 'a' to be an int yields the following symptoms:
  ¤ From Pharo to C (function with 'abc' as argument type), the fields are
badly read.
  ¤ From C to Pharo (function with 'abc' as return type), the VM crash
without an error nor a dump.

Am I doing something wrong or is it maybe specific to the compiler I use
(the one that comes with Visual Studio Express 2013) ?


I'm pretty sure I could go arround this using NBExternalObject and building
the structure on C side, but it would be nice to avoid it.


On a side note, my understanding is that creating a structure on Pharo side
will have it stored in Pharo memory. Is it problematic when it comes to
pass it by value ? Or should I manage the copying on the C heap to be safe ?


Thomas.

Re: [Pharo-users] NativeBoost: structure with different types

[Igor Stasenko]

On 4 August 2014 12:37, Thomas Bany mun.sys...@gmail.com wrote:

 Hi everyone !

 I experience troubles with NBExternalStructure in NativeBoost when the
 structure modeled contains fields with different types. For example,
 manipulating the following structure poses no problem and I can manipulate
 the fields correctly:

 typedef struct abc_s {
 double a;
 double b;
 double c;
 } abc;

 However, setting field 'a' to be an int yields the following symptoms:
   ¤ From Pharo to C (function with 'abc' as argument type), the fields are
 badly read.
   ¤ From C to Pharo (function with 'abc' as return type), the VM crash
 without an error nor a dump.

 Am I doing something wrong or is it maybe specific to the compiler I use
 (the one that comes with Visual Studio Express 2013) ?



This caused by wrong alignment of structure in memory. Different compilers
can align structures differently, and there's no way to know it at run time.

Try to change the #
*byteAlignment of the structure.Also, if nothing helps, you can use dummy
fields* for padding fields, like in your example:

int a;
int dummy;
double b;
double c;


 I'm pretty sure I could go arround this using NBExternalObject and
 building the structure on C side, but it would be nice to avoid it.


 On a side note, my understanding is that creating a structure on Pharo
 side will have it stored in Pharo memory. Is it problematic when it comes
 to pass it by value ? Or should I manage the copying on the C heap to be
 safe ?


 Thomas.




-- 
Best regards,
Igor Stasenko.

Re: [Pharo-users] NativeBoost: structure with different types

[Thomas Bany]

The compiler indeed inserted 32 dummy bits between the first (32 bits) and
second (64 bits) field. It feels like it want to align its 64 bits fields
on 64 bits chunk of bits because the 32 bits fields at the end of my
structure are contiguous.

Simply move the first 32 bits field at the end of the structure might sovle
it !

Thanks a lot for the quick response !!



2014-08-04 13:18 GMT+02:00 Igor Stasenko siguc...@gmail.com:




 On 4 August 2014 12:37, Thomas Bany mun.sys...@gmail.com wrote:

 Hi everyone !

 I experience troubles with NBExternalStructure in NativeBoost when the
 structure modeled contains fields with different types. For example,
 manipulating the following structure poses no problem and I can manipulate
 the fields correctly:

 typedef struct abc_s {
 double a;
 double b;
 double c;
 } abc;

 However, setting field 'a' to be an int yields the following symptoms:
   ¤ From Pharo to C (function with 'abc' as argument type), the fields
 are badly read.
   ¤ From C to Pharo (function with 'abc' as return type), the VM crash
 without an error nor a dump.

 Am I doing something wrong or is it maybe specific to the compiler I use
 (the one that comes with Visual Studio Express 2013) ?



 This caused by wrong alignment of structure in memory. Different compilers
 can align structures differently, and there's no way to know it at run time.

 Try to change the #
 *byteAlignment of the structure.Also, if nothing helps, you can use dummy
 fields* for padding fields, like in your example:

 int a;
 int dummy;
 double b;
 double c;


 I'm pretty sure I could go arround this using NBExternalObject and
 building the structure on C side, but it would be nice to avoid it.


 On a side note, my understanding is that creating a structure on Pharo
 side will have it stored in Pharo memory. Is it problematic when it comes
 to pass it by value ? Or should I manage the copying on the C heap to be
 safe ?


 Thomas.




 --
 Best regards,
 Igor Stasenko.

[Pharo-users] NativeBoost: use of array

[Thomas Bany]

Hi again !


I'm having trouble to call the function with the following prototype :

void propagateTLE(orbit_t orb, double secondSince[], xyz_t * out, size_t
 nbEpoch)


with the corresponding NB call:

self nbCall: #( void propagateTLE(orbit_t orbit, double * secondSince,
 xyz_t * out, size_t nbEpoch) )


The argument *secondSince* is an input and the argument *out* is the output
pointer that the function should fill. I have made 2 subclass of
NBExternalArray to feed this function, (allmost) namely: *ArrayOfDoubles *and
*ArrayOfXYZ*. Should I mention that type *xyz_t* is a struct that I modeled
with an *NBExternalStructure*.

I face 2 issues:

   - The type *ArrayOfXYZ* is refused as an *xyz_t** type. However,
the *ArrayOfDoubles
   *is accepted as a *double** type.
   - If a get rid of the *out* argument to test the array *secondSince*, I
   get an undefined error (Error durring FFI call: nil).



My current solution is to use the adress of my arrays and the following NB
call:

self nbCall: #( void propagateTLE(orbit_t orbit, NBExternalAddress
 secondSince, NBExternalAddress out, size_t nbEpoch) )


But it feels like I'm cheating my way trough, by pretty much avoiding any
type check. Any clue as to why the typecheck of NB is refusing to call my
function ?


Thanks in advance,

Thomas.

Re: [Pharo-users] NativeBoost

[Markus Fritsche]

On 2014-04-30 04:58, Igor Stasenko wrote:

NBFFICalloutforeignCall: aBlock



callInfo := self newCallInfo.
callInfo alignment: 16.
asm performingCall: callInfo in: aBlock.



while use:
NativeBoostWin32stackAlignment
^ 1


This seems to work - however, I did not to subsequent calls.


and then swap values.


That crashes instantaneously.

Best regards,
  Markus

Re: [Pharo-users] NativeBoost

[Igor Stasenko]

On 30 April 2014 11:09, Markus Fritsche mfrits...@reauktion.de wrote:

 On 2014-04-30 04:58, Igor Stasenko wrote:

 NBFFICalloutforeignCall: aBlock


  callInfo := self newCallInfo.
 callInfo alignment: 16.
 asm performingCall: callInfo in: aBlock.


  while use:
 NativeBoostWin32stackAlignment
 ^ 1


 This seems to work - however, I did not to subsequent calls.

 did not what?


  and then swap values.


 That crashes instantaneously.


So, it seems that it is DLL function wants stack alignment.


 Best regards,
   Markus




-- 
Best regards,
Igor Stasenko.

Re: [Pharo-users] NativeBoost

[Markus Fritsche]

On 2014-04-30 11:35, Igor Stasenko wrote:


So, it seems that it is DLL function wants stack alignment.


So does that mean (doing it the right way) that I will have to change my 
stackAlignment method or do I have to use different nbCall-sonventions?


Best regards,
  Markus

Re: [Pharo-users] NativeBoost

[Igor Stasenko]

On 30 April 2014 11:46, Markus Fritsche mfrits...@reauktion.de wrote:

 On 2014-04-30 11:35, Igor Stasenko wrote:

  So, it seems that it is DLL function wants stack alignment.


 So does that mean (doing it the right way) that I will have to change my
 stackAlignment method or do I have to use different nbCall-sonventions?


It is safer to change it for whole platform, e.g in:
NativeBoostWin32stackAlignment


 Best regards,
   Markus




-- 
Best regards,
Igor Stasenko.

Re: [Pharo-users] NativeBoost

[Igor Stasenko]

On 29 April 2014 20:54, Markus Fritsche mfrits...@reauktion.de wrote:

 Hello Igor,

 I did change my class (tbh, I was just looking at the Cairo stuff and
 did some cargo cult programming).

 NBFFICallout new resolveType: #TM1U prints TM1U

 NBFFICallout new resolveType: #TM1P prints TM1P

 - my DoIt still gives NBExternalType

 I attached the resulting CompiledMethod as a fuel serialized file.

 What can I look at more deeply?

 i don't know what is going on..
everything looks correct..

as a workaround, you can change the return type of offending call to return
uint,
and then you can manually convert it to instance of TM1P with corresponding
handle value.

Also, i doubt it, but try change the alignment
NativeBoostWin32stackAlignment
 to use 16


P.S. the fuel file with compiled method is not really helpful - it gives me
an error during materialization.


 Thank you for your patience,
   Markus

 On 29.04.2014 00:36, Igor Stasenko wrote:
  Object subclass: #TM1U
  uses: TTM1ApiLibrary
  instanceVariableNames: 'handle'
  classVariableNames: ''
  poolDictionaries: ''
  category: 'Cognos-TM1-Api'
 
  hmm.. why just don't subclass from NBExternalObject?
  If you don't need to subclass from own base class, you can just subclass
  from
  NBExternalObject, which means you already having handle ivar, and
  #asNBExternalType: inherited at class side, tested and working..?
 
 
  So, try
 
  NBFFICallout new resolveType: #TM1U
 
  what it gives?
 
  On 28 April 2014 23:44, Markus Fritsche mfrits...@reauktion.de wrote:
 
 
  On 28.04.2014 13:30, Igor Stasenko wrote:
  This is strange.. should work fine. There's no way how
  NBExternalObjectType could return an instance of NBExternalHandle.
  Please check your code again.
  Been there, done that = thrown everything away and restarted the code
  from scratch... Sourcecode attached (the 32bit libraries are in the bin
  subdirectory, there's another bin64 directory) - is there anything
  obvious wrong with it?.
 
  Workspace:
  
  TM1LibraryLoader loadTM1Library.
 
  TM1Library tm1APIInitialize.
  hUser := TM1Library tm1SystemOpen.
  hPool1 := hUser tm1ValPoolCreate.
  hPool1 inspect.
  hUser tm1SystemClose.
  TM1Library tm1APIFinalize.
  
 
  The Inspector I get shows
  NBExternalHandle
  self@ 16r74CF4A8
  (apparently it's fine for TM1U, otherwise tm1ValPoolCreate wouldn't be
  found)
 
  could it be inspector screwed?
  what
  hPool1 class
  gives?
 
 
  From the headers:
 
  #define TM1API __stdcall
  #ifndef TM1IMPORT
#define TM1IMPORT __declspec( dllimport )
  #endif
 
  typedef void * TM1U;   // user  handle
  typedef void * TM1P;   // pool  handle
  TM1IMPORT void TM1API TM1APIInitialize( void );
  TM1IMPORT TM1U TM1API TM1SystemOpen( void );
  TM1IMPORT TM1P TM1API TM1ValPoolCreate( TM1U hUser );
 
 
   i don't see where you are using stdcall calling convention option?
   you should specify it either in code:
 
  self nbCallout
 stdCall
 function: #( TM1U  TM1SystemOpen( ) ) module:
 
  or in the class with callout, implementing
 
  ffiCalloutOptions
  ^ #( + optStdcall )
 
  (i think you can just put it into trait)
 
 
  In order to debug further I will have to redo the Windows VM.
 
 
 
 




-- 
Best regards,
Igor Stasenko.

Re: [Pharo-users] NativeBoost

[Markus Fritsche]

Hello Igor,

 Also, i doubt it, but try change the alignment
 NativeBoostWin32stackAlignment
  to use 16

That did the trick - it was ^ 1 - changed it to ^ 16 and now the DoIt
opens an inspector on a TM1P object.

Should this be reported on fogbugz?

Thank you
  Markus

Re: [Pharo-users] NativeBoost

[Igor Stasenko]

On 26 April 2014 09:44, Markus Fritsche mfrits...@reauktion.de wrote:

 Hello,

 tl;dr: what's the reason to get aNBExternalHandle even if you expect a
 MySuperHandle object from an nbCall?

 I am trying to build my first DLL wrapper with NativeBoost. I am having a
 problem that instead of returning a handle object (as I thought), my
 primitive throws NBExternalHandles at me.

 The API I am trying to wrap tries to be somewhat object oriented by
 (mostly) having a handle of some sort.

 My thinking was to attach all DLL primitives to the respective Handle
 Objects they take as a first parameter and go from there.

 Some workspace code:

 Supplementary DLLs
 Tm1ULibDllLibraryLoader loadLibrary.
 LibIbmCogEayLibraryLoader loadLibrary.
 SslIbmCogEayLibraryLoader loadLibrary.
 Log4CxxLibraryLoader loadLibrary.
 DLL to wrap
 TM1LibraryLoader loadTM1Library.

 t := TM1Api new.
 t tm1APIInitialize.
 hUser := t tm1SystemOpen. Returns a proper 'TM1UHandle' object'
 hUser tm1SystemAdminHostSet: 'localhost'.
 hPool1 := hUser tm1ValPoolCreate. Returns NBExternalHandle
 hPool1 inspect.
 hUser tm1SystemClose.
 t tm1APIFinalize.

 TM1Api#tm1SystemOpen
 primitive: #primitiveNativeCall
  module: #NativeBoostPlugin
 ^ self nbCall: #(TM1UHandle TM1SystemOpen(void))

 TM1UHandle#tm1ValPoolCreate
 primitive: #primitiveNativeCall
  module: #NativeBoostPlugin
 ^ self nbCall: #(#TM1PHandle TM1ValPoolCreate ( TM1UHandle self ) )

 sidenote: when using 'self', you can use it without type. just say 'self',
since it refers to
the instance of method's class, which is enough to determine the type to
use for marshalling.


 Both, TM1UHandle class and TM1PHandle class have the method
 asNBExternalType: gen
 use handle ivar to hold my instance (TM1x)
 ^ NBExternalObjectType objectClass: self

 and are subclasses of object. What's my mistake? Can you tell with the
 information I provided?


This is strange.. should work fine.
There's no way how NBExternalObjectType could return an instance of
NBExternalHandle.
Please check your code again.

Best regards,
   Markus




-- 
Best regards,
Igor Stasenko.

Re: [Pharo-users] NativeBoost

[Markus Fritsche]

On 28.04.2014 13:30, Igor Stasenko wrote:
 This is strange.. should work fine. There's no way how
 NBExternalObjectType could return an instance of NBExternalHandle.
 Please check your code again.
Been there, done that = thrown everything away and restarted the code
from scratch... Sourcecode attached (the 32bit libraries are in the bin
subdirectory, there's another bin64 directory) - is there anything
obvious wrong with it?.

Workspace:

TM1LibraryLoader loadTM1Library.

TM1Library tm1APIInitialize.
hUser := TM1Library tm1SystemOpen.
hPool1 := hUser tm1ValPoolCreate.
hPool1 inspect.
hUser tm1SystemClose.
TM1Library tm1APIFinalize.


The Inspector I get shows
NBExternalHandle
self@ 16r74CF4A8
(apparently it's fine for TM1U, otherwise tm1ValPoolCreate wouldn't be
found)

From the headers:

#define TM1API __stdcall
#ifndef TM1IMPORT
  #define TM1IMPORT __declspec( dllimport )
#endif

typedef void * TM1U;   // user  handle 
typedef void * TM1P;   // pool  handle   
TM1IMPORT void TM1API TM1APIInitialize( void );
TM1IMPORT TM1U TM1API TM1SystemOpen( void ); 
TM1IMPORT TM1P TM1API TM1ValPoolCreate( TM1U hUser );


In order to debug further I will have to redo the Windows VM.
Trait named: #TTM1ApiLibrary
uses: {}
category: 'Cognos-TM1-Api'!
!TTM1ApiLibrary commentStamp: 'MarkusFritsche 4/28/2014 22:01' prior: 0!
a simple trait used for NB callouts to TM1 library functions!


!TTM1ApiLibrary methodsFor: 'library path' stamp: 'MarkusFritsche 4/28/2014 
21:59'!
nbLibraryNameOrHandle
^ self class nbLibraryNameOrHandle
! !

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- !

TTM1ApiLibrary classTrait
uses: {}!
!TTM1ApiLibrary classTrait commentStamp: 'historical' prior: 0!
!


!TTM1ApiLibrary classTrait methodsFor: 'library path' stamp: 'MarkusFritsche 
4/28/2014 22:00'!
nbLibraryNameOrHandle
^ TM1LibraryLoader getLibraryHandle! !


Object subclass: #TM1U
uses: TTM1ApiLibrary
instanceVariableNames: 'handle'
classVariableNames: ''
poolDictionaries: ''
category: 'Cognos-TM1-Api'!
!TM1U commentStamp: 'historical' prior: 0!
!


!TM1U methodsFor: 'library path' stamp: 'MarkusFritsche 4/28/2014 23:18'!
tm1ValPoolCreate
primitive: #primitiveNativeCall module: #NativeBoostPlugin error: 
errorCode

^ self nbCall: #(TM1P TM1ValPoolCreate(self))! !

!TM1U methodsFor: 'library path' stamp: 'MarkusFritsche 4/28/2014 22:52'!
tm1SystemClose
primitive: #primitiveNativeCall module: #NativeBoostPlugin error: 
errorCode

^ self nbCall: #(void TM1SystemClose(self))! !

!TM1U methodsFor: 'library path'!
nbLibraryNameOrHandle
^ self class nbLibraryNameOrHandle
! !

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- !

TM1U class
uses: TTM1ApiLibrary classTrait
instanceVariableNames: ''!
!TM1U class commentStamp: 'historical' prior: 0!
!


!TM1U class methodsFor: 'as yet unclassified' stamp: 'MarkusFritsche 4/28/2014 
22:40'!
asNBExternalType: gen
use handle ivar to hold my instance (TM1U)
^ NBExternalObjectType objectClass: self! !


!TM1U class methodsFor: 'library path'!
nbLibraryNameOrHandle
^ TM1LibraryLoader getLibraryHandle! !


Object subclass: #TM1Library
uses: TTM1ApiLibrary
instanceVariableNames: 'handle'
classVariableNames: ''
poolDictionaries: ''
category: 'Cognos-TM1-Api'!
!TM1Library commentStamp: 'historical' prior: 0!
!


!TM1Library methodsFor: 'library path'!
nbLibraryNameOrHandle
^ self class nbLibraryNameOrHandle
! !

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- !

TM1Library class
uses: TTM1ApiLibrary classTrait
instanceVariableNames: 'uniqueSession'!
!TM1Library class commentStamp: 'historical' prior: 0!
!


!TM1Library class methodsFor: 'library path'!
nbLibraryNameOrHandle
^ TM1LibraryLoader getLibraryHandle! !


!TM1Library class methodsFor: 'as yet unclassified' stamp: 'MarkusFritsche 
4/28/2014 23:18'!
tm1SystemOpen
primitive: #primitiveNativeCall module: #NativeBoostPlugin error: 
errorCode

^ self nbCall: #(TM1U TM1SystemOpen(void))! !

!TM1Library class methodsFor: 'as yet unclassified' stamp: 'MarkusFritsche 
4/28/2014 22:53'!
tm1APIFinalize
primitive: #primitiveNativeCall module: #NativeBoostPlugin error: 
errorCode

^ self nbCall: #(void TM1APIFinalize(void))! !

!TM1Library class methodsFor: 'as yet unclassified' stamp: 'MarkusFritsche 
4/28/2014 22:51'!
tm1APIInitialize
primitive: #primitiveNativeCall module: #NativeBoostPlugin error: 
errorCode

^ self nbCall: #(void TM1APIInitialize(void))! !


Object subclass: #TM1P
uses: TTM1ApiLibrary
instanceVariableNames: 'handle'
classVariableNames: ''
poolDictionaries: ''
category: 'Cognos-TM1-Api'!
!TM1P 

Re: [Pharo-users] NativeBoost

[Igor Stasenko]

Object subclass: #TM1U
uses: TTM1ApiLibrary
instanceVariableNames: 'handle'
classVariableNames: ''
poolDictionaries: ''
category: 'Cognos-TM1-Api'

hmm.. why just don't subclass from NBExternalObject?
If you don't need to subclass from own base class, you can just subclass
from
NBExternalObject, which means you already having handle ivar, and
#asNBExternalType: inherited at class side, tested and working..?


So, try

NBFFICallout new resolveType: #TM1U

what it gives?

On 28 April 2014 23:44, Markus Fritsche mfrits...@reauktion.de wrote:


 On 28.04.2014 13:30, Igor Stasenko wrote:
  This is strange.. should work fine. There's no way how
  NBExternalObjectType could return an instance of NBExternalHandle.
  Please check your code again.
 Been there, done that = thrown everything away and restarted the code
 from scratch... Sourcecode attached (the 32bit libraries are in the bin
 subdirectory, there's another bin64 directory) - is there anything
 obvious wrong with it?.

 Workspace:
 
 TM1LibraryLoader loadTM1Library.

 TM1Library tm1APIInitialize.
 hUser := TM1Library tm1SystemOpen.
 hPool1 := hUser tm1ValPoolCreate.
 hPool1 inspect.
 hUser tm1SystemClose.
 TM1Library tm1APIFinalize.
 

 The Inspector I get shows
 NBExternalHandle
 self@ 16r74CF4A8
 (apparently it's fine for TM1U, otherwise tm1ValPoolCreate wouldn't be
 found)

 could it be inspector screwed?
what
hPool1 class
gives?


 From the headers:

 #define TM1API __stdcall
 #ifndef TM1IMPORT
   #define TM1IMPORT __declspec( dllimport )
 #endif

 typedef void * TM1U;   // user  handle
 typedef void * TM1P;   // pool  handle
 TM1IMPORT void TM1API TM1APIInitialize( void );
 TM1IMPORT TM1U TM1API TM1SystemOpen( void );
 TM1IMPORT TM1P TM1API TM1ValPoolCreate( TM1U hUser );


 i don't see where you are using stdcall calling convention option?
 you should specify it either in code:

self nbCallout
   stdCall
   function: #( TM1U  TM1SystemOpen( ) ) module:

or in the class with callout, implementing

ffiCalloutOptions
^ #( + optStdcall )

(i think you can just put it into trait)


 In order to debug further I will have to redo the Windows VM.




-- 
Best regards,
Igor Stasenko.

Re: [Pharo-users] NativeBoost and standard out

[Emilio Oca]

Hi Esteban
 I recommend you to take a look at this: 
 http://smalltalkhub.com/#!/~OS/OS-Windows
 there can be a solution (not sure, because I never used it)
Yes I did, I got something like this

si := WinStartupInfo new.
si wShowWindow: 0.
pi := WinProcessInformation new.
WinProcess createProcess: aCommand startupInfo: si processInformation:
pi.
[ (WinProcess waitForSingleObject: pi hProcess timeout: 10)  0 ]
whileTrue: [
 (Delay forMilliseconds: 10) wait.
].
pi hProcess closeHandle.
pi hThread closeHandle.
That gives me some synchronicity betwtenn several of these proceses without
freezing the image
aCommand may be...
'sqlplus -S usr/pass@QA @V:\work\suite.sql  proc.log' works but doesn't
writes into proc.log
'c:\path\test.bat  proc.log' works as expected

I am looking for a way to get at least the sql sentence stdout writen into a
file.


 Other possibility is not using NB but OSProcess: 
 http://www.squeaksource.com/OSProcess.html
 hope it solves your problem. 
I am exploring this now, thanks

 cheers, 
 Esteban   

Best 

Emilio


-- 
Best regards,
Igor Stasenko. 

Re: [Pharo-users] NativeBoost callbacks from different threads?

[Clément Bera]

Hello,

This is still true in Pharo 3 AFAIK. With NativeBoost you need to have the
call back in the same thread as the VM.

If you want multithreaded callback you can do it through the FFI VM plugin
and the Cog Multi threaded VM (you can find the CogMT VM prebuilt for Pharo
here: https://ci.inria.fr/pharo/view/VM/job/CogMTVM/ ). However it depends
what you want to do with your call backs. This VM looks stable but very few
people use it so it may not be as stable as it looks like. So if you plan
to use it for real (like production app) do some experiments before to see
if your use cases work fine.




2014-02-02 Joachim Geidel joachim.gei...@onlinehome.de:

 In 2012, Igor Stasenko wrote: the limitation is multithreading. callback
 should be called in same
 thread as VM.
 http://forum.world.st/NativeBoost-callbacks-status-td4656362.html#a4656371

 Is this still true in Pharo 3.0? If it is, I don't have to search for the
 reason why my Pharo code is equivalent to Pharo become: nil. :-)

 Best regards,
 Joachim Geidel




 --
 View this message in context:
 http://forum.world.st/NativeBoost-callbacks-from-different-threads-tp4740997.html
 Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] NativeBoost: Regenerate Native Code

[Igor Stasenko]

.. or just restart an image


On 28 November 2013 12:01, Igor Stasenko siguc...@gmail.com wrote:




 On 27 November 2013 17:03, Sean P. DeNigris s...@clipperadams.com wrote:

 How do I tell NativeBoost to regenerate all naive code for a class e.g.
 after
 changing the implementation of #nbCallingConvention?

 N.B. to NativeBoost newbies like myself, this is a *huge* potential
 pitfall
 that's difficult to diagnose. I was thinking, well, I changed the calling
 convention and the vm is still crashing, so that can't be the problem not
 realizing that the callouts never picked up the change

 NativeBoost clearNativeCode




 -
 Cheers,
 Sean
 --
 View this message in context:
 http://forum.world.st/NativeBoost-Regenerate-Native-Code-tp4725651.html
 Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.




 --
 Best regards,
 Igor Stasenko.




-- 
Best regards,
Igor Stasenko.

Re: [Pharo-users] NativeBoost: Regenerate Native Code

[Igor Stasenko]

On 27 November 2013 17:03, Sean P. DeNigris s...@clipperadams.com wrote:

 How do I tell NativeBoost to regenerate all naive code for a class e.g.
 after
 changing the implementation of #nbCallingConvention?

 N.B. to NativeBoost newbies like myself, this is a *huge* potential pitfall
 that's difficult to diagnose. I was thinking, well, I changed the calling
 convention and the vm is still crashing, so that can't be the problem not
 realizing that the callouts never picked up the change

 NativeBoost clearNativeCode




 -
 Cheers,
 Sean
 --
 View this message in context:
 http://forum.world.st/NativeBoost-Regenerate-Native-Code-tp4725651.html
 Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.




-- 
Best regards,
Igor Stasenko.

Re: [Pharo-users] NativeBoost Questions while wrapping FMOD

[Igor Stasenko]

On 25 November 2013 21:53, Sean P. DeNigris s...@clipperadams.com wrote:

 Sean P. DeNigris wrote
  I'm wrapping the FMOD cross-platform audio library
  [snip]
  I have a few more questions

 
 Problem #1:
 

 I have the following callout:
 primitive: #primitiveNativeCall module: #NativeBoostPlugin

 FMOD_RESULT FMOD_System_Init(
 FMOD_SYSTEM *system,
 int maxchannels,
 FMOD_INITFLAGS flags,
 void *extradriverdata);

 ^ self nbCall: #(FMOD_RESULT System_Init(NBExternalAddress system,
 32, 0,
 nil)).

 It works fine on Mac. On Windows, it returns some crazy error code that is
 not listed in the API.

 However, if I wrap the FMOD DLL in another DLL that just forwards all
 calls:
   FMOD_RESULT System_Init(FMOD_SYSTEM *system, int maxchannels,
 FMOD_INITFLAGS flags, void *extradriverdata)
   {
 return FMOD_System_Init(system, maxchannels, flags,
 extradriverdata);
   }
 When I call out to the wrapper DLL, it works! Does that provide a clue as
 to
 what's going wrong when calling from NB?


This seems like a calling convention issue. By default, unless you specify,
NB using
cdecl calling convention, but on windows, many libs (especially kernel)
using stdcall convention.
Check how the library is built and which call convention it uses.
Or just try changing it and see if it solves the problem.


 Other info:
 - Other dll functions succeed, so there is communication with the library.
 In fact, if I proceed past that first error, a sound starts to play... but
 then the VM crashes...

 
 Problem #2:
 
 (much less important)

 I wanted to be able to bundle the DLL with the image so one doesn't have to
 copy it into the VM folder. If I use the full path for the wrapper DLL
 described above, it is found, but when it calls fmodL.dll, which is in the
 same directory, it can't be found. I could only get it to work if at least
 fmodL.dll is in the VM plugins folder. Is there a way to specify more
 search
 locations for dynamic libraries from the image side?

 No, you can do it yourself in a form of:
 self nbCall: ... module: (self searchAndLoadLibrary)


Thanks!



 -
 Cheers,
 Sean
 --
 View this message in context:
 http://forum.world.st/NativeBoost-Questions-while-wrapping-FMOD-tp4724116p4725188.html
 Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.




-- 
Best regards,
Igor Stasenko.

Re: [Pharo-users] NativeBoost Questions while wrapping FMOD

[Luc Fabresse]

Hi Sean,

2013/11/25 Sean P. DeNigris s...@clipperadams.com

 Sean P. DeNigris wrote
  I'm wrapping the FMOD cross-platform audio library
  [snip]
  I have a few more questions

 
 Problem #1:
 

 I have the following callout:
 primitive: #primitiveNativeCall module: #NativeBoostPlugin

 FMOD_RESULT FMOD_System_Init(
 FMOD_SYSTEM *system,
 int maxchannels,
 FMOD_INITFLAGS flags,
 void *extradriverdata);

 ^ self nbCall: #(FMOD_RESULT System_Init(NBExternalAddress system,
 32, 0,
 nil)).

 It works fine on Mac. On Windows, it returns some crazy error code that is
 not listed in the API.

 However, if I wrap the FMOD DLL in another DLL that just forwards all
 calls:
   FMOD_RESULT System_Init(FMOD_SYSTEM *system, int maxchannels,
 FMOD_INITFLAGS flags, void *extradriverdata)
   {
 return FMOD_System_Init(system, maxchannels, flags,
 extradriverdata);
   }
 When I call out to the wrapper DLL, it works! Does that provide a clue as
 to
 what's going wrong when calling from NB?

 Other info:
 - Other dll functions succeed, so there is communication with the library.
 In fact, if I proceed past that first error, a sound starts to play... but
 then the VM crashes...


could it be a calling convention problem?
cdecl, ...



 
 Problem #2:
 
 (much less important)

 I wanted to be able to bundle the DLL with the image so one doesn't have to
 copy it into the VM folder. If I use the full path for the wrapper DLL
 described above, it is found, but when it calls fmodL.dll, which is in the
 same directory, it can't be found. I could only get it to work if at least
 fmodL.dll is in the VM plugins folder. Is there a way to specify more
 search
 locations for dynamic libraries from the image side?


I do not know if one can add more search locations.
But, you can rebuild the full path from image side: Smalltalk
imageDirectory / 'lib.dll'

Cheers,

Luc



 Thanks!



 -
 Cheers,
 Sean
 --
 View this message in context:
 http://forum.world.st/NativeBoost-Questions-while-wrapping-FMOD-tp4724116p4725188.html
 Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] NativeBoost Questions while wrapping FMOD

[Stéphane Ducasse]

I really think that NativeBoost MUST HAVE a decent documentation.
It is a central part of Pharo and Igor you should do something about it.
If I would know I would have written a chapter on it but I cannot because I DO 
NOT KNOW.

Stef

 
 
 
 On 21 November 2013 22:40, Sean P. DeNigris s...@clipperadams.com wrote:
 I'm wrapping the FMOD cross-platform audio library. The code is MIT and lives
 at http://smalltalkhub.com/#!/~SeanDeNigris/FMOD
 
 
 Problem #1:
 
 
 I'm calling into the FMOD library with:
 primStoreIsPlaying: channelHandle in: isPlayingHandle
 primitive: #primitiveNativeCall module: #NativeBoostPlugin
 
 FMOD_RESULT FMOD_Channel_IsPlaying(
 FMOD_CHANNEL *channel,
 bool *isplaying);
 
 ^ self nbCall: #(FMOD_RESULT FMOD_Channel_IsPlaying(NBExternalAddress
 channel, NBExternalAddress isPlayingHandle)).
 
 I call the above with:
 isPlaying
 | isPlaying |
 isPlaying := NBExternalAddress new.
 self primStoreIsPlaying: channel in: isPlaying.
 ^ isPlaying value  0.
 
 isPlaying is always 0. The method works directly from C with:
 int isPlaying = 1;
 while (isPlaying) {
 FMOD_Channel_IsPlaying(channel, isPlaying);
 }
 
 I also tried changing the callout signature to ... bool* isPlayingHandle)
 and passing isPlaying := true. instead of using the NBExternalAddress
 stuff.
 
 err.. again, you must pass an address where value will be stored, 
 
 ^ self nbCall: #(FMOD_RESULT FMOD_Channel_IsPlaying(
 NBExternalAddress channel, NBExternalAddress * isPlayingHandle)).
 otherwise you passing NULL pointer, and i quite surprised it not segfaults 
 when you call it like that (looks like they have a check in the library )
  
  you can also use NBExternalTypeValue for that:
 
 boolValueClass := NBExternalTypeValue ofType: 'bool'. sure thing, creating 
 anonymous class for each call is overkill, this should be done once, 
 somewhere else
 
 boolValue := boolValueClass new.
 
 self callTheThingWith: boolValue.
 
 boolValue value ifTrue: [... blah]
 
 (and this will work, assuming you have bool* in signature for this argument).
 
 I have a few more questions, but this is the most pressing as it's holding
 up any further development.
 
 Thanks!
 
 
 
 -
 Cheers,
 Sean
 --
 View this message in context: 
 http://forum.world.st/NativeBoost-Questions-while-wrapping-FMOD-tp4724116.html
 Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
 
 
 
 
 -- 
 Best regards,
 Igor Stasenko.

Re: [Pharo-users] NativeBoost Questions while wrapping FMOD

[Denis Kudriashov]

Hi

2013/11/22 Igor Stasenko siguc...@gmail.com



 2. instead of returning useful objects, FMOD returns error codes and you
 pass a pointer to receive the object.

 - The first consequence is that I have to wrap all the calls e.g. self
 processErrorCode: self primCreate. where
 processErrorCode: anInteger
 anInteger = 0 ifFalse: [ self error: 'FMOD returned error code ',
 anInteger
 asString ].
 Is there a more graceful way to do that?

 i doubt so.. since it is library API which dictates you to use it in
 certain way.
 The proper error handling never hurts (except from causing extra code
 bloat, of course :)


Is it good idea to override (or create new) #nbCall: method to handle
library common logic? (when any library function returns error code)

Re: [Pharo-users] NativeBoost Questions while wrapping FMOD

[Igor Stasenko]

On 23 November 2013 09:07, Stéphane Ducasse stephane.duca...@inria.frwrote:

 I really think that NativeBoost MUST HAVE a decent documentation.


i agree. i need to invest into it.


 It is a central part of Pharo and Igor you should do something about it.
 If I would know I would have written a chapter on it but I cannot because
 I DO NOT KNOW.

 Stef




 On 21 November 2013 22:40, Sean P. DeNigris s...@clipperadams.com wrote:

 I'm wrapping the FMOD cross-platform audio library. The code is MIT and
 lives
 at http://smalltalkhub.com/#!/~SeanDeNigris/FMOD

 
 Problem #1:
 

 I'm calling into the FMOD library with:
 primStoreIsPlaying: channelHandle in: isPlayingHandle
 primitive: #primitiveNativeCall module: #NativeBoostPlugin

 FMOD_RESULT FMOD_Channel_IsPlaying(
 FMOD_CHANNEL *channel,
 bool *isplaying);

 ^ self nbCall: #(FMOD_RESULT
 FMOD_Channel_IsPlaying(NBExternalAddress
 channel, NBExternalAddress isPlayingHandle)).

 I call the above with:
 isPlaying
 | isPlaying |
 isPlaying := NBExternalAddress new.
 self primStoreIsPlaying: channel in: isPlaying.
 ^ isPlaying value  0.

 isPlaying is always 0. The method works directly from C with:
 int isPlaying = 1;
 while (isPlaying) {
 FMOD_Channel_IsPlaying(channel, isPlaying);
 }

 I also tried changing the callout signature to ... bool*
 isPlayingHandle)
 and passing isPlaying := true. instead of using the NBExternalAddress
 stuff.

 err.. again, you must pass an address where value will be stored,

 ^ self nbCall: #(FMOD_RESULT FMOD_Channel_IsPlaying(

 NBExternalAddress channel, NBExternalAddress * isPlayingHandle)).

 otherwise you passing NULL pointer, and i quite surprised it not segfaults
 when you call it like that (looks like they have a check in the library )

  you can also use NBExternalTypeValue for that:

 boolValueClass := NBExternalTypeValue ofType: 'bool'. sure thing,
 creating anonymous class for each call is overkill, this should be done
 once, somewhere else

 boolValue := boolValueClass new.

 self callTheThingWith: boolValue.

 boolValue value ifTrue: [... blah]

 (and this will work, assuming you have bool* in signature for this
 argument).

 I have a few more questions, but this is the most pressing as it's holding
 up any further development.

 Thanks!



 -
 Cheers,
 Sean
 --
 View this message in context:
 http://forum.world.st/NativeBoost-Questions-while-wrapping-FMOD-tp4724116.html
 Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.




 --
 Best regards,
 Igor Stasenko.





-- 
Best regards,
Igor Stasenko.

Re: [Pharo-users] NativeBoost Questions while wrapping FMOD

[Igor Stasenko]

On 22 November 2013 05:09, Sean P. DeNigris s...@clipperadams.com wrote:

 Igor Stasenko wrote
  The better way is to subclass from NBExternalObject then
  which made exactly for such purposes, by holding an opaque handle to
  something (you don't care what is inside), and simplifies a lot of
 things.

 I made NBExternalObject subclass: #FMOD_SYSTEM.
 I then tried to use it via:
 system := FMOD_SYSTEM new.
 err := self System_CreateNBExternalObject: system.
 With callout:
 ^ self nbCall: #(FMOD_RESULT FMOD_System_Create(NBExternalObject
 system)).

 For the argument type in the signature, for good measure I tried:
 1. NBExternalObject
 2. FMOD_SYSTEM
 3. NBExternalAddress
 All three with zero, one, and two *'s after. The only one that didn't
 report
 some variety of An instance of Xyz expected was
 FMOD_System_Create(FMOD_SYSTEM system) for which the library returns an
 invalid argument error code.

 yet again, you miss the right solution: you must pass a pointer to where
value will be stored
(since function doing exactly that).

so you should do it like:
1. NBExternalObject subclass: #FMOD_SYSTEM.

2. method to call the function will look like following:
  create: system
^ self nbCall: #(FMOD_RESULT FMOD_System_Create(FMOD_SYSTEM * system)).

3. and call it like following:

  system :=  FMOD_SYSTEM new.
  self handleError: (self create: system) ifOk: [ ^ system ]

3a. optionally, you want want to initialize it just after you know that you
obtained correct handle,
to do that, you could do following:

FMOD_SYSTEM classnew
  | system |
  system :=  super new.
  self handleError: (self create: system) ifOk: [ ^ self newWithHandle:
system handle ]

and newWithHandle: could look something like following:

newWithHandle: aHandle

 system := super basicNew.
 system handle: aHandle.
 ^ system initialize

(because it is important to set the handle first, like that you can
actually initialize something more
by using it, which you logically do, just after creating a new handle.
and note you must not call 'super initialize' then, because it will reset
handle.)
and i'm sure you can find more elegant solution :)

btw if anyone wants to play with it:
 1.
 Gofer it
 smalltalkhubUser: 'SeanDeNigris' project: 'FMOD';
 package: 'FMOD';
 load.

 2. Download the FMOD library for your platform:
 - windows -

 http://www.fmod.org/download/fmodstudio/api/Win/fmodstudioapi10208win-installer.exe
 - Mac -

 http://www.fmod.org/download/fmodstudio/api/Mac/fmodstudioapi10208mac-installer.dmg

 3. Copy the library to FileLocator imageDirectory / 'FMOD Programmers
 API/api/lowlevel/lib/libfmod.dylib'

 The working example is:
 | sound |
 sound := FmodSound fromFile: '/path/to/file.mp3' asFileReference.
 [ sound play ] fork.

 The broken one described above is: FMOD exampleNBExternalObject.



 -
 Cheers,
 Sean
 --
 View this message in context:
 http://forum.world.st/NativeBoost-Questions-while-wrapping-FMOD-tp4724116p4724192.html
 Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.




-- 
Best regards,
Igor Stasenko.

Re: [Pharo-users] NativeBoost Questions while wrapping FMOD

[p...@highoctane.be]

We'll soon be able to do this in Pharo then :-)

My friend David also uses FMOD in there.

http://www.youtube.com/watch?v=077sYFHAgTM

---
Philippe Back
Dramatic Performance Improvements
Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027
Mail:p...@highoctane.be | Web: http://philippeback.eu
Blog: http://philippeback.be | Twitter: @philippeback
Youtube: http://www.youtube.com/user/philippeback/videos

High Octane SPRL
rue cour Boisacq 101 | 1301 Bierges | Belgium

Pharo Consortium Member - http://consortium.pharo.org/
Featured on the Software Process and Measurement Cast -
http://spamcast.libsyn.com
Sparx Systems Enterprise Architect and Ability Engineering EADocX Value
Added Reseller




On Thu, Nov 21, 2013 at 10:40 PM, Sean P. DeNigris s...@clipperadams.comwrote:

 I'm wrapping the FMOD cross-platform audio library. The code is MIT and
 lives
 at http://smalltalkhub.com/#!/~SeanDeNigris/FMOD

 
 Problem #1:
 

 I'm calling into the FMOD library with:
 primStoreIsPlaying: channelHandle in: isPlayingHandle
 primitive: #primitiveNativeCall module: #NativeBoostPlugin

 FMOD_RESULT FMOD_Channel_IsPlaying(
 FMOD_CHANNEL *channel,
 bool *isplaying);

 ^ self nbCall: #(FMOD_RESULT
 FMOD_Channel_IsPlaying(NBExternalAddress
 channel, NBExternalAddress isPlayingHandle)).

 I call the above with:
 isPlaying
 | isPlaying |
 isPlaying := NBExternalAddress new.
 self primStoreIsPlaying: channel in: isPlaying.
 ^ isPlaying value  0.

 isPlaying is always 0. The method works directly from C with:
 int isPlaying = 1;
 while (isPlaying) {
 FMOD_Channel_IsPlaying(channel, isPlaying);
 }

 I also tried changing the callout signature to ... bool* isPlayingHandle)
 and passing isPlaying := true. instead of using the NBExternalAddress
 stuff.

 I have a few more questions, but this is the most pressing as it's holding
 up any further development.

 Thanks!



 -
 Cheers,
 Sean
 --
 View this message in context:
 http://forum.world.st/NativeBoost-Questions-while-wrapping-FMOD-tp4724116.html
 Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] NativeBoost Questions while wrapping FMOD

[Igor Stasenko]

On 21 November 2013 22:40, Sean P. DeNigris s...@clipperadams.com wrote:

 I'm wrapping the FMOD cross-platform audio library. The code is MIT and
 lives
 at http://smalltalkhub.com/#!/~SeanDeNigris/FMOD

 
 Problem #1:
 

 I'm calling into the FMOD library with:
 primStoreIsPlaying: channelHandle in: isPlayingHandle
 primitive: #primitiveNativeCall module: #NativeBoostPlugin

 FMOD_RESULT FMOD_Channel_IsPlaying(
 FMOD_CHANNEL *channel,
 bool *isplaying);

 ^ self nbCall: #(FMOD_RESULT
 FMOD_Channel_IsPlaying(NBExternalAddress
 channel, NBExternalAddress isPlayingHandle)).

 I call the above with:
 isPlaying
 | isPlaying |
 isPlaying := NBExternalAddress new.
 self primStoreIsPlaying: channel in: isPlaying.
 ^ isPlaying value  0.

 isPlaying is always 0. The method works directly from C with:
 int isPlaying = 1;
 while (isPlaying) {
 FMOD_Channel_IsPlaying(channel, isPlaying);
 }

 I also tried changing the callout signature to ... bool* isPlayingHandle)
 and passing isPlaying := true. instead of using the NBExternalAddress
 stuff.

 err.. again, you must pass an address where value will be stored,

^ self nbCall: #(FMOD_RESULT FMOD_Channel_IsPlaying(

 NBExternalAddress channel, NBExternalAddress * isPlayingHandle)).

otherwise you passing NULL pointer, and i quite surprised it not segfaults
when you call it like that (looks like they have a check in the library )

 you can also use NBExternalTypeValue for that:

boolValueClass := NBExternalTypeValue ofType: 'bool'. sure thing, creating
anonymous class for each call is overkill, this should be done once,
somewhere else

boolValue := boolValueClass new.

self callTheThingWith: boolValue.

boolValue value ifTrue: [... blah]

(and this will work, assuming you have bool* in signature for this
argument).

I have a few more questions, but this is the most pressing as it's holding
 up any further development.

 Thanks!



 -
 Cheers,
 Sean
 --
 View this message in context:
 http://forum.world.st/NativeBoost-Questions-while-wrapping-FMOD-tp4724116.html
 Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.




-- 
Best regards,
Igor Stasenko.

Re: [Pharo-users] NativeBoost Questions while wrapping FMOD

[Igor Stasenko]

On 22 November 2013 01:23, Sean P. DeNigris s...@clipperadams.com wrote:

 Igor Stasenko wrote
  err.. again, you must pass an address where value will be stored,

 hee hee... sorry... I don't understand enough of what's going on behind the
 scenes to adapt well. I reasoned that since last time, the signature was
 Whatever** and you said to make it NBExternalAddress*, that therefore
 Whatever* (one less *) would be NBExternalAddress (also one less *).

 While we're here, I'll ask my other questions...

 1. What's the differenct between primitive: #primitiveNativeCall module:
 #NativeBoostPlugin and the variant with error:? What does the second one
 buy you?

 Historically, NB was first running on Squeak VM, which has no support for
primitive error.
Using extra #error: keyword in primitive is HIGHLY recommended, unless you
want to
deal with some quite rare (but possible and thus very hard to track down)
wrong error reporting.


 2. instead of returning useful objects, FMOD returns error codes and you
 pass a pointer to receive the object.

 - The first consequence is that I have to wrap all the calls e.g. self
 processErrorCode: self primCreate. where
 processErrorCode: anInteger
 anInteger = 0 ifFalse: [ self error: 'FMOD returned error code ',
 anInteger
 asString ].
 Is there a more graceful way to do that?

 i doubt so.. since it is library API which dictates you to use it in
certain way.
The proper error handling never hurts (except from causing extra code
bloat, of course :)


 - The second issue is how to create a Smalltalk object from the pointer.
 What I've been doing is:
 | soundHandle |
 soundHandle := NBExternalAddress new.
 self processErrorCode: (self primCreate: soundHandle on: system
 handle
 fromFile: file fullName).
 sound := FmodSystemSound on: soundHandle.
 Again, is there a better way? I thought to subclass NBExternalAddress, but
 evaluating sound := FmodSystemSound new to pass to the callout seemed a
 bit dirty i.e. it is not a invalid instance until initialized by the
 callout. I also played around with NBExternalObject, but couldn't get that
 to work either...

 The better way is to subclass from NBExternalObject then
which made exactly for such purposes, by holding an opaque handle to
something (you don't care what is inside), and simplifies a lot of things.


 Thanks for all the support. This is fun!!

 You are very welcome.




 -
 Cheers,
 Sean
 --
 View this message in context:
 http://forum.world.st/NativeBoost-Questions-while-wrapping-FMOD-tp4724116p4724158.html
 Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.




-- 
Best regards,
Igor Stasenko.

Re: [Pharo-users] NativeBoost Questions while wrapping FMOD

[Sean P. DeNigris]

Igor Stasenko wrote
 err.. again, you must pass an address where value will be stored,

hee hee... sorry... I don't understand enough of what's going on behind the
scenes to adapt well. I reasoned that since last time, the signature was
Whatever** and you said to make it NBExternalAddress*, that therefore
Whatever* (one less *) would be NBExternalAddress (also one less *).

While we're here, I'll ask my other questions...

1. What's the differenct between primitive: #primitiveNativeCall module:
#NativeBoostPlugin and the variant with error:? What does the second one
buy you?

2. instead of returning useful objects, FMOD returns error codes and you
pass a pointer to receive the object. 

- The first consequence is that I have to wrap all the calls e.g. self
processErrorCode: self primCreate. where
processErrorCode: anInteger
anInteger = 0 ifFalse: [ self error: 'FMOD returned error code ', 
anInteger
asString ].
Is there a more graceful way to do that?

- The second issue is how to create a Smalltalk object from the pointer.
What I've been doing is:
| soundHandle |
soundHandle := NBExternalAddress new.
self processErrorCode: (self primCreate: soundHandle on: system handle
fromFile: file fullName).
sound := FmodSystemSound on: soundHandle.
Again, is there a better way? I thought to subclass NBExternalAddress, but
evaluating sound := FmodSystemSound new to pass to the callout seemed a
bit dirty i.e. it is not a invalid instance until initialized by the
callout. I also played around with NBExternalObject, but couldn't get that
to work either...

Thanks for all the support. This is fun!!



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/NativeBoost-Questions-while-wrapping-FMOD-tp4724116p4724158.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] NativeBoost: Null-terminated Strings

[Igor Stasenko]

String pseudo type corresponds to
'const char *' type.. because it passes the string by copying it on stack
and null terminating it there,
and then pushing the pointer (which on stack), as argument to function.
That means that original string is never modified, in your case function
will modify a temporary
string on stack, and after call finished it will be lost.

If function takes pointer to write some data at given location, you can
just pass a ByteArray instance
as a buffer to hold that string (so function will receive a pointer of
first byte in it)..
and after it return, trim/convert it to ByteString.




On 20 August 2013 19:45, Udo Schneider udo.schnei...@homeaddress.de wrote:

 All,

 I just wrapped a few functions using NB - as easy as it used to be in
 Dolphin! Really nice.

 I'm stuck with a simple thing however. I'm passing a string buffer into a
 function which fills this buffer (null-terminated String). The passed in
 String however contains all the nulls as well (which is not surprising).
 What's the official way to truncate the String to it's correct length?

 Best Regards,

 Udo





-- 
Best regards,
Igor Stasenko.