On 5 July 2013 16:09, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 05/07/2013 15:31, Igor Stasenko a écrit :
On 5 July 2013 15:22, Igor Stasenko <siguctua@gmail.com> wrote:
On 5 July 2013 11:03, Goubier Thierry <thierry.goubier@cea.fr> 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.