Here's a small text that describes the most important improvements compared
to 3.0.x:
The IDE now supports debugging rules: breakpoints can be added in drl files
for rule right-hand side (consequences) and inside functions. Whenever a
rule breakpoint is encounter during debugging, the correspo
Hi Mark,
I've had a bit of a hard time getting up the energy to finish it off but I
did get set up on the weekend to do the doco for it and am getting enthused
again so I should hopefully get it a lot further in the next week. Mic had
mentioned getting some help but no names as yet.
cheers
Steve
Steven,
Hiya, how is that going? I think someone at JBoss was hoping to help you
out with it, has mic given you the details?
I haven't moved templates across to MVEL yet, but yes eventually that
makes sense. However don't go out of your way, more important you get it
finished first :) Really
Hi Mark,
The new decision table handling uses StringTemplate. I gather I should
probably change it over to use MVEL as well?
cheers
Steve
On 2/10/07, Mark Proctor <[EMAIL PROTECTED]> wrote:
I've done a bit of refactor. JCI has no been inlined and all it' use of
commons-* removed, including co
We are still preparing some release notes, and overviews for this
release, before we announce it. But for the brave here are some links to
binaries:
http://labs.jboss.com/file-access/default/members/jbossrules/downloads/3.1.0-M1/jbossrules-ide-3.1.0-M1-bin.zip
http://labs.jboss.com/file-access/d
After a long walk and thinking about shadow facts I think the only way
forward is to remove modify() from drl consequences. Modify will
exist external via the WorkingMemory interface, but shadow facts must be
turned on for that class for it to work.
To allow a series of setters for a singl
I guess its more to do with the drl.
We currently have:
count.setValue(.);
modify( count );
now I can do a regexp that changes
count.setValue(); to
retract( count ); count.setValue(...); assert( account );
But then what happens if the user used modify. One of the advantages of
using mo
Mark,
Follows the list of main features added to core/compiler I was able
to get from JIRA.
Do you want me to ellabora on each item or the JIRA is enough and we
focus on documentation? I think it would be good to start a wiki page on
migration from 3.0.x to 3.2. What do you think?
M1 binaries are uploading to the server now. I'm uploading docs,but they
are unchanged as of 3.0, we will work on docs once we hit the RC stage.
We do still need a "new and noteworthy" just to give people a starting
point of the new stuff. Edson and kris, think you can send me something
in htm
I think it will be hard. My preference is to change the drl to do a
retract+assert on a modify, that way we don't need shadow facts - as
long as they keep the modifies strictly inside the drl - which I think
is fair.
Mark
Edson Tirelli wrote:
Mark,
I can tell you for sure that the overh
Mark,
I can tell you for sure that the overhead is not linear. It is worst
then that.
For that user asserting up to 1million facts, as the rules have just
a few partial matches, the overhead makes the performance be worst than
3.0.x branch.
One question and one comment:
Comment: I
11 matches
Mail list logo
