On 5 July 2013 16:55, Goubier Thierry <[email protected]> wrote: > > > Le 05/07/2013 16:36, Igor Stasenko a écrit : > >> On 5 July 2013 16:09, Goubier Thierry <[email protected]> wrote: >>> >>> >>> >>> Le 05/07/2013 15:31, Igor Stasenko a écrit : >>>> >>>> >>>> On 5 July 2013 15:22, Igor Stasenko <[email protected]> wrote: >>>>> >>>>> >>>>> On 5 July 2013 11:03, Goubier Thierry <[email protected]> wrote: >>>>>> >>>>>> >>>>>> 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). >>> >>> >>> >>> Of course. I could do with having the same error for both and knowing >>> that >>> when developping and testing I would get it for stupid syntax errors and >>> in >>> production to handle a real situation. >>> >>> >>>>> If its fine to you, i can do it. >>> >>> >>> >>> Maybe I can try myself to see if I can write, before entering that loader >>> stuff, a correct test which raises an error if the method source isn't >>> available. >>> >>> >> well, all you need is basicaly replace this: >> >> Error signal: 'Could not find accessor for variable named "' , >> argName , '" in ' , method name >> >> with: >> >> NBArgumentNotFound signal: argName >> >> .. or NBCannotBindName.. >> >> what name for exception? > > > I believe the proper way would be to have : > > NBCannotBindName (for the errors you already handle at the moment) > > and, somewhere in there, a > > NBMethodSourceNotAvailable > > triggered in NBFFICallout>>sender: if the source code is decompiledCode > (but, as far as I can see, there is no method to test a CompiledMethod for > that :)) > > Something like > > CompiledMethod>>hasSourceCode > "Say false if we have to reconstruct the code." > > | trailer source | > trailer := self trailer. > trailer sourceCode > ifNotNil: [:code | ^ true ]. > trailer hasSourcePointer > ifFalse: [ ^ false]. > "Situation normal; read the sourceCode from the file" > source := [self getSourceFromFile] > on: Error > do: [ :ex | ex return: nil]. > source isEmptyOrNil > ifTrue: [ ^ false ]. > ^ true > > and, in sender: > > aSenderContext method hasSourceCode > ifFalse: [NBMethodSourceNotAvailable signal: method printString] > > What do you think ? >
I think it is not responsibility of NB to deal with availability of source code. NB simply using reflection protocol of system to get what it wants to get, and where it come (from source code, or from something else) is completely irrelevant. Yes, with current implementation, it ends up with getting & parsing source code, but it is not what NB is asking for: the intent is to simply ask a compiled method to provide the argument names. That's why i totally agree with introduction of NBCannotBindName exception, but i cannot see place for NBMethodSourceNotAvailable. Otherwise similar tools with similar requirements will need to (re)implement same? This should be a responsibility of kernel/system.. but not NB itself. > > 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.
