On 5 July 2013 11:03, Goubier Thierry <[email protected]> wrote: > > > Le 04/07/2013 19:11, Igor Stasenko a écrit : >> >> On 4 July 2013 13:07, Goubier Thierry <[email protected]> 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--root-ThierryGoubier.4.mcz >>> >>> 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.
