Re: XmlLogger is fixed! Was RE: [nant-dev] XmlLogger is broken?

[Gert Driesen]

> - Original Message - 
> From: "Troy Laurin" <[EMAIL PROTECTED]>
> To: "Gert Driesen" <[EMAIL PROTECTED]>
> Cc: "Nant-Developers (E-Mail)" <[EMAIL PROTECTED]>
> Sent: Thursday, July 22, 2004 7:18 AM
> Subject: XmlLogger is fixed! Was RE: [nant-dev] XmlLogger is broken?
> 

> Responding to myself, because it looks like our mail server decided not
> to deliver this last message (grr)
> 
> Comments below.
> 
> > -Original Message-
> > From: Troy Laurin 
> > Sent: Wednesday, 21 July 2004 5:26 PM
> > To: Gert Driesen
> > Cc: Nant-Developers (E-Mail)
> > Subject: RE: [nant-dev] XmlLogger is broken?
> > 
> > > > I'll see if I can reproduce this later today ...
> > > > 
> > > > Gert
> > > 
> > > In fact, every time the build has hung has been during an 
> > 'exec' task.
> > > Although there doesn't seem to be anything wrong with the task (by) 
> > > itself... the build process completes perfectly if the xml 
> > logger is 
> > > removed as a listener.
> > 
> > Success!
> > 
> > Repro and log attached.  Pardon the absolutely horrible build file :-)
> > 
> > Running the build will require changing the arguments to cvs 
> > to something that will actually work (I would have referenced 
> > a public cvs repository, but our proxy would have blocked 
> > testing it on my machine (grr))
> > 
> 
> > Interestingly, with this repro, neither the hang point nor 
> > the xml exception are consistent.  In multiple runs, the 
> > build never hung before the exception, although both the time 
> > and 'distance' between the exception and hang was variable.
> > 
> > I would guess that the exception is caused by exec's output 
> > and error streams emitting strings at essentially the same time:
> > error stream...  cvs export: Updating C:/temp/foo/Gif2Png 
> > output stream... U C:/temp/foo/Gif2Png/gif2png.lib
> > 
> > Putting a synchronization lock in XmlLogger should prevent 
> > the exception, which may in turn prevent the hang... 
> > Unfortunately no time to try this today, but I'll try first 
> > thing tomorrow.
> > I guess the question remains: Is this the appropriate fix?  
> > The exec task probably shouldn't be logging on two threads at 
> > once, but the XmlLogger probably shouldn't fail in this case anyway.
> > 
> > 
> > Oop, network's going down in 2 mins :-)
> > 
> > -T

> Adding synchronization to XmlLogger does indeed fix the problem!
> Context diff attached.

Thanks !! Fix committed to cvs.

>
> In ExternalProgramBase.cs, there are comments in the two threaded
> methods to the tune of "Ensure only one thread writes to the log at any
> time", but the synchronization is then performed on the _reading_
> stream.  That is, each thread is synchronizing on a different object.
> Should this be changed, so both threads are locking on OutputWriter,
> rather than its own input stream?

Yeps indeed, this is now also fixed in cvs.

Again, thanks for tracking this bug down !

Gert



---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers

Re: [nant-dev] Bug in NAnt Visual Studio .NET Solution builder

[Gert Driesen]

Stephen,

Can you try to reproduce this using a recent nightly build of NAnt
(http://nant.sourceforge.net/nightly/builds) ?

If you can reproduce it, would you be able to package up a zip file
containing the minimum set of files necessary to reproduce this issue ?

Thanks,

Gert

- Original Message -
From: "Stephen Dunn" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 20, 2004 12:34 PM
Subject: [nant-dev] Bug in NAnt Visual Studio .NET Solution builder


I'm using thetag to build a solution.

I've found the following:

The solution contains two projects, Project A and Project B

Project A in has a reference to a com DLL.  This DLL is produced as
output from Project B.  The project's build order build Project B first
so that the file referenced by Project A will exist.  This works fine
when building from Visual Studio .NET(2003).

The problem occurs when using NAntContrib.  When loading the solution,
dependencies are being resolved at load time, and hence failing on the
missing DLL that is referenced by Project A.  Here's the call stack:

[solution] Starting solution build.



BUILD FAILED



INTERNAL ERROR



System.Exception: Couldn't find referenced type library
'd:\projects\libraries\picrypt\debug\PICrypt.dll'.

   at NAnt.VSNet.Reference.HandleWrapperImport(XmlElement elemReference)

   at NAnt.VSNet.Reference..ctor(Solution solution, ProjectSettings ps,
XmlElement elemReference, SolutionTask solutionTask, String outputDir)

   at NAnt.VSNet.Project.Load(Solution sln, String projectPath)

   at NAnt.VSNet.ProjectFactory.LoadProject(Solution sln, SolutionTask
slnTask, TempFileCollection tfc, String outputDir, String path)

   at NAnt.VSNet.Solution.LoadProjects()

   at NAnt.VSNet.Solution..ctor(String solutionFileName, ArrayList
additionalProjects, ArrayList referenceProjects, TempFileCollection tfc,
SolutionTa

sk solutionTask, WebMapCollection webMappings, FileSet excludesProjects,
String outputDir)

   at NAnt.VSNet.Tasks.SolutionTask.ExecuteTask()

   at NAnt.Core.Task.Execute()

   at NAnt.Core.Target.Execute()

   at NAnt.Core.Project.Execute(String targetName, Boolean
forceDependencies)

   at NAnt.Core.Project.Execute()

   at NAnt.Core.Project.Run()



Please send bug report to [EMAIL PROTECTED]



Total time: 74.6 seconds.



Please let me know if you require more information.



Many thanks,



Steve Dunn

This email and any attachments are confidential. They may contain privileged
information and are intended for the named addressee(s) only. They must not
be distributed without Perfect Information's consent. If you are not the
intended recipient, please notify us immediately and do not disclose,
distribute, or retain this email or any part of it. Unless expressly stated,
opinions in this email are those of the individual sender, and not of
Perfect Information. We believe but do not warrant that this e-mail and any
attachments are virus free. You must therefore take full responsibility for
virus checking. Perfect Information reserves the right to monitor all email
communications through their networks.




---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers

[nant-dev] Re: [Nant-users] Typed properties

[Malcolm MacLucas]

>From a user point of view, I love it.

I'm not currently doing anything with NAnt that would require this much power,
but it would be nice to have.

Malcolm

--- Jaroslaw Kowalski <[EMAIL PROTECTED]> wrote:
> Hi guys!
> 
> I'd like to propose the introduction of typed properties to NAnt. Currently
> properties are stored as strings which has many drawbacks, esp. when used
> within expressions.
> For example:
> 
> 
> 
> ...
> 
> 
> this test fails because: 
> 1. "a" is stored as a string
> 2. equality operator promotes "false" literal to string which becomes "False"
> (note the initial cap - this is what Convert.ToString() does) the compares
> both sides as strings.
> 3. 'false' != 'False'
> 
> My idea is to:
> 
> 1. Disallow ALL implicit conversions for operators - to avoid such confusions
> 2. Add support for typed properties - to let properties store values of types
> other than strings. It would involve type checking on assignment and
> type-safe retrieval.
> 
> The proposed syntax would be:
> 
> 
> 
> 
> When "type" is omitted - "string" is assumed by default for compatibility.
> 
> The following would fail because of incompatible types:
> 
> 
> 
> 
> 
> Assuming we disallow all implicit conversions:
> 
> 
> 
> 
> 
> 
> 
>  -- causes an error, today it outputs
> 'TrueFalse'
>  --- causes an error, today it outputs
> aaaFalse
>  --- outputs aaaFalse
>  -- outputs 444, today it outputs 123321
>  -- fails, currently it outputs 123456
>  -- outputs 123456
>  -- outputs 579
> 
> Implicit conversion would still be applied when passing arguments to
> functions:
> Assuming 
> 
> int fun(int k) { return k; }
> 
>  -- outputs 457
> 
> There are probably more consequences of this idea, if you see any danger -
> let me know.
> I'm awaiting your comments. If this idea passes, I'll prepare the appropriate
> patch. Initial feasibility study shows that it's possible to do it without
> breaking compatibility.
> 
> Jarek


=
"Oh Bother!" said the Borg, "We just assimilated Pooh."



__
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 


---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers

Re: [Nant-users] Re: [nant-dev] Typed properties

[Malcolm MacLucas]

--- Gert Driesen <[EMAIL PROTECTED]> wrote:
> From: "Malcolm MacLucas" <[EMAIL PROTECTED]>
> > After thinking about it for a bit, I'll repeat what I said earlier, Typed
> > properties would be cool.
> >
> > That being said, I think that it should be looked at and placed on the
> road map
> > somewhere down the road.  Around .87 or .88.
> 
> Not sure, we really should make sure we don't have to break people's build
> files when we introduce typed properties at that stage ...

Gert, you are right, my bad, I meant, 
"I think that it should be looked at and <<< if approved by the design team,
>>> placed on the roadmap somewhere down the road.  Around .87 or .88 <<< but,
in my estimation, not any sooner. >>>.

Very critical omissions on my part.

> > what they want to work on.  ...  Some of the project management tasks are
> very
> > "un-sexy", tedious and pretty much not rewarded.
> 
> I've spent a good part of the day doing this un-sexy work : a first draft of
> the release notes for NAnt 0.85 beta 1 is in cvs ...

Thanks Gert, that work tends be be something that no one notices if it's done
right, but everyone complains about if its even slightly off.  Same tends to go
for technical writing.

As a side note, I have got to figure out how to use CVS.  Anyone have a
preference for a cvs how to that will have me up and running in 15 - 20 minutes
from end of download?
 
> >
> > We are an Agile development tool, I'm thinking that we have the chance to
> > demonstrate the value of an agile methodology (multiple incremental
> builds,
> > always in a stable state)
> >
> > What would it take for us to put out a release candidate, on say, August
> 4th,
> > that gives us 2 weeks to make it happen.
> 
> Sure, see no problem with that ...

Cool, again, any thing I can do to help, even if I have to submit the stuff to
you via e-mail, I love what is possible with NAnt and want to get it into the
hands of busy end users that are looking for a simple solution to solve their
needs.  A solution that they can get running in 15-20 minutes from the time
they finish their download.
> 
> >
> > Speaking of which, I have not been able to find the roadmap, or vision
> document
> > for NAnt.  Can someone point me in their direction?
> 
> There isn't really one, except for the release plan (and even that is not
> something that has been discussed very much) ...

?release plan?  Where do I find that?  Let me guess, there's a "documents"
section in the CVS isn't there?

Thanks again.

Malcolm


=
"Oh Bother!" said the Borg, "We just assimilated Pooh."




__
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/


---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers

[nant-dev] Bug in NAnt Visual Studio .NET Solution builder

[Stephen Dunn]

I’m using the    tag
to build a solution.

I’ve found the following:

The solution contains two projects, Project A and Project
B

Project A in has a reference to a com DLL.  This DLL
is produced as output from Project B.  The project’s build order
build Project B first so that the file referenced by Project A will
exist.  This works fine when building from Visual Studio .NET(2003).

The problem occurs when using NAntContrib.  When
loading the solution, dependencies are being resolved at load time, and hence
failing on the missing DLL that is referenced by Project A.  Here’s
the call stack:

[solution] Starting solution build.

 

BUILD FAILED

 

INTERNAL ERROR

 

System.Exception: Couldn't find referenced type library
'd:\projects\libraries\picrypt\debug\PICrypt.dll'.

   at
NAnt.VSNet.Reference.HandleWrapperImport(XmlElement elemReference)

   at NAnt.VSNet.Reference..ctor(Solution
solution, ProjectSettings ps, XmlElement elemReference, SolutionTask
solutionTask, String outputDir)

   at NAnt.VSNet.Project.Load(Solution sln,
String projectPath)

   at NAnt.VSNet.ProjectFactory.LoadProject(Solution
sln, SolutionTask slnTask, TempFileCollection tfc, String outputDir, String
path)

   at NAnt.VSNet.Solution.LoadProjects()

   at NAnt.VSNet.Solution..ctor(String
solutionFileName, ArrayList additionalProjects, ArrayList referenceProjects, TempFileCollection
tfc, SolutionTa

sk solutionTask, WebMapCollection webMappings, FileSet
excludesProjects, String outputDir)

   at
NAnt.VSNet.Tasks.SolutionTask.ExecuteTask()

   at NAnt.Core.Task.Execute()

   at NAnt.Core.Target.Execute()

   at NAnt.Core.Project.Execute(String
targetName, Boolean forceDependencies)

   at NAnt.Core.Project.Execute()

   at NAnt.Core.Project.Run()

 

Please send bug report to
[EMAIL PROTECTED]

 

Total time: 74.6 seconds.

 

Please let me know if you require more information.

 

Many thanks,

 

Steve Dunn



This email and any attachments are confidential. They may contain privileged information and are intended for the named addressee(s) only. They must not be distributed without Perfect Information's consent. If you are not the intended recipient, please notify us immediately and do not disclose, distribute, or retain this email or any part of it. Unless expressly stated, opinions in this email are those of the individual sender, and not of Perfect Information. We believe but do not warrant that this e-mail and any attachments are virus free. You must therefore take full responsibility for virus checking. Perfect Information reserves the right to monitor all email communications through their networks.

Re: [Nant-users] Re: [nant-dev] Typed properties

[Malcolm MacLucas]

After thinking about it for a bit, I'll repeat what I said earlier, Typed
properties would be cool.

That being said, I think that it should be looked at and placed on the road map
somewhere down the road.  Around .87 or .88.

We have been 7 months without a "release".  We can't keep adding new features
and hope that they will go in with no problems and or side effects.  At the
same time, this is a volunteer effort so the reality is that people only have a
limited amount of time and that for the most part, people are going to work on
what they want to work on.  ...  Some of the project management tasks are very
"un-sexy", tedious and pretty much not rewarded. 

We are an Agile development tool, I'm thinking that we have the chance to
demonstrate the value of an agile methodology (multiple incremental builds,
always in a stable state)

What would it take for us to put out a release candidate, on say, August 4th,
that gives us 2 weeks to make it happen.

Speaking of which, I have not been able to find the roadmap, or vision document
for NAnt.  Can someone point me in their direction?

Thanks

Malcolm



--- Jaroslaw Kowalski <[EMAIL PROTECTED]> wrote:
> On Wed, 21 Jul 2004, Troy Laurin wrote:
> 
> > Jarek, others,
> >
> > I kind of like the idea of a property having a type, but I have a few
> > questions regarding implementation...
> >
> 
> > Notwithstanding, "it's possible to do it without breaking
> > compatibility"... you can't claim this if you are making a change that
> > turns a previously valid operation into an error!
> 
> Yes, but there's been no stable release of NAnt + expressions. We've had a 
> discussion with Gert some time ago and agreed we need to get rid of 
> implicit conversions by the time 0.85 ships.


=
"Oh Bother!" said the Borg, "We just assimilated Pooh."



__
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 


---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers

RE: [Nant-users] Re: [nant-dev] Typed properties

[Troy Laurin]

 

> -Original Message-
> From: Gert Driesen [mailto:[EMAIL PROTECTED] 
> 
> - Original Message -
> From: "Jaroslaw Kowalski" <[EMAIL PROTECTED]>
> 
> > On Wed, 21 Jul 2004, Troy Laurin wrote:
> >
> > The destination type is "string"
> > unless overriden by "type" attribute. This is what most 
> > people expect from assignment operation (in languages
> > like C++, C#, Java ...)
> >
> > > 
> > >
> > > Again, if the default property type is 'string', then what is the 
> > > type of 'a' after this assignment?
> >
> > "string"

Why I brought up these examples is that it is actually quite different
from behaviour in most compiled languages, in that the _value_ is
determining type... in most compiled languages, the _property_
(variable) determines type.  Of course, scripting/interpreted languages
often use value-determined type to good use... at the cost of very weak
(or nonexistant) type checking.

> > > mostly because it isn't always (often?) going to be apparent by 
> > > looking at the build file exactly what a property's type is.  I 
> >
> > Property's type is always "string" unless specifically 
> > overriden. Simple.

The problem arises in that the property's type may be set somewhere
distant in the build file, and then it's not apparent when looking at
the _use_ of the build file what the property's type is... so you don't
know if you're going to get a conversion exception or not until you
actually run the build.

> > All implicit conversion will be disabled and will cause an error 
> > requiring you to fix your build file.
> >
> > > Notwithstanding, "it's possible to do it without breaking 
> > > compatibility"... you can't claim this if you are making a change 
> > > that turns a previously valid operation into an error!
> >
> > Yes, but there's been no stable release of NAnt + 
> > expressions.

Good point :-)
The nightly builds have been pushed quite strongly on the mailing
lists... but it would be simple to notify the lists that expressions
would need to be updated.

> > > Having said the above, there is an alternative to disallowing 
> > > implicit type conversion (that unfortunately also breaks 
> backwards 
> > > compatibility) that means that all implicit type 
> conversions should be safe:
> > > I've never been a particular fan of overloading the '+' operator 
> > > with string concatenation... if '+' only means addition, then it 
> > > would always involve numeric-conversion.
> 
> what about, for example, datetime values ?  we currently 
> support the additional of datetime and timespan values ...

That's not in the documentation! :-)

I think that still works okay... because datetime and timespan can't be
converted (implicitly or explicitly!) to int or float, '+' can be safely
overloaded to date/time addition (and '-' to date/time subtraction)
without ambiguity.

Of course, whether it's a good idea to support operator overloading
(whether safe or not) is a separate question.  A simple, though not
necessarily optimal, "fix" would be to remove the date-related
"overloads" on the operator, and instead use datetime:: functions.  One
benefit to using functions rather than operators is that it's
immediately obvious whether you're incrementing the date or the time.

> > Because there is no implicit conversion
> > > from boolean to integer, a boolean operand will cause an error.
> > > Conversely if (for example) '|' means concatenation then it would 
> > > always involve (unambiguous) string-conversion.
> >
> > I like the idea. We could replace '+' with a '.' as it is 
> > used in PERL or PHP for example. Alternatively we could
> > have string::concat(...) for this purpose but this would be
> > too verbose.

I agree that string::concat is far too verbose for common use.
'.' as the concatenation operator was actually my first thought, as you
mentioned for its current use in Perl/PHP... but then I wondered what
the syntax would be when trying to concat the property 'str.prefix' with
'file.name', hence my suggestion of | (I think | or || is the string
concatenation operator in Oracle SQL, if anyone wanted a link to an
existing language ;-)

Alternatively, it could be required that operators are surrounded by
whitespace. (Basically upgrading the recommendation that operators are
surrounded by whitespace that's currently in the documentation)

> > > Would just this last be enough type safety?  It still includes 
> > > implicit conversion from string to int/float, but in a 
> (IMHO) safe fashion.
> >
> > After some thought, I give this idea (using concatenation operator 
> > other than a plus) +1. Gert, what do you think? This would 
> solve 99% 
> > of all ambiguity problems without the need for typed properties.
> 
> Think I still need to give it some more thought ... I'm in 
> "holiday" mode today ;-)
> 
> Gert

Regarding Malcolm's comment that typed properties shouldn't get in the
way of the up-and-coming 0.85 release, I very much agree... but there's
also the fact that this discussion 

Re: [Nant-users] Re: [nant-dev] Typed properties

[Ian MacLean]

Gert Driesen wrote:
- Original Message -
From: "Malcolm MacLucas" <[EMAIL PROTECTED]>
To: "Jaroslaw Kowalski" <[EMAIL PROTECTED]>; "Troy Laurin"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Wednesday, July 21, 2004 9:02 PM
Subject: Re: [Nant-users] Re: [nant-dev] Typed properties
 

After thinking about it for a bit, I'll repeat what I said earlier, Typed
properties would be cool.
That being said, I think that it should be looked at and placed on the
   

road map
 

somewhere down the road.  Around .87 or .88.
   

Not sure, we really should make sure we don't have to break people's build
files when we introduce typed properties at that stage ...
 

Yeah but on the other hand we shouldn't go rushing in features because 
we're worried about breaking builds later on. Two points : firstly we 
are reccomending that people use nightly builds *now* which means that 
they'll get broken builds anyway and secondly, the amount of changes 
since 0.84 means that updrading users will get a slew of deprecated 
messages. Thats not a big problem but I mention it to make the point 
that upgrading will have a 'cost' regardless of which release we target 
features too.
My view is that adding typed properties is a significant change with the 
potential to add complexity to builds. I can see the problems that can 
be solved by their addition but I'm not yet convinced that they are 
sufficent justification.  It seems to me that it will be more 
complicated than just adding a type attribute. What types will we 
support ? just basic string, int, bool etc or the full CLR type system ?

Ian
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers

Cvs how-to; was: RE: [Nant-users] Re: [nant-dev] Typed properties

[Clayton Harbour]

Hi Malcolm,

You can try downloading TortoiseCVS
(http://www.tortoisecvs.org/download.shtml) which should make basic cvs
work painless.  It provides shell integration and an intuitive gui for
checkouts and updates.  If you look at the user's guide
(http://www.tortoisecvs.org/UserGuide_en.chm) "Checking out a Module"
and the NAnt cvs information on the project page
(http://sourceforge.net/cvs/?group_id=31650) it should get you up and
running fairly quickly.

You will have read only access to the NAnt repository with the anonymous
user which is not optimal if you are doing frequent updates but you
should be able to generate patch files and submit them to the list.  If
your updates are frequent enough it might be worthwhile to get committer
access.

Hope that helps.


Cheers,


Clayton

> -Original Message-
> From: Malcolm MacLucas [mailto:[EMAIL PROTECTED] 
> Sent: July 21, 2004 1:24 PM
> To: Gert Driesen; Jaroslaw Kowalski; Troy Laurin; 
> [EMAIL PROTECTED]; 
> [EMAIL PROTECTED]
> Subject: Re: [Nant-users] Re: [nant-dev] Typed properties
> 
> 
> --- Gert Driesen <[EMAIL PROTECTED]> wrote:
> > From: "Malcolm MacLucas" <[EMAIL PROTECTED]>
> > > After thinking about it for a bit, I'll repeat what I 
> said earlier, 
> > > Typed properties would be cool.
> > >
> > > That being said, I think that it should be looked at and 
> placed on 
> > > the
> > road map
> > > somewhere down the road.  Around .87 or .88.
> > 
> > Not sure, we really should make sure we don't have to break 
> people's 
> > build files when we introduce typed properties at that stage ...
> 
> Gert, you are right, my bad, I meant, 
> "I think that it should be looked at and <<< if approved by 
> the design team,
> >>> placed on the roadmap somewhere down the road.  Around .87 or .88 
> >>> <<< but,
> in my estimation, not any sooner. >>>.
> 
> Very critical omissions on my part.
> 
> > > what they want to work on.  ...  Some of the project management 
> > > tasks are
> > very
> > > "un-sexy", tedious and pretty much not rewarded.
> > 
> > I've spent a good part of the day doing this un-sexy work : a first 
> > draft of the release notes for NAnt 0.85 beta 1 is in cvs ...
> 
> Thanks Gert, that work tends be be something that no one 
> notices if it's done right, but everyone complains about if 
> its even slightly off.  Same tends to go for technical writing.
> 
> As a side note, I have got to figure out how to use CVS.  
> Anyone have a preference for a cvs how to that will have me 
> up and running in 15 - 20 minutes from end of download?
>  
> > >
> > > We are an Agile development tool, I'm thinking that we have the 
> > > chance to demonstrate the value of an agile methodology (multiple 
> > > incremental
> > builds,
> > > always in a stable state)
> > >
> > > What would it take for us to put out a release candidate, on say, 
> > > August
> > 4th,
> > > that gives us 2 weeks to make it happen.
> > 
> > Sure, see no problem with that ...
> 
> Cool, again, any thing I can do to help, even if I have to 
> submit the stuff to you via e-mail, I love what is possible 
> with NAnt and want to get it into the hands of busy end users 
> that are looking for a simple solution to solve their needs.  
> A solution that they can get running in 15-20 minutes from 
> the time they finish their download.
> > 
> > >
> > > Speaking of which, I have not been able to find the roadmap, or 
> > > vision
> > document
> > > for NAnt.  Can someone point me in their direction?
> > 
> > There isn't really one, except for the release plan (and 
> even that is 
> > not something that has been discussed very much) ...
> 
> ?release plan?  Where do I find that?  Let me guess, there's 
> a "documents" section in the CVS isn't there?
> 
> Thanks again.
> 
> Malcolm
> 
> 
> =
> "Oh Bother!" said the Borg, "We just assimilated Pooh."
> 
> 
>   
>   
> __
> Do you Yahoo!?
> Vote for the stars of Yahoo!'s next ad campaign! 
> http://advision.webevents.yahoo.com/yahoo/votelifeengine/
> 
> 
> ---
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today. 
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> ___
> Nant-users mailing list
> [EMAIL PROTECTED] 
> https://lists.sourceforge.net/lists/listinfo/nant-users
> 


---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id040&op=click
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers

Re: [Nant-users] Re: [nant-dev] Typed properties

[Gert Driesen]

- Original Message -
From: "Malcolm MacLucas" <[EMAIL PROTECTED]>
To: "Jaroslaw Kowalski" <[EMAIL PROTECTED]>; "Troy Laurin"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Wednesday, July 21, 2004 9:02 PM
Subject: Re: [Nant-users] Re: [nant-dev] Typed properties


> After thinking about it for a bit, I'll repeat what I said earlier, Typed
> properties would be cool.
>
> That being said, I think that it should be looked at and placed on the
road map
> somewhere down the road.  Around .87 or .88.

Not sure, we really should make sure we don't have to break people's build
files when we introduce typed properties at that stage ...

>
> We have been 7 months without a "release".  We can't keep adding new
features
> and hope that they will go in with no problems and or side effects.  At
the
> same time, this is a volunteer effort so the reality is that people only
have a
> limited amount of time and that for the most part, people are going to
work on
> what they want to work on.  ...  Some of the project management tasks are
very
> "un-sexy", tedious and pretty much not rewarded.

I've spent a good part of the day doing this un-sexy work : a first draft of
the release notes for NAnt 0.85 beta 1 is in cvs ...

>
> We are an Agile development tool, I'm thinking that we have the chance to
> demonstrate the value of an agile methodology (multiple incremental
builds,
> always in a stable state)
>
> What would it take for us to put out a release candidate, on say, August
4th,
> that gives us 2 weeks to make it happen.

Sure, see no problem with that ...

>
> Speaking of which, I have not been able to find the roadmap, or vision
document
> for NAnt.  Can someone point me in their direction?

There isn't really one, except for the release plan (and even that is not
something that has been discussed very much) ...

Gert



---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers

[nant-dev] [ nant-Bugs-940942 ] if & unless attribute of target tag

[SourceForge.net]

Bugs item #940942, was opened at 2004-04-23 21:45
Message generated for change (Comment added) made by drieseng
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=402868&aid=940942&group_id=31650

Category: Documentation
Group: 0.8.4.0
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Kevin Sagon (ksagon)
Assigned to: Gert Driesen (drieseng)
Summary: if & unless attribute of target tag

Initial Comment:
The if and unless attributes of the target tag are 
documented and are intended to function on the 
premise that they will "sense" the existence or non-
existence of the property specified by their value.  
Unfortunately it looks as if they are coded so that if the 
property exists then an attempt is made to convert the 
value to a boolean and return that result.  If I am 
reading the code right the value that is used for 
conversion is the value of the property specified, this 
will usually result in a conversion error as the value of 
the property was not intended to be used in this way.  
Indeed, the presence of the property is all that should 
be checked for to stay consistent with both the 
documentation and the Java version of the same 
functionality.

The code in question is in the Target.cs source lines 
108-117 (if attribute) and lines 148-157 (unless 
attribute).

If you would like more details please feel free to contact 
me.

--

>Comment By: Gert Driesen (drieseng)
Date: 2004-07-21 20:18

Message:
Logged In: YES 
user_id=707851

I've updated the docs to reflect the fact that the if and 
unless attributes actually expect an expression that 
evaluates to a bool.

--

Comment By: Gert Driesen (drieseng)
Date: 2004-07-20 12:05

Message:
Logged In: YES 
user_id=707851

You need a NAnt 0.85 nightly build 
(http://nant.sourceforge.net/nighlty/builds) in order to have 
expression support.

--

Comment By: MArcin Slusarczyk (mslusar)
Date: 2004-07-20 11:55

Message:
Logged In: YES 
user_id=799500

Example presented by drieseng :



Does not work for me. I got error:
Property 'file::exists('build.xml')' has not been set.

--

Comment By: explorer (junp50)
Date: 2004-06-29 19:39

Message:
Logged In: YES 
user_id=1073549

I followed the instructions posted by drieseng, but I still
got errors

INTERNAL ERROR

System.FormatException: String was not recognized as a valid
Boolean.
   at System.Boolean.Parse(String value)
   at System.Convert.ToBoolean(String value)
   at NAnt.Core.Tasks.IfTask.get_ConditionsTrue() in
C:\DOCUME~1\drieseng\LOCALS~1\Temp\tmp15EB.tmpsrc\NAnt.Core\Tasks\IfTask.cs:line 271
   at NAnt.Core.Tasks.IfTask.ExecuteTask() in
C:\DOCUME~1\drieseng\LOCALS~1\Temp\tmp15EB.tmp\src\NAn
t.Core\Tasks\IfTask.cs:line 333
   at NAnt.Core.Task.Execute() in
C:\DOCUME~1\drieseng\LOCALS~1\Temp\tmp15EB.tmp\src\NAnt.Core\Task.
cs:line 176
   at NAnt.Core.Target.Execute() in
C:\DOCUME~1\drieseng\LOCALS~1\Temp\tmp15EB.tmp\src\NAnt.Core\Tar
get.cs:line 249
   at NAnt.Core.Project.Execute(String targetName, Boolean
forceDependencies) in C:\DOCUME~1\driesen
g\LOCALS~1\Temp\tmp15EB.tmp\src\NAnt.Core\Project.cs:line 870
   at NAnt.Core.Project.Execute() in
C:\DOCUME~1\drieseng\LOCALS~1\Temp\tmp15EB.tmp\src\NAnt.Core\Pr
oject.cs:line 827
   at NAnt.Core.Project.Run() in
C:\DOCUME~1\drieseng\LOCALS~1\Temp\tmp15EB.tmp\src\NAnt.Core\Projec
t.cs:line 895

Please send bug report to [EMAIL PROTECTED]

--

Comment By: Gert Driesen (drieseng)
Date: 2004-05-02 10:04

Message:
Logged In: YES 
user_id=707851

Kevin,

This is actually a documentation issue.  The NAnt developers 
took a departure from their Ant counterpart on this topic, and 
forgot to update the docs accordingly.  

In NAnt the if and unless attributes expect an expression that 
evaluates to either true or false.

To be honest : when I first started working on NAnt I didn't 
agree with this departure from Ant's logic too, but that 
departure does allow us to have expressions in the if and 
unless attributes now, without breaking any existing builds.

Right now, you could have a target executed only if a certain 
file exists, without having to use intermediate properties to 
hold a bool indicating whether the file exists or not :





I'm updating the category of this bug report 
to "Documentation", and wil fix the docs in the next few 
days ...

Thanks for the report !

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=402868&aid=940942&group_id=31650


---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Jav

[nant-dev] [ nant-Bugs-995409 ] Improvement to NUNit2

[SourceForge.net]

Bugs item #995409, was opened at 2004-07-21 12:39
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=402868&aid=995409&group_id=31650

Category: Tasks
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tom Cabanski (tcabanski)
Assigned to: Nobody/Anonymous (nobody)
Summary: Improvement to NUNit2

Initial Comment:
I’ve run into a situation where I have to run my unit test 
suite under a number of cultures to verify proper 
handling of number and date formatting.  Rather that 
manually switching my machine for each test, I’ve 
introduced a culture attribute to the test element of the 
nunit2 task.  For example, the following directive runs 
my test suite in five cultures:


    
  
  
  
  
  
    
  

We've had this for several months now and found it 
quite useful.  As a result, I got the latest code from CVS 
and added the new attribute to it.

Here’s the diff from CVS:

Index: NUnit2Task.cs
==
=
RCS 
file: /cvsroot/nant/nant/src/NAnt.NUnit/NUnit2/NUnit2Ta
sk.cs,v
retrieving revision 1.37
diff -r1.37 NUnit2Task.cs
107a108,118
> ///    
> ///   Run tests in the MyProject.Tests.dll 
assembly using the Italian culture (even if the computer 
is using a different culture).
> ///   
> ///   
> /// 
> ///   
278a290,298
>     
>     //Save the current culture and set the 
thread's 
> culture based on the default of the Culture attribute
>     System.Globalization.CultureInfo 
holdCulture = 
> 
System.Threading.Thread.CurrentThread.CurrentCulture;
>     
System.Threading.Thread.CurrentThread.CurrentCulture 
= 
> test.CultureInfo;
> 
>     if (holdCulture.Name != 
test.CultureInfo.Name)
>     {
>   Console.WriteLine("RUNNING TESTS 
UNDER CULTURE 
> {0}", test.CultureInfo.Name);
>     }
287a308,310
>     //Put back the old culture
>     
System.Threading.Thread.CurrentThread.CurrentCulture 
= 
> holdCulture;
> 
Index: NUnit2Test.cs
==
=
RCS 
file: /cvsroot/nant/nant/src/NAnt.NUnit/NUnit2/NUnit2Te
st.cs,v
retrieving revision 1.23
diff -r1.23 NUnit2Test.cs
44a45
>   private System.Globalization.CultureInfo 
_culture = 
> System.Globalization.CultureInfo.CurrentCulture;
106a108,127
>   /// 
>   /// Set to a culture name such as "fr-FR" 
(France French)
>   /// to run the tests under a culture other than
>   /// the machine default culture.
>   /// 
>   [TaskAttribute("culture")]
>   public string Culture
>   {
>     get { return _culture.Name; }
>     set { _culture = new
> System.Globalization.CultureInfo(value); }
>   }
> 
> /// 
> /// The CultureInfo object which will be used to 
set the culture of the test.
> /// 
> public System.Globalization.CultureInfo 
CultureInfo
> {
> get { return _culture; }
> }
> 

* CVS exited normally with code 1 *

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=402868&aid=995409&group_id=31650


---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers

Re: [Nant-users] Re: [nant-dev] Typed properties

[Gert Driesen]

- Original Message -
From: "Jaroslaw Kowalski" <[EMAIL PROTECTED]>
To: "Troy Laurin" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, July 21, 2004 9:57 AM
Subject: [Nant-users] Re: [nant-dev] Typed properties


> On Wed, 21 Jul 2004, Troy Laurin wrote:
>
> > Jarek, others,
> >
> > I kind of like the idea of a property having a type, but I have a few
> > questions regarding implementation...
> >
> > In the following...
> >
> > 
> > 
> >
> > If the default type for properties if none is specified is 'string',
> > then what is the type of 'a' after the two property assignments above?
>
> The idea is that the type conversion occurs AFTER the value has been
> evaluated and BEFORE the value is stored.

What about dynamic properties ? These are not evaluated before they are
stored ...

> The destination type is "string"
> unless overriden by "type" attribute. This is what most people expect from
> assignment operation (in languages like C++, C#, Java ...)
>
> > 
> >
> > Again, if the default property type is 'string', then what is the type
> > of 'a' after this assignment?
>
> "string"
>
> HOWEVER: We could be smart (or dumb - pick one) by introducing the
> following rule: If the value of the property already has a type and
>  doesn't specify a type - use the resulting type. In this case
> the answer would be "integer". This can be confusing, though:

Yeah, and we should avoid confusion (and complexity) whenever possible ...
we're already getting enough questions as is ;-)

>
> Some examples of inferenced types:
>
>  -- type=string
>  -- type=integer
>  -- type=boolean
>  -- type=string
>  -- type=string
>  -- type=string
>
> > Regarding disallowing all implicit conversions in operators, I can see
> > why you might want this, but I have a feeling that it will be more of a
> > source for error than a means for preventing errors... mostly because it
> > isn't always (often?) going to be apparent by looking at the build file
> > exactly what a property's type is.  I imagine this will lead to people
> > not using types because of the dangers of inappropriate implicit
> > conversion, or guarding against implicit conversion by extensively
> > (excessively) using explicit conversion.
>
> Property's type is always "string" unless specifically overriden. Simple.
> All implicit conversion will be disabled and will cause an error requiring
> you to fix your build file.
>
> > Notwithstanding, "it's possible to do it without breaking
> > compatibility"... you can't claim this if you are making a change that
> > turns a previously valid operation into an error!
>
> Yes, but there's been no stable release of NAnt + expressions. We've had a
> discussion with Gert some time ago and agreed we need to get rid of
> implicit conversions by the time 0.85 ships.

I still agree with this, but I'm not the only one to decide upon this
ofcourse ...

>
> > Having said the above, there is an alternative to disallowing implicit
> > type conversion (that unfortunately also breaks backwards compatibility)
> > that means that all implicit type conversions should be safe:
> > I've never been a particular fan of overloading the '+' operator with
> > string concatenation... if '+' only means addition, then it would always
> > involve numeric-conversion.

what about, for example, datetime values ?  we currently support the
additional of datetime and timespan values ...

> Because there is no implicit conversion
> > from boolean to integer, a boolean operand will cause an error.
> > Conversely if (for example) '|' means concatenation then it would always
> > involve (unambiguous) string-conversion.
>
> I like the idea. We could replace '+' with a '.' as it is used in PERL or
> PHP for example. Alternatively we could have string::concat(...) for this
> purpose but this would be too verbose.
>
> > Would just this last be enough type safety?  It still includes implicit
> > conversion from string to int/float, but in a (IMHO) safe fashion.
>
> After some thought, I give this idea (using concatenation operator other
> than a plus) +1. Gert, what do you think? This would solve 99% of all
> ambiguity problems without the need for typed properties.

Think I still need to give it some more thought ... I'm in "holiday" mode
today ;-)

Gert



---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers

Re: [nant-dev] Typed properties

[Jaroslaw Kowalski]

On Wed, 21 Jul 2004, Troy Laurin wrote:

> Jarek, others,
>
> I kind of like the idea of a property having a type, but I have a few
> questions regarding implementation...
>
> In the following...
>
> 
> 
>
> If the default type for properties if none is specified is 'string',
> then what is the type of 'a' after the two property assignments above?

The idea is that the type conversion occurs AFTER the value has been 
evaluated and BEFORE the value is stored. The destination type is "string" 
unless overriden by "type" attribute. This is what most people expect from 
assignment operation (in languages like C++, C#, Java ...)

> 
>
> Again, if the default property type is 'string', then what is the type
> of 'a' after this assignment?

"string"

HOWEVER: We could be smart (or dumb - pick one) by introducing the 
following rule: If the value of the property already has a type and 
 doesn't specify a type - use the resulting type. In this case 
the answer would be "integer". This can be confusing, though:

Some examples of inferenced types:

 -- type=string
 -- type=integer
 -- type=boolean
 -- type=string
 -- type=string
 -- type=string

> Regarding disallowing all implicit conversions in operators, I can see
> why you might want this, but I have a feeling that it will be more of a
> source for error than a means for preventing errors... mostly because it
> isn't always (often?) going to be apparent by looking at the build file
> exactly what a property's type is.  I imagine this will lead to people
> not using types because of the dangers of inappropriate implicit
> conversion, or guarding against implicit conversion by extensively
> (excessively) using explicit conversion.

Property's type is always "string" unless specifically overriden. Simple.
All implicit conversion will be disabled and will cause an error requiring 
you to fix your build file.

> Notwithstanding, "it's possible to do it without breaking
> compatibility"... you can't claim this if you are making a change that
> turns a previously valid operation into an error!

Yes, but there's been no stable release of NAnt + expressions. We've had a 
discussion with Gert some time ago and agreed we need to get rid of 
implicit conversions by the time 0.85 ships.

> Having said the above, there is an alternative to disallowing implicit
> type conversion (that unfortunately also breaks backwards compatibility)
> that means that all implicit type conversions should be safe:
> I've never been a particular fan of overloading the '+' operator with
> string concatenation... if '+' only means addition, then it would always
> involve numeric-conversion.  Because there is no implicit conversion
> from boolean to integer, a boolean operand will cause an error.
> Conversely if (for example) '|' means concatenation then it would always
> involve (unambiguous) string-conversion.

I like the idea. We could replace '+' with a '.' as it is used in PERL or 
PHP for example. Alternatively we could have string::concat(...) for this 
purpose but this would be too verbose.

> Would just this last be enough type safety?  It still includes implicit
> conversion from string to int/float, but in a (IMHO) safe fashion.

After some thought, I give this idea (using concatenation operator other 
than a plus) +1. Gert, what do you think? This would solve 99% of all 
ambiguity problems without the need for typed properties.

Jarek


---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers

RE: [nant-dev] XmlLogger is broken?

[Troy Laurin]

Gert,

thanks for that, I'll if removing the buffering from the logger affects
the build.

> I'll see if I can reproduce this later today ...
> 
> Gert

I just had a go at reproducing this using the script task logging in a
tight loop, and I couldn't get it to hang (39M log file).

I just looked in the xml log from last time it failed, and the last
thing in the log is a BuildException: External Program Failed:
C:\Program Files\GNU\WinCVS 1.3\CVSNT\cvs.exe (return code was 1)  This
message doesn't appear in the console, however (I'm using the default
logger, with an xml logger listener)... but it does kind of explain why
there is a log file at all.

In fact, every time the build has hung has been during an 'exec' task.
Although there doesn't seem to be anything wrong with the task (by)
itself... the build process completes perfectly if the xml logger is
removed as a listener.

I can't spend too much time on this just now, we have a release going
out the door next week, but I'll let you know if I find out any more
about this.


Regards,

-- Troy

Disclaimer Message:

This message contains confidential information and is intended only for the 
individual(s) named.  If you are not the named addressee you should not disseminate, 
distribute or copy this e-mail. Please immediately delete it and all copies of it from 
your system, destroy any hard copies of it, and notify the sender. E-mail transmission 
cannot be guaranteed to be secure or error-free as information could be intercepted, 
corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. To the 
maximum extent permitted by law, Immersive Technologies Pty. Ltd. does not accept 
liability for any errors or omissions in the contents of this message which arise as a 
result of e-mail transmission.


---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id040&op=click
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers