Hehehe, always good to have your help. As you will see the skip one and
skip all tokens strategies are implemented. The "inject a token" and try
again is not, as that is a lot more complicated to do it and maintain
manually.
Edson
2011/7/27 Wolfgang Laun
> On 27 July 2011 15:34, Edson Tir
On 27 July 2011 15:34, Edson Tirelli wrote:
>
>Just to explain how the parser recovers from errors, it tries to skip a
> token that fail to match the construct being parsed. If that still fails, it
> will skip all tokens until it finds the start of a top level construct (i.e.
> a statement li
Just to explain how the parser recovers from errors, it tries to skip a
token that fail to match the construct being parsed. If that still fails, it
will skip all tokens until it finds the start of a top level construct (i.e.
a statement like a rule, query, declare, etc) and resynch from there.
On 26 July 2011 21:28, Edson Tirelli wrote:
> QUESTION:
>As we can see above, we will need several new constructs in order to
> support features in our roadmap. We have the choice of making them all top
> level constructs, making the error recovery in the parser a lot more
> complicated, or
Thanks for the feedback Michael, and you are right, it will replace the
previous way of dealing with windows, but we will still support the old way
for backward compatibility.
The idea is to have this working in the engine for Beta1, so I will let
you know as soon as the parser is done in th
Personally, I don't see a problem with option 1.
For consistency (with entry-points) the named windows and usage thereof
should, IMO, be defined thus:-
*
*
**declare window X
@type( tumbling )
@keep( last 10 )
StockTick( symbol == "RHT" ) from entry-point Y
end
rule Z
when
StockTi
All,
BACKGROUND:
As Drools moves forward, we need to be able to declare several new
structures, as well as make existing structures more robust for compile time
analysis, error reporting and tooling support. For instance, as it is today,
entry points are implicit declared by simply using the
