How do i unsubscribe?
by Caleb Mathis
I removed my account, but still get the emails. How do i unsubscribe?
14 years
Git migration plans: keep it as similar to SVN as possible
by Geoffrey De Smet
As promised, some more information about our move to git.
Note that these changes are not in effect yet, which should happen next
Saturday.
First phase (this year)
==============
In this phase, *we will keep everything as similar to SVN as possible*.
So the learning curve is as gentle as possible.
This means:
* *Same centralized model*
o 1 SVN repository:
+ https://svn.jboss.org/repos/labs/labs/jbossrules
+ 1 additional anonymous repository mirror:
# http://anonsvn.jboss.org/repos/labs/labs/jbossrules
o 1 Git /reference/ repository (= /blessed repository/):
+ https://github.com/droolsjbpm/droolsjbpm.git
+ No need for a separate anonymous repository
* *Same authorization*
o Everyone who had write access on the SVN repository, gets
write access on the Git reference repository (for now).
+ If they send me their login details! [1]
* *Same branches, same tags, same trunk (=master)
*
o master == trunk. master is just another word for trunk/.
trunk/ shall hence forth be known as /master/.
o Previous authors will be migrated correctly too, if and only
if everyone sends me his user details [1].
* *Same directory structure* (for now)
o If you "git checkout master", you will see exactly the same
directories and files as you see now if you "svn checkout trunk"
o Our project will still build exactly the same way, don't worry.
I 'll also write a mail "Git migration: What do I need to do now that
it's done?" so you're up and running fast next Monday.
Note that you should have already done [1] by tomorrow or you're a lot
of time waiting for authorization next Monday!
Once everyone is acquainted with git, I 'll write a blog about how
outsiders can supply us pull requests instead of clumsy patches.
[1]
http://drools-java-rules-engine.46999.n3.nabble.com/Git-Next-Saterday-18-...
Future phases (next year)
================
In future phases (probably starting around the end of January) we might
look into some bigger changes.
This is also the reason why it's called /droolsjbpm.git/ and not
/drools.git/.
The droolsjbpm.git will be split up into git submodules called
drools.git, jbpm.git, guvnor.git, ...
So you can checkout guvnor without checking out drools-core/compiler.
But droolsjbpm.git will still exist as an aggregation, so you will also
still be able to checkout everything, like you do now.
All those git submodules and the aggregation repository, will all be
under the github organization jbpmdrools:
https://github.com/droolsjbpm
--
With kind regards,
Geoffrey De Smet
14 years
DSL expansion: ready for commit
by Wolfgang Laun
On 13 December 2010 19:58, Edson Tirelli <ed.tirelli(a)gmail.com> wrote:
> Hi Wolfgang,
>
> Mark said you would like us to take a look at some of your commits?
> Can you let me know which ones?
>
>
Hi Edson,
I have reached a state where I think changes might be committed - see the
attached README. I'll just go through the code and add some comments and
make sure no "noise" remains. Then I'll send you the zipped tarball of all
changes. If there are no objections, I'll also commit, but I need to do this
before the git change incapacitates me. (I just don't have the time right
now for making this conversion, and I won't have it until E12/2010. Worst
time of the year for doing a change like that!)
@developers: Anybody interested in this set of changes can ask me for the
sources.
Best
Wolfgang
14 years
Branch day for 5.2.0.M1: next Thursday 16-DEC-2010 18:00 GMT
by Geoffrey De Smet
Hi guys,
Toni and Jervis would like to start working on the release next Friday,
so *anything that is committed before Thursday 16-DEC-2010 18:00 GMT
(=branch day) makes the release
and anything that's later does NOT make the release.*
At least, that's the general idea :)
If needed, you can ask Toni to port specific commits to the release branch.
Please don't commit anything unstable Thursday, just to get it to ship
in the M1 release.
The release date will be /soon/ after that branch day, but no sooner
than it's ready :)
More info
======
* /Release branch/: No release is done from trunk (including
milestone releases). Every release set gets a release branch, for
example:
o drools-5.2.x branch with tags:
+ drools-5.2.0.RC1
+ drools-5.2.0.RC2
+ drools-5.2.0
+ drools-5.2.1
+ drools-5.2.2
o drools-5.2.0.M1 branch with tags:
+ drools-5.2.0.M1
o drools-5.2.0.M2 branch with tags:
+ drools-5.2.0.M2
* *Branch day*: the day (actually a timestamp) on which Toni creates
the release branch as a copy from trunk (master)
o Usually 1 or 2 weeks before the aimed release day
+ For milestones 1 or 2 days can be sufficient
+ This gives them a chance to test the assemblies and
release artifacts and patch any blocking bugs
# without the other developers adding stuff
+ Compare this to the linux kernel where they can commit
for half a month and the branch day is 2 and half
months before the release :)
o Stable features can be added before the branch day. Unstable
or risky features must be added after the branch day.
o *The branch day date is mostly unchangeable for all
developers (at least close to the date)*:
+ Postponing the timestamp for 1 developer = blocking
all other developers of adding their risky features to
trunk.
o *In or out principle:*
+ Either your commit is there, before the branch day,
and it makes the release.
+ Either your commit is not there, before the branch
day, and it will have to wait for the release.
+ Either you convince Toni that there is 100% no risk in
adding your commit and you commit it to both trunk and
release branch.
o Fight your inner feeling that says "I 'll just add this
improvement fast so it's part of the release. I am sure it's
/fine/."
+ It might not be /fine/. It's not worth the risk.
* /Release date/: When the release branch is releasable. /It's ready
when it's ready./
o The release date is irrelevant for most developers. They
should watch the branch day.
So to put this in effect:
* Branch day (timestamp) for M1 Thursday 16-DEC-2010 evening 18:00 GMT.
o Either your commit is in there
o Or it is NOT
+ Don’t worry, it will be in the next release
o Or you politely convince Toni so you can commit it to both
trunk and the release branch
--
With kind regards,
Geoffrey De Smet
14 years
DSL: progress report
by Wolfgang Laun
*Long lines:* \-escape is working satisfactorily, But I'll look into the
option of merging lines depending on the first chars in the next line, which
would be much more attractive.
*DSLR analysis*: is a little more lenient; you may have, for instance "when
there is a foo" on a single line, and the trigger keywords (rule,query, when
then, end) may be indented.
*Substitution:* is now done "manually" rather than with
Matcher.replaceAll(). This eliminates some problems with '\' and '$' and
creates the opportunity for new features.
*New features:* I'm experimenting with using key-value pairs saved from
preceding lines to provide a replacement value for a {}-variable that isn't
defined on the current line. Also, a variable reference such as
{variable-name!function-name} is simple to implement; case conversions would
be useful functions.
[when]there is an? {entity}=${entity!lc}: {entity!ucf}()
[then]discard the fact=retract( ${entity!lc} );
But these features depend on "reasonable" {}-variable names.
*Open issue:* {}-variable may contain almost any Unicode character. This
causes much pain in the parser and even more in the expander; and users are
burdened with having to escape this or that character. Is it really a good
or important thing to be able to write a variable name like
><!@%^*|+?,/''"|&().; and/or escape sequences?? If someone would make a
decisive statement ("has to remain as it is" OR "restrict to the usual
lexical identifier syntax") I'd appreciate this very much.
Best
Wolfgang
14 years
A remarkable flop
by Wolfgang Laun
Given classes Switch and Track, and the "natural" class hierarchy
representing state changes for these two elements:
ElementState
TrackState extends ElementState ("free/occupied")
SwitchState extends TrackState (adds "left/right/moving")
Now we have rules for updating Switch and Track elements, like this one:
rule "Xyz state update"
when
$s: XyzState( $id: id, ... )
$e: Xyz( id == $id )
then
//...update $e, retract $s
end
and, since we want to catch bad ids, also
rule "Xyz state for unknown element"
when
$s: XyzState( $id: id )
not Xyz( id == $id )
then
//... diagnostic, retract $s
end
Best practice, wouldn't you say?
Testing by inserting a few of SwitchState objects works fine:
updated: Switch 5 RIGHT occupied
updated: Switch 2 RIGHT
updated: Switch 1 RIGHT occupied
so everything is allright, wouldn't you say?
Add another SwitchState for Switch "4" to the test, and suddenly:
updated: Switch 4 RIGHT
track state for unknown element 5
updated: Switch 2 RIGHT
updated: Switch 1 RIGHT occupied
What's this?!
After some headscratching I realized that the negative rule for the
SwitchState's superclass TrackState produces another activation, since, for
any Switch element with an id x there clearly isn't a Track element with id
x! This activation *occasionally *precedes the activation for the match in
the "update" rule.
This is annoying. Of course, negative salience for the "not" rules fixes
this, but who would have thought that you need it with conditions
(seemingly!) describing disjoint situations. And the negative salience is
counter-intuitive, since normally you'd perform the check "no such element"
*before *permitting any update action.
Remarkable.
Wolfgang
14 years
timer and duration tests releases- and please note the PS!
by Wolfgang Laun
Hi Mark,
here now:
Ooh, it seems Eclipse outwitted me once again. But I think I made it on the
2nd try...
-W
PS:
(1) A decision on the matter of DSL variables would be appreciated. I'm
currently
developing a non-trivial DSL, and learning a lot about what's needed for a
*real world *application. Most importantly, some means of structuring the
DSL definition, so that they can be applied distinctively to specific groups
of
rules. This reduces the risk of "ricochets" if you know what I mean.
I've thought about proposing an entirely new approach, based on DRL
syntactic
entities, i.e., the expansion of a DSL phrase must be a "medium level"
non-terminal
of the DRL language. But this certainly restricts phrase parameters to
terminals.
If it's too sophisticated, you end up with a parser/compiler almost as nasty
as ANTLR3.
(2) I haven't forgotten the spreadsheet fixes. There's another relic I
found: some of
the column keywords have single letter alternatives (e.g. "U" for "no-loop",
"X" for
"activation-group"). Should I retain them - they are NOT documented in
Expert.
Should I add timer(int:)? Duration is deprecated, I'll leave this in but it
ought to
be marked clearly as such in the documentation, at least.
Please advise - I can live with everything - non of this is important for
my company,
but I want to get the fixes and additions out of my thinning hair ;-)
14 years
Long DSL lines
by Wolfgang Laun
Currently each entry must be a single line of text. This results in long
lines, especially on the RHS.
I have experimentally inserted a transformation of the DSL text (in
DSLTokenizedMappingFile)
which converts '\'+EOL on the fly to a space. (The passed-in reader is read
into a buffer, '\'+EOL
is translated to space, and EOLs are inserted later to readjust the line
number.) In a text editor,
I can now write, e.g.,
then][][Bb]ook the customer for the flight=\
$f.setAvailable( $f.getAvailable() - 1 );\
update( $f ); \
Booking booking = new Booking(); \
booking.setCustomer( $r.getCustomer() ); \
booking.setFlight( $f ); \
insert( booking );
Of course, the DSL editor will not preserve this, but future development
might provide more
convenient editing there, too.
Any objections?
-W
14 years, 1 month
