I was getting the error below running the benchmarkNQueens.sh script in drools-solver-examples. I got around it by taking the "<scope>runtime</scope>" line out of the slf4j-log4j12 dependency in drools-solver-examples/pom.xml. Not sure if that's the right way to get around it, but it worked. :) --- On Fri, 2/13/09, Geoffrey De Smet <ge0ffrey.spam(a)gmail.com&gt; wrote:

Thanks Geoffrey! I patched this yesterday with slf4j-jcl and slf4j-nop for no loging. I'll post the mavne dependencies later this morning in case others wish to use non-log4j implementations. :) I did noticeas well that the "scoreCalculator" global is referenced by name from the solver. Want me to file a jira issue on that? It seems strange that the variable name shoudl be static like that to me. best wishes, Andrew On Fri, Feb 13, 2009 at 7:55 AM, Geoffrey De Smet <ge0ffrey.spam(a)gmail.com&gt;wrote: -- +1 510 342 5693 PO Box 7775 #8750 San Francisco, California 94120-7775 "Warning: following standard input indefinitely is ineffective" - /bin/tail error message "Against logic there is no armor like ignorance." - Laurence J. Pete

Sure, I'll put a jira together. I'll try and come up with a technique to suggest as well; off the top of my head, it would certainly make things more explicit if you had the calculator handle specified in the configuration file. best wishes, Andrew --------------------------------- Andrew Waterman San Cristóbal de las Casas, Chiapas, Mexico +52 1 967 107 5902 +1 510 342 5693 On Feb 13, 2009, at 9:37 AM, Geoffrey De Smet wrote:

I am actually considering a couple of designs, which also happens to solve the problem of the magic name of the scoreCalculator. 1) a score will no longer be a double, but an instance of a new interface Score. This will means that a score of an int hard and int soft will be represented as it should be: an int hard and an int soft. That has 2 advantages: - you could use implement their own Score, if the out-of-the-box types don't suffice, say int hard, BigDecimal soft, double verySoft. - it would be possible to decide the step, not on a normal compareTo, where hard is always higher then soft, but on (hard * hardAsSoftWeight + soft), where hardAsSoftWeight changes: it's normally very high, but when no hard constraints are broken in a long time, it temporarily goes down. This allows the local search to take steps that break a hard constraints for a while, passing through hard barriers. Experiments have proven that this gives better results. 2) a Solution has a Score. That Score can be uninitialized or dirty. A Solution is also inserted into the working memory (along with it's facts). Every changing fact (Queen, Lesson, Exam, ...) will also need to hold a reference to it's Solution. That way every ConstraintOccurrence can hold a reference to it's Solution. Then the calculateScore rule will update the score in a solution, instead of putting it into a global. The solver still has a reference to the solution, so it can retrieve the score. This allows for multiple solution instances to be put into same working memory and there's no magic scoreCalculator. What do you think? Criticism welcome :) Of course, backward compatibility will be broken (as stated in the manual), but everything will be documented into an upgradeRecipe.txt, so it shouldn't be to hard to upgrade to a newer version. With kind regards, Geoffrey De Smet Greg Barton schreef:

Hi Geoffrey, Sorry to be so late on this feedback. I like your suggestions, it would be quite nice to move away from the magic ScoreCalculator name. I'd like to be able to list the components that were fed into a score, as well. For example, I have a rule such as: rule "western border deforested" when $tok1 : Token ($id : id, border == BorderType.WEST, type in (TokenType.MODERATE_PASTURE, TokenType.INTENSIVE_PASTURE)) $tok2 : Token (id > $id, $id2 : id, border == BorderType.WEST, type in (TokenType.MODERATE_PASTURE, TokenType.INTENSIVE_PASTURE)) $tok3 : Token (id > $id2, border == BorderType.WEST, type in (TokenType.MODERATE_PASTURE, TokenType.INTENSIVE_PASTURE)) then insertLogical ( new UnweightedConstraintOccurrence("western border deforested", $tok1, $tok2, $tok3)); end I would like to be able to query the score later, in my case when it is less than 0.0, in order to list out the specific constraints (identifying String and causal objects) that keep the problem from being solved, I believe I can do this today, by implementing my own ScoreCalculator, but it would be a nice feature of the Score object, especially when accessible from the Solution handle. I'm not sure how happy I am with imposing references to the actions of the solver into outside facts, however. I would prefer to keep my inserted facts quite seperate from the solver code -- however I see nothing wrong with a reference inside a Move implementation. :) best wishes, Andrew --------------------------------- Andrew Waterman San Cristóbal de las Casas, Chiapas, Mexico +52 1 967 107 5902 +1 510 342 5693 On Feb 21, 2009, at 5:07 AM, Geoffrey De Smet wrote:

Sounds good, hopefully the changes will make it into the release candidate soon. :) I haven't given too much thought to how I want this to interface with my persistence hierarchy; I will want this for a portion of the application which is still being designed. Right now I'm using the solver to research solutions to one game of ours, I do want to generalize from that work, and at first, use the solver to help inform our AI players. So from the context of my application, the solver runs very much in a separate space -- but it shouldn't matter in general, as one should be able to easily wrap a Solution implementation with any persistence provider/implementation one would like -- it seems out of scope for your design, but perhaps I'm missing something? Anyway, if you're thinking of placing a handle in: Solution Move Score Makes sense to me. :) Looking forward to the RC! best wishes, Andrew --------------------------------- Andrew Waterman San Cristóbal de las Casas, Chiapas, Mexico +52 1 967 107 5902 +1 510 342 5693 On Mar 10, 2009, at 10:48 AM, Geoffrey De Smet wrote: > > With kind regards, > Geoffrey De Smet > > > Andrew Waterman schreef: >> Hi Geoffrey, >> Sorry to be so late on this feedback. I like your suggestions, it >> would be quite nice to move away from the magic ScoreCalculator >> name. I'd like to be able to list the components that were fed >> into a score, as well. For example, I have a rule such as: >> rule >> "western border deforested" >> when >> $tok1 : Token ($id : id, border == BorderType.WEST, >> type in (TokenType.MODERATE_PASTURE, TokenType.INTENSIVE_PASTURE)) >> $tok2 : Token (id > $id, $id2 : id, border == BorderType.WEST, >> type in (TokenType.MODERATE_PASTURE, >> TokenType.INTENSIVE_PASTURE)) >> $tok3 : Token (id > $id2, border == BorderType.WEST, >> type in (TokenType.MODERATE_PASTURE, >> TokenType.INTENSIVE_PASTURE)) then >> insertLogical ( >> new UnweightedConstraintOccurrence("western border >> deforested", $tok1, $tok2, $tok3)); >> end > >> I'm not sure how happy I am with imposing references to the actions >> of the solver into outside facts, however. I would prefer to keep >> my inserted facts quite seperate from the solver code -- however I >> see nothing wrong with a reference inside a Move implementation. :) > > I haven't started on this part yet, so these are just some ideas: > > >> best wishes, >> Andrew >> --------------------------------- >> Andrew Waterman >> San Cristóbal de las Casas, Chiapas, Mexico >> +52 1 967 107 5902 >> +1 510 342 5693 >> On Feb 21, 2009, at 5:07 AM, Geoffrey De Smet wrote: >>> Feed-back welcome :) >>> >>> The score should be a Score instance of double. Add build-in >>> support for HardAndSoftScore. Replace ScoreCalculator with >>> ScoreHolder. >>> https://jira.jboss.org/jira/browse/JBRULES-1158 >>> >>> Solution should have a getScore() and the score rules need to >>> calculate the correct score for a solution instead of filling some >>> magic global variable >>> https://jira.jboss.org/jira/browse/JBRULES-1977 >>> >>> With kind regards, >>> Geoffrey De Smet >>> >>> >>> Geoffrey De Smet schreef: >>>> I am actually considering a couple of designs, which also happens >>>> to solve the problem of the magic name of the scoreCalculator. >>>> 1) a score will no longer be a double, but an instance of a new >>>> interface Score. This will means that a score of an int hard and >>>> int soft will be represented as it should be: an int hard and an >>>> int soft. That has 2 advantages: >>>> - you could use implement their own Score, if the out-of-the-box >>>> types don't suffice, say int hard, BigDecimal soft, double >>>> verySoft. >>>> - it would be possible to decide the step, not on a normal >>>> compareTo, where hard is always higher then soft, but on (hard * >>>> hardAsSoftWeight + soft), where hardAsSoftWeight changes: >>>> it's normally very high, but when no hard constraints are broken >>>> in a long time, it temporarily goes down. >>>> This allows the local search to take steps that break a hard >>>> constraints for a while, passing through hard barriers. >>>> Experiments have proven that this gives better results. >>>> 2) a Solution has a Score. That Score can be uninitialized or >>>> dirty. >>>> A Solution is also inserted into the working memory (along with >>>> it's facts). >>>> Every changing fact (Queen, Lesson, Exam, ...) will also need to >>>> hold a reference to it's Solution. >>>> That way every ConstraintOccurrence can hold a reference to it's >>>> Solution. >>>> Then the calculateScore rule will update the score in a solution, >>>> instead of putting it into a global. The solver still has a >>>> reference to the solution, so it can retrieve the score. >>>> This allows for multiple solution instances to be put into same >>>> working memory and there's no magic scoreCalculator. >>>> What do you think? Criticism welcome :) >>>> Of course, backward compatibility will be broken (as stated in >>>> the manual), but everything will be documented into an >>>> upgradeRecipe.txt, >>>> so it shouldn't be to hard to upgrade to a newer version. >>>> With kind regards, >>>> Geoffrey De Smet >>>> Greg Barton schreef: >>>>> Actually, I was wishing for something similar last night, but >>>>> for the names of entry-points. I think it would be nice if you >>>>> could specify the names of things in DRL from the values of >>>>> public static final Strings. (i.e. constants) Do you dev folk >>>>> think that's possible enough to make a jira request for it? >>>>> >>>>> --- On Fri, 2/13/09, Geoffrey De Smet <ge0ffrey.spam(a)gmail.com <mailto:ge0ffrey.spam@gmail.com >>>>> >> wrote: >>>>> >>>>>> From: Geoffrey De Smet <ge0ffrey.spam(a)gmail.com <mailto:ge0ffrey.spam@gmail.com >>>>>> >> >>>>>> Subject: [rules-users] Re: drools-solver - magic name of >>>>>> scoreCalculator >>>>>> To: rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org >>>>>> > >>>>>> Date: Friday, February 13, 2009, 9:37 AM >>>>>> Yes, it's not that good that it's a magic name. >>>>>> However, I don't know any other way to do it. >>>>>> Feel free to make a jira for it, especially if you know a >>>>>> better way to do it :) >>>>>> >>>>>> With kind regards, >>>>>> Geoffrey De Smet >>>>>> >>>>>> >>>>>> Andrew Waterman schreef: >>>>>>> Thanks Geoffrey! I patched this yesterday with >>>>>> slf4j-jcl and slf4j-nop for no loging. I'll post the >>>>>> mavne dependencies later this morning in case others wish to >>>>>> use non-log4j implementations. :) I did noticeas well that >>>>>> the "scoreCalculator" global is referenced by name >>>>>> from the solver. Want me to file a jira issue on that? It >>>>>> seems strange that the variable name shoudl be static like >>>>>> that to me. >>>>>>> best wishes, >>>>>>> >>>>>>> Andrew >>>>>>> >>>>>>> On Fri, Feb 13, 2009 at 7:55 AM, Geoffrey De Smet >>>>>> <ge0ffrey.spam(a)gmail.com <mailto:ge0ffrey.spam@gmail.com> >>>>>> <mailto:ge0ffrey.spam@gmail.com>> wrote: >>>>>>> Adding the slf4j-log4j12 dependency to your >>>>>> pom.xml should fix it :) >>>>>>> <dependency> >>>>>>> >>>>>> <groupId>org.slf4j</groupId> >>>>>>> >>>>>> <artifactId>slf4j-log4j12</artifactId> >>>>>>> <scope>runtime</scope> >>>>>>> </dependency> >>>>>>> >>>>>>> Not sure how changing anything in >>>>>> drools-solver-examples could fix >>>>>>> it, normally your project wouldn't depend on >>>>>> it, only on >>>>>>> drools-solver-core. >>>>>>> >>>>>>> >>>>>>> With kind regards, >>>>>>> Geoffrey De Smet >>>>>>> >>>>>>> >>>>>>> Greg Barton schreef: >>>>>>> >>>>>>> I was getting the error below running the >>>>>> benchmarkNQueens.sh >>>>>>> script in drools-solver-examples. I got >>>>>> around it by taking the >>>>>>> "<scope>runtime</scope>" >>>>>> line out of the slf4j-log4j12 >>>>>>> dependency in drools-solver-examples/pom.xml. >>>>>> Not sure if >>>>>>> that's the right way to get around it, but >>>>>> it worked. :) >>>>>>> --- On Fri, 2/13/09, Geoffrey De Smet >>>>>> <ge0ffrey.spam(a)gmail.com <mailto:ge0ffrey.spam@gmail.com> >>>>>>> <mailto:ge0ffrey.spam@gmail.com>> >>>>>> wrote: >>>>>>> From: Geoffrey De Smet >>>>>> <ge0ffrey.spam(a)gmail.com <mailto:ge0ffrey.spam@gmail.com> >>>>>>> <mailto:ge0ffrey.spam@gmail.com>> >>>>>>> Subject: [rules-users] Re: drools-solver >>>>>> -- logger error >>>>>>> (slf4j binding)? >>>>>>> To: rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org >>>>>>> > >>>>>>> <mailto:rules-users@lists.jboss.org> >>>>>>> Date: Friday, February 13, 2009, 1:04 AM >>>>>>> drools-score (like hibernate and many >>>>>> other lib projects) >>>>>>> just depends on sl4j-api, which is a >>>>>> logging interface. >>>>>>> It's up to the end-use product to >>>>>> decide which logging >>>>>>> implementation to use under that and how >>>>>> to configure the >>>>>>> logging (where to log to, how much to log, >>>>>> ...). >>>>>>> In the drools solver examples I 've >>>>>> put slf4j-log4j >>>>>>> underneat it, because I am familiar with >>>>>> log4j's >>>>>>> configuration, take a look at their >>>>>> log4j.xml files. However >>>>>>> they say that the logback implementation >>>>>> is better these >>>>>>> days. >>>>>>> >>>>>>> >>>>>>> PS: I 'll take a look at the other >>>>>> discussions this >>>>>>> afternoon. >>>>>>> >>>>>>> With kind regards, >>>>>>> Geoffrey De Smet >>>>>>> >>>>>>> Andrew Waterman schreef: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I'm using the drools-solver.M5 >>>>>> build through Maven >>>>>>> and have gotten the following error while >>>>>> running my >>>>>>> project: >>>>>>> >>>>>>> SLF4J: Failed to load class >>>>>>> >>>>>>> >>>>>> "org.slf4j.impl.StaticLoggerBinder". >>>>>>> SLF4J: See >>>>>>> >>>>>>> >>>>>> http://www.slf4j.org/codes.html#StaticLoggerBinder for >>>>>>> further details. >>>>>>> >>>>>>> I've checked my dependency graph, >>>>>> and >>>>>>> drools-solver references the sl4j-api, but >>>>>> no >>>>>>> implementation. I checked the >>>>>> mvnrepository, and there are >>>>>>> several other slf4j related projects. >>>>>> What is the preferred >>>>>>> binding for JDK1.6? >>>>>>> >>>>>>> best wishes, >>>>>>> >>>>>>> Andrew >>>>>>> >>>>>>> --------------------------------- >>>>>>> Andrew Waterman >>>>>>> San Cristóbal de las Casas, Chiapas, >>>>>> Mexico >>>>>>> +52 1 967 107 5902 >>>>>>> +1 510 342 5693 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>>> rules-users mailing list >>>>>>> rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org >>>>>>> > >>>>>>> >>>>>> <mailto:rules-users@lists.jboss.org> >>>>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>>>>> >>>>>> _______________________________________________ >>>>>>> rules-users mailing list >>>>>>> rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org >>>>>>> > >>>>>> <mailto:rules-users@lists.jboss.org> >>>>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>>> rules-users mailing list >>>>>>> rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org >>>>>>> > >>>>>> <mailto:rules-users@lists.jboss.org> >>>>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>>>>> >>>>>>> _______________________________________________ >>>>>>> rules-users mailing list >>>>>>> rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org >>>>>>> > >>>>>> <mailto:rules-users@lists.jboss.org> >>>>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- +1 510 342 5693 >>>>>>> >>>>>>> PO Box 7775 #8750 >>>>>>> San Francisco, California 94120-7775 >>>>>>> >>>>>>> "Warning: following standard input indefinitely >>>>>> is ineffective" >>>>>>> - /bin/tail error message >>>>>>> >>>>>>> "Against logic there is no armor like >>>>>> ignorance." >>>>>>> - Laurence J. Pete >>>>>>> >>>>>>> >>>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>>> _______________________________________________ >>>>>>> rules-users mailing list >>>>>>> rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org> >>>>>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>>>> _______________________________________________ >>>>>> rules-users mailing list >>>>>> rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org> >>>>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>>> >>>>> >>>>> _______________________________________________ >>>>> rules-users mailing list >>>>> rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org> >>>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>>> >>>> _______________________________________________ >>>> rules-users mailing list >>>> rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/rules-users >>> >>> _______________________________________________ >>> rules-users mailing list >>> rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/rules-users >> ------------------------------------------------------------------------ >> _______________________________________________ >> rules-users mailing list >> rules-users(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users