Hi Michael, Yes, I can do so, once this is finished :)
Cheers, Leo. On Tue, Sep 21, 2010 at 10:13 AM, Anstis, Michael (M.) <[email protected]>wrote: > You're not alone in wanting to see the changes... > > It'd be good if Leo would be willing to post his experience as a comment on > the original blog > http://blog.athico.com/2010/09/lazily-enabled-truth-maintenace.html > > It might help others wanting to get involved. > > ------------------------------ > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Mauricio Salatino > *Sent:* 20 September 2010 23:18 > *To:* Rules Dev List > *Subject:* Re: [rules-dev] Lazily Enabled Truth Maintenace (Project > Propsoal) > > nice, is it working? I would like to see the changes in the commits.. > Greetings. > > On Mon, Sep 20, 2010 at 7:09 PM, Mark Proctor <[email protected]>wrote: > >> On 20/09/2010 21:58, Leonardo Gomes wrote: >> >> Ok, it took me much longer that I had thought, but I think it's working >> now.. all tests passing except for ReteooWorkingMemoryTest that does: >> >> FactHandle fd = workingMemory.insert( string ); >>> >>> assertEquals( 1, >>> tms.getAssertMap().size() ); >>> >> >> Which is a good sign, since tms is now empty as long as you haven't done >> any logical insert :) >> >> I implemented just the first part of your suggestion, with a boolean. I >> will try to implement the solution with the counter later this week and >> maybe do some adjustments before submitting a patch. >> >> Do you have any suggestion in terms of unit tests that you would like to >> see or just the apparent lack of regressions is enough? Well, I can also >> think of some tests by taking ReteooWorkingMemoryTest as an example, in case >> you don't have anything particular in mind. >> >> When you do some insertions cast to get some of the internal data >> structures and check the equality map is null, maybe check the OT confs are >> false, do a logical insertion check it can turn on for specific OTNs and not >> all and that it correctly adds all objects for the OTN. This will be >> important for the next stage of the work. >> >> Mark >> >> >> Cheers, >> Leo. >> >> >> >> >> On Mon, Sep 20, 2010 at 5:14 PM, Mark Proctor <[email protected]>wrote: >> >>> On 20/09/2010 15:53, Leonardo Gomes wrote: >>> >>> I think I wasn't quite clear in my last email, so let me try to >>> reformulate it: >>> >>> I also gave it a try to try to do what you suggested here ( >>> http://blog.athico.com/2010/09/lazily-enabled-truth-maintenace.html), >>> Mark, and couldn't make it work due to the following situation: >>> >>> 1) Current code seems to rely on the equality map to know that a logical >>> insert (insertLogical) for an object that has already been regularly >>> inserted (insert) should be ignored; >>> >>> You would need to lazily maintain an equality map. When the first logical >>> insertion is done we will have to first populate that map from the Object >>> Type Node set of FactHandles. >>> In the "insert" one of the first lines is: >>> ObjectTypeConf typeConf = this.typeConfReg.getObjectTypeConf( >>> this.entryPoint, >>> >>> object ); >>> >>> So we get the ObjectTypeConf before we do anything with the object >>> itself, and we can check if TMS is being maintained for that Object Type. >>> >>> >>> 2) If I apply the modifications that you suggested, from what I >>> understood, things would start to be put in the equality map only when a >>> logical insert is issued; >>> >>> *Problem*: How would I handle the situation described in item 1, if I >>> don't have anything in the equality map at the moment a logical insert comes >>> in and I have to "lazily activate" TMS? >>> >>> final Rete source = this.ruleBase.getRete(); >>> ClassObjectType cot = new ClassObjectType( MyClass.class ); >>> Map<ObjectType, ObjectTypeNode> map = source.getObjectTypeNodes( >>> EntryPoint.DEFAULT ); >>> ObjectTypeNode node = map.get( cot ); >>> final ObjectHashSet memory = (ObjectHashSet) workingMemory.getNodeMemory( >>> node ); >>> >>> That "memory" is the set of currently asserted objects for that OTN. You >>> can now iterate that and populate the equality hash map. This is a one off >>> as the flag will be set on the ObjectTypeConf from then on and all objects >>> will be added to the equality map at the point of insertion. >>> >>> Does that help? All the information is there, you should have to know how >>> to retrieve it :) We don't currently maintain TMS for anything other than >>> the default entry point. Although I think that was a mistake and we will >>> probably move all entrypoints to work with same, but for now you can ignore >>> that and just focus on the default. >>> >>> Btw this should not be confused with "equality" mode where the equality >>> map has to be maintained by default from the start. Some would argue that a >>> rule engine should only under work and understand on the bases of equality >>> and thus all users must implement hashcode and equals correctly... >>> >>> >>> -- >>> >>> Moreover, I'm willing to attempt to implement the left and right >>> un-linking and tried to start with this easier task to start to get familiar >>> with drools-core. I already read the article you linked and your article. >>> Would you have any document with an overview of the way drools implements >>> rete? >>> >>> not really no, Rete has already well documented in a number of papers. >>> The best thing to do is get onto irc and talk directly to edson and I and we >>> can walk you through classes. >>> http://www.jboss.org/drools/irc.html >>> >>> Mark >>> >>> >>> Thanks in advance! >>> >>> Cheers, >>> Leo. >>> >>> >>> >>> >>> >>> >>> On Sat, Sep 18, 2010 at 3:49 AM, Leonardo Gomes < >>> [email protected]> wrote: >>> >>>> if you look at the AbstractWorkingMemory insert method you'll see one >>>>> argument is whether it's a logical insertion or not. You'll also see it >>>>> check the global maintainTMS configuration and also retrieve the >>>>> ObjectTypeConf. So between those things someone should be able to get it >>>>> working. >>>>> >>>> >>>> Today, it enters a block where it operates on the equality map and also >>>> creates a default handle based on that TMS global option and *regardless* >>>> of >>>> whether it's a logical insert. >>>> >>>> If I'm *not* putting things in the equality map for regular inserts, >>>> when a logical insert comes in, but there were already stated inserts, how >>>> will I know that? I would create a new handle for the logical insert and do >>>> the tms.addLogicalDependency(...), even tough there were regular inserts >>>> before and this seems to be a wrong behaviour. >>>> >>>> Apparently, today, you can disable TMS and still use logical inserts in >>>> your drl, what, I believe, will lead to inconsistent behaviour, but you're >>>> at your own risk. >>>> >>>> Ideas? I feel that I missed something :) >>>> >>>> Cheers, >>>> Leo. >>>> >>>> P.S.: I reached the conclusions above based on the fact that >>>> LogicalAssertionTest started failing after I did the changes you suggested. >>>> >>>> >>>> >>>> >>>> On Wed, Sep 15, 2010 at 3:47 PM, Mark Proctor <[email protected]>wrote: >>>> >>>>> On 15/09/2010 14:35, Michael Anstis wrote: >>>>> >>>>> Is this in drools-core; or drools-compiler? >>>>> >>>>> Whilst not undertaking to do the work; have a purpose to nose through >>>>> the code makes understanding easier. >>>>> >>>>> It's all in DroolsCore. >>>>> >>>>> It's a 5 minute hack for me and then 15 minute unit writing test. But I >>>>> thought I'd write it up in a hope to bring someone else into the fold, we >>>>> need more help writting the core engine someone else out there must want >>>>> to >>>>> work on current edge engine design :) >>>>> >>>>> if you look at the AbstractWorkingMemory insert method you'll see one >>>>> argument is whether it's a logical insertion or not. You'll also see it >>>>> check the global maintainTMS configuration and also retrieve the >>>>> ObjectTypeConf. So between those things someone should be able to get it >>>>> working. >>>>> >>>>> Mark >>>>> >>>>> >>>>> On 14 September 2010 16:47, Mark Proctor <[email protected]>wrote: >>>>> >>>>>> Here is another project proposal, this time simpler. I think this one >>>>>> has Wolfgang's name on it ;) >>>>>> >>>>>> http://blog.athico.com/2010/09/lazily-enabled-truth-maintenace.html >>>>>> >>>>>> Three weeks ago I posted the project idea for "Left and Right >>>>>> Unlinking"<http://blog.athico.com/2010/08/left-and-right-unlinking-community.html>. >>>>>> So far there are no takers, so if you are interested let me know :) >>>>>> >>>>>> In the meantime I tried to think of a simpler enhancement that we >>>>>> would like to see done. >>>>>> >>>>>> At the moment Drools has a user setting "MaintainTMSOption" which can >>>>>> be true or false. It's a small optimisation that when turned off avoids >>>>>> using the equality hashmap that is maintained for all inserted objects. >>>>>> >>>>>> It would be a much better idea to remove this configuration setting, >>>>>> thus simplifying things for end users and have TMS lazily enabled on >>>>>> demand. >>>>>> >>>>>> For each object type there is an "ObjectTypeConf" configuration object >>>>>> that is retrieved every time a working memory action, such as insert, is >>>>>> executed. The enabledTMS boolean should be moved there, so there is one >>>>>> per >>>>>> object type, by default it is false. >>>>>> >>>>>> When a working memory action occurs, like insert, it retrieved the >>>>>> ObjectTypeConf and checks the maintainTms boolean there, instead of the >>>>>> current engine scoped configuration. When a logical insertion occurs and >>>>>> the >>>>>> ObjectTypeConf is retrieved if maintainTms is false it sets the value to >>>>>> true and then iterates the associated ObjectTypeNode memory lazily adding >>>>>> all the objects to the TMS equality map. From then on for that ObjectType >>>>>> all inserted objects are added to that equality map. >>>>>> >>>>>> With this you now have the advantage of TMS being laziy enabled, so >>>>>> the minor hashmap operation is no longer used and likewise a small memory >>>>>> saving from not populating the map. There is a further advantage that >>>>>> this >>>>>> is now fine grained and when enabled only impacts for that specific >>>>>> object >>>>>> type. >>>>>> >>>>>> A further enhancement could use a int counter, instead of a boolean. >>>>>> Each logical insertion for that object type increases the counter, each >>>>>> retraction decreases the counter; even if automatically retracted if the >>>>>> truth is broken for that logical assertion. When the counter reaches >>>>>> zero, >>>>>> TMS for that OTN can be disabled. We do not however remove the objects >>>>>> from >>>>>> the equality map, as this would cause "churn" if TMS is continuously >>>>>> enabled >>>>>> and disabled. Instead when TMS is disabled record the current fact >>>>>> counter >>>>>> id. Then if TMS is disabled on a retraction but there is a counter id, we >>>>>> can check that counter id to see if the fact is prior to TMS being >>>>>> disabled >>>>>> and thus would need to be retracted from the equality map. >>>>>> >>>>>> _______________________________________________ >>>>>> rules-dev mailing list >>>>>> [email protected] >>>>>> https://lists.jboss.org/mailman/listinfo/rules-dev >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> rules-dev mailing >>>>> [email protected]https://lists.jboss.org/mailman/listinfo/rules-dev >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> rules-dev mailing list >>>>> [email protected] >>>>> https://lists.jboss.org/mailman/listinfo/rules-dev >>>>> >>>>> >>>> >>> >>> >> >> >> _______________________________________________ >> rules-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/rules-dev >> >> > > > -- > - CTO @ http://www.plugtree.com > - MyJourney @ http://salaboy.wordpress.com > - Co-Founder @ http://www.jbug.com.ar > > - Salatino "Salaboy" Mauricio - > > > _______________________________________________ > rules-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-dev > >
_______________________________________________ rules-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-dev
