On 5 July 2013 15:22, Igor Stasenko <[email protected]> wrote: > 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" >
oh.. and i forgot about most important aspect of it: i don't wanna see <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode > in code, instead if wanna use <native> (or similar), which admit, much more concise, elegant and user-friendly, and hides unnecessary implementation detail. >> 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. -- Best regards, Igor Stasenko.
