Le 04/07/2013 11:58, Igor Stasenko a écrit :
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.
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--root-ThierryGoubier.4.mcz
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 [[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
--
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
