Hi Stephane, I worked around it... as long as I don't make FileReference>>exists as a NB call, then the Changes file will open correctly and NB calls will work after that (Changes opening doesn't use isReadable or isWriteable, which is interesting in itself ;))... But it makes my solution fragile. However, if you make the Changes file not readable (still owned by you, still writeable), many interesting things happen, starting with a nbGetEnv failure and a total unability to quit Pharo apart from a killall pharo. I tried to: - Get NB to accept positional arguments instead of named ones (by catching names like _1, _2). Easy, since apparently the NB generated code just takes an offset on the pointer stack finally (i.e. names are only used to get the index in the arguments array). Seemed to work. - Change all NB calls with numbers above to be able to have NB working before / without the Changes file. Ended with a segfault on startup (globalSymbolLoading for GetEnv again), and I gave up. Igor, would there be a way to write the call with the effective arguments instead of #symbols, so that by looking at the bytecode you would get the position in the arguments stack? Or would it be possible to store by hand the source of the methods (triggered by the <pragma>) inside a source cache inside NB for the time being? Or is there an event for NB correct start (with Changes and all ready) so that we can write NB code with a fallback if NB isn't able to work? NB made it so easy to do simple and usefull calls to external libs that I really want it to work! Thierry ________________________________________ De : Pharo-dev [pharo-dev-bounces@lists.pharo.org] de la part de Stéphane Ducasse [stephane.ducasse@inria.fr] Date d'envoi : mercredi 3 juillet 2013 21:51 à : Pharo Development List Objet : Re: [Pharo-dev] NativeBoost with no access to sources
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) ) ?
Igor I understand your concerns but also the problem thierry is facing and it looks to me like a valid scenario. Stef