Re: [nant-dev] PATCH: Expression evaluator for NAnt
Aren't we making this too difficult for ourselves and for our users here, by
not using the $ or ${} delimiters ?
Perhaps I'm alone on this, but I really have serious doubts on this ...
Gert
- Original Message -
From: Jaroslaw Kowalski [EMAIL PROTECTED]
To: Ian MacLean [EMAIL PROTECTED]; Martin Aliger
[EMAIL PROTECTED]
Cc: Gert Driesen [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Friday, December 05, 2003 12:00 PM
Subject: Re: [nant-dev] PATCH: Expression evaluator for NAnt
One more think came to my mind:
Dash (-) is a legal character in property name today and this may cause
problems with expression evaluator because you cannot tell the difference
between:
property1 MINUS property2 (written as property1-property2)
and
very DASH long DASH property DASH name (written as
very-long-property-name)
I've run script-sample.build from examples directory and found that
there
are actually 6 properties with dashes in their names:
nant.tasks.cvs-update
nant.tasks.cvs-checkout
nant.tasks.delay-sign
nant.tasks.cvs-update.location
nant.tasks.cvs-checkout.location
nant.tasks.delay-sign.location
Do you think we should do anything special to handle them?
EE currently supports propertyvalue() function where you can specify
property name as a string (so no quoting problems will arise). So for
these
special properties you would have to write, e.g:
if
test=${contains(propertyvalue('nant.tasks.cvs-checkout.location'),'c:\windo
ws')}
echo message=zzz /
/if
Is it ok?
Jarek
- Original Message -
From: Jaroslaw Kowalski [EMAIL PROTECTED]
To: Ian MacLean [EMAIL PROTECTED]; Martin Aliger
[EMAIL PROTECTED]
Cc: Gert Driesen [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Wednesday, December 03, 2003 4:26 PM
Subject: Re: [nant-dev] PATCH: Expression evaluator for NAnt
Can we define properties as:
property name = identifier { separator identifier } *
separator = . | -.
identifier = [a-zA-Z_][a-zA-Z0-9_-]*
In English:
property name is a sequence of identifiers separated by separators
separator is a dot
identifier starts with a latin letter or an underscore and contains
only
letters, digits underscores or dashes.
This may affect people using property names with non-latin characters.
Jarek
- Original Message -
From: Ian MacLean [EMAIL PROTECTED]
To: Martin Aliger [EMAIL PROTECTED]
Cc: Jaroslaw Kowalski [EMAIL PROTECTED]; Gert Driesen
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, December 03, 2003 3:20 PM
Subject: Re: [nant-dev] PATCH: Expression evaluator for NAnt
Is anyone actually using numeric property names ? I say we should
dissallow them and be done with it.
Ian
Martin Aliger wrote:
- it won't break compatibility for properties with numeric names
(eg
${123})
Can you have properties with such names? What's the use for them?
Maybe
they
should be disallowed or deprecated?
What about output warning when defining property with such name?
that is on property name=123 value=whatever/ outputs something
like:
[property] warning: define property with numeric name is not
recomended.
[or
is deprecated.]
Martin
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] PATCH: Expression evaluator for NAnt
Hi Gert,
As we're awaiting Scott's opinion on the subject, I have more arguments:
1. Assuming we used $propertyname the proper way to specify properties
inside expressions would be:
${$propertyname}
while currently supported syntax is:
${propertyname}.
Should we get rid of ${propertyname} syntax and change it to
${$propertyname}? It's very difficult IMO.
Introduce another magic tag for specifying expressions? %{$propertyname}.
You could then either use %{$propertyname} or ${propertyname}. Ugly - I
think.
2. Assuming we used ${propertyname} we have the same problem - there are two
legal ways to access properties, which may lead to confusion:
${propertyname} - current form
${${propertyname}} - expression whose value is the value of the
propertyname property
It's also more difficult to parse and you cannot use regular expressions
here because regexes cannot support balancing nested braces.
3. Notation proposed by Martin and implemented by me in test1 doesn't have
these problems:
It's compatible with today's approach to accessing properties (modulo the
mentioned problem with dash character). It allows for easy introduction of
functions and arithmetic expression without uglifying (dollarizing ;-) NAnt
scripts.
BTW. Assuming we have expression evaluator in place, we could get rid of
nant.tasks.TASKNAME syntax at all by replacing it with a function, like
taskexists('taskname'). Similar approach could be used to check for
location of the task: tasklocation('taskname') instead of
nant.tasks.TASKNAME.location. Assuming this, there would be no need to
have properties with dashes in them.
Jarek
- Original Message -
From: Gert Driesen [EMAIL PROTECTED]
To: Jaroslaw Kowalski [EMAIL PROTECTED]; Ian MacLean
[EMAIL PROTECTED]; Martin Aliger [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, December 05, 2003 12:12 PM
Subject: Re: [nant-dev] PATCH: Expression evaluator for NAnt
Aren't we making this too difficult for ourselves and for our users here,
by
not using the $ or ${} delimiters ?
Perhaps I'm alone on this, but I really have serious doubts on this ...
Gert
- Original Message -
From: Jaroslaw Kowalski [EMAIL PROTECTED]
To: Ian MacLean [EMAIL PROTECTED]; Martin Aliger
[EMAIL PROTECTED]
Cc: Gert Driesen [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Friday, December 05, 2003 12:00 PM
Subject: Re: [nant-dev] PATCH: Expression evaluator for NAnt
One more think came to my mind:
Dash (-) is a legal character in property name today and this may
cause
problems with expression evaluator because you cannot tell the
difference
between:
property1 MINUS property2 (written as property1-property2)
and
very DASH long DASH property DASH name (written as
very-long-property-name)
I've run script-sample.build from examples directory and found that
there
are actually 6 properties with dashes in their names:
nant.tasks.cvs-update
nant.tasks.cvs-checkout
nant.tasks.delay-sign
nant.tasks.cvs-update.location
nant.tasks.cvs-checkout.location
nant.tasks.delay-sign.location
Do you think we should do anything special to handle them?
EE currently supports propertyvalue() function where you can specify
property name as a string (so no quoting problems will arise). So for
these
special properties you would have to write, e.g:
if
test=${contains(propertyvalue('nant.tasks.cvs-checkout.location'),'c:\windo
ws')}
echo message=zzz /
/if
Is it ok?
Jarek
- Original Message -
From: Jaroslaw Kowalski [EMAIL PROTECTED]
To: Ian MacLean [EMAIL PROTECTED]; Martin Aliger
[EMAIL PROTECTED]
Cc: Gert Driesen [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Wednesday, December 03, 2003 4:26 PM
Subject: Re: [nant-dev] PATCH: Expression evaluator for NAnt
Can we define properties as:
property name = identifier { separator identifier } *
separator = . | -.
identifier = [a-zA-Z_][a-zA-Z0-9_-]*
In English:
property name is a sequence of identifiers separated by
separators
separator is a dot
identifier starts with a latin letter or an underscore and contains
only
letters, digits underscores or dashes.
This may affect people using property names with non-latin characters.
Jarek
- Original Message -
From: Ian MacLean [EMAIL PROTECTED]
To: Martin Aliger [EMAIL PROTECTED]
Cc: Jaroslaw Kowalski [EMAIL PROTECTED]; Gert Driesen
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, December 03, 2003 3:20 PM
Subject: Re: [nant-dev] PATCH: Expression evaluator for NAnt
Is anyone actually using numeric property names ? I say we should
dissallow them and be done with it.
Ian
Martin Aliger wrote:
- it won't break compatibility for properties with numeric names
(eg
${123})
Can you have properties with such names? What's the use for them?
Maybe
they
should be disallowed
Re: [nant-dev] PATCH: Expression evaluator for NAnt
You've convinced me. It works for backwards compatibility too as you can
think of the older type of property ${foo} as an expression containing a
single identifier and so the result of the expression is the value of
that identifier.
good work Jarek. Do you want me to commit this to the branch ? or will
you do it ?
Ian
Ian,
Be sure to check my test1 release of EE. I've implemented the syntax
suggested by Martin and I cannot live without it any more. It's ultra-clean,
doesn't break builds (hopefully) and works for all attributes regardless of
their type.
One more argument for allowing properties in expressions to be written
without $: Compare:
echo message=aaa if=${endswith(${somefilename},${extension})} /
with
echo message=aaa if=${endswith(somefilename,extension)} /
The ugliness factor is close to zero in the latter case, IMHO.
Jarek
- Original Message -
From: Ian MacLean [EMAIL PROTECTED]
To: Jaroslaw Kowalski [EMAIL PROTECTED]
Cc: Martin Aliger [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Wednesday, December 03, 2003 7:01 AM
Subject: Re: [nant-dev] PATCH: Expression evaluator for NAnt
I'd much prefer to see properties still distinguised by the $. Maybe the
parser can easily determine that its a property but its not so clear for
a user reading it. Especially since propertys everywhere else require
the $ syntax.
Ian
Jaroslaw Kowalski wrote:
It's of course possible to distinguish between property and
function()
within the parser.
The following interpretation of keywords is very easy to implement:
keyword followed by ( is a function call.
true/false are boolean literals
everything else denotes a property
The following would be allowed then (should it be?):
property name=length value= /
if test=length(length)=8
echo message=ok /
/if
Jarek
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
--
Ian MacLean, Developer,
ActiveState, a division of Sophos
http://www.ActiveState.com
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
--
Ian MacLean, Developer,
ActiveState, a division of Sophos
http://www.ActiveState.com
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] PATCH: Expression evaluator for NAnt
I'll do it when I manage to re-format the code. Unfortunately NAnt coding
style is a bit different than mine. I'm fighting with astyle right now ;-)
Jarek
- Original Message -
From: Ian MacLean [EMAIL PROTECTED]
To: Jaroslaw Kowalski [EMAIL PROTECTED]
Cc: Martin Aliger [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Wednesday, December 03, 2003 12:36 PM
Subject: Re: [nant-dev] PATCH: Expression evaluator for NAnt
You've convinced me. It works for backwards compatibility too as you can
think of the older type of property ${foo} as an expression containing a
single identifier and so the result of the expression is the value of
that identifier.
good work Jarek. Do you want me to commit this to the branch ? or will
you do it ?
Ian
Ian,
Be sure to check my test1 release of EE. I've implemented the syntax
suggested by Martin and I cannot live without it any more. It's
ultra-clean,
doesn't break builds (hopefully) and works for all attributes regardless
of
their type.
One more argument for allowing properties in expressions to be written
without $: Compare:
echo message=aaa if=${endswith(${somefilename},${extension})} /
with
echo message=aaa if=${endswith(somefilename,extension)} /
The ugliness factor is close to zero in the latter case, IMHO.
Jarek
- Original Message -
From: Ian MacLean [EMAIL PROTECTED]
To: Jaroslaw Kowalski [EMAIL PROTECTED]
Cc: Martin Aliger [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Wednesday, December 03, 2003 7:01 AM
Subject: Re: [nant-dev] PATCH: Expression evaluator for NAnt
I'd much prefer to see properties still distinguised by the $. Maybe the
parser can easily determine that its a property but its not so clear for
a user reading it. Especially since propertys everywhere else require
the $ syntax.
Ian
Jaroslaw Kowalski wrote:
It's of course possible to distinguish between property and
function()
within the parser.
The following interpretation of keywords is very easy to implement:
keyword followed by ( is a function call.
true/false are boolean literals
everything else denotes a property
The following would be allowed then (should it be?):
property name=length value= /
if test=length(length)=8
echo message=ok /
/if
Jarek
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
--
Ian MacLean, Developer,
ActiveState, a division of Sophos
http://www.ActiveState.com
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
--
Ian MacLean, Developer,
ActiveState, a division of Sophos
http://www.ActiveState.com
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] PATCH: Expression evaluator for NAnt
I actually still prefer using the ${foo} syntax as :
- its easier to distinguish properties (as Ian originally said)
- it won't break compatibility for properties with numeric names (eg ${123})
- corresponds with the MSbuild implementation. (not that this is importantà
- XSLT also uses a ($) prefix for variables
I also don't think we should use lt, gt, ... instead of ==, for operators,
both XSLT and MSBuild use similar operators ... so I don't see why we should
be different ...
In my opinion, it would be better to combine the best of XSLT and MSbuild
expressions, and try to be compatibile with these where it makes sense and
were these's no added value for not being compatible ... (eg. use the same
functions names, operators, ...)
Just my 2 cents ..
Gert
- Original Message -
From: Ian MacLean [EMAIL PROTECTED]
To: Jaroslaw Kowalski [EMAIL PROTECTED]
Cc: Martin Aliger [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Wednesday, December 03, 2003 12:36 PM
Subject: Re: [nant-dev] PATCH: Expression evaluator for NAnt
You've convinced me. It works for backwards compatibility too as you can
think of the older type of property ${foo} as an expression containing a
single identifier and so the result of the expression is the value of
that identifier.
good work Jarek. Do you want me to commit this to the branch ? or will
you do it ?
Ian
Ian,
Be sure to check my test1 release of EE. I've implemented the syntax
suggested by Martin and I cannot live without it any more. It's
ultra-clean,
doesn't break builds (hopefully) and works for all attributes regardless
of
their type.
One more argument for allowing properties in expressions to be written
without $: Compare:
echo message=aaa if=${endswith(${somefilename},${extension})} /
with
echo message=aaa if=${endswith(somefilename,extension)} /
The ugliness factor is close to zero in the latter case, IMHO.
Jarek
- Original Message -
From: Ian MacLean [EMAIL PROTECTED]
To: Jaroslaw Kowalski [EMAIL PROTECTED]
Cc: Martin Aliger [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Wednesday, December 03, 2003 7:01 AM
Subject: Re: [nant-dev] PATCH: Expression evaluator for NAnt
I'd much prefer to see properties still distinguised by the $. Maybe the
parser can easily determine that its a property but its not so clear for
a user reading it. Especially since propertys everywhere else require
the $ syntax.
Ian
Jaroslaw Kowalski wrote:
It's of course possible to distinguish between property and
function()
within the parser.
The following interpretation of keywords is very easy to implement:
keyword followed by ( is a function call.
true/false are boolean literals
everything else denotes a property
The following would be allowed then (should it be?):
property name=length value= /
if test=length(length)=8
echo message=ok /
/if
Jarek
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
--
Ian MacLean, Developer,
ActiveState, a division of Sophos
http://www.ActiveState.com
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
--
Ian MacLean, Developer,
ActiveState, a division of Sophos
http://www.ActiveState.com
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] PATCH: Expression evaluator for NAnt
Gert Driesen wrote:
I actually still prefer using the ${foo} syntax as :
- its easier to distinguish properties (as Ian originally said)
I'm happy with either one of Jareks options 2 and 3:
2. if=${length($propertyname)=length($someotherpropertyname)}
3. if=${length(propertyname)=length(someotherpropertyname)}
3. is cleaner and it basically changes ${ from meaning property to
meaning expression. So
if=${length(propertyname)}
returns the result of the function while:
if=${propertyname)}
returns just the value of the property, however they are both expressions.
- it won't break compatibility for properties with numeric names (eg ${123})
hmm - this works with Jareks current implementation. so
echo message=${123} /
will output the value of the property 123 if it exists and the literal
123 if it doesn't. Still I don't know a single language that allows
numeric identifiers.
- corresponds with the MSbuild implementation. (not that this is importantà
- XSLT also uses a ($) prefix for variables
xslt variables differ from nant properties in a number of ways. They
have always been more macro substitutions than true variables.
I also don't think we should use lt, gt, ... instead of ==, for operators,
both XSLT and MSBuild use similar operators ... so I don't see why we should
be different ...
not so. From the xslt spec:
NOTE: When an XPath expression occurs in an XML document, any and =
operators must be quoted according to XML 1.0 rules by using, for
example, lt; and lt;=. In the following example the value of the test
attribute is an XPath expression: xsl:if test=@value lt; 10.../xsl:if
not sure about msbuild but as its an xml vocabulary it will surely have
the same issues with escaping angle brackets.
In my opinion, it would be better to combine the best of XSLT and MSbuild
expressions, and try to be compatibile with these where it makes sense and
were these's no added value for not being compatible ... (eg. use the same
functions names, operators, ...)
sure using the same function names is a good idea. I think the string
fucntions that Jarek has implemented are pretty similar to xslt's one
anyway.
Ian
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] PATCH: Expression evaluator for NAnt
I actually still prefer using the ${foo} syntax as :
- its easier to distinguish properties (as Ian originally said)
- it won't break compatibility for properties with numeric names (eg
${123})
this is a little problem. I dont think it is good idea to have property with
such name but expression certainly breaks compatibility here... :(
- corresponds with the MSbuild implementation. (not that this is
importantà
- XSLT also uses a ($) prefix for variables
Perl as well. Maybe this is reason why I dont like it :) I prefer clear
languages as c# or Pascal or Python...
.build files are for administrators and they could not be programmers in
some cases. Clarity is big interest there IMO.
I also don't think we should use lt, gt, ... instead of ==, for
operators,
both XSLT and MSBuild use similar operators ... so I don't see why we
should
be different ...
In my opinion, it would be better to combine the best of XSLT and MSbuild
expressions, and try to be compatibile with these where it makes sense
and
were these's no added value for not being compatible ... (eg. use the same
functions names, operators, ...)
Just my 2 cents ..
Gert
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] PATCH: Expression evaluator for NAnt
apologies. I missed a previous email in the thread. I didn't realize the choice was between lt and lt. Ian I also don't think we should use lt, gt, ... instead of ==, for operators, both XSLT and MSBuild use similar operators ... so I don't see why we should be different ... not so. From the xslt spec: NOTE: When an XPath expression occurs in an XML document, any and = operators must be quoted according to XML 1.0 rules by using, for example, lt; and lt;=. In the following example the value of the test attribute is an XPath expression: xsl:if test=@value lt; 10.../xsl:if --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] PATCH: Expression evaluator for NAnt
- it won't break compatibility for properties with numeric names (eg
${123})
Can you have properties with such names? What's the use for them? Maybe
they
should be disallowed or deprecated?
What about output warning when defining property with such name?
that is on property name=123 value=whatever/ outputs something like:
[property] warning: define property with numeric name is not recomended. [or
is deprecated.]
Martin
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] PATCH: Expression evaluator for NAnt
Is anyone actually using numeric property names ? I say we should
dissallow them and be done with it.
Ian
Martin Aliger wrote:
- it won't break compatibility for properties with numeric names (eg
${123})
Can you have properties with such names? What's the use for them? Maybe
they
should be disallowed or deprecated?
What about output warning when defining property with such name?
that is on property name=123 value=whatever/ outputs something like:
[property] warning: define property with numeric name is not recomended. [or
is deprecated.]
Martin
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] PATCH: Expression evaluator for NAnt
- Original Message -
From: Ian MacLean [EMAIL PROTECTED]
To: Gert Driesen [EMAIL PROTECTED]
Cc: Jaroslaw Kowalski [EMAIL PROTECTED]; Martin Aliger
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, December 03, 2003 3:01 PM
Subject: Re: [nant-dev] PATCH: Expression evaluator for NAnt
Gert Driesen wrote:
I actually still prefer using the ${foo} syntax as :
- its easier to distinguish properties (as Ian originally said)
I'm happy with either one of Jareks options 2 and 3:
2. if=${length($propertyname)=length($someotherpropertyname)}
3. if=${length(propertyname)=length(someotherpropertyname)}
3. is cleaner and it basically changes ${ from meaning property to
meaning expression.
No doubt about that, 3 is definitely more cleaner ... but I prefer clarity
...
we'll certainly have to be more strict on what property names we allow ...
little question : do we need to have the expression surrounded in ${ }?
So
if=${length(propertyname)}
returns the result of the function while:
if=${propertyname)}
returns just the value of the property, however they are both expressions.
- it won't break compatibility for properties with numeric names (eg
${123})
hmm - this works with Jareks current implementation. so
echo message=${123} /
will output the value of the property 123 if it exists and the literal
123 if it doesn't. Still I don't know a single language that allows
numeric identifiers.
But when used as parameter to a function, there's no way of knowing whether
you meant the value of property '123' or the numeric value 123.
how do you compare the value of a property to a fixed literal ?
is it
1. if=${propertyname} = '123'
or
2. if=propertyname = '123'
I assume (1) right ?
- corresponds with the MSbuild implementation. (not that this is
importantà
- XSLT also uses a ($) prefix for variables
xslt variables differ from nant properties in a number of ways. They
have always been more macro substitutions than true variables.
I don't really see much difference here ... We sometimes even refer to (or
certainly used to) properties as macros ...
I also don't think we should use lt, gt, ... instead of ==, for
operators,
both XSLT and MSBuild use similar operators ... so I don't see why we
should
be different ...
not so. From the xslt spec:
NOTE: When an XPath expression occurs in an XML document, any and =
operators must be quoted according to XML 1.0 rules by using, for
example, lt; and lt;=. In the following example the value of the test
attribute is an XPath expression: xsl:if test=@value lt;
10.../xsl:if
not sure about msbuild but as its an xml vocabulary it will surely have
the same issues with escaping angle brackets.
no ofcourse, you're right, 'less than' was a very bad example ...
In my opinion, it would be better to combine the best of XSLT and MSbuild
expressions, and try to be compatibile with these where it makes sense
and
were these's no added value for not being compatible ... (eg. use the
same
functions names, operators, ...)
sure using the same function names is a good idea. I think the string
fucntions that Jarek has implemented are pretty similar to xslt's one
anyway.
I'm not saying they aren't ... I'm just saying we should pay attention to
this ...
I may be way off on all this as I haven't even hard time to look at Jarek's
current implementation, but a little discussion never hurts ;-)
Gert
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] PATCH: Expression evaluator for NAnt
1. if=${propertyname} = '123'
or
2. if=propertyname = '123'
you need
if=${propertyname = '123'} right now.
btw: Not very convenient in if attributes. They could/should be automatic
that is without ${}.
But you could use ${} everywhere e.g.
echo message=hello ${propertyname='123'} world./
[writes hello true world.]
Martin
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] PATCH: Expression evaluator for NAnt
Sorry - I wrote that the wrong way around. Nant properties are/ have been macro expansions, meaning that they are simple text substitutions that occur before any semantic processing of the build file occurs - similar to macros in C. Xslt's variables are true variables and have an associated type. The other difference with xslt is that expressions ( xpaths ) are only allowable in certain attributes. You can't just substitute a variable for any attribute in the script the way you can with properties in nant. Ian xslt variables differ from nant properties in a number of ways. They have always been more macro substitutions than true variables. I don't really see much difference here ... We sometimes even refer to (or certainly used to) properties as macros ... --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] PATCH: Expression evaluator for NAnt
Can we define properties as:
property name = identifier { separator identifier } *
separator = . | -.
identifier = [a-zA-Z_][a-zA-Z0-9_-]*
In English:
property name is a sequence of identifiers separated by separators
separator is a dot
identifier starts with a latin letter or an underscore and contains only
letters, digits underscores or dashes.
This may affect people using property names with non-latin characters.
Jarek
- Original Message -
From: Ian MacLean [EMAIL PROTECTED]
To: Martin Aliger [EMAIL PROTECTED]
Cc: Jaroslaw Kowalski [EMAIL PROTECTED]; Gert Driesen
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, December 03, 2003 3:20 PM
Subject: Re: [nant-dev] PATCH: Expression evaluator for NAnt
Is anyone actually using numeric property names ? I say we should
dissallow them and be done with it.
Ian
Martin Aliger wrote:
- it won't break compatibility for properties with numeric names (eg
${123})
Can you have properties with such names? What's the use for them? Maybe
they
should be disallowed or deprecated?
What about output warning when defining property with such name?
that is on property name=123 value=whatever/ outputs something
like:
[property] warning: define property with numeric name is not recomended.
[or
is deprecated.]
Martin
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] PATCH: Expression evaluator for NAnt
I think it that ${ ... }s are good because you can immediately tell where
the expressions are, and they are syntax-highlightable.
Editors like VIM could easily support highlighting function names inside
expressions or even intellisense ;-)
I actually think that
if test=... /
should always be written as
if test=${...} /
just for the consistency.
Jarek
- Original Message -
From: Martin Aliger [EMAIL PROTECTED]
To: Gert Driesen [EMAIL PROTECTED]; Ian MacLean
[EMAIL PROTECTED]
Cc: Jaroslaw Kowalski [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Wednesday, December 03, 2003 3:50 PM
Subject: Re: [nant-dev] PATCH: Expression evaluator for NAnt
1. if=${propertyname} = '123'
or
2. if=propertyname = '123'
you need
if=${propertyname = '123'} right now.
btw: Not very convenient in if attributes. They could/should be automatic
that is without ${}.
But you could use ${} everywhere e.g.
echo message=hello ${propertyname='123'} world./
[writes hello true world.]
Martin
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] PATCH: Expression evaluator for NAnt
I think it that ${ ... }s are good because you can immediately tell where
the expressions are, and they are syntax-highlightable.
Editors like VIM could easily support highlighting function names inside
expressions or even intellisense ;-)
I am convinved :) We should be consistent whereever possible.
I actually think that
if test=... /
should always be written as
if test=${...} /
just for the consistency.
even there!
Martin
Jarek
- Original Message -
From: Martin Aliger [EMAIL PROTECTED]
To: Gert Driesen [EMAIL PROTECTED]; Ian MacLean
[EMAIL PROTECTED]
Cc: Jaroslaw Kowalski [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Wednesday, December 03, 2003 3:50 PM
Subject: Re: [nant-dev] PATCH: Expression evaluator for NAnt
1. if=${propertyname} = '123'
or
2. if=propertyname = '123'
you need
if=${propertyname = '123'} right now.
btw: Not very convenient in if attributes. They could/should be
automatic
that is without ${}.
But you could use ${} everywhere e.g.
echo message=hello ${propertyname='123'} world./
[writes hello true world.]
Martin
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] PATCH: Expression evaluator for NAnt
Great! Superb! Maybe I'd love to see startwith and endwith string functions
in addition, but great start as Ian said :)
Is it in already?
I tried: [with nant-20031128]
foreach item=String in=${changes} delim= property=folder
property name=name value=${folder}.dll/
if test=indexof('.Test.dll','${name}'==0
...
and no luck :( :
BUILD FAILED
C:\temp\server\GINIS.NET.build(84,5):
[if] at least one if condition must be set (propertytrue,
targetexists, etc...):
Total time: 0.6 seconds.
Martin
- Original Message -
From: Ian MacLean [EMAIL PROTECTED]
To: Jaroslaw Kowalski [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, November 21, 2003 7:14 AM
Subject: Re: [nant-dev] PATCH: Expression evaluator for NAnt
Jaroslaw,
Awesome ! Checking it out now. Obviously this is another thing to go in
post 0.84 but this looks like a great start.
Thanks !
Ian
Hi!
As I've promised some time ago on the list, I've implemented a simple,
yet
very powerful, expression evaluator for NAnt. See below for a full list
of
features.
You can now write quite sophisticated expressions, like:
if test=tolower(${somefilename}) = ${someotherfilename} + '.txt'
...
/if
I've added my parser to NAnt.Core.ExpressionEval namespace and I've
modified
if and ifnot tasks to support a new attribute called test (named
after
XSLT ;-)
It's ultra-easy to add new functions. You simply add new public C#
function
in NAnt/Core/ExpressionEval/ExpressionEvaluator.cs and it works!
The code should be considered alpha-quality, but should work in most
cases.
I've taken some well-tested parts from another project of mine, yet some
parts are new and they may not work correctly in 100% cases.
Can someone please take a look at this patch and commit to CVS if it's
ok?
Jarek
P.S. No NUnit-style unit tests yet, but I'm working on them.
Full list of features:
==
Data types:
integer, double, string, boolean and date
Operators:
and, or, not
=, , , , =, = (because NAnt is XML I'm considering renaming
them
to lt, gt, le, ge)
unary minus,
+,-,*,/,%(modulo) with natural precedence, braces (), property
access:
${propertyname}
Functions:
propertyexists(name) - returns true when the property exists, false
otherwise
propertyvalue(name) - returns the value of the named property, fails
when it's not present
Conversion operators:
int(a) - converts a to integer (if possible) and returns the value
double(a) - converts a to double (if possible) and returns the value
string(a) - converts a to string and returns the value
date(a) - converts a to date
String functions:
length(a) - returns the length of the string
substring(a,b,c) - equivalent to a.Substring(b,c) in .NET
tolower(s) - returns s converted to lower-case
toupper(s) - returns s converted to upper-case
contains(str,subs) - returns true when subs is a substring of str
indexof(a,b) - equivalent to a.IndexOf(b) in .NET
padleft(a,b,c) - equivalent to a.PadStart(a,b,c) in .NET
padright(a,b,c) - equivalent to a.PadEnd(a,b,c) in .NET
trim(a) - equivalent to a.Trim() in .NET
trimstart(a) - equivalent to a.TrimStart() in .NET
trimend(a) - equivalent to a.TrimEnd() in .NET
Math functions:
round(v)
floor(v)
ceiling(v)
abs(v)
File functions:
getcreationtime(filename)
getlastwritetime(file)
getlastaccesstime(file)
fileexists(file)
filesize(file)
Date functions:
now()
datediff(d1,d2) - returns date difference in seconds
dateadd(d1,seconds) - returns d1 + seconds
Here are some examples of things that are known to work, taken from my
unit
tests:
Assert(1+2, 3);
Assert(1+2+3, 6);
Assert(1+2*3, 7);
Assert(2*1*3, 6);
Assert(1/2+3, 3);
Assert(5.0/(2+8), 0.5);
Assert(double(5)/(2+8), 0.5);
Assert(double(1)/2+3, 3.5);
Assert(1, 1);
Assert(1+2, 3);
Assert(1+2)+(2+1, 6);
Assert(1+2)/(2+1, 1);
Assert(length(''), 0);
Assert(length('')=0, true);
Assert(length('')=1, false);
Assert(length('test'), 4);
Assert(length('test')=4, true);
Assert(length('test')=5, false);
Assert(length('d''Artagnan'), 10);
Assert(length('d''Artagnan')=10, true);
Assert(length('d''Artagnan')=11, false);
Assert(-1, -1);
Assert(--1, 1);
Assert('a' = 'a', true);
Assert('a' = 'b', false);
Assert('a' 'a', false);
Assert('a' 'b', true);
Assert(1 = 1, true);
Assert(1 1, false);
Assert(1 = 2, false);
Assert(1 2, true);
Assert(1.0 = 1.0, true);
Assert(1.0 1.0, false);
Assert(1.0 = 2.0, false);
Assert(1.0 2.0, true);
Assert(true, true);
Assert(false, false);
Assert(true==true, true);
Assert(true==false, false);
Assert(truefalse, true);
Assert(truetrue, false);
Assert(!true, false);
Assert(!false, true);
Assert(!(1=1), false);
Assert(substring('abcde',1,2)='bc', true);
Assert(trim(' ab ')='ab
Re: [nant-dev] PATCH: Expression evaluator for NAnt
It's not in yet, but I'm working on adding this to NAnt (startswith and
endswith will be there, too). Some preliminary version should be available
before this weekend in a separate branch of NAnt.
Expression evaluation will be supported in almost all places where you can
specify in NAnt. So instead of:
echo message= if=true /
you will be able to write:
echo message= if=startswith('','a') /
This will work in for all attributes where non-string values are expected
(if, timeout, unless, failonerror, verbose, and all task-specific attributes
like debug,optimize,etc.).
For strings, I'm planning to provide embedded expressions, like:
echo message=the length of the file is: %{filelength(${filename})} /
What do you think?
Jarek
- Original Message -
From: Martin Aliger [EMAIL PROTECTED]
To: Ian MacLean [EMAIL PROTECTED]; Jaroslaw Kowalski
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, December 02, 2003 2:26 PM
Subject: Re: [nant-dev] PATCH: Expression evaluator for NAnt
Great! Superb! Maybe I'd love to see startwith and endwith string
functions
in addition, but great start as Ian said :)
Is it in already?
I tried: [with nant-20031128]
foreach item=String in=${changes} delim= property=folder
property name=name value=${folder}.dll/
if test=indexof('.Test.dll','${name}'==0
...
and no luck :( :
BUILD FAILED
C:\temp\server\GINIS.NET.build(84,5):
[if] at least one if condition must be set (propertytrue,
targetexists, etc...):
Total time: 0.6 seconds.
Martin
- Original Message -
From: Ian MacLean [EMAIL PROTECTED]
To: Jaroslaw Kowalski [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, November 21, 2003 7:14 AM
Subject: Re: [nant-dev] PATCH: Expression evaluator for NAnt
Jaroslaw,
Awesome ! Checking it out now. Obviously this is another thing to go in
post 0.84 but this looks like a great start.
Thanks !
Ian
Hi!
As I've promised some time ago on the list, I've implemented a simple,
yet
very powerful, expression evaluator for NAnt. See below for a full list
of
features.
You can now write quite sophisticated expressions, like:
if test=tolower(${somefilename}) = ${someotherfilename} + '.txt'
...
/if
I've added my parser to NAnt.Core.ExpressionEval namespace and I've
modified
if and ifnot tasks to support a new attribute called test (named
after
XSLT ;-)
It's ultra-easy to add new functions. You simply add new public C#
function
in NAnt/Core/ExpressionEval/ExpressionEvaluator.cs and it works!
The code should be considered alpha-quality, but should work in most
cases.
I've taken some well-tested parts from another project of mine, yet
some
parts are new and they may not work correctly in 100% cases.
Can someone please take a look at this patch and commit to CVS if it's
ok?
Jarek
P.S. No NUnit-style unit tests yet, but I'm working on them.
Full list of features:
==
Data types:
integer, double, string, boolean and date
Operators:
and, or, not
=, , , , =, = (because NAnt is XML I'm considering renaming
them
to lt, gt, le, ge)
unary minus,
+,-,*,/,%(modulo) with natural precedence, braces (), property
access:
${propertyname}
Functions:
propertyexists(name) - returns true when the property exists, false
otherwise
propertyvalue(name) - returns the value of the named property,
fails
when it's not present
Conversion operators:
int(a) - converts a to integer (if possible) and returns the value
double(a) - converts a to double (if possible) and returns the
value
string(a) - converts a to string and returns the value
date(a) - converts a to date
String functions:
length(a) - returns the length of the string
substring(a,b,c) - equivalent to a.Substring(b,c) in .NET
tolower(s) - returns s converted to lower-case
toupper(s) - returns s converted to upper-case
contains(str,subs) - returns true when subs is a substring of str
indexof(a,b) - equivalent to a.IndexOf(b) in .NET
padleft(a,b,c) - equivalent to a.PadStart(a,b,c) in .NET
padright(a,b,c) - equivalent to a.PadEnd(a,b,c) in .NET
trim(a) - equivalent to a.Trim() in .NET
trimstart(a) - equivalent to a.TrimStart() in .NET
trimend(a) - equivalent to a.TrimEnd() in .NET
Math functions:
round(v)
floor(v)
ceiling(v)
abs(v)
File functions:
getcreationtime(filename)
getlastwritetime(file)
getlastaccesstime(file)
fileexists(file)
filesize(file)
Date functions:
now()
datediff(d1,d2) - returns date difference in seconds
dateadd(d1,seconds) - returns d1 + seconds
Here are some examples of things that are known to work, taken from my
unit
tests:
Assert(1+2, 3);
Assert(1+2+3, 6);
Assert(1+2*3, 7
Re: [nant-dev] PATCH: Expression evaluator for NAnt
Sounds good!
embedded expression should maybe use ${...} syntax unless we could break
some existing buildfiles.
how property expansion works together with expressions?
e.g.:
does echo message=the length of the file is: %{filelength(${filename})}
/work
or should I write echo message=the length of the file is:
%{filelength('${filename}')} / ?
Maybe, if expressions could use properties directly as variables there could
be more straightforward
%{filelength(filename)} or even with begining ${ to be compatible.
${property} than will be property or expression which is the same in that
case.
Martin
- Original Message -
From: Jaroslaw Kowalski [EMAIL PROTECTED]
To: Martin Aliger [EMAIL PROTECTED]; Ian MacLean
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, December 02, 2003 3:27 PM
Subject: Re: [nant-dev] PATCH: Expression evaluator for NAnt
It's not in yet, but I'm working on adding this to NAnt (startswith and
endswith will be there, too). Some preliminary version should be available
before this weekend in a separate branch of NAnt.
Expression evaluation will be supported in almost all places where you can
specify in NAnt. So instead of:
echo message= if=true /
you will be able to write:
echo message= if=startswith('','a') /
This will work in for all attributes where non-string values are expected
(if, timeout, unless, failonerror, verbose, and all task-specific
attributes
like debug,optimize,etc.).
For strings, I'm planning to provide embedded expressions, like:
echo message=the length of the file is: %{filelength(${filename})} /
What do you think?
Jarek
- Original Message -
From: Martin Aliger [EMAIL PROTECTED]
To: Ian MacLean [EMAIL PROTECTED]; Jaroslaw Kowalski
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, December 02, 2003 2:26 PM
Subject: Re: [nant-dev] PATCH: Expression evaluator for NAnt
Great! Superb! Maybe I'd love to see startwith and endwith string
functions
in addition, but great start as Ian said :)
Is it in already?
I tried: [with nant-20031128]
foreach item=String in=${changes} delim= property=folder
property name=name value=${folder}.dll/
if test=indexof('.Test.dll','${name}'==0
...
and no luck :( :
BUILD FAILED
C:\temp\server\GINIS.NET.build(84,5):
[if] at least one if condition must be set (propertytrue,
targetexists, etc...):
Total time: 0.6 seconds.
Martin
- Original Message -
From: Ian MacLean [EMAIL PROTECTED]
To: Jaroslaw Kowalski [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, November 21, 2003 7:14 AM
Subject: Re: [nant-dev] PATCH: Expression evaluator for NAnt
Jaroslaw,
Awesome ! Checking it out now. Obviously this is another thing to go
in
post 0.84 but this looks like a great start.
Thanks !
Ian
Hi!
As I've promised some time ago on the list, I've implemented a
simple,
yet
very powerful, expression evaluator for NAnt. See below for a full
list
of
features.
You can now write quite sophisticated expressions, like:
if test=tolower(${somefilename}) = ${someotherfilename} + '.txt'
...
/if
I've added my parser to NAnt.Core.ExpressionEval namespace and I've
modified
if and ifnot tasks to support a new attribute called test
(named
after
XSLT ;-)
It's ultra-easy to add new functions. You simply add new public C#
function
in NAnt/Core/ExpressionEval/ExpressionEvaluator.cs and it works!
The code should be considered alpha-quality, but should work in most
cases.
I've taken some well-tested parts from another project of mine, yet
some
parts are new and they may not work correctly in 100% cases.
Can someone please take a look at this patch and commit to CVS if
it's
ok?
Jarek
P.S. No NUnit-style unit tests yet, but I'm working on them.
Full list of features:
==
Data types:
integer, double, string, boolean and date
Operators:
and, or, not
=, , , , =, = (because NAnt is XML I'm considering renaming
them
to lt, gt, le, ge)
unary minus,
+,-,*,/,%(modulo) with natural precedence, braces (), property
access:
${propertyname}
Functions:
propertyexists(name) - returns true when the property exists,
false
otherwise
propertyvalue(name) - returns the value of the named property,
fails
when it's not present
Conversion operators:
int(a) - converts a to integer (if possible) and returns the
value
double(a) - converts a to double (if possible) and returns the
value
string(a) - converts a to string and returns the value
date(a) - converts a to date
String functions:
length(a) - returns the length of the string
substring(a,b,c) - equivalent to a.Substring(b,c) in .NET
tolower(s) - returns s converted to lower-case
Re: [nant-dev] PATCH: Expression evaluator for NAnt
This looks like a good idea. I'll think about it:
We could have:
echo message=aaa ${length('aaa')} if=someproperty /
echo message=aaa ${length('aaa')} if=length(someproperty) = 3 /
if test=contains(nant.settings.currentframework.description,
'Microsoft')
echo message=We're running on Microsoft! /
/if
But it may break some build scripts which use length and similar keywords
as property names. What should we do then?
Also, since we use XML, there's a problem with , =, , and = operators
which need to be written as lt; gt; which isn't very readable. Shouldn't
we call the operators lt, le, gt, ge (less than, less or equal,
greater than, greater or equal) adding eq (for equality) and ne (for
not-equality) ??? Or should we allow for both forms?
This way you could have:
echo message=aaa if='aaa' eq someproperty /
Shoud unary boolean negation be not or !?
Should binary boolean operators be and, or or ||, (amp;amp;) in
XML)
I'm awaiting your opinions.
Jarek
- Original Message -
From: Martin Aliger [EMAIL PROTECTED]
To: Jaroslaw Kowalski [EMAIL PROTECTED]; Ian MacLean
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, December 02, 2003 3:44 PM
Subject: Re: [nant-dev] PATCH: Expression evaluator for NAnt
Sounds good!
embedded expression should maybe use ${...} syntax unless we could break
some existing buildfiles.
how property expansion works together with expressions?
e.g.:
does echo message=the length of the file is: %{filelength(${filename})}
/work
or should I write echo message=the length of the file is:
%{filelength('${filename}')} / ?
Maybe, if expressions could use properties directly as variables there
could
be more straightforward
%{filelength(filename)} or even with begining ${ to be compatible.
${property} than will be property or expression which is the same in that
case.
Martin
- Original Message -
From: Jaroslaw Kowalski [EMAIL PROTECTED]
To: Martin Aliger [EMAIL PROTECTED]; Ian MacLean
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, December 02, 2003 3:27 PM
Subject: Re: [nant-dev] PATCH: Expression evaluator for NAnt
It's not in yet, but I'm working on adding this to NAnt (startswith and
endswith will be there, too). Some preliminary version should be
available
before this weekend in a separate branch of NAnt.
Expression evaluation will be supported in almost all places where you
can
specify in NAnt. So instead of:
echo message= if=true /
you will be able to write:
echo message= if=startswith('','a') /
This will work in for all attributes where non-string values are
expected
(if, timeout, unless, failonerror, verbose, and all task-specific
attributes
like debug,optimize,etc.).
For strings, I'm planning to provide embedded expressions, like:
echo message=the length of the file is: %{filelength(${filename})} /
What do you think?
Jarek
- Original Message -
From: Martin Aliger [EMAIL PROTECTED]
To: Ian MacLean [EMAIL PROTECTED]; Jaroslaw Kowalski
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, December 02, 2003 2:26 PM
Subject: Re: [nant-dev] PATCH: Expression evaluator for NAnt
Great! Superb! Maybe I'd love to see startwith and endwith string
functions
in addition, but great start as Ian said :)
Is it in already?
I tried: [with nant-20031128]
foreach item=String in=${changes} delim= property=folder
property name=name value=${folder}.dll/
if test=indexof('.Test.dll','${name}'==0
...
and no luck :( :
BUILD FAILED
C:\temp\server\GINIS.NET.build(84,5):
[if] at least one if condition must be set (propertytrue,
targetexists, etc...):
Total time: 0.6 seconds.
Martin
- Original Message -
From: Ian MacLean [EMAIL PROTECTED]
To: Jaroslaw Kowalski [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, November 21, 2003 7:14 AM
Subject: Re: [nant-dev] PATCH: Expression evaluator for NAnt
Jaroslaw,
Awesome ! Checking it out now. Obviously this is another thing to go
in
post 0.84 but this looks like a great start.
Thanks !
Ian
Hi!
As I've promised some time ago on the list, I've implemented a
simple,
yet
very powerful, expression evaluator for NAnt. See below for a full
list
of
features.
You can now write quite sophisticated expressions, like:
if test=tolower(${somefilename}) = ${someotherfilename} +
'.txt'
...
/if
I've added my parser to NAnt.Core.ExpressionEval namespace and
I've
modified
if and ifnot tasks to support a new attribute called test
(named
after
XSLT ;-)
It's ultra-easy to add new functions. You simply add new public C#
function
in NAnt/Core/ExpressionEval/ExpressionEvaluator.cs and it works!
The code should be considered alpha-quality, but should work in
most
cases
Re: [nant-dev] PATCH: Expression evaluator for NAnt
This looks like a good idea. I'll think about it:
We could have:
echo message=aaa ${length('aaa')} if=someproperty /
echo message=aaa ${length('aaa')} if=length(someproperty) = 3 /
if test=contains(nant.settings.currentframework.description,
'Microsoft')
echo message=We're running on Microsoft! /
/if
But it may break some build scripts which use length and similar
keywords
as property names. What should we do then?
true :-( Looks we couldn't be 100% compatible... Unless expression generator
allows to use length variable/property and length() function in the same
time.
Also, since we use XML, there's a problem with , =, , and = operators
which need to be written as lt; gt; which isn't very readable. Shouldn't
we call the operators lt, le, gt, ge (less than, less or equal,
greater than, greater or equal) adding eq (for equality) and ne (for
not-equality) ??? Or should we allow for both forms?
I prefer plan lt; xml syntax there. You could use other operators without
problem (even ). I was examining xml specs with cdata attributes, but it is
not included in xml (was in sgml i think!)
This way you could have:
echo message=aaa if='aaa' eq someproperty /
Shoud unary boolean negation be not or !?
Should binary boolean operators be and, or or ||, (amp;amp;)
in
XML)
I prefer and, or, not there. But it is just mine oppinion...
I'm looking forward to expression so much that this small details... :-)
Martin
I'm awaiting your opinions.
Jarek
- Original Message -
From: Martin Aliger [EMAIL PROTECTED]
To: Jaroslaw Kowalski [EMAIL PROTECTED]; Ian MacLean
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, December 02, 2003 3:44 PM
Subject: Re: [nant-dev] PATCH: Expression evaluator for NAnt
Sounds good!
embedded expression should maybe use ${...} syntax unless we could break
some existing buildfiles.
how property expansion works together with expressions?
e.g.:
does echo message=the length of the file is:
%{filelength(${filename})}
/work
or should I write echo message=the length of the file is:
%{filelength('${filename}')} / ?
Maybe, if expressions could use properties directly as variables there
could
be more straightforward
%{filelength(filename)} or even with begining ${ to be compatible.
${property} than will be property or expression which is the same in
that
case.
Martin
- Original Message -
From: Jaroslaw Kowalski [EMAIL PROTECTED]
To: Martin Aliger [EMAIL PROTECTED]; Ian MacLean
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, December 02, 2003 3:27 PM
Subject: Re: [nant-dev] PATCH: Expression evaluator for NAnt
It's not in yet, but I'm working on adding this to NAnt (startswith
and
endswith will be there, too). Some preliminary version should be
available
before this weekend in a separate branch of NAnt.
Expression evaluation will be supported in almost all places where you
can
specify in NAnt. So instead of:
echo message= if=true /
you will be able to write:
echo message= if=startswith('','a') /
This will work in for all attributes where non-string values are
expected
(if, timeout, unless, failonerror, verbose, and all task-specific
attributes
like debug,optimize,etc.).
For strings, I'm planning to provide embedded expressions, like:
echo message=the length of the file is: %{filelength(${filename})}
/
What do you think?
Jarek
- Original Message -
From: Martin Aliger [EMAIL PROTECTED]
To: Ian MacLean [EMAIL PROTECTED]; Jaroslaw Kowalski
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, December 02, 2003 2:26 PM
Subject: Re: [nant-dev] PATCH: Expression evaluator for NAnt
Great! Superb! Maybe I'd love to see startwith and endwith string
functions
in addition, but great start as Ian said :)
Is it in already?
I tried: [with nant-20031128]
foreach item=String in=${changes} delim=
property=folder
property name=name value=${folder}.dll/
if test=indexof('.Test.dll','${name}'==0
...
and no luck :( :
BUILD FAILED
C:\temp\server\GINIS.NET.build(84,5):
[if] at least one if condition must be set (propertytrue,
targetexists, etc...):
Total time: 0.6 seconds.
Martin
- Original Message -
From: Ian MacLean [EMAIL PROTECTED]
To: Jaroslaw Kowalski [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, November 21, 2003 7:14 AM
Subject: Re: [nant-dev] PATCH: Expression evaluator for NAnt
Jaroslaw,
Awesome ! Checking it out now. Obviously this is another thing to
go
in
post 0.84 but this looks like a great start.
Thanks !
Ian
Hi!
As I've promised some time ago on the list, I've implemented a
simple,
yet
very powerful, expression evaluator
Re: [nant-dev] PATCH: Expression evaluator for NAnt
But it may break some build scripts which use length and similar keywords as property names. What should we do then? true :-( Looks we couldn't be 100% compatible... Unless expression generator allows to use length variable/property and length() function in the same time. It's of course possible to distinguish between property and function() within the parser. The following interpretation of keywords is very easy to implement: keyword followed by ( is a function call. true/false are boolean literals everything else denotes a property The following would be allowed then (should it be?): property name=length value= / if test=length(length)=8 echo message=ok / /if Jarek --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] PATCH: Expression evaluator for NAnt
I'd much prefer to see properties still distinguised by the $. Maybe the parser can easily determine that its a property but its not so clear for a user reading it. Especially since propertys everywhere else require the $ syntax. Ian Jaroslaw Kowalski wrote: It's of course possible to distinguish between property and function() within the parser. The following interpretation of keywords is very easy to implement: keyword followed by ( is a function call. true/false are boolean literals everything else denotes a property The following would be allowed then (should it be?): property name=length value= / if test=length(length)=8 echo message=ok / /if Jarek --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers -- Ian MacLean, Developer, ActiveState, a division of Sophos http://www.ActiveState.com --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] PATCH: Expression evaluator for NAnt
Jaroslaw,
Awesome ! Checking it out now. Obviously this is another thing to go in
post 0.84 but this looks like a great start.
Thanks !
Ian
Hi!
As I've promised some time ago on the list, I've implemented a simple, yet
very powerful, expression evaluator for NAnt. See below for a full list of
features.
You can now write quite sophisticated expressions, like:
if test=tolower(${somefilename}) = ${someotherfilename} + '.txt'
...
/if
I've added my parser to NAnt.Core.ExpressionEval namespace and I've
modified
if and ifnot tasks to support a new attribute called test (named after
XSLT ;-)
It's ultra-easy to add new functions. You simply add new public C# function
in NAnt/Core/ExpressionEval/ExpressionEvaluator.cs and it works!
The code should be considered alpha-quality, but should work in most cases.
I've taken some well-tested parts from another project of mine, yet some
parts are new and they may not work correctly in 100% cases.
Can someone please take a look at this patch and commit to CVS if it's ok?
Jarek
P.S. No NUnit-style unit tests yet, but I'm working on them.
Full list of features:
==
Data types:
integer, double, string, boolean and date
Operators:
and, or, not
=, , , , =, = (because NAnt is XML I'm considering renaming them
to lt, gt, le, ge)
unary minus,
+,-,*,/,%(modulo) with natural precedence, braces (), property access:
${propertyname}
Functions:
propertyexists(name) - returns true when the property exists, false
otherwise
propertyvalue(name) - returns the value of the named property, fails
when it's not present
Conversion operators:
int(a) - converts a to integer (if possible) and returns the value
double(a) - converts a to double (if possible) and returns the value
string(a) - converts a to string and returns the value
date(a) - converts a to date
String functions:
length(a) - returns the length of the string
substring(a,b,c) - equivalent to a.Substring(b,c) in .NET
tolower(s) - returns s converted to lower-case
toupper(s) - returns s converted to upper-case
contains(str,subs) - returns true when subs is a substring of str
indexof(a,b) - equivalent to a.IndexOf(b) in .NET
padleft(a,b,c) - equivalent to a.PadStart(a,b,c) in .NET
padright(a,b,c) - equivalent to a.PadEnd(a,b,c) in .NET
trim(a) - equivalent to a.Trim() in .NET
trimstart(a) - equivalent to a.TrimStart() in .NET
trimend(a) - equivalent to a.TrimEnd() in .NET
Math functions:
round(v)
floor(v)
ceiling(v)
abs(v)
File functions:
getcreationtime(filename)
getlastwritetime(file)
getlastaccesstime(file)
fileexists(file)
filesize(file)
Date functions:
now()
datediff(d1,d2) - returns date difference in seconds
dateadd(d1,seconds) - returns d1 + seconds
Here are some examples of things that are known to work, taken from my unit
tests:
Assert(1+2, 3);
Assert(1+2+3, 6);
Assert(1+2*3, 7);
Assert(2*1*3, 6);
Assert(1/2+3, 3);
Assert(5.0/(2+8), 0.5);
Assert(double(5)/(2+8), 0.5);
Assert(double(1)/2+3, 3.5);
Assert(1, 1);
Assert(1+2, 3);
Assert(1+2)+(2+1, 6);
Assert(1+2)/(2+1, 1);
Assert(length(''), 0);
Assert(length('')=0, true);
Assert(length('')=1, false);
Assert(length('test'), 4);
Assert(length('test')=4, true);
Assert(length('test')=5, false);
Assert(length('d''Artagnan'), 10);
Assert(length('d''Artagnan')=10, true);
Assert(length('d''Artagnan')=11, false);
Assert(-1, -1);
Assert(--1, 1);
Assert('a' = 'a', true);
Assert('a' = 'b', false);
Assert('a' 'a', false);
Assert('a' 'b', true);
Assert(1 = 1, true);
Assert(1 1, false);
Assert(1 = 2, false);
Assert(1 2, true);
Assert(1.0 = 1.0, true);
Assert(1.0 1.0, false);
Assert(1.0 = 2.0, false);
Assert(1.0 2.0, true);
Assert(true, true);
Assert(false, false);
Assert(true==true, true);
Assert(true==false, false);
Assert(truefalse, true);
Assert(truetrue, false);
Assert(!true, false);
Assert(!false, true);
Assert(!(1=1), false);
Assert(substring('abcde',1,2)='bc', true);
Assert(trim(' ab ')='ab', true);
Assert(trimstart(' ab ')='ab ', true);
Assert(trimend(' ab ')=' ab', true);
Assert(padleft('ab',5,'.')='...ab', true);
Assert(padright('ab',5,'.')='ab...', true);
Assert(indexof('abc','c')=2, true);
Assert(indexof('abc','d')=-1, true);
Assert(indexof('abc','d')=-1, true);
Assert(round(0.1), 0.0);
Assert(round(0.7), 1.0);
Assert(floor(0.1), 0.0);
Assert(floor(0.7), 0.0);
Assert(ceiling(0.1), 1.0);
Assert(ceiling(0.7), 1.0);
Assert(if(true,1,2), 1);
Assert(if(true,'a','b'), a);
Assert(if(false,'a','b'), b);
Assert(abs(1), 1.0);
Assert(abs(-1), 1.0);
Assert(fileexists('c:\\notthere.txt'), false);
Assert(dateadd(${somedate},3600) = ${someotherdate}, true);
Assert('a' + 'b' = 'ab', true);
--
Ian MacLean, Developer,
ActiveState, a division of Sophos
http://www.ActiveState.com
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you
