Edson Tirelli | 5 Aug 21:57

Re: [rules-dev] [rules-users] MVEL parsing / keyword conflict


   The DRL parser requires that the argument expression to a "from" CE be a function call or a chained call to methods. The work around to that is to call the MVEL "function" "return":

$items: LinkedList (size > 1) from collect ( Model ( ) from return( object.getOriginal(null) in spatialIndex.query(...) ) )

   This way, the parser will passthrough whatever he finds inside the return( ... ) to MVEL. Let us know if it works for you. I never tested that.

   []s
   Edson



2009/8/5 Simon Thum <simon.thum <at> gmx.de>
Edson Tirelli wrote:
>    Simon,
>
>    Can you show us what syntax are you trying?
Sure, I was just speculating it's known or trivial.

Works:
$items: LinkedList (size > 1) from collect ( Model ( ) from
spatialIndex.query(...) )

Fails:

$items: LinkedList (size > 1) from collect ( Model ( ) from
>object.getOriginal(null) in spatialIndex.query(...)< )

The angle brackets aren't typed, they just mark what's intended as mvel.

>
>    []s
>    Edson
>
> 2009/8/5 Simon Thum <simon.thum <at> gmx.de>
>
>> Hi all,
>>
>> I've stumbled on some mvel integration issues in 5.0.1. I'm using drools
>> to do, among others, spatial reasoning. At insertion time I maintain a
>> specialized index, which can be queried later using [collect] from. This
>> works fine in general.
>>
>> However, as soon as I use the mvel 2 projections a.k.a. 'in' keyword,
>> hell breaks loose. 'in' is described here:
>> http://mvel.codehaus.org/MVEL+2.0+Projections+and+Folds
>>
>> But I only seem to get syntax errors. If it is possible, to somehow
>> escape keywords or explicitly pipe through the mvel part, please let me
>> know!
>>
>> Needless to say, this feature would be great to have since my object
>> model is mainly fixed and 'is' allows me to compensate that. Worse, I'd
>> need to assert objects I don't want to assert to work around.
>>
>> I tried parenthesizing, only to discover that
>> ... from valid_stmt
>>
>> is fine, but
>>
>> ... from (valid_stmt)
>>
>> won't work either. Error 101, reason unknown, but it doesn't even make
>> it through the parser.
>>
>> I'd really appreciate to be given an idea why what I did went wrong.
>> Googling around didn't get me too far.
>>
>> Cheers,
>>
>> Simon
>> _______________________________________________
>> rules-users mailing list
>> rules-users <at> lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> rules-users mailing list
> rules-users <at> lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users




--
 Edson Tirelli
 JBoss Drools Core Development
 JBoss by Red Hat <at> www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Geoffrey De Smet | 8 Aug 11:39
Picon
Gravatar

[rules-dev] Drools Solver homepage

Hi guys,

On the drools homepage, each of the major subprojects have a homepage, 
for example for Guvnor:
   http://labs.jboss.com/drools/drools-guvnor.html

Such a homepage answers a few start questions:
- What is it?
- What are its features?
- Lets see some screenshots.
- Where do I go next? => download, examples, reference manual, blog, ...

Drools Solver doesn't have such a homepage yet, so when I have to fill 
in a link to drools solver, I sometimes fill in the blog or the 
reference manual or even the article on Dzone.
So such a Drools Solver homepage is missing: I can create some content 
for it, if JBoss is willing to add a page to the Drools homepage?

WDYT?

--

-- 
With kind regards,
Geoffrey De Smet

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

Geoffrey De Smet | 8 Aug 12:46
Picon
Gravatar

[rules-dev] Why is this DRL twice as slow?

Hi guys,

I've run some experiments on the DRL's used in the drools solver 
examination example to see how the DRL affects performance.

In one experiment, I merged 2 rules into 1 rule:

I changed this DRL part of examinationScoreRules.drl:

rule "hardConstraintsBroken"
         salience -1
     when
         $hardTotal : Number() from accumulate(
             IntConstraintOccurrence(constraintType == 
ConstraintType.NEGATIVE_HARD, $weight : weight),
             sum($weight)
         );
     then
         scoreCalculator.setHardConstraintsBroken($hardTotal.intValue());
end

rule "softConstraintsBroken"
         salience -1
     when
         $softTotal : Number() from accumulate(
             IntConstraintOccurrence(constraintType == 
ConstraintType.NEGATIVE_SOFT, $weight : weight),
             sum($weight)
         );
     then
         scoreCalculator.setSoftConstraintsBroken($softTotal.intValue());
end

into this DRL part:

rule "constraintsBroken"
         salience -1
     when
         $hardTotal : Number() from accumulate(
             IntConstraintOccurrence(constraintType == 
ConstraintType.NEGATIVE_HARD, $weight : weight),
             sum($weight)
         );
         $softTotal : Number() from accumulate(
             IntConstraintOccurrence(constraintType == 
ConstraintType.NEGATIVE_SOFT, $weight : weight),
             sum($weight)
         );
     then
         scoreCalculator.setHardConstraintsBroken($hardTotal.intValue());
         scoreCalculator.setSoftConstraintsBroken($softTotal.intValue());
end

Now the performance for a 100 steps when from 71s to 172s, so it more 
then doubled.
All other code stayed the same and the output (except for the times) is 
exactly the same.
What can explain this loss in performance?

--

-- 
With kind regards,
Geoffrey De Smet

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

Greg Barton | 8 Aug 13:22
Picon
Favicon

Re: [rules-dev] Why is this DRL twice as slow?


As I understand it, the from keyword is not optimized in the way that it's output is not indexed.  Therefore if
the set of objects matched changes it must rerun.  So when you have the two rules, "hardConstraintsBroken"
is reevaluated when you change the hard constraints, and "softConstraintsBroken" is reevaluated when
you change the soft constraints.  When there's just the one rule, it's reevaluated when either the hard or
soft constraints changed, but BOTH accumulate expressions are evaluated every time.  Thus, 2x the
evaluation time.

--- On Sat, 8/8/09, Geoffrey De Smet <ge0ffrey.spam <at> gmail.com> wrote:

> From: Geoffrey De Smet <ge0ffrey.spam <at> gmail.com>
> Subject: [rules-dev] Why is this DRL twice as slow?
> To: rules-dev <at> lists.jboss.org
> Date: Saturday, August 8, 2009, 5:46 AM
> Hi guys,
> 
> I've run some experiments on the DRL's used in the drools
> solver 
> examination example to see how the DRL affects
> performance.
> 
> In one experiment, I merged 2 rules into 1 rule:
> 
> I changed this DRL part of examinationScoreRules.drl:
> 
> rule "hardConstraintsBroken"
>          salience -1
>      when
>          $hardTotal :
> Number() from accumulate(
>          
>    IntConstraintOccurrence(constraintType ==
> 
> ConstraintType.NEGATIVE_HARD, $weight : weight),
>          
>    sum($weight)
>          );
>      then
>      
>    scoreCalculator.setHardConstraintsBroken($hardTotal.intValue());
> end
> 
> rule "softConstraintsBroken"
>          salience -1
>      when
>          $softTotal :
> Number() from accumulate(
>          
>    IntConstraintOccurrence(constraintType ==
> 
> ConstraintType.NEGATIVE_SOFT, $weight : weight),
>          
>    sum($weight)
>          );
>      then
>      
>    scoreCalculator.setSoftConstraintsBroken($softTotal.intValue());
> end
> 
> 
> 
> into this DRL part:
> 
> rule "constraintsBroken"
>          salience -1
>      when
>          $hardTotal :
> Number() from accumulate(
>          
>    IntConstraintOccurrence(constraintType ==
> 
> ConstraintType.NEGATIVE_HARD, $weight : weight),
>          
>    sum($weight)
>          );
>          $softTotal :
> Number() from accumulate(
>          
>    IntConstraintOccurrence(constraintType ==
> 
> ConstraintType.NEGATIVE_SOFT, $weight : weight),
>          
>    sum($weight)
>          );
>      then
>      
>    scoreCalculator.setHardConstraintsBroken($hardTotal.intValue());
>      
>    scoreCalculator.setSoftConstraintsBroken($softTotal.intValue());
> end
> 
> 
> Now the performance for a 100 steps when from 71s to 172s,
> so it more 
> then doubled.
> All other code stayed the same and the output (except for
> the times) is 
> exactly the same.
> What can explain this loss in performance?
> 
> -- 
> With kind regards,
> Geoffrey De Smet
> 
> _______________________________________________
> rules-dev mailing list
> rules-dev <at> lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
> 

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

Geoffrey De Smet | 8 Aug 14:03
Picon
Gravatar

Re: [rules-dev] Why is this DRL twice as slow?

But even if it get re-evaluated twice, it cannot explain a performance 
loss of more then 5%, let alone a a performance loss of 150%?

If you take a look at the accumulate sum function implementation, you 
'll see that the total gets cached.
That's also why an accumulate has "action code" and "reverse code".

So since that sum total gets cached, I see no reason why this line:
   $hardTotal : Number() from accumulate ...
would take any noticeable time?

I have a very strong feeling for a long time that accumulate functions 
are poison for drools-solver. Yet I see no way to workaround them.
Maybe we need some sort of "forward chaining accumulate" implementation?

With kind regards,
Geoffrey De Smet

Greg Barton schreef:
> As I understand it, the from keyword is not optimized in the way that it's output is not indexed.  Therefore
if the set of objects matched changes it must rerun.  So when you have the two rules,
"hardConstraintsBroken" is reevaluated when you change the hard constraints, and
"softConstraintsBroken" is reevaluated when you change the soft constraints.  When there's just the one
rule, it's reevaluated when either the hard or soft constraints changed, but BOTH accumulate
expressions are evaluated every time.  Thus, 2x the evaluation time.
> 
> --- On Sat, 8/8/09, Geoffrey De Smet <ge0ffrey.spam <at> gmail.com> wrote:
> 
>> From: Geoffrey De Smet <ge0ffrey.spam <at> gmail.com>
>> Subject: [rules-dev] Why is this DRL twice as slow?
>> To: rules-dev <at> lists.jboss.org
>> Date: Saturday, August 8, 2009, 5:46 AM
>> Hi guys,
>>
>> I've run some experiments on the DRL's used in the drools
>> solver 
>> examination example to see how the DRL affects
>> performance.
>>
>> In one experiment, I merged 2 rules into 1 rule:
>>
>> I changed this DRL part of examinationScoreRules.drl:
>>
>> rule "hardConstraintsBroken"
>>          salience -1
>>      when
>>          $hardTotal :
>> Number() from accumulate(
>>          
>>    IntConstraintOccurrence(constraintType ==
>>
>> ConstraintType.NEGATIVE_HARD, $weight : weight),
>>          
>>    sum($weight)
>>          );
>>      then
>>      
>>    scoreCalculator.setHardConstraintsBroken($hardTotal.intValue());
>> end
>>
>> rule "softConstraintsBroken"
>>          salience -1
>>      when
>>          $softTotal :
>> Number() from accumulate(
>>          
>>    IntConstraintOccurrence(constraintType ==
>>
>> ConstraintType.NEGATIVE_SOFT, $weight : weight),
>>          
>>    sum($weight)
>>          );
>>      then
>>      
>>    scoreCalculator.setSoftConstraintsBroken($softTotal.intValue());
>> end
>>
>>
>>
>> into this DRL part:
>>
>> rule "constraintsBroken"
>>          salience -1
>>      when
>>          $hardTotal :
>> Number() from accumulate(
>>          
>>    IntConstraintOccurrence(constraintType ==
>>
>> ConstraintType.NEGATIVE_HARD, $weight : weight),
>>          
>>    sum($weight)
>>          );
>>          $softTotal :
>> Number() from accumulate(
>>          
>>    IntConstraintOccurrence(constraintType ==
>>
>> ConstraintType.NEGATIVE_SOFT, $weight : weight),
>>          
>>    sum($weight)
>>          );
>>      then
>>      
>>    scoreCalculator.setHardConstraintsBroken($hardTotal.intValue());
>>      
>>    scoreCalculator.setSoftConstraintsBroken($softTotal.intValue());
>> end
>>
>>
>> Now the performance for a 100 steps when from 71s to 172s,
>> so it more 
>> then doubled.
>> All other code stayed the same and the output (except for
>> the times) is 
>> exactly the same.
>> What can explain this loss in performance?
>>
>> -- 
>> With kind regards,
>> Geoffrey De Smet
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev <at> lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
> 
> 
>       
> 
> _______________________________________________
> rules-dev mailing list
> rules-dev <at> lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
> 

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

Edson Tirelli | 8 Aug 14:05

Re: [rules-dev] Why is this DRL twice as slow?


    Greg is in the right direction. When you have:

when
    Pattern1()
    Pattern2()
then
   ...

   Anytime Pattern1 change, Pattern2 beta constraints must be reevaluated. The problem in your case is that both patterns are accumulates, so they are heavier by themselves AND everytime the first one changes, the second must fully recalculate.

   []s
   Edson

2009/8/8 Greg Barton <greg_barton <at> yahoo.com>

As I understand it, the from keyword is not optimized in the way that it's output is not indexed.  Therefore if the set of objects matched changes it must rerun.  So when you have the two rules, "hardConstraintsBroken" is reevaluated when you change the hard constraints, and "softConstraintsBroken" is reevaluated when you change the soft constraints.  When there's just the one rule, it's reevaluated when either the hard or soft constraints changed, but BOTH accumulate expressions are evaluated every time.  Thus, 2x the evaluation time.

--- On Sat, 8/8/09, Geoffrey De Smet <ge0ffrey.spam <at> gmail.com> wrote:

> From: Geoffrey De Smet <ge0ffrey.spam <at> gmail.com>
> Subject: [rules-dev] Why is this DRL twice as slow?
> To: rules-dev <at> lists.jboss.org
> Date: Saturday, August 8, 2009, 5:46 AM
> Hi guys,
>
> I've run some experiments on the DRL's used in the drools
> solver
> examination example to see how the DRL affects
> performance.
>
> In one experiment, I merged 2 rules into 1 rule:
>
> I changed this DRL part of examinationScoreRules.drl:
>
> rule "hardConstraintsBroken"
>          salience -1
>      when
>          $hardTotal :
> Number() from accumulate(
>          
>    IntConstraintOccurrence(constraintType ==
>
> ConstraintType.NEGATIVE_HARD, $weight : weight),
>          
>    sum($weight)
>          );
>      then
>      
>    scoreCalculator.setHardConstraintsBroken($hardTotal.intValue());
> end
>
> rule "softConstraintsBroken"
>          salience -1
>      when
>          $softTotal :
> Number() from accumulate(
>          
>    IntConstraintOccurrence(constraintType ==
>
> ConstraintType.NEGATIVE_SOFT, $weight : weight),
>          
>    sum($weight)
>          );
>      then
>      
>    scoreCalculator.setSoftConstraintsBroken($softTotal.intValue());
> end
>
>
>
> into this DRL part:
>
> rule "constraintsBroken"
>          salience -1
>      when
>          $hardTotal :
> Number() from accumulate(
>          
>    IntConstraintOccurrence(constraintType ==
>
> ConstraintType.NEGATIVE_HARD, $weight : weight),
>          
>    sum($weight)
>          );
>          $softTotal :
> Number() from accumulate(
>          
>    IntConstraintOccurrence(constraintType ==
>
> ConstraintType.NEGATIVE_SOFT, $weight : weight),
>          
>    sum($weight)
>          );
>      then
>      
>    scoreCalculator.setHardConstraintsBroken($hardTotal.intValue());
>      
>    scoreCalculator.setSoftConstraintsBroken($softTotal.intValue());
> end
>
>
> Now the performance for a 100 steps when from 71s to 172s,
> so it more
> then doubled.
> All other code stayed the same and the output (except for
> the times) is
> exactly the same.
> What can explain this loss in performance?
>
> --
> With kind regards,
> Geoffrey De Smet
>
> _______________________________________________
> rules-dev mailing list
> rules-dev <at> lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>




_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev



--
 Edson Tirelli
 JBoss Drools Core Development
 JBoss by Red Hat <at> www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Geoffrey De Smet | 8 Aug 14:43
Picon
Gravatar

Re: [rules-dev] Why is this DRL twice as slow? Why is calculationg from scratch faster?

So I tried this "query from scratch each time" experiment:

query "hardConstraintsBroken"
     constraintOccurrence : IntConstraintOccurrence(constraintType == 
ConstraintType.NEGATIVE_HARD)
end
query "softConstraintsBroken"
     constraintOccurrence : IntConstraintOccurrence(constraintType == 
ConstraintType.NEGATIVE_SOFT)
end

With this java code:

         int hard = 0;
         QueryResults results = 
workingMemory.getQueryResults("hardConstraintsBroken");
         for (QueryResult result : results) {
             IntConstraintOccurrence constraintOccurrence = 
(IntConstraintOccurrence) result.get("constraintOccurrence");
             hard += constraintOccurrence.getWeight();
         }
         int soft = 0;
         results = workingMemory.getQueryResults("softConstraintsBroken");
         for (QueryResult result : results) {
             IntConstraintOccurrence constraintOccurrence = 
(IntConstraintOccurrence) result.get("constraintOccurrence");
             soft += constraintOccurrence.getWeight();
         }

That takes 118s.
So it's clearly faster than the merged rule DRL!
It's not faster than the original accumulate DRL.
- original DRL: 71s
- query from scratch each time: 118s
- merged rule DRL: 172s

So calculating everything from scratch each time (and fetching it from 
the QueryResult Map) is faster than using 2 accumulate.

With kind regards,
Geoffrey De Smet

Geoffrey De Smet schreef:
> Hi guys,
> 
> I've run some experiments on the DRL's used in the drools solver 
> examination example to see how the DRL affects performance.
> 
> In one experiment, I merged 2 rules into 1 rule:
> 
> I changed this DRL part of examinationScoreRules.drl:
> 
> rule "hardConstraintsBroken"
>          salience -1
>      when
>          $hardTotal : Number() from accumulate(
>              IntConstraintOccurrence(constraintType == 
> ConstraintType.NEGATIVE_HARD, $weight : weight),
>              sum($weight)
>          );
>      then
>          scoreCalculator.setHardConstraintsBroken($hardTotal.intValue());
> end
> 
> rule "softConstraintsBroken"
>          salience -1
>      when
>          $softTotal : Number() from accumulate(
>              IntConstraintOccurrence(constraintType == 
> ConstraintType.NEGATIVE_SOFT, $weight : weight),
>              sum($weight)
>          );
>      then
>          scoreCalculator.setSoftConstraintsBroken($softTotal.intValue());
> end
> 
> 
> 
> into this DRL part:
> 
> rule "constraintsBroken"
>          salience -1
>      when
>          $hardTotal : Number() from accumulate(
>              IntConstraintOccurrence(constraintType == 
> ConstraintType.NEGATIVE_HARD, $weight : weight),
>              sum($weight)
>          );
>          $softTotal : Number() from accumulate(
>              IntConstraintOccurrence(constraintType == 
> ConstraintType.NEGATIVE_SOFT, $weight : weight),
>              sum($weight)
>          );
>      then
>          scoreCalculator.setHardConstraintsBroken($hardTotal.intValue());
>          scoreCalculator.setSoftConstraintsBroken($softTotal.intValue());
> end
> 
> 
> Now the performance for a 100 steps when from 71s to 172s, so it more 
> then doubled.
> All other code stayed the same and the output (except for the times) is 
> exactly the same.
> What can explain this loss in performance?
> 

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

Mauricio Salatino | 8 Aug 15:37
Picon
Gravatar

Re: [rules-dev] Drools Solver homepage

yes.. it would be nice.. can you post your blog here?


On Sat, Aug 8, 2009 at 6:39 AM, Geoffrey De Smet <ge0ffrey.spam <at> gmail.com> wrote:
Hi guys,

On the drools homepage, each of the major subprojects have a homepage,
for example for Guvnor:
  http://labs.jboss.com/drools/drools-guvnor.html

Such a homepage answers a few start questions:
- What is it?
- What are its features?
- Lets see some screenshots.
- Where do I go next? => download, examples, reference manual, blog, ...

Drools Solver doesn't have such a homepage yet, so when I have to fill
in a link to drools solver, I sometimes fill in the blog or the
reference manual or even the article on Dzone.
So such a Drools Solver homepage is missing: I can create some content
for it, if JBoss is willing to add a page to the Drools homepage?

WDYT?

--
With kind regards,
Geoffrey De Smet

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev



--
- http://salaboy.wordpress.com
- http://www.jbug.com.ar
- Salatino "Salaboy" Mauricio -
_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Geoffrey De Smet | 8 Aug 16:12
Picon
Gravatar

Re: [rules-dev] Drools Solver homepage

Maurico,

The drools solver blog is just the drools blog filtered on the label solver:
   http://blog.athico.com/search/label/solver

With kind regards,
Geoffrey De Smet

Mauricio Salatino schreef:
> yes.. it would be nice.. can you post your blog here?
> 
> 
> On Sat, Aug 8, 2009 at 6:39 AM, Geoffrey De Smet 
> <ge0ffrey.spam <at> gmail.com <mailto:ge0ffrey.spam <at> gmail.com>> wrote:
> 
>     Hi guys,
> 
>     On the drools homepage, each of the major subprojects have a homepage,
>     for example for Guvnor:
>       http://labs.jboss.com/drools/drools-guvnor.html
> 
>     Such a homepage answers a few start questions:
>     - What is it?
>     - What are its features?
>     - Lets see some screenshots.
>     - Where do I go next? => download, examples, reference manual, blog, ...
> 
>     Drools Solver doesn't have such a homepage yet, so when I have to fill
>     in a link to drools solver, I sometimes fill in the blog or the
>     reference manual or even the article on Dzone.
>     So such a Drools Solver homepage is missing: I can create some content
>     for it, if JBoss is willing to add a page to the Drools homepage?
> 
>     WDYT?
> 
>     --
>     With kind regards,
>     Geoffrey De Smet
> 
>     _______________________________________________
>     rules-dev mailing list
>     rules-dev <at> lists.jboss.org <mailto:rules-dev <at> lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/rules-dev
> 
> 
> 
> 
> -- 
> - http://salaboy.wordpress.com
> - http://www.jbug.com.ar
> - Salatino "Salaboy" Mauricio -
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> rules-dev mailing list
> rules-dev <at> lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

Mauricio Salatino | 8 Aug 16:13
Picon
Gravatar

Re: [rules-dev] Drools Solver homepage

heh,, ok.. I suppose that you have your own blog about solver..

On Sat, Aug 8, 2009 at 11:12 AM, Geoffrey De Smet <ge0ffrey.spam <at> gmail.com> wrote:
Maurico,

The drools solver blog is just the drools blog filtered on the label solver:
  http://blog.athico.com/search/label/solver

With kind regards,
Geoffrey De Smet


Mauricio Salatino schreef:
> yes.. it would be nice.. can you post your blog here?
>
>
> On Sat, Aug 8, 2009 at 6:39 AM, Geoffrey De Smet
> <ge0ffrey.spam <at> gmail.com <mailto:ge0ffrey.spam <at> gmail.com>> wrote:
>
>     Hi guys,
>
>     On the drools homepage, each of the major subprojects have a homepage,
>     for example for Guvnor:
>       http://labs.jboss.com/drools/drools-guvnor.html
>
>     Such a homepage answers a few start questions:
>     - What is it?
>     - What are its features?
>     - Lets see some screenshots.
>     - Where do I go next? => download, examples, reference manual, blog, ...
>
>     Drools Solver doesn't have such a homepage yet, so when I have to fill
>     in a link to drools solver, I sometimes fill in the blog or the
>     reference manual or even the article on Dzone.
>     So such a Drools Solver homepage is missing: I can create some content
>     for it, if JBoss is willing to add a page to the Drools homepage?
>
>     WDYT?
>
>     --
>     With kind regards,
>     Geoffrey De Smet
>
>     _______________________________________________
>     rules-dev mailing list
>     rules-dev <at> lists.jboss.org <mailto:rules-dev <at> lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
>
> --
> - http://salaboy.wordpress.com
> - http://www.jbug.com.ar
> - Salatino "Salaboy" Mauricio -
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> rules-dev mailing list
> rules-dev <at> lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev



--
- http://salaboy.wordpress.com
- http://www.jbug.com.ar
- Salatino "Salaboy" Mauricio -
_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

Gmane