On 3 July 2013 23:04, GOUBIER Thierry <[email protected]> wrote: > 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.
can you share this code? i think it doesn't hurts being able to refer to method argument by number , not by name, if author wants to. > - 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? > i wanna change it, so that when you compile method with NB primitive, it remembers the arg names. > 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 [[email protected]] de la part de Stéphane > Ducasse [[email protected]] > 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 > -- Best regards, Igor Stasenko.
