[rules-dev] Re: [drools-dev] 3.2 M1

Edson Tirelli tirelli at post.com
Sat Jan 13 15:44:25 EST 2007


   Peter,

   I imagine you are right, but FOL "forall" requires 2 levels of 
nesting. From an implementation perspective (code), supporting 2 levels 
of nesting or supporting X levels of nesting is exactly the same, as the 
algorithm for creating the subnetworks is inherently recursive.
  
   So, if users start to abuse, good for the consultants.

   []s
   Edson

Peter Lin wrote:

>
> haha, users already do the right thing :)
>
> so no one ever needs to worry about a rule being 5 pages with deeply 
> nested and/or.  Joking aside, I am quite shocked at how frequent users 
> do it. In fact, I would say it's like half the time, users do stupid 
> things like that.
>
> then they bring in a consultant, who fixes the pile of mess.
>
> peter
>
> On 1/13/07, *Michael Neale* <michael.neale at gmail.com 
> <mailto:michael.neale at gmail.com>> wrote:
>
>     yes, well just cause you can, doesn't mean you should... ;)
>
>     I think its needed for the first order logic stuff like not,
>     exists, forall, *occasionally* (especially "not" I have often
>     wanted it), but should only be used as a light seasoning.
>
>
>     On 1/12/07, *Peter Lin* < woolfel at gmail.com
>     <mailto:woolfel at gmail.com>> wrote:
>
>
>         oh the horror of users nesting statements 4-10 deep.
>
>         I fear the poor user won't know what the heck they wrote the
>         next day :)
>
>         peter
>
>
>         On 1/12/07, *Edson Tirelli* < tirelli at post.com
>         <mailto:tirelli at post.com>> wrote:
>
>                Except for the need to change code target to 1.5, core
>             and compiler
>             are compiling fine now and all tests are green.
>
>                I just commited the new Builders. We now support any
>             level of
>             Conditional Elements nesting.
>
>                Forall is just syntax sugar that I will add now. Shall
>             be ok on monday.
>
>                So, I think the major requirement for M1 is the MVEL stuff.
>
>                []s
>                Edson
>
>             Michael Neale wrote:
>
>> lol ! other then 3.0.x branch ?? ;)
>>
>> Edson may know a branch to use, but in any case, Mark is
>             beavering
>> away on MVEL integration which will be awesome (I think
>             he wants MVEL
>> for an M1 release).
>>
>> On 1/12/07, *Dirk Bergstrom* < dirk at juniper.net
>             <mailto:dirk at juniper.net>
>> <mailto: dirk at juniper.net <mailto:dirk at juniper.net>>> wrote:
>>
>>     Michael Neale was heard to exclaim, On 01/02/07 05:28:
>>     > Guys, I am ok to do a M1 release of 3.2  whenever
>             needed
>>
>>     Any news on this?  I've been running (in production
>             now) on code I
>>     pulled from
>>     trunk a month or so ago, and it throws NPEs now and
>             again.  I'd
>>     really like to
>>     get something a bit more stable.  Today's trunk
>             "revision 8842"
>>     doesn't build,
>>     because the mvel code is Java 1.5.
>>
>>     I'm kinda stuck here, and I'm hoping that someone can
>             throw me a
>>     bone.  If M1
>>     isn't coming soon, was there a particular revision
>             number that was
>>     fairly stable
>>     that I can use?
>>
>>     --
>>     Dirk Bergstrom               dirk at juniper.net
>             <mailto:dirk at juniper.net>
>>     <mailto: dirk at juniper.net <mailto:dirk at juniper.net>>
>>     _____________________________________________
>>     Juniper Networks Inc.,          Computer Geek
>>     Tel: 408.745.3182           Fax: 408.745.8905
>>     _______________________________________________
>>     rules-users mailing list
>>     rules-users at lists.jboss.org
>             <mailto:rules-users at lists.jboss.org>
>             <mailto:rules-users at lists.jboss.org
>             <mailto:rules-users at lists.jboss.org>>
>>     https://lists.jboss.org/mailman/listinfo/rules-users
>             <https://lists.jboss.org/mailman/listinfo/rules-users>
>>
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>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
>>
>>
>
>
>             --
>             Edson Tirelli
>             Software Engineer - JBoss Rules Core Developer
>             Office: +55 11 3124-6000
>             Mobile: +55 11 9218-4151
>             JBoss, a division of Red Hat @ www.jboss.com
>             <http://www.jboss.com>
>
>
>             _______________________________________________
>             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
>
>
>
>         _______________________________________________
>         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
>
>
>
>
>     _______________________________________________
>     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
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>rules-dev mailing list
>rules-dev at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/rules-dev
>  
>


-- 
 Edson Tirelli
 Software Engineer - JBoss Rules Core Developer
 Office: +55 11 3124-6000
 Mobile: +55 11 9218-4151
 JBoss, a division of Red Hat @ www.jboss.com





More information about the rules-dev mailing list