Or rather, override the test method in LeapsTest so that we know to
review it when the time comes.

-----Original Message-----
From: Mark Proctor [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, 11 April 2006 6:35 AM
To: Edson Tirelli
Cc: Alexander Bagerman; Michael Neale; [email protected]
Subject: Re: Column/declaration order

ReteOO is the supported and stable algorithm, if it correctly fixes 
ReteOO then keep it. Leaps is marked experimental, and it sounds like 
its not a regression over previous Leaps relases, so its fine just to 
make users aware of this issue. For now just xxxtest the unit test so 
the build doesn't break, hopefully Alex will fix soon.

Mark
PS. I have CC'd the dev list.
Edson Tirelli wrote:
>   All,
>
>   The situation is this: I fixed the issue JBRULES-183 for ReteOO as 
> we discussed yesterday. After testing everything in reteoo, I ran a 
> full test and realized that leaps was broken. I thought it was because

> of my changes and started talking to Alex. After some research, I 
> decided to get code back to revision 3550 (before my changes) and 
> tested and the error was happening before my changes.
>
>   This rule works fine in LEAPS:
>
> rule "not rule test2"
>    salience 6
>    when             not Cheese( price == 5 )
>        Cheese( price == 7 )
>    then
>        list.add( new Integer( 7 ) );
> end  
>   If you add a binding to cheese, it throws exception:
>
> rule "not rule test2"
>    salience 6
>    when             not Cheese( price == 5 )
>        $c : Cheese( price == 7 )
>    then
>        list.add( new Integer( 7 ) );
> end  
>   So, basically, both algorithms were suffering from the same problem 
> and my fix fixed only ReteOO problem.
>   It seems simple, but it might be not that simple. When NOT is used 
> in the first column, RuleBuilder right now assumes someone will create

> the initial-fact and it will be index 0 on the tuple, so, it does not 
> increment offset. In leaps, according to Alex, there is no 
> initial-fact, and this way, the offset calculation should be different

> for Rete and Leaps.
>   Alex sugests to do the calculation on the Rule.getTransformedLhs() 
> method. It may be possible, but my question is:
>
>    Mark, you said you wanted to release RC2 tonight. Should we simply 
> comment out the test case to avoid leaps error or do you want me to 
> remove my changes until we fix leaps also?
>
>    []s
>    Edson
>
> PS: Alex and I are working on fixing this anyway.
>
> Alexander Bagerman wrote:
>
>> Edson,
>> I think the most logical place for the changes I propose would be
>> Rule.getTransformedLhs(). Both reteoo and leaps builders use it while
>> adding rule to the respective structures.
>>
>> There are still problems with this approach - declaration and column
>> classes do not have setters on column(Declaration) and index(Column)
>> that would result in generating new Declaration and Column classes.
>> This in turn will break low level Java rules because declarations
>> created on columns are used in Consequences. It would be better if
>> Declaration takes Column and int in constractor but it would not
solve
>> the problem either. I think I painted myself into the corner.....
>>
>> I'm online till 3pm PST (California time) so feel free to ping me to 
>> chat.
>> -Alex
>>
>>
>>  
>>
>
>

Reply via email to