NPE in update via wrong entry point
by Wolfgang Laun
This sequence of statements disagrees with the documentation:
WorkingMemoryEntryPoint entryPoint =
kSession.getWorkingMemoryEntryPoint( "epn" );
FactHandle fh = entryPoint.insert( fact );
kSession.update( fh, fact ); // should be done using entryPoint.update
But this causes (in 5.1.1) a NPE
Exception in thread "main" java.lang.NullPointerException
at
org.drools.common.AbstractWorkingMemory.update(AbstractWorkingMemory.java:1379)
at
org.drools.common.AbstractWorkingMemory.update(AbstractWorkingMemory.java:1338)
at
org.drools.impl.StatefulKnowledgeSessionImpl.update(StatefulKnowledgeSessionImpl.java:266)
at event.Main.execute(Main.java:153)
at event.Main.main(Main.java:164)
This is the line:
if ( this.maintainTms ) {
status = ((InternalFactHandle)
factHandle).getEqualityKey().getStatus();
}
and similar code can be found in trunk, so I suppose this is still possible.
-W
14 years, 1 month
Accessing Drools compiled classes
by Guillaume Sauthier
Hi team
I've tried the IRC (without much success I admit), maybe here someone
will have some thoughts to share :)
I'm looking for a way to "intercept" the classes being generated by the
drools compiler.
I've seen that the classes bytecode is stored deep in
PackageStore/JavaDialectRuntimeData, so deep that I cannot easily access
it :)
The objective is to be able to give theses classes to Bnd (I want to
store all of that in an OSGi bundle) so that appropriate Import-Packages
can be computed. That will avoid to have DynamicImport-Packages all
around my bundles :)
Currently, what I get from the drools compiler is a
Collection<KnowledgePackage> but I have no API (or didn't find any) to
access (or know) the classes generated by the compiler.
Any ideas ?
Thanks
--Guillaume
14 years, 1 month
backward chaining
by Christine Karman
Hi,
we're using Drools in a commercial project. Yesterday a coworker
realized that drools doesn't support backward chaining. I have used
drools before in several projects, but apparently I never noticed that
either. We do need backward chaining in our project. Is this a feature
that is planned? Is there anything we can do to help create it?
dagdag
Christine
--
dagdag is just a two-character rotation of byebye.
14 years, 1 month
exploring functional programming
by Mark Proctor
We are thinking of moving "accumulate" to a simple "for" keyword. We
might allow 'in' and 'from' to be used interchangably and allow ';' semi
colons to separate the sections. I'm also wondering ho we could allow
function pipelines for the function part of the element. We also need
type inference and "default" return values.
So here are some code snippets to show what I'm thinking, as
improvements over what we do with accumulate now.
// Simple 'or' very simlar to accumulate before. ; for section
separating. With a new boolean section at the end to decide whether to
propagate or not. Will probably use '=' for function assignments.
$c : Customer()
for( $bi : BasketItem( customer == $c );
$s = sum( $bi.price);
$s > 100 )
// Multiple functions are ofcourse allowed
$c : Customer()
for( $bi : BasketItem( customer == $c );
$mn =min( $bi.price),
$mx = max( $bi.price); )
// As are multiple patterns, and as before patterns can come 'from' an
expression and with type inference we can get some nice compact text:
for ( x in [0..4]
y in [0..4]
$c : Cell( row == y, col == x );
$avg = avg( $cell.value );
$avg > 100 )
The above is possible now with the following:
Integer( this > 100) from
accumulate( x : Integer() from [0, 1, 2, 3, 4]
y : Integer() from [0, 1, 2, 3, 4],
$c : Cell( row == y, col == x ),
avg( $c.value) )
I think the proposed additions reall help with declarative readability.
The normal chaining of elements is supported:
$c : Customer()
for( $b1 : BasketItem() in
for( $b2 : BasketItem( customer == $c );
filter( $b2, $b2.price > 100); );
$a = avg( $b1.price ); )
'for' will have a default return type for each bound function. In this
case it returns a single value $a, if there are multiple bound results
an array/map must be used for access.
I also think we should allow pipelineing of functions, much as you would
do in a normal functional programming, possibly using haskell like
"stream fusion" capable functions.
// '$' refers to the magic contents of the function which is "piped" in.
So $bi is piped to map, $ refers to each value evaluated in the
function, with type inference. 'map' results are piped to 'filter'. The
final results are assigned to $r.
$c : Customer()
for( $bi : BasketItem( customer == $c );
$r = $bi | map( $, $.price * 2) |
filter( $, $.price < 100);
$r.size > 100 )
More ideas welcome :) But I think this opens up some very interesting
areas for DRL, with something that will hopefully feel more natural for
developers.
Mark
14 years, 1 month
