On 22 November 2013 01:23, Sean P. DeNigris <sean@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.