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
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
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 ($)
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.
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
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
- 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
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
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
- 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
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./
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
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
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
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
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
(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
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
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
- 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
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
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
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
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
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
25 matches
Mail list logo
