On 10 April 2014 13:35, Henrik Johansen <henrik.s.johansen@veloxit.no>wrote:
On 10 Apr 2014, at 1:18 , Igor Stasenko <siguctua@gmail.com> wrote:
On 10 April 2014 11:44, Henrik Johansen <henrik.s.johansen@veloxit.no>wrote:
On 09 Apr 2014, at 5:30 , Max Leske <maxleske@gmail.com> wrote:
On 09.04.2014, at 17:25, Sean P. DeNigris <sean@clipperadams.com>
wrote:
Max Leske wrote
In NB, how do I pass NULL into a function call without modifying the argument type? e.g. my argument has type String. passing something
like
`NBExternalAddress null` will be converted into a C string instead of being passed through (I know, that seems to be the point in this case but I couldn't find any other way to create NULL). Any suggestions?
I think you just pass nil, no?
One would think so, but no⦠:) NB will signal an exception because UndefinedObject is not of the expected type.
I remember an optCoerceNilToNull, but that seems to 1) Only apply to pointer types (which could mean having to use char *, not String, and thus need to do encoding/decoding manually) 2) Be scoped to entire call, not single parameter (may or may not be more than a philosophical objection)
Might be worth a shot though?
- optCoerceNilToNull is for pointers
for strings, there's an option: - optStringOrNull
which, if enabled, adds additional check for nil in generated marshaller code, so that by passing nil it will pass NULL to calling function.
Would probably aid discoverability quite a bit if optionAt: was used consistently, and (at least the convenient-for-implementing-not-so-convenient-for-using option handling in) NBNativeCodeGen >> #doesNotUnderstand: removedâ¦
removed? nope doesNotUnderstand: message (message selector isUnary and: [ message selector beginsWith: 'opt'] ) ifTrue: [ ^ options includes: message selector ]. ^ super doesNotUnderstand: message
The finder is unable to point me to users of optStringOrNull even when I know the selector, and the defaultOptions method (which was the first place I found with a list of options) contains far from a complete set of the total available options, it seemsâ¦
My rationale behind it: - there is no fixed list of options.. they can be introduced/removed depending from the place they actually used - most of the times this is in marshalling code.. and so best way to figure out is to see what marshaller does and expecting (NBExternalType subclasses). To find out what marshaller behind specific type, one can use following expression: NBFFICallout new resolveType: typename. where type name is a string or symbol.. like that: NBFFICallout new resolveType: #String gives NBExternalString and inspecting it further you can see what options there. I'd like to point out that the complete set of options depends from implementation of various marshalling code. i am open for any suggestions which could make options more accessible. For example, NativeBoost class >> allCalloutOptions | symbols options package | symbols := Symbol allSubInstances select: [ :ea | ea beginsWith: 'opt' ]. options := Set new. package := self package. symbols do: [ :symbol | | senders | senders := SystemNavigation default allSendersOf: symbol. (senders anySatisfy: [ :ea | ea methodClass package = package ]) ifTrue: [ options add: symbol ]. ]. ^ options gives: a Set(#optProxyLabels #optAllowByteArraysPtr #optReturnNullAsNil #optCoerceNilToNull #optUseStackPointer #optStdcall #optStringOrNull #optCheckFailOnEveryArgument #optDebug #optAllowExternalAddressPtr #optDirectProxyFnAddress #options: #optEmitCall #optCdecl #optFailOnReturnNull #optCheckIndirectArgBounds #optReserveCallgateSpace #optNoCleanup #optMayGC #optNoAlignment #optNonMovable #optReturnPtrAsInt #optReturnPtrAsExternalAddress) Cheers,
Henry
-- Best regards, Igor Stasenko.