headers
Mark Proctor | 2 Feb 2005 01:21

[drools-dev] events and durations

I have been working on this and have managed to keep durations and 
events while moving to a retract/assert for a modify. This is achieved 
by using two maps  itemsToRetract and scheduledItemsToRetract to keep 
track of items retracted during a modify, the following assertion then 
removes them from the map, what ever is left in the maps after 
assertions is then actually retracted and events thrown. I have done a 
further optimisation so that if no events are registered it doesn't 
check the map.

For those interested the bulk of those changes are in the Agenda:
http://cvs.drools.codehaus.org/viewrep/drools/drools/drools-core/src/main/org/drools/reteoo/Agenda.java?r=1.54

This is quite a big change so can I urge you all to checkout cvs head to 
test and profile this and give feedback asap. I want to beta on 
thursday, although I wouldn't recommend that beta for production use 
untill we are sure this code is good.

Mark
Permalink | Reply | 0 comments |
headers
Mark Proctor | 2 Feb 2005 01:56

[drools-dev] extractors

Now that drools is using retract and assert for a modify, the reasons 
for removing extractors are no longer prevalent - this means we have the 
opportunity to put them back in.

Extractors are synthetic facts. In implementation they are a Rete node 
that executes an expression and assigns the value to a declaration that 
is available to further conditions and the consequence. Its ideal so 
that users dont have to keep evaluating the same expressions each time a 
condition is evaluated. ie if we have a condition that is comparing ages 
but the fact is a date of birth, requiring the same repeated 
calculation, we can evaluate the age as an extractor to give that 
synthetic value and use that in later conditions.

The question though is - are extractors a good solution for this 
problem, or are they just a hack? I need feedback on the legitimacy of 
them and whether users want them back in.

Mark
Permalink | Reply | 0 comments |
headers
Mark Proctor | 2 Feb 2005 02:06

[drools-dev] Re: [drools-user] extractors

Although I should add that extractors add a level of complexity, 
especially with how you introduce a new fact midway into the Rete, that 
has no fact handle - this complexity is mostly in the Tuple which needs 
to determine if a declaration is a normal fact or an extraction when a 
user tries to access the value for a declaration.

Mark
Mark Proctor wrote:

> Now that drools is using retract and assert for a modify, the reasons 
> for removing extractors are no longer prevalent - this means we have 
> the opportunity to put them back in.
>
> Extractors are synthetic facts. In implementation they are a Rete node 
> that executes an expression and assigns the value to a declaration 
> that is available to further conditions and the consequence. Its ideal 
> so that users dont have to keep evaluating the same expressions each 
> time a condition is evaluated. ie if we have a condition that is 
> comparing ages but the fact is a date of birth, requiring the same 
> repeated calculation, we can evaluate the age as an extractor to give 
> that synthetic value and use that in later conditions.
>
> The question though is - are extractors a good solution for this 
> problem, or are they just a hack? I need feedback on the legitimacy of 
> them and whether users want them back in.
>
> Mark
>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Proctor | 2 Feb 2005 03:44

[drools-dev] DROOLS-259 and classloaders

Anyone have any feedback on what I should do with this:
http://jira.codehaus.org/browse/DROOLS-259

Mark
Permalink | Reply | 0 comments |
headers
Mark Proctor | 2 Feb 2005 18:06

[drools-dev] Re: [drools-user] extractors

With the current code base we are near enough in a condition to do a 
release candidate after one or two more betas. If I take the effort to 
put extractors back in it will the delay the release. Whats the group's 
view on this? My personal feelings is to leave them out and finally get 
2.0 out, especially as very few people use them. Although if the group 
thinks its important enough I will endevour to put them back in, however 
because of the nature of extractors I cannot gaurantee any length of 
ongoing support for them - ie if they oppose some other mainstream 
feature I may drop them again.

Mark
Peter wrote:

>As you know I want to have extractors back - I like the idea of the
>extractors in general.  What I wanted though is perhaps a subclass of
>Extractor - "InExtractor" that expands the returned object (that should be a
>Collection or array) and creates a tuple for each element that matches the
>ObjectType.
>
>Peter.
>
>----- Original Message ----- 
>From: "Steven Warren" <steve <at> myvest.com>
>To: <user <at> drools.codehaus.org>
>Sent: Tuesday, February 01, 2005 08:38 PM
>Subject: RE: [drools-user] extractors
>
>
>  
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Proctor | 2 Feb 2005 18:07

[drools-dev] Re: [drools-user] extractors

With the current code base we are near enough in a condition to do a 
release candidate after one or two more betas. If I take the effort to 
put extractors back in it will the delay the release. Whats the group's 
view on this? My personal feelings is to leave them out and finally get 
2.0 out, especially as very few people use them. Although if the group 
thinks its important enough I will endevour to put them back in, however 
because of the nature of extractors I cannot gaurantee any length of 
ongoing support for them - ie if they oppose some other mainstream 
feature I may drop them again.

Mark
Peter wrote:

>As you know I want to have extractors back - I like the idea of the
>extractors in general.  What I wanted though is perhaps a subclass of
>Extractor - "InExtractor" that expands the returned object (that should be a
>Collection or array) and creates a tuple for each element that matches the
>ObjectType.
>
>Peter.
>
>----- Original Message ----- 
>From: "Steven Warren" <steve <at> myvest.com>
>To: <user <at> drools.codehaus.org>
>Sent: Tuesday, February 01, 2005 08:38 PM
>Subject: RE: [drools-user] extractors
>
>
>  
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Proctor | 2 Feb 2005 19:18

[drools-dev] Re: [drools-user] extractors

ok consider it done then. I'm going to release another beta tonight 
then. If that goes well hopefully one more beta before I RC.

Mark
Peter wrote:

>I would not hold up the release for extractors - when/if you decide to add
>extractors - this can be a post 2.0 feature enhancement.
>
>----- Original Message ----- 
>From: "Steven Warren" <steve <at> myvest.com>
>To: <user <at> drools.codehaus.org>
>Sent: Wednesday, February 02, 2005 12:18 PM
>Subject: RE: [drools-user] extractors
>
>
>  
>
>>I am certainly fine with that, there are other ways to do extractor
>>support (such as using AOP).
>>
>>-----Original Message-----
>>From: Mark Proctor [mailto:mproctor <at> codehaus.org]
>>Sent: Wednesday, February 02, 2005 9:06 AM
>>To: user <at> drools.codehaus.org; dev <at> drools.codehaus.org
>>Subject: Re: [drools-user] extractors
>>
>>
>>With the current code base we are near enough in a condition to do a
>>release candidate after one or two more betas. If I take the effort to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Lin | 3 Feb 2005 01:59
Picon

[drools-dev] updating the website

Since it is getting close to releasing Drools 2.0, it might be a good
time to update the documentation to reflect the current knowledge
about RETE and make some corrections.

I can help update the docs if help is needed. It is more accurate to say this.

Drools is currently working to implement Dr. Forgy's RETE algorithm.
The current implementation is closer to a tuple based forward chaining
algorithm. There are several important differences between strict RETE
and Drools.

1. RETE requires implementing alpha and beta memory, which Drools is
working towards

2. Drools does not create shadow facts from objects, which is
necessary and crucial for truth maintenance

3. Drools current uses the object for bindings, which results in
dramatic impact in performance. Strict RETE uses slot based binding,
which means bindings are local to a rule. Slot in RETE are equivalent
to object fields in Java.

4. Drools does not yet support negation count in the RETE network. The
temporary work around although functional is not the most optimal. The
current method for handling negation count is to use the semantic
module.

5. As the rulebase grows in size, Drools will slow down dramatically.
This is because Drools currently does not implement strict RETE.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Barry Kaplan | 5 Feb 2005 15:12

[drools-dev] Drools 2.0-BETA-21 Released

Drools 2.0-BETA-21 Released

The Drools development team is proud to announce the release of Drools 2.0-Beta-21.

Please see the Release Notes for more details on this release 
(http://docs.codehaus.org/display/DROOLS/Release+Notes).

---

This release includes an implementation of the "Jess in Action" HVAC example 
using the new annotation module. When I created that example I pretty much 
converted the code as is from the book. However, I am now back-writing 
unit-tests for this example (since this has been comming up recently on the 
mailing list), and as a result I'm performing quite a few refactorings to the 
rules. Of course, had the example been written test first (vs conversion) these 
refactorings would have been designed in.

In any case, these tests and refactorings are not included in the beta-21 
distribution; you will have to check out cvs or use fisheye if you wish to study 
the tests and refactored rules.

Enjoy!

--

-- 
barry kaplan
codehaus <at> memelet.com
Permalink | Reply | 0 comments |
headers
Barry Kaplan | 5 Feb 2005 18:53

[drools-user] Re: [drools-dev] Drools 2.0-BETA-21 Released

Barry Kaplan wrote:

I've committed the HVAC unit-tests. You can get a snapshot via CVS or
from fishsye at:

  - http://cvs.drools.codehaus.org/viewrep/drools/drools/drools-examples-jdk5.

--

-- 
barry kaplan
groups1 <at> memelet.com
Permalink | Reply | 0 comments |

Gmane