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
[nant-dev] bug in resources compiling
Hello nant-developers,
I've found a bug in resource compiling (for dependent resources):
(according to nightly build from 28.11.03) in Resource.cs:104 there
is a regex which extracts namespace name and class name. The problem
is that it expects that the class is derived from something (it
extracts the class name till the ':' symbol), which is generally not
true.
So, the right regex should be something like
Regex re = new Regex(@
(?namespace(?ns(.|\s)*?){)
|
(?class(?class.*?)[:{])
|
}
, RegexOptions.IgnorePatternWhitespace | RegexOptions.Multiline |
RegexOptions.Compiled);
(the changed line is highlighted)
--
Best regards,
Ivan mailto:[EMAIL PROTECTED]
* Beware of the man who knows the answer before he understands the question.
---
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
[nant-dev] verbosity logging
Hi all, I'm very confused by logging support in current nant. There exist two distinct mechanisms! One implemented in Task via Log method (and Verbose/Info/Warning/Error levels) and second via log4net! Why not use log4net even for screen outputs?? It will be much easier to redirect such output to file etc. (even redirect verbose output and to screen with warning level only). This could also prevent this: logger.Info(strLogContents); //do not print LogPrefix, just pad that length. Log(Level.Info, new string(char.Parse( ), LogPrefix.Length) + strLogContents); why to have it twice and format message here? That is log4net stuff, I think... 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
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] Re: project references problems in solution task
(re-cc'ing the list) AppDomains allow you load/unload assemblies at will. The .NET runtime tends to exhibit some odd/unpredictable behaviour as you load assemblies with the same name, especially if they don't have strong names. You can end up with types no longer resolving as expected. By loading assemblies in the separate AppDomain, you side-step all of these issues. Ivan Tarasov wrote: Hello Matthew, oh, it's quite an ugly way. I was considering this but I rejected Hashtable because it smells like it is a hack :) Could you please explain the need of separate AppDomain? Is it because of some sequrity reason (loaded assembly can execute some nant internal code or its own code with nant's privelegies)? MM System.Collections.Hashtable is your friend here. :) MM Sounds good - just make sure you use a separate AppDomain while checking MM for assembly references. I would also recommend caching lists of MM dependent assemblies based on filename to save time. why do I need separate AppDomain? I wanted to do some caching (I needed something like std::set in C++), but I couldn't find something similar in framework, I'd apreciate if you point me the right way to do it --- 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] Expression Evaluator for NAnt - test1
Hi Jarek!
I tested your code. Good!
Only thing I found is type incompatibility in expressions e.g.
ifnot test=true1
or
ifnot test=endswith(true,false)
throws
INTERNAL ERROR
System.ArgumentException: Object must be of type Boolean.
at System.Boolean.CompareTo(Object obj)
at
NAnt.Core.ExpressionEval.ExpressionEvalBase.ParseRelationalExpression() in
e:\src\extern\nant\src\NAnt.Core\ExpressionEval\ExpressionEvalBase.cs:line
195
All exceptions during function call or operator evaluation should be user
BuildExceptions.
Martin
- Original Message -
From: Jaroslaw Kowalski [EMAIL PROTECTED]
To: [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Tuesday, December 02, 2003 11:09 PM
Subject: [nant-dev] Expression Evaluator for NAnt - test1
Hi!
Here's the first test release of the expression evaluator I'm developing
for
NAnt.
I encourage everyone to try it. I'd like to get as much feedback as
possible
on it.
Please report:
1. Does it work for you? Bug reports are welcome.
2. Is it useful?
3. Do you find the syntax simple enough? Are the build files more/less
readable?
4. Does it break your existing build files? (it shouldn't!)
5. What functions/data types/conversions/operators/conversions should be
added/removed?
6. What other features would you like to see?
Pre-compiled binaries along with patches to current CVS code can be found
at:
http://jaak.sav.net/nant-ee/nant-ee-test1.zip
Changes:
* new attribute test for if and ifnot which lets you write:
=
if test=property1 = property2 + '.txt'
...
/if
=
* support for expressions in (hopefully) all places where ${propertyname}
syntax could be used:
=
property name=prop1 value=${'aaa' + 'bbb'} /
echo message=length of prop1 is: ${length(prop1)} if=${1+2=3} /
=
Jarek
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 (), properties can
be
accessed just by providing their name
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
bool(a) - converts a to boolean
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
startswith(a,b) - equivalent to a.StartsWith(b) in .NET
endswith(a,b) - equivalent to a.EndsWith(b) 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,
[nant-dev] Expression Evaluator in CVS
Hi!
I've committed expression evaluator (as in test1 release) to CVS in
EE-patches branch.
I think what we now need is:
- unit tests (for ExpressionEval classes alone as they are easily separable
and for NAnt changes.
- user documentation
Unfortunately these tasks cannot be started until we agree on the syntax.
As I understand there are 3 major candidates:
A. echo message=aaa if=${length(propertyname)=3} /
B. echo message=aaa if=${length($propertyname)=3} /
C. echo message=aaa if=${length(${propertyname})=3} /
Currently there are 4 opinions:
Jarek: A
Martin: A
Ian: A or B
Gert: B or C (i can't tell which one exactly)
Another (rather minor) question is:
Should if test=expression / require expression to be surrounded by
${...} (this would allow for full syntax highlighting in some editors) or
not.
Opinions:
Jarek: Yes
Martin: Yes
Ian: ?
Gert: ?
I encourage everyone to try test1 release at
http://jaak.sav.net/nant-ee/nant-ee-test1.zip
or CVS code and report your thoughts to the list.
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] Expression Evaluator in CVS
- Original Message -
From: Jaroslaw Kowalski [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, December 03, 2003 6:24 PM
Subject: [nant-dev] Expression Evaluator in CVS
Hi!
I've committed expression evaluator (as in test1 release) to CVS in
EE-patches branch.
I think what we now need is:
- unit tests (for ExpressionEval classes alone as they are easily
separable
and for NAnt changes.
- user documentation
Unfortunately these tasks cannot be started until we agree on the syntax.
As I understand there are 3 major candidates:
A. echo message=aaa if=${length(propertyname)=3} /
B. echo message=aaa if=${length($propertyname)=3} /
C. echo message=aaa if=${length(${propertyname})=3} /
Currently there are 4 opinions:
Jarek: A
Martin: A
Ian: A or B
Gert: B or C (i can't tell which one exactly)
Me neither, both are fine by me ... If the majority agrees that A is the
way to go, and there are no serious drawbacks, its fine by me too ...
But I'd also like to hear Scott's opinion on this subject
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[2]: [nant-dev] Re: project references problems in solution task
Hello Matthew,
I've implemented the proof-of-concept program, which creates AppDomain
and loads assemblies there, but I'm not sure if it works around the
problem you've described. Probably it would be good to set up some
security policy for the newly-created AppDomain, so that the loaded
assembly couldn't do any harm (AFAIR, static constructors are called
when assembly is being loaded). Also, in MSDN there is a clause that
it may take quite a time to Unload the AppDomain. An alternative way
is to call Abort on all threads of this domain which is a bit harsh.
I'm not sure which way to go, please tell your opinion if you find
some way to be the preferable one.
Program source is attached, it just prints the names of referenced
assemblies.
I'm also going to do some speedup by using Hashtable, so don't take
the current ArrayList implementation into account.
It would be great if somebody commented upon that code (style/bad
practices/etc.), so that I could change it now.
MM AppDomains allow you load/unload assemblies at will. The .NET runtime
MM tends to exhibit some odd/unpredictable behaviour as you load assemblies
MM with the same name, especially if they don't have strong names. You can
MM end up with types no longer resolving as expected. By loading
MM assemblies in the separate AppDomain, you side-step all of these issues.
--
Best regards,
Ivanmailto:[EMAIL PROTECTED]using System;
using System.IO;
using System.Collections;
using System.Reflection;
using System.Runtime.Remoting;
public class GetRefs {
public static void Main(string[] p_args) {
if (p_args.Length != 1) {
Console.WriteLine(usage: refs dll);
return;
}
string[] referenced = GetAllReferencedModules(p_args[0]);
Console.WriteLine(Referenced:);
Console.WriteLine(string.Join(\n, referenced));
}
private static string[] GetAllReferencedModules(string module) {
string fullPathToModule = Path.GetFullPath(module);
string moduleDirectory = Path.GetDirectoryName(fullPathToModule);
AppDomain temporaryDomain = AppDomain.CreateDomain(temporaryDomain);
ArrayList referenceList = new ArrayList();
try {
ReferencesResolver referencesResolver =
((ReferencesResolver) temporaryDomain.CreateInstanceFrom(refs.exe,
typeof(ReferencesResolver).FullName).Unwrap());
referenceList.Add(fullPathToModule);
for (int currentModule = 0; currentModule referenceList.Count;
currentModule++) {
referencesResolver.AppendReferencedModulesLocatedInGivenDirectory(moduleDirectory,
(string) referenceList[currentModule], ref referenceList);
}
} finally {
AppDomain.Unload(temporaryDomain);
}
return (string[]) referenceList.ToArray(typeof(string));
}
}
public class ReferencesResolver : MarshalByRefObject {
public void AppendReferencedModulesLocatedInGivenDirectory(string moduleDirectory,
string moduleName,
ref ArrayList
referenceList) {
Assembly module = Assembly.LoadFrom(moduleName);
AssemblyName[] referencedAssemblies = module.GetReferencedAssemblies();
foreach (AssemblyName referencedAssemblyName in referencedAssemblies) {
string fullPathToReferencedAssembly = string.Format(@{0}\{1}.dll,
moduleDirectory, referencedAssemblyName.Name);
// we only add referenced assemblies which are located in given directory
if (File.Exists(fullPathToReferencedAssembly)
!referenceList.Contains(fullPathToReferencedAssembly))
referenceList.Add(fullPathToReferencedAssembly);
}
}
}
[nant-dev] Re: verbosity of some tasks
At some point I'd like to use the multiple .resx input of resgen.exe - it would be nice to swallow output if no errors occur and just output: [resgen] Transformed 5 .resx files The solution builds would be a lot easier to read. Perhaps I can compress all of the reference copy operations into a single task call as well. [solution] Building SomeProject... [resgen] Transformed 5 .resx files [csc] Compiling 48 files (compiler output) [csc] Successfully compiled 48 files [copy] Copied 12 files to C:\fakeproject\bin\Debug ... etc Lots of work to get that point, however. Matt. Gert Driesen wrote: Martin, The delay-sign task will now at least output the number of assemblies that will be delay-signed ... About the solution task : we use resgen.exe to compile the resources and there's no way to quiet it down ... Gert - Original Message - From: Martin Aliger [EMAIL PROTECTED] To: ! nant [EMAIL PROTECTED] Sent: Tuesday, December 02, 2003 4:33 PM Subject: [nant-dev] verbosity of some tasks Hi again (hope last one today) I found verbosity level of many tasks very inconsistent. Maybe we could say how much task should output under normal run and other messages move into verbose level. for example solution task with only 2 assemblies to compile (without warning) outputs: [solution] Starting solution build. [solution] Building Gordic.General [Release]... Read in 11 resources from 'c:\temp\build-src\Gordic.Gene ral\Gordic.General.resx' Writing resource file... Done. [solution] Building Gordic.Support.Win32 [Release]... Read in 5 resources from 'c:\temp\build-src\Gordic.Suppo rt.Win32\Gordic.Support.Win32.resx' Writing resource file... Done. where plain [solution] Building Gordic.General [Release]... [solution] Building Gordic.Support.Win32 [Release]... should be enough. In opposite e.g. delay-sign outputs _nothing_ even when signing over 100 assemblies (in verbose mode it outputs 10 lines per assembly) I think something like copy's [copy] Copying 17 files to c:\temp\build-src. should be outputted. [delay-sign] 117 assemblies was delay signed. Regards, 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/ --- 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
[nant-dev] Delphi 8 .NET
NAnt Developers, With Delphi 8 .NET just over the horizon, I thought that I would propose that we try to get some Delphi tasks under development as soon as it comes out. In the past Borland has released a free for personal use version of Delphi. If they continue to do so then I would enjoy trying to get some solution like tasks together for Delphi projects. If they do not, then I doubt that I will be able to afford a copy (unless I can talk the boss into picking up a copy ;)). Should the planning begin now for how these new tasks will fit in with the rest of the tasks or should we just wait until the final product comes out? -Scott --- 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] Delphi 8 .NET
Talk away, but this may also be a good discussion to start in the NAntContrib list. That is most likely where they will be stored, and developed:) I would like to keep NAnt-Dev focused on NAnt-Core idea and dev issues. Not that I don't like to discuss new task ideas, but focusing things into NAntContrib would be better IMO. :) - Original Message - From: Scott Ford [EMAIL PROTECTED] To: Nant-Developers (E-mail) [EMAIL PROTECTED] Sent: Wednesday, December 03, 2003 4:07 PM Subject: [nant-dev] Delphi 8 .NET NAnt Developers, With Delphi 8 .NET just over the horizon, I thought that I would propose that we try to get some Delphi tasks under development as soon as it comes out. In the past Borland has released a free for personal use version of Delphi. If they continue to do so then I would enjoy trying to get some solution like tasks together for Delphi projects. If they do not, then I doubt that I will be able to afford a copy (unless I can talk the boss into picking up a copy ;)). Should the planning begin now for how these new tasks will fit in with the rest of the tasks or should we just wait until the final product comes out? -Scott --- 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] Delphi 8 .NET
My apologies. I will send a copy of my message to the NAnt-Contrib list. -Original Message- From: Scott Hernandez [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2003 7:19 PM To: Scott Ford Cc: Nant-Developers (E-mail) Subject: Re: [nant-dev] Delphi 8 .NET Talk away, but this may also be a good discussion to start in the NAntContrib list. That is most likely where they will be stored, and developed:) I would like to keep NAnt-Dev focused on NAnt-Core idea and dev issues. Not that I don't like to discuss new task ideas, but focusing things into NAntContrib would be better IMO. :) - Original Message - From: Scott Ford [EMAIL PROTECTED] To: Nant-Developers (E-mail) [EMAIL PROTECTED] Sent: Wednesday, December 03, 2003 4:07 PM Subject: [nant-dev] Delphi 8 .NET NAnt Developers, With Delphi 8 .NET just over the horizon, I thought that I would propose that we try to get some Delphi tasks under development as soon as it comes out. In the past Borland has released a free for personal use version of Delphi. If they continue to do so then I would enjoy trying to get some solution like tasks together for Delphi projects. If they do not, then I doubt that I will be able to afford a copy (unless I can talk the boss into picking up a copy ;)). Should the planning begin now for how these new tasks will fit in with the rest of the tasks or should we just wait until the final product comes out? -Scott --- 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
