On 3 July 2013 14:19, Goubier Thierry <[email protected]> wrote:
>
>
> Le 03/07/2013 11:59, Igor Stasenko a écrit :
>
>> On 3 July 2013 11:48, Goubier Thierry <[email protected]> wrote:
>>>
>>> Is there something against that ?
>>>
>>> It seems as if NB is used to check file existence / isReadable, then,
>>> upon
>>> startup, the vm is unable to open the changes file and all NB calls
>>> becomes
>>> incorrect.
>>>
>>
>> NB callout needs argument names (which it can only get right now by
>> accessing method's source).
>> We plan to change that after introducing pluggable mechanism in opal
>> to use it to run additional
>> code on certain pragma to handle it in custom way (like remembering
>> argument names in method's properties).
>
>
> If it is like that, I have to give up any chance of correcting the file
> permissions problem on Pharo 2.0.
>
> Any chance that we could use arguments positions instead ?
>
I don't know.. look:
realloc: flags mem: lpMem size: dwBytes
<primitive: #primitiveNativeCall module: #NativeBoostPlugin error:
errorCode>
^ self nbCall:
#( LPVOID HeapReAlloc (self, DWORD flags, LPVOID lpMem,
SIZE_T dwBytes) )
here, see: flags, lpMem, dwBytes names is in function signature same
as in your method.
That's how NB knows which argument from method corresponds to argument
passed to function.
now if you don't use argument names , how the above should look like?
realloc: flags mem: lpMem size: dwBytes
<primitive: #primitiveNativeCall module: #NativeBoostPlugin error:
errorCode>
^ self nbCall:
#( LPVOID HeapReAlloc (self, DWORD @1, LPVOID @2,
SIZE_T @3) )
?
potentially , you can change the signature parser to accept such syntax..
but as to me, that's really ugly, counter intuitive and error prone.
--
Best regards,
Igor Stasenko.