Le 04/07/2013 11:58, Igor Stasenko a écrit :
On 3 July 2013 23:04, GOUBIER Thierry <thierry.goubier@cea.fr> 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.
I wondered if it could be both (name and number), but went for the shortest path, that is the simplest solution: NBFFICallout>>loaderFromMethodArgsNamed: argName methodArgs ifNotNil: [ | index | (argName first = $_ and: [ argName allButFirst isAllDigits ]) ifTrue: [ ^ NBSTMethodArgument new stackIndex: methodArgs size - argName asUnsignedInteger ]. index := methodArgs indexOf: argName ifAbsent: [ nil ]. index ifNotNil: [ "ok, this is a method argument" ^ NBSTMethodArgument new stackIndex: methodArgs size - index ] ]. ^ nil Then I tried to change all calls to use numbers, but it ended in a Segfault (not in NB itself, but somewhere else as if I had a corrupted heap). The end result with all changes is there: http://ss3.gemstone.com/ss/PharoInbox/SLICE-Issue-11102-FileSystemError-Path... If you see where I missed something, I'd be happy to know.
- 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.
Yes, I suspect it would be the best solution. Trap on <primitive: ? If you track the MethodAdded / MethodRemoved events, you can note all uses of <primitive:> and cache the info there ?
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
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95