12:38 p.m.
We are looking to tighten up accumulate, using a new keyword to
differentiate. It will use ; for separation, to follow a similar form to
a 'for' loop.
acc( CE*;
<func>*;
<guard>? )
so something like:
acc( $o : Order();
$min : min( $o.value ),
$max : max($o.value);
$min > 100 && $max < 100 )
I have wondered if we could use pipes on our functions, to be able to
pass the results of one function into another - just not sure how that
will work or look yet.
func(...) in func(...)
func(...) | func(...)
Mark
1:17 p.m.
On 18 August 2011 18:38, Mark Proctor <mproctor(a)codehaus.org> wrote:
We are looking to tighten up accumulate, using a new keyword to
differentiate. It will use ; for separation, to follow a similar form to
a 'for' loop.
acc( CE*;
<func>*;
<guard>? )
so something like:
acc( $o : Order();
$min : min( $o.value ),
$max : max($o.value);
$min > 100 && $max < 100 )
Given that I can do this today using an eval after the accumulate CE: What's
the big gain, as compared to the nuisance of yet another CE, with the need
to document (which, traditionally, isn't done so eagerly) and teach and
learn and getting it free of bugs?
-W
I have wondered if we could use pipes on our functions, to be able to
pass the results of one function into another - just not sure how that
will work or look yet.
func(...) in func(...)
func(...) | func(...)
Mark
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
1:27 p.m.
On 18/08/2011 18:17, Wolfgang Laun wrote:
On 18 August 2011 18:38, Mark Proctor <mproctor(a)codehaus.org
<mailto:mproctor@codehaus.org>> wrote:
We are looking to tighten up accumulate, using a new keyword to
differentiate. It will use ; for separation, to follow a similar
form to
a 'for' loop.
acc( CE*;
<func>*;
<guard>? )
so something like:
acc( $o : Order();
$min : min( $o.value ),
$max : max($o.value);
$min > 100 && $max < 100 )
Given that I can do this today using an eval after the accumulate CE:
What's the big gain, as compared to the nuisance of yet another CE,
with the need to document (which, traditionally, isn't done so
eagerly) and teach and learn and getting it free of bugs?
I find the above looks
cleaner and easier to read, the more we can
reduce the need for 'eval' the better. It is a common enough use case
that I feel it is worth support. Acc is used a lot for CEP use cases and
we need a syntax that can compete succinctly with alternative approaches
- if we look like a dog dinner, we'll lose out to alternative CEP
syntaxes. The separation of the segments using ";" gives a clearer
distinction too, and it's 'for' loop like nature should more natural to
people new to the engine.
Mark
-W
I have wondered if we could use pipes on our functions, to be able to
pass the results of one function into another - just not sure how that
will work or look yet.
func(...) in func(...)
func(...) | func(...)
Mark
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
12:53 a.m.
On 18 August 2011 19:27, Mark Proctor <mproctor(a)codehaus.org> wrote:
On 18/08/2011 18:17, Wolfgang Laun wrote:
On 18 August 2011 18:38, Mark Proctor <mproctor(a)codehaus.org> wrote:
> We are looking to tighten up accumulate, using a new keyword to
> differentiate. It will use ; for separation, to follow a similar form to
> a 'for' loop.
>
> acc( CE*;
> <func>*;
> <guard>? )
>
> so something like:
>
> acc( $o : Order();
> $min : min( $o.value ),
> $max : max($o.value);
> $min > 100 && $max < 100 )
>
Given that I can do this today using an eval after the accumulate CE:
What's the big gain, as compared to the nuisance of yet another CE, with the
need to document (which, traditionally, isn't done so eagerly) and teach and
learn and getting it free of bugs?
I find the above looks cleaner and easier to read, the more we can reduce
the need for 'eval' the better. It is a common enough use case that I feel
it is worth support.
Well, a condition that's never true isn't a good use case. Even after
repairing it, the example does not tell you *where *the min and max,
respectively, are. Apart from determining the exact value of mininimum and
maximum (which could easily be added, together with locating the containing
Order!)
not Order( value <= 100 )
not Order( value >= 200 )
is more descriptive that the rather procedural "for" hidden in the proposed
"acc".
Perhaps there are better use case; this one does not convince me.
-W
Acc is used a lot for CEP use cases and we need a syntax that can
compete
succinctly with alternative approaches - if we look like a dog dinner, we'll
lose out to alternative CEP syntaxes. The separation of the segments using
";" gives a clearer distinction too, and it's 'for' loop like
nature should
more natural to people new to the engine.
Mark
-W
>
> I have wondered if we could use pipes on our functions, to be able to
> pass the results of one function into another - just not sure how that
> will work or look yet.
> func(...) in func(...)
> func(...) | func(...)
>
> Mark
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
_______________________________________________
rules-dev mailing
listrules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
6:39 p.m.
On 19/08/2011 05:53, Wolfgang Laun wrote:
On 18 August 2011 19:27, Mark Proctor <mproctor(a)codehaus.org
<mailto:mproctor@codehaus.org>> wrote:
On 18/08/2011 18:17, Wolfgang Laun wrote:
> On 18 August 2011 18:38, Mark Proctor <mproctor(a)codehaus.org
> <mailto:mproctor@codehaus.org>> wrote:
>
> We are looking to tighten up accumulate, using a new keyword to
> differentiate. It will use ; for separation, to follow a
> similar form to
> a 'for' loop.
>
> acc( CE*;
> <func>*;
> <guard>? )
>
> so something like:
>
> acc( $o : Order();
> $min : min( $o.value ),
> $max : max($o.value);
> $min > 100 && $max < 100 )
>
>
> Given that I can do this today using an eval after the accumulate
> CE: What's the big gain, as compared to the nuisance of yet
> another CE, with the need to document (which, traditionally,
> isn't done so eagerly) and teach and learn and getting it free of
> bugs?
I find the above looks cleaner and easier to read, the more we can
reduce the need for 'eval' the better. It is a common enough use
case that I feel it is worth support.
Well, a condition that's never true isn't a good use case. Even after
repairing it, the example does not tell you /where /the min and max,
respectively, are. Apart from determining the exact value of mininimum
and maximum (which could easily be added, together with locating the
containing Order!)
not Order( value <= 100 )
not Order( value >= 200 )
is more descriptive that the rather procedural "for" hidden in the
proposed "acc".
I wasn't showing it as a use case, I was showing it
as illustrative of
the syntax. I could have just done
acc( $o : MyClass();
$f1 : fun1( $o ),
$f2 : fun2( $o );
somBooleanFunc( $f1, $f2 ) )
Mark
Perhaps there are better use case; this one does not convince me.
-W
Acc is used a lot for CEP use cases and we need a syntax that can
compete succinctly with alternative approaches - if we look like a
dog dinner, we'll lose out to alternative CEP syntaxes. The
separation of the segments using ";" gives a clearer distinction
too, and it's 'for' loop like nature should more natural to people
new to the engine.
Mark
>
> -W
>
>
> I have wondered if we could use pipes on our functions, to be
> able to
> pass the results of one function into another - just not sure
> how that
> will work or look yet.
> func(...) in func(...)
> func(...) | func(...)
>
> Mark
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
5:32 a.m.
Am 18.08.2011 18:38, schrieb Mark Proctor:
We are looking to tighten up accumulate, using a new keyword to
differentiate. It will use ; for separation, to follow a similar form to
a 'for' loop.
acc( CE*;
<func>*;
<guard>? )
Hi Mark,
from the above description, I don't grok the meaning of the "new acc".
Could you describe in a few words what "acc" is going to do?
From a user perspective, I find it hard to differentiate between
"acc"
and "accumulate". I bet this is going to be an eternal
source of
confusion and "which acc is for which purpose?" questions.
If "acc" is different from "accumulate", then I'd like to learn
what
"acc" actually does, how it differs from "accumulate" and try to find
a
keyword which precisely resembles what it does.
Best regards
Ansgar
7:42 a.m.
"Good programmers appreciate what you put in,
Great programmers appreciate what you leave out "
-- Josh Bloch
I also believe that having 2 accumulates is just going to bring
confusion and complexity.
Op 19-08-11 11:32, Ansgar Konermann schreef:
Am 18.08.2011 18:38, schrieb Mark Proctor:
> We are looking to tighten up accumulate, using a new keyword to
> differentiate. It will use ; for separation, to follow a similar form to
> a 'for' loop.
>
> acc( CE*;
> <func>*;
> <guard>? )
>
Hi Mark,
from the above description, I don't grok the meaning of the "new acc".
Could you describe in a few words what "acc" is going to do?
> From a user perspective, I find it hard to differentiate between "acc"
and "accumulate". I bet this is going to be an eternal source of
confusion and "which acc is for which purpose?" questions.
If "acc" is different from "accumulate", then I'd like to learn
what
"acc" actually does, how it differs from "accumulate" and try to find
a
keyword which precisely resembles what it does.
Best regards
Ansgar
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
With kind regards,
Geoffrey De Smet
6:42 p.m.
On 19/08/2011 12:42, Geoffrey De Smet wrote:
"Good programmers appreciate what you put in,
Great programmers appreciate what you leave out "
-- Josh Bloch
I also believe that having 2 accumulates is just going to bring
confusion and complexity.
Over time we'll deprecate the old accumulate. But we
must evolve the
language to improve it, it's not easier as there is no one to copy for
this, it's virgin territory. That means we can't be afraid to try
things, and change them if think we can improve it.
Mark
Op 19-08-11 11:32, Ansgar Konermann schreef:
> Am 18.08.2011 18:38, schrieb Mark Proctor:
>> We are looking to tighten up accumulate, using a new keyword to
>> differentiate. It will use ; for separation, to follow a similar form to
>> a 'for' loop.
>>
>> acc( CE*;
>> <func>*;
>> <guard>? )
>>
> Hi Mark,
>
> from the above description, I don't grok the meaning of the "new acc".
> Could you describe in a few words what "acc" is going to do?
>
>> From a user perspective, I find it hard to differentiate between
"acc"
> and "accumulate". I bet this is going to be an eternal source of
> confusion and "which acc is for which purpose?" questions.
>
> If "acc" is different from "accumulate", then I'd like to
learn what
> "acc" actually does, how it differs from "accumulate" and try to
find a
> keyword which precisely resembles what it does.
>
> Best regards
>
> Ansgar
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
4:18 a.m.
New subject: accumulate to acc - Don't call it acc(umulate)
Op 20-08-11 00:42, Mark Proctor schreef:
On 19/08/2011 12:42, Geoffrey De Smet wrote:
> "Good programmers appreciate what you put in,
> Great programmers appreciate what you leave out "
> -- Josh Bloch
>
> I also believe that having 2 accumulates is just going to bring
> confusion and complexity.
Over time we'll deprecate the old accumulate. But we must evolve the
language to improve it, it's not easier as there is no one to copy for
this, it's virgin territory. That means we can't be afraid to try
things, and change them if think we can improve it.
Mark
I am not against adding new features to the language. (*)
But don't call it "acc" or "accumulate", that will just confuse
everyone.
Call it "gather", collect, hoard, amass, pileUp, cumulate, conglomerate,
... anything but accumulate or an abbreviation.
http://www.thefreedictionary.com/accumulate
*Using the same term for 2 different things greatly disrupts
communication (= API, manual, code readability, ...).*
The 2 WorkingMemory (= same term for 2 different things) are still
causing confusion:
org.drools.WorkingMemory
org.drools.runtime.rule.WorkingMemory
You can even mix them in your code (several planner examples did that
for a couple of years before I noticed it).
Let's investigate ways to clean that up first? For example: move the old
one to drools-core-legacy-api already, before we completely remove it.
With kind regards,
Geoffrey De Smet
(*) I do believe we need a more future proof system of adding keywords
and features. I see 2 alternatives:
A) Specify a drlModel version in the DRL. This allows backwards
incompatible changes between drlModel versions, but new drools jars
should still support the last 3 drlModel versions. This is similar to:
-- pom.xml's <modelVersion>4.0.0</modelVersion>
B) Find a way to reserve keywords.
-- By having to import the keywords?
import keyword org.drools.parser.acc; // I can now use acc in my rules
import keyword org.drools.parser.thenElse; // I can now use
thenElse in my rules
-- By prefixing the keywords with a reserved character.
For example: @acc, @thenElse or #acc, #thenElse
-- Like Ceylon, by layout (probably not possible): "Note also that
annotations like doc, by, see, and deprecated aren't keywords. They're
just ordinary identifiers. The same is true for annotations which are
part of the language definition: abstract, variable, shared, formal,
actual, and friends. On the other hand, void is a keyword. "
--
4:47 a.m.
New subject: accumulate to acc - Don't call it acc(umulate)
Adding new keywords is not as impossible as it might seem. It depends on the
place the new keyword should appear. Almost all keywords are now recognized
depending on the symbol(s) before or after. This makes the parser somewhat
vulnerable w.r.t. garbage input token sequences, but there's no way around
that.
As for the "acc" proposal itself, I find that
dontCallItAcc( Foo( $x:x ...);
$max: min($x), $min: max($x);
$max - $min > 100 )
as a CE is not *declarative* enough. If I'd like to do the same thing for a
Bar(), I'd have to write it all over again. For instance, if there were a
declare MinMax( Number n )
min : Number from min( n );
max : Number from max( n )
end
I might use this in more than one place:
Foo( $x: x ) | MinMax( $x )( max - min > 100 )
Bar( $y: y ) | MinMax( $y )( max - min > 200 )
-W
On 22 August 2011 10:18, Geoffrey De Smet <ge0ffrey.spam(a)gmail.com> wrote:
**
Op 20-08-11 00:42, Mark Proctor schreef:
On 19/08/2011 12:42, Geoffrey De Smet wrote:
"Good programmers appreciate what you put in,
Great programmers appreciate what you leave out "
-- Josh Bloch
I also believe that having 2 accumulates is just going to bring
confusion and complexity.
Over time we'll deprecate the old accumulate. But we must evolve the
language to improve it, it's not easier as there is no one to copy for
this, it's virgin territory. That means we can't be afraid to try
things, and change them if think we can improve it.
Mark
I am not against adding new features to the language. (*)
But don't call it "acc" or "accumulate", that will just confuse
everyone.
Call it "gather", collect, hoard, amass, pileUp, cumulate, conglomerate,
... anything but accumulate or an abbreviation.
http://www.thefreedictionary.com/accumulate
*Using the same term for 2 different things greatly disrupts communication
(= API, manual, code readability, ...).*
The 2 WorkingMemory (= same term for 2 different things) are still causing
confusion:
org.drools.WorkingMemory
org.drools.runtime.rule.WorkingMemory
You can even mix them in your code (several planner examples did that for a
couple of years before I noticed it).
Let's investigate ways to clean that up first? For example: move the old
one to drools-core-legacy-api already, before we completely remove it.
With kind regards,
Geoffrey De Smet
(*) I do believe we need a more future proof system of adding keywords and
features. I see 2 alternatives:
A) Specify a drlModel version in the DRL. This allows backwards
incompatible changes between drlModel versions, but new drools jars should
still support the last 3 drlModel versions. This is similar to:
-- pom.xml's <modelVersion>4.0.0</modelVersion>
B) Find a way to reserve keywords.
-- By having to import the keywords?
import keyword org.drools.parser.acc; // I can now use acc in my rules
import keyword org.drools.parser.thenElse; // I can now use thenElse in
my rules
-- By prefixing the keywords with a reserved character.
For example: @acc, @thenElse or #acc, #thenElse
-- Like Ceylon, by layout (probably not possible): "Note also that
annotations like doc, by, see, and deprecated aren't keywords. They're just
ordinary identifiers. The same is true for annotations which are part of the
language definition: abstract, variable, shared, formal, actual, and
friends. On the other hand, void is a keyword. "
--
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
6:28 a.m.
New subject: accumulate to acc - Don't call it acc(umulate)
On 22/08/2011 09:18, Geoffrey De Smet wrote:
Op 20-08-11 00:42, Mark Proctor schreef:
> On 19/08/2011 12:42, Geoffrey De Smet wrote:
>> "Good programmers appreciate what you put in,
>> Great programmers appreciate what you leave out "
>> -- Josh Bloch
>>
>> I also believe that having 2 accumulates is just going to bring
>> confusion and complexity.
> Over time we'll deprecate the old accumulate. But we must evolve the
> language to improve it, it's not easier as there is no one to copy for
> this, it's virgin territory. That means we can't be afraid to try
> things, and change them if think we can improve it.
>
> Mark
I am not against adding new features to the language. (*)
But don't call it "acc" or "accumulate", that will just confuse
everyone.
The other keyword being discussed is 'for'.
Once 'for' is in place 'accumulate' will be removed from the
documentation, or atleast relegated t a deprecate stage, so it's only
there for backwards comptability.
Mark
Call it "gather", collect, hoard, amass, pileUp, cumulate,
conglomerate, ... anything but accumulate or an abbreviation.
http://www.thefreedictionary.com/accumulate
*Using the same term for 2 different things greatly disrupts
communication (= API, manual, code readability, ...).*
The 2 WorkingMemory (= same term for 2 different things) are still
causing confusion:
org.drools.WorkingMemory
org.drools.runtime.rule.WorkingMemory
You can even mix them in your code (several planner examples did that
for a couple of years before I noticed it).
Let's investigate ways to clean that up first? For example: move the
old one to drools-core-legacy-api already, before we completely remove it.
With kind regards,
Geoffrey De Smet
(*) I do believe we need a more future proof system of adding keywords
and features. I see 2 alternatives:
A) Specify a drlModel version in the DRL. This allows backwards
incompatible changes between drlModel versions, but new drools jars
should still support the last 3 drlModel versions. This is similar to:
-- pom.xml's <modelVersion>4.0.0</modelVersion>
B) Find a way to reserve keywords.
-- By having to import the keywords?
import keyword org.drools.parser.acc; // I can now use acc in my rules
import keyword org.drools.parser.thenElse; // I can now use
thenElse in my rules
-- By prefixing the keywords with a reserved character.
For example: @acc, @thenElse or #acc, #thenElse
-- Like Ceylon, by layout (probably not possible): "Note also that
annotations like doc, by, see, and deprecated aren't keywords. They're
just ordinary identifiers. The same is true for annotations which are
part of the language definition: abstract, variable, shared, formal,
actual, and friends. On the other hand, void is a keyword. "
--
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
6:55 a.m.
New subject: accumulate to acc - Don't call it acc(umulate)
On 22 August 2011 12:28, Mark Proctor <mproctor(a)codehaus.org> wrote:
On 22/08/2011 09:18, Geoffrey De Smet wrote:
I am not against adding new features to the language. (*)
But don't call it "acc" or "accumulate", that will just confuse
everyone.
The other keyword being discussed is 'for'.
Once 'for' is in place 'accumulate' will be removed from the
documentation,
or atleast relegated t a deprecate stage, so it's only there for backwards
comptability.
There are two thingies now using "accumulate": the accumulate *phrase* and
the accumulate *conditional element.*
The accumulate phrase:
- must follow "from"
- may contain inline code (init, action, result)
- may have a single accumulate function call
The accumulate CE
- can be used in combination with a pattern, "not", "exists",
"eval" and
"forall".
- may *not *contain inline code
- may have more than one accumulate function call
So it seems that "accumulate" is going to stay, at least for the phrase. If
"for" is then used for the extended accumulate CE, there'll be
"for" and
"forall".
-W
*
*
9:41 a.m.
New subject: accumulate to acc - Don't call it acc(umulate)
I don't think that to focus on the name of the keyword is so important.
However I also don't like 'acc' for at least 2 reasons: first I don't
like
abbreviation and even worse being that keyword the abbreviation of another
already existing (even if deprecated) one can generate confusion.
'for' can be a better option even if we will have to use them in statements
like "from for(...)" that could be a bit odd and cacophony.
For a similar (even if not so powerful) feature in my lambdaj library I used
'aggregate', that maybe could be closer to what the keyword actually should
be used for.
In the end, my favorite option is 'fold' for a few reasons:
1. It's short
2. IMHO sounds slightly better than 'for' in the contexts where we are going
to use it
3. People who knows a bit of functional programming is familiar with the
meaning of 'fold' that is also quite similar to what the new feature will do
even if, once again, our one will be more powerful and rich than the
"classic" fold
Mario
6:55 p.m.
On 19/08/2011 10:32, Ansgar Konermann wrote:
Am 18.08.2011 18:38, schrieb Mark Proctor:
> We are looking to tighten up accumulate, using a new keyword to
> differentiate. It will use ; for separation, to follow a similar form to
> a 'for' loop.
>
> acc( CE*;
> <func>*;
> <guard>? )
>
Hi Mark,
from the above description, I don't grok the meaning of the "new acc".
Could you describe in a few words what "acc" is going to do?
> From a user perspective, I find it hard to differentiate between "acc"
and "accumulate". I bet this is going to be an eternal source of
confusion and "which acc is for which purpose?" questions.
If "acc" is different from "accumulate", then I'd like to learn
what
"acc" actually does, how it differs from "accumulate" and try to find
a
keyword which precisely resembles what it does.
The behaviour is the same, it's
just more compact and provides a clause
for a guard, I also want to explore function chaining, like with
functional programming. I felt we made some mistakes on the accumulate
syntax and this is an opportunity to try and get it right, without
breaking backwards compability. The comma separation in the syntax makes
it very hard to evolve, hence the; in the new 'acc' for the segments.
further 'accumulate' is quite verbose. I also considered using 'for'
instead of 'acc', as in essence it is a for loop over a stream of data,
as I thought maybe developers might find that more familiar.
acc( $o : Order() from list;
$min : min( $o.value ),
$max : max( $o.value );
$min > 100 && $max < 200 );
The above will take a list of Orders and for each value execute the
function(s) on it. That is the same as if it was an accumulate. We allow
the function result to be bound, $min and $max are bound to the result.
We then allow a guard on the result of the accumulate which will only
allow those results to propagate if the guard is true. Example with
'for' instead:
for( $o : Order() from list;
$min : min( $o.value ),
$max : max( $o.value );
$min > 100 && $max < 200 );
You could do this on the old accumulate as follows:
$m : Map() from accumulate( $o : Order() from list,
minMaxFunction( $o
) ) // user plugged in function that executes two functions and binds
results to a map.
$min : Number() from $m.min
$max : Number() from $m.max
eval( $min > 100 && $max < 200 )
This is virgin territory, and we need to be free to make mistakes and
evolve the syntax, while trying to keep backwards compatability as long
as possible. At some point we can deprecate older syntaxes and produce
something much cleaner.
Mark
Best regards
Ansgar
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
4630
days inactive
4634
days old
15 comments
6 participants
participants (6)
-
Ansgar Konermann -
Geoffrey De Smet -
Marco Rietveld -
Mario Fusco -
Mark Proctor -
Wolfgang Laun