On 5 July 2013 11:03, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 04/07/2013 19:11, Igor Stasenko a écrit :
On 4 July 2013 13:07, Goubier Thierry <thierry.goubier@cea.fr> wrote:
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
This looks fine , and i will add it into NB.
Could you rather test for unability to get the source of the method and raise a NB-defined error? So that I could write a fallback on non-NB code with a on: do:. Please :)
(it would then both handle startup related errors and unreadable sources as well).
And with a backport to 2.0, because the odds of seeing an Opal based solution on 2.0 are fairly low.
the problem is that you will get same error when you put wrong name into signature or when no sources avail e.g.: foo: bar ^ self nbCall: #( void foo (int baz) ) will give same error (unable to find binding for name 'baz' in given context). If its fine to you, i can do it.
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.
you probably made a mistake somewhere. ;) because counting the argument index, instead of putting its name is error prone.
Well, in almost all cases, arguments were used in the order they were given, which should have been almost foolproof ;)
that's why there is separate words in english for 'all' and 'almost' :)
not cache, just put it into method's attributes, so i can access them later. And not when method added/removed, but at compilation time.
Is there a real, practical difference between "at compilation time" and "when receiving MethodAdded event"? i.e. is the complexity added in the compilation process worthwhile?
the problem is that you may not always receive MethodAdded event, because different tools putting different meaning into "this should be compiled silently". This is outstanding issue in Pharo.. and that's the main reason why i would go with compiler (like that i have guarantee that instance of CompiledMethod is well-formed, and don't need to rely on 3-rd party toolchain to deliver notification to me. and besides, we need such hook mechanism in Compiler anyways (for many other use cases) and so, it will be not "renting a Boeing for single passenger"
Thierry
-- 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
-- Best regards, Igor Stasenko.