On Fri, Jul 23, 2010 at 10:12 AM, St�phane Ducasse <stephane.ducasse@inria.fr> wrote:

I thought I integrated those.

My point was that while good work on non-interactive errors in the standard compiler has been done there's no guarantee its finished and we should check and make whatever modifications are required so that it all errors can be caught.

best

Eliot

�

Fernando if you can check and let us know.

Stef

On Jul 23, 2010, at 6:48 PM, Eliot Miranda wrote:

> Hi Fernando,
>
> On Fri, Jul 23, 2010 at 2:46 AM, Fernando olivero <oliverof@lu.unisi.ch> wrote:
> Lukas, thanks for the answer. I will see if AST-Semantics solves my problem.
>
> I also tried using the Compiler and the parser, and faking a notifier. But the Compiler>>interactive behavior is hard to override,
> it always gives me visual feedback ( pop menus and related dialogs).
>
> Colin Putney has done good work replacing a number of interactive errors with exceptions whose defaultAction is to produce the notifier. �These are in Squeak 4.1. �Have you taken a look at the trunk 4.1 compiler? �Clearly the standard compiler should be able to do what you want. �We should fix it :)
>
> best
> Eliot
>
> Maybe the newCompiler is more customizable?
>
> Fernando
>
>
> On Jul 23, 2010, at 7:34 AM, Lukas Renggli wrote:
>
> > You can use #parseMethod:onError: to check for syntactical errors.
> >
> > Semantical errors are harder to detect, some of them (e.g. undeclared
> > variables) you can find using AST-Semantics.
> >
> > Lukas
> >
> > On 23 July 2010 00:35, Fernando olivero <oliverof@lu.unisi.ch> wrote:
> >> I have a question about validating a methodNode, suppose we have the following:
> >>
> >> parsedNode := �RBParser parseMethod: 'test ^ self add: anUnbindedVariable'.
> >>
> >> Is there a way of checking the health/validity of the parsedNode?
> >>
> >> I couldn't find any behavior in RBMethodNode or related classes.
> >>
> >> Lukas, do you have an idea is i could run any Lint rule?
> >>
> >> My idea is to provide a method editor morph, that prevents from accepting invalid sources, and informs the user any problems detected with the edited code.
> >>
> >> Thanks,
> >> Fernando
> >>
> >>
> >> _______________________________________________
> >> Pharo-project mailing list
> >> Pharo-project@lists.gforge.inria.fr
> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >>
> >
> >
> >
> > --
> > Lukas Renggli
> > www.lukas-renggli.ch
> >
> > _______________________________________________
> > Pharo-project mailing list
> > Pharo-project@lists.gforge.inria.fr
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project