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. > > >>>> >>>> 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. > > > You mean that hacking support into the third party compiler isn't 3rd party > toolchain :) >
well, to me the compiler's behavior is much much more predictable comparing to chances that when you loading code with broken Monticello/RPackage or running test, you won't receive the event you expecting. > >>> 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. > > > I remember seeing people introducing syntax extensions inside smalltalk > methods in VisualWorks, would that work as well ? Customize on a per class / > per method which compiler we should use. > yes. But i don't wanna extend syntax in case of NB , obviously :) > > 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.
