Re: [nant-dev] Fileset scanning speed-ups in CVS
Good work. That is one that needed to be optimized :) Do you have profiler stats/results on other most called, or time most spent in, functions? It would be good to list them so anyone out there could step up to challenge themselves with optimizing those functions. Just an idea... - Original Message - From: "Matthew Mastracci" <[EMAIL PROTECTED]> > I just checked in a change to fileset scanning that eliminates a large > chunk of time (checked via profiling) during many of the common NAnt > operations. > > One of the biggest losers on the profiling run was Regex.Match(), called > many, many times during a build. The new code replaces a good > proportion of these with CompareInfo.Compare() calls, reducing the > overhead dramatically. > > Instead of converting all includes to regexes, the new code > will only convert those that actually contain wildcards. --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] expression support -> null's
I like the null literal more than a is-null() function.
- Original Message -
From: "Jaroslaw Kowalski" <[EMAIL PROTECTED]>
> We can have a null literal and overload comparisons for equality and
> inequality:
>
> if test="${property::get-value(...) != null}" />
>
> This would make 3 literals: true, false, null
---
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] Re: [nant-dev][Nant-users] deprecation of built-in properties
Yep, I would agree that functions are a more powerful way to express these properties. We have talked about this for a while. But I would like to depreciate these over a few builds before actually remove them completely. This will cause some serious problems with peoples' build files (and projects that ship build files). We should offer an easy suggestion to run with them until the user can remove them from the build file. Maybe they can just include a buildfile that creates these properties, that is included at the top of their build file. We could even ship such a depreciated-properties.xml buildfile with the dist so people can easily find the transition statements to get to those old properties. I know this just lengthens the time we effectively support these properties, but it seems like a much better solution for the end user. What do you think? Plus, there is something to documenting the old properties, and their values. - Original Message - From: "Gert Driesen" <[EMAIL PROTECTED]> > Hi, > > I'd like to propose deprecating the following built-in properties in favor > of their corresponding functions : > > nant.filename > nant.version > nant.location > nant.project.name > nant.project.buildfile > nant.project.default > nant.platform > nant.platform.win32 > nant.platform.unix > nant.settings.currentframework.description > nant.settings.currentframework.frameworkdirectory > nant.settings.currentframework.sdkdirectory > nant.settings.currentframework.frameworkassemblydirectory > nant.settings.currentframework.runtimeengine > nant.tasks.* > > so that would mean we'd end up having the following not-deprecated built-in > properties : > > nant.project.basedir > nant.onsuccess > nant.onfailure > nant.settings.currentframework > > (although it would be good to at least get rid of the last one too) > > Ofcourse, we'll need to provide decent warning messages to users, and direct > them to the function(s) corresponding to a given property. > > What do you think ? --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] fileset deprecations
+1 on co-existence, of include+includes, for a release or two, but totally removal by 1.0. As for the "strict" enforcement of only declared elements and properties for tasks/types, I had done some work on that a long time ago. Take a look at the Element.AttributeConfigurator.InitilizeElement() code at the end of the method. You will see a section that say "#region Check Tracking Collections for Attribute and Element use" that emits the warnings. You could change those to fail with a switch. But I would suggest that you go through and run a lot of tests before you do this. There are still some tasks/types that correctly do their own process that this method may flag as errors. As I remember. I went through a cleanup a lot of them a year ago, but much has changed since then. For now, you can run with warnings logged and see what is caught. > From: "Clayton Harbour" [EMAIL PROTECTED] > Hi, > > > the naming is clearer I suppose but there is a certain amount of > > > inertia > > > - there are a lot of build files out there wil the current naming. > > > > I know, that why I'm asking ... we'll see how others respond > > ... we could ofcourse have both of them coexist, and then > > deprecate includes/excludes later ... > > I would prefer it if the two co-existed for a release (or two even), > with the element deprecated (and warnings during the build > process). It gives people fair enough warning before their build files > stop working. > > Also, there was also talk about adding a "strict" switch to the > commandline awhile back which. This might be a good notification > feature when this goes away. Has anyone done any work on this? I could > probably take a stab at it if someone gave me a high level on the > project load process. --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] Fileset include required WAS: problem with ASIS attribute on source file list in CSC task
Yeah, now the only problems is to implement it. :) (remember, it needs to efficient too) We are accepting patches on this one! Will someone step up to the plate? I've moved this into the dev list. - Original Message - From: "Hearn, Bruce" <[EMAIL PROTECTED]> > Scott, > > I think you nailed it. The addition of a "failonmissing" attribute > would be quite helpful. > > If you try to build using the VS.NET IDE, the build will fail if a file > is missing. In an automated build process I want to be able to > implement the same behavior. This allows the build to be more > consistent between the IDE and NANT. I've seen from practice that when > there are subtle differences between 2 build environments, many hours > can be lost in tracking down an issue. > > Thanks, > > Bruce > > -Original Message- > From: Scott Hernandez [mailto:[EMAIL PROTECTED] > Sent: Saturday, May 01, 2004 11:15 AM > To: Gert Driesen > Cc: Hearn, Bruce; [EMAIL PROTECTED] > Subject: Re: [Nant-users] RE: problem with ASIS attribute on source file > list in CSC task > > It would definitely be a nice feature to say that a certain > is > required and should throw an error if no match on the filesystem is > found. > But no, this should not be the default behavior. The problem in the past > has > been with wildcard expressions and the fileset implementation not easily > allowing for a check that a wildcard statement results in filesystem > hit. > Adding the 'failonempty' attribute to the seems like a > stop-gap > measure to ensure this kind of checking. > > I think this is where Bruce is coming from. Bruce? > > Here is an example: > > > > > > > > > - Original Message - > From: "Gert Driesen" <[EMAIL PROTECTED]> > > > - Original Message - > > > From: "Hearn, Bruce" <[EMAIL PROTECTED]> > > > Hi Gert, > > > a) if a non-existent file is included in the source list, it > compiles > > > anyway without error or warning. > > > > The sources to compile are specific using a fileset, which actually > uses > > pattern matching and scanning to determine the matching files. A file > that > > doesn't exist will therefor not be part of the resulting matches. I > don't > > think we will be changing this. Ian, Scott : what do you think ? > Should > we > > throw a build error when the includes name does not contain a wildcard > > pattern, and does not exist ? --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Windows setup contribution
Yes, for a release we should not dist the pdb files. What is the NAnt SDK? Would that include the parts of the source tree that aren't needed at runtime unless you are building nant? I would assume this would include anything needed to build tasks, functions, or extensions. An example would be the NAnt-NDoc documenters, right? - Original Message - From: "Jaroslaw Kowalski" <[EMAIL PROTECTED]> To: "Nicklas Norling" <[EMAIL PROTECTED]>; "Nant-Developers (E-mail)" <[EMAIL PROTECTED]> Sent: Tuesday, March 23, 2004 9:29 AM Subject: Re: [nant-dev] Windows setup contribution > Very nice installer! > > I have some ideas for 1.0 release and I wonder if they can all be > implemented with this tool: > > 1. Binaries should go to "Program Files\NAnt\bin" and should include *.exe, > *.dll but no *.xml (at least not by default) > > 2. I wonder if we could get rid of the *.pdb since they occupy about 50% of > all space used. > > 3. We should include the documentation. I think that "doc/help/**/*" is > enough. The docs should be either plain *.html or *.chm compressed files > (which I personally prefer). PDF would be nice as an option, too because > it's easy to print as a reference. > > 4. We should also include the SDK docs as an option. > > 5. We should register ourselves in the registry in some versioning-aware > manner so that various tools (like NAntMenu or editor integrations) can > locate NAnt executables or config file. > > 6. I think that the final executable of the installer should be below 1 MB > in size. Having a huge build tool scares many people. If needed, we could > make some parts not usually needed (like the SDK docs, PDB symbols, source > code) available as separate downloads. > > 7. Should we register Nant SDK components in AssemblyFolders so that they > are easily referenceable in VS.NET ? Unfortunately this would clash with > log4net.dll, NUnit.Framework.dll and other components that also register > themselves this way. > > 8. We should somehow detect alternative CLIs (Mono, Rotor, .NETCF, DotGNU) > and modify NAnt.config file accordingly to make NAnt find them. Should they > be installed in some non-standard place, we'd allow the user to browse for > the appropriate paths. > > 9. Should we include some GUI (shell integration, VS.NET integration) in the > 1.0 release? > > Offtopic: > > 1. We should do something about the linux installation really soon. I've > heard voices that "NAnt is very complicated to install on Linux because you > cannot do ./configure --prefix=... && make && make install". Maybe a simple > configure script that would setup the mono paths in the config file would > do? > > Awaiting your comments. > > Jarek > > - Original Message - > From: "Nicklas Norling" <[EMAIL PROTECTED]> > To: "Nant-Developers (E-mail)" <[EMAIL PROTECTED]> > Sent: Tuesday, March 23, 2004 4:10 PM > Subject: [nant-dev] Windows setup contribution > > > > Hi all. > > > > I always package up NAnt in a setup for my developers so I thought > > I could as well contribute the iss script file I use in case there are > more > > out there that would like it. > > > > It uses InnoSetup 4.2.0 http://www.jrsoftware.org/isdl.php which is a > totaly > > free and awsome setup tool. > > > > The iss file is designed to be in the root or the release togther with > > the NAnt.sln file. From there is will zipp up .\bin\*. > > > > During install it installs this in a directory, optionally adds a program > > group and leaves standard uninstall entry in add/remove programs. > > > > It does not currently alter the PATH variable, but I hope to find some > free > > prog that will do that. > > > > The installer file will be called NAntInstaller.exe and will be placed at > > the root of the release. > > > > I added licence file reference and copyrights as best I could. Hope I got > it > > right. > > > > /Nicke > > > > > > > > --- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > ___ > nant-developers mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/nant-developers > > --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Windows setup contribution
http://www.jrsoftware.org/isfaq.php has a section on changing environment variables (like the path). Would anyone like to volunteer to create a wrapper task for innosetup? We already have one for an MSI installer in NAntContrib. We also have a setup target that creates an msi installer (creating features for NAnt and NAntContrib). The biggest problem there is the requirements for running the msi task. It is not a trivial thing as you need to have the installer SDK and a few other things. But this is true with the chm creation needing the help 2 sdk also. - Original Message - From: "Nicklas Norling" <[EMAIL PROTECTED]> > Hi all. > > I always package up NAnt in a setup for my developers so I thought > I could as well contribute the iss script file I use in case there are more > out there that would like it. > > It uses InnoSetup 4.2.0 http://www.jrsoftware.org/isdl.php which is a totaly > free and awsome setup tool. > > The iss file is designed to be in the root or the release togther with > the NAnt.sln file. From there is will zipp up .\bin\*. > > During install it installs this in a directory, optionally adds a program > group and leaves standard uninstall entry in add/remove programs. > > It does not currently alter the PATH variable, but I hope to find some free > prog that will do that. > > The installer file will be called NAntInstaller.exe and will be placed at > the root of the release. > > I added licence file reference and copyrights as best I could. Hope I got it > right. > > /Nicke --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] cvs.exe - bad naming
Why do we need the managed executable (?) and the managed dll? If this is a win32 only binary, I would rather not see it in our dist. - Original Message - From: "Clayton Harbour" <[EMAIL PROTECTED]> To: "Gert Driesen" <[EMAIL PROTECTED]>; "Simon Steele" <[EMAIL PROTECTED]>; "Nantdev" <[EMAIL PROTECTED]> Sent: Monday, March 22, 2004 7:11 PM Subject: RE: [nant-dev] cvs.exe - bad naming > Hi Gert and Simon, > > I would prefer to just change the name of the sharpcvslib binary and > leave it in the NAnt repository as it means the basic cvs commands work > out of the box in a situation where there isn't a cvs binary installed > (i.e. on a build server). It also makes it easier for me to keep track > of versions (I deploy the .dll and .exe in one go), and the client does > not take up a lot of space. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Remove support for WebDAV from task ?
+1 on WebDAV tasks. This is something that will be more and more useful in the future. It sounds like a lot of new server projects are providing webdav file access. In fact, I believe one of the deployment options for Subversion is via webdav. This would really simplify the requirements to do a get, update, or commit. :) Maybe with a set of WebDAV tasks it would be possible to do better testing and integration into the solution/project tasks at a later time, if it is pulled now. - Original Message - From: "Jaroslaw Kowalski" <[EMAIL PROTECTED]> > Perhaps we could have a task instead that would be similar to > but accept WebDAV sources/targets. > > +1 for the idea of removing WebDAV from the task. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: PATCH: file::exists() wildcard support, WAS: Re: [nant-dev] 2 small changes to consider
Yeah, I'm sure we all go back and forward on this issue. Performance is
important, and we should strive towards it, but I have found that sometimes
what seems like a performance tweak turns out to not work out as I expect.
I'm sure the scanner is slower than file.exists, but in this case I would
lean towards less code paths, and leave the performance issues till we start
to see a problem. Profiling nant will most likely result in all kinds of hot
spots. If this is an issue, changing it will be important. It may even be
that we tune the scanner to check for the special case of a file without any
wildcards, then the overhead is just a few objects and a virtual method
calls, as compared to just the file.exists call. I'm sure the slowest part
of all this, by far, is the io operation to check for the file.
This is really more of a general question as to whether we should code for
less code paths (simpler code?) or try to write with performance in mind.
I'm leaning towards less code paths... :)
What do others think?
- Original Message -
From: "Jaroslaw Kowalski" <[EMAIL PROTECTED]>
To: "Scott Hernandez" <[EMAIL PROTECTED]>; "Hemry, Jeff"
<[EMAIL PROTECTED]>
Cc: "! nant" <[EMAIL PROTECTED]>
Sent: Friday, February 27, 2004 11:30 AM
Subject: Re: PATCH: file::exists() wildcard support, WAS: Re: [nant-dev] 2
small changes to consider
> Speed? Of course it's possible to always use the scanner and I can change
> it.
>
> Jarek
> - Original Message -
> From: "Scott Hernandez" <[EMAIL PROTECTED]>
> To: "Jaroslaw Kowalski" <[EMAIL PROTECTED]>; "Hemry, Jeff"
> <[EMAIL PROTECTED]>
> Cc: "! nant" <[EMAIL PROTECTED]>
> Sent: Friday, February 27, 2004 8:27 PM
> Subject: Re: PATCH: file::exists() wildcard support, WAS: Re: [nant-dev] 2
> small changes to consider
>
>
> >
> > Is there any reason that you don't always use the scanner?
> >
> > if (file.IndexOf("*") != -1 || file.IndexOf("?") != -1) {
> > ...
> > } else
> > return File.Exists(Project.GetFullPath(file));
> >
> > Less code paths, etc... :)
> >
> > - Original Message -
> > From: "Jaroslaw Kowalski" <[EMAIL PROTECTED]>
> > To: "Hemry, Jeff" <[EMAIL PROTECTED]>; "! nant"
> > <[EMAIL PROTECTED]>
> > Sent: Friday, February 27, 2004 11:13 AM
> > Subject: PATCH: file::exists() wildcard support, WAS: Re: [nant-dev] 2
> small
> > changes to consider
> >
> >
> > > This patch adds wildcard support to file::exists(). Basically it uses
> > > DirectoryScanner to find matching files.
> > >
> > > Is it ok to commit it ?
> > >
> > > Jarek
> > >
> >
>
>
---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: PATCH: file::exists() wildcard support, WAS: Re: [nant-dev] 2 small changes to consider
Is there any reason that you don't always use the scanner?
if (file.IndexOf("*") != -1 || file.IndexOf("?") != -1) {
...
} else
return File.Exists(Project.GetFullPath(file));
Less code paths, etc... :)
- Original Message -
From: "Jaroslaw Kowalski" <[EMAIL PROTECTED]>
To: "Hemry, Jeff" <[EMAIL PROTECTED]>; "! nant"
<[EMAIL PROTECTED]>
Sent: Friday, February 27, 2004 11:13 AM
Subject: PATCH: file::exists() wildcard support, WAS: Re: [nant-dev] 2 small
changes to consider
> This patch adds wildcard support to file::exists(). Basically it uses
> DirectoryScanner to find matching files.
>
> Is it ok to commit it ?
>
> Jarek
>
---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Addition documentation (+/-)?
Also, the Wiki is a great place for this type of info; it can be updated by users directly. :) http://nant.sf.net/wiki - Original Message - From: "Gert Driesen" <[EMAIL PROTECTED]> > Perhaps first post it to the list for review, is that ok for you ? > - Original Message - > From: "Mitch Denny" <[EMAIL PROTECTED]> > Gert suggested that we start to add references to third party > tasks/resources. I've got some doco to commit which is a start. Can I > get a green light to commit that (+/-)? --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Experimental branches . . .
The nightly snapshot is now a nightly build; it just builds from the head. We used to have a nightly tarball but replaced it when we started using a build server. For the purpose of your branch I think it might be best if you get cvs access so you can manage it. Mitch, is that something you are up for? Gert, Ian, Gerry, does that sound reasonable? I'd rather take the enabling approach than to put more levels of indirection in... :) - Original Message - From: "Mitch Denny" <[EMAIL PROTECTED]> To: "Scott Hernandez" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, January 26, 2004 6:19 AM Subject: RE: [nant-dev] Experimental branches . . . > Hi Scott, > > Good idea about the zip. Does the nightly snapshot just take the HEAD? > > Follow-up Questions: > > 1. Who can do the branch for me? > 2. When I finish patches, who do I send them to? --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Experimental branches . . .
+1 As far as I understand it, branching is done from the head (or any tag I guess). As for blogging, go for it. Posting to the dev list is probably also a good idea. Anon CVS access is rather behind, and less reliable. It may make sense to post on your website a zip of the tree/dist when you want people to try it out. - Original Message - From: "Mitch Denny" <[EMAIL PROTECTED]> > Hi folks, > > We'll I think we have had the discussion, so I thought it would be an > appropraite time to tag and branch for some of the experimental stuff > that we have been talking about. I'd like to start experimenting more > publically with the element first. > > If possible I'd like the branch done from the head and not the previous > tag since there have been a number of fixes since then that specifically > affect the ability to do a successful build. > > Once I had something working and a patch applied I was hoping to do a > blog post and get a bit of end-user feedback on the idea. I know a lot > of Nant users are into blogs so I thought it would be a good outlet. > > They would be able to anon cvs download from that branch and try it out. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Property Scoping
I think we had talked about this before and just didn't flush it out enough. If I remember correctly we were in support of it. I'd like to see some more discussion about it, and the consequences, before we move forward, but I'd give it a tentative +!. It definitely fits in with a typed expression engine... :) - Original Message - From: "Jaroslaw Kowalski" <[EMAIL PROTECTED]> > > Yeah, I was considering the same thing. I also wondered whether this > > could mean that there could be a unified type system. Filesets, string > > properties etc. > > You mean storing a fileset inside a property? Interesting idea. > > Gert, Ian, Scott - what do you think about typed properties? > > Jarek --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Property Scoping
Seems like the "flow" scope should be called "local" in C#/programming terms, and local would be private/container-only scoping. Having "global" be the default is a good call, but only in come case, as you have identified in //etc. I'm sure we will be able to say more with a patch; so we can test things out. If the changes are small enough, and defaults don't change existing functionality, I'm happy to put them in the head since we are still a little while from testing/beta'n this version. I'd be inclined to separate the two patches, one for scoped properties (which are core changes) and one for the new task def stuff. - Original Message - From: "Mitch Denny" <[EMAIL PROTECTED]> > Hi folks, > > OK, I've got a bit of a prototype working for property scoping which so > far appears to be non-breaking to existing scripts. It works like this: > > > > Global is actually the default. If I had this: > > > > It would mean that the property is accessible to all things in the > current scope where a scope is defined by the current target (project > for root level tasks) or TaskContainer. So this would cause an error in > the expression evaluator: > > > > > > > > Because x is not accessible outside of the scope defined by the if task > container. This works with my earlier taskdef work too! Interestingly > the following won't work. > > > > > > > > > Because local is local to the current task container. I introduced a > third accessibility level called Flow which allows this to work. > Remember that the default is Global when you are using the > task, so it won't break anything. The way it works is that I have lots > of PropertyDictionary objects attached to a hierarchy of Scope objects. > The scope is updated when ever a build/target/task container starts or > finishes. > > I also modified quite a bit of the implementation of PropertyDictionary > so that it now stores a Property object as its value although the > external interface is unaffected (cross fingers I didn't break > anything). > > Now that I have done this, and if there is enough interest I'd like to > propose that we do something like has been done for expression > evaluation, take a branch and do some exploritory work on this where > this = and property scoping. > > Can I get a +1 or -1? --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev]
Having support for our own FileInfo+URI object could be useful. This would support either relative file paths, or uris. It would resolve them and provide useful information if there were errors. We already do this in places, and having this code in one place where tasks could use it would be a plus. We have a more than a few tasks that can accept either a filepath or uri, and will probably have more in the future. Leaving validation to the xslt classes is fine, but will still require some type of logic to convert relative file paths. - Original Message - From: "Ian MacLean" <[EMAIL PROTECTED]> [snip] > >However, it should be perfectly possible to also support the System.Uri > >class as a special property type in NAnt and also construct a URI referring > >to a full path relative to the project base dir if the value of the > >attribute is not a value URI. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev]
+1 on URI backed properties. Can we also do a FileInfo_Or_URI setter too (I'm not sure how this would work...)? In some cases it is an "or" option. - Original Message - From: "Gert Driesen" <[EMAIL PROTECTED]> > Ian, [snip] > > Let me know if you'd want me to add support for properties backed by a Uri > type (regardless of whether you'll use it for the
Re: [nant-dev] ?
Nested expression support sounds like a must, no? Somehow I thought our expression engine already supported this. - Original Message - From: "Jaroslaw Kowalski" <[EMAIL PROTECTED]> [snip] > BTW. Gert, what do you think about allowing sub-expression evaluation in > strings so that we could write: > > > > > Jarek --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Filterchains?
I hope so Nick. This is still on the list, but as we are a collection of individual developers, each with our own interests, it sometimes turns out that one of those individuals can re-focus the direction of the group. I think all it would take to get filterchains going is for someone to put together a path for this feature. I'm sure it would get its fair share of excitement. I just wish that dev could be me right now. But that is a general wish for a lot of things. (short wistful glance to the greenery outside,... and ...back to email!) - Original Message - From: "Nick Varacalli" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, January 07, 2004 8:18 PM Subject: [nant-dev] Filterchains? > Are filterchains going to be implemented in .85, or is the excitement about > functions overwhelming them? > > Nick > http://www.varacalli.com > > > > --- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > ___ > nant-developers mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/nant-developers > > --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Nightly builds
Yes, we really need to get a version task working for our build files so that the date/version is generated correctly. This is a must before any .85 beta. - Original Message - From: "Nicklas Norling" <[EMAIL PROTECTED]> > Hmm, that's no good. In my world it's better with no version at all then > wrong version. > It's giving me a lot of headache as I can't know, or prove what version I'm > using. Nor can > I distribute this to my team as I can not later on know weather or not they > have upgraded > or not. > It ought to also give this list problems knowing what version was used. > I suggest that the version information is removed until a "fool proof" way > of keeping it > up to date is devised. > > I hope Clayton believes me when I assure him I am using the latest version --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Re: Inter-Task XML Communication (WAS: new xml type)
Yep, I expect that the XPathObjectNavigator needs a good deal of work before we can use it. See this message for my ideas of what needs to be done. http://sourceforge.net/mailarchive/forum.php?thread_id=3707522&forum_id=32775 Plus I'm sure there are many bugs that needs to be fixed and unit test that need to be written. I'm hoping to spend a day or two next week getting things into shape, and hopefully after that creating a new sf.net project for it. Any help would be greatly appreciated :) - Original Message - From: "Martin Aliger" <[EMAIL PROTECTED]> To: "Ian MacLean" <[EMAIL PROTECTED]>; "Matthew Mastracci" <[EMAIL PROTECTED]> Cc: "Scott Hernandez" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, January 08, 2004 6:41 AM Subject: Re: [nant-dev] Re: Inter-Task XML Communication (WAS: new xml type) > Hi all, > > I successfully include XPathObjectNavigator from Bamboo.Prevalence. > > Script like this: > > > > > > > now correctly writes: > [exec] foo.exe 1 2 3 > E:\src\extern\nant\test2\test.build(21,3): External Program Failed: foo.exe > (return code was 2) > [echo] 2 > > What is not so nice is: > > 1/ Bamboo makes object names from hierarichy based on their names. In NAnt > we use custom attributes to customize names > 2/ We could want to hide some names from result (or all public is ok?) > 3/ Badly formed xpath do not throws exception but rather returns string > "NAnt.Core.Tasks.ExecTask". > 4/ Collections returned via xpath (e.g. "/ExecTask/Environment") returns as > "NAnt.Core.Types.OptionCollection". Not very useful... > > Maybe, I'm doing something wrong with Bamboo... > > Attached are patched to NAnt sources + zip with needed Bamboo.Prevalence > sources. > Sources are alot simlyfied now (e.g. only one result element) and no fail > checks yet. It is meant just to test this approach. --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] DependsTask Patch (fix)
James, I've made a few changes (please let me know if it still works for you) and committed it to NAntContrib. Would you like cvs write access to NAntContrib repository on sf.net? :) If so, just send me your sf.net userid. Thanks for the work :) - Original Message - From: "James C. Papp" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, January 07, 2004 3:08 PM Subject: Re: [nant-dev] DependsTask Patch (fix) > I've finally made it into the office today and was able to test out the quick > changes I made. I fixed a missing attribute and missing #endregion directive > (this is the version without the dynamic attribute). > > BTW, thanks for taking the time to looks at this stuff - I really appreciate it. --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] filesets
From: "Martin Aliger" <[EMAIL PROTECTED]> [snip] > > BTW. How to copy the fileset and store it with a different name? > Good point I thinks it is currently impossible... Any proposals? If it has an "id" it is definition. If it has a "refid" it uses a def to work from. Isn't this how it was defined to work before? So, --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] custom functions with the script task
I'd lean the other way and require that the script be basically a full
namespace/class def. (or no function decl. at all).
namespace test {
[FunctionSet("test", "Test")]
class myFuncs : FunctionSetBase {
[Function("test-func")]
public string Testfunc( ) {
return "some result ";
}}}
or
return "some result ";
Then all of the scripts could be combined for a
project, or you could define many functions and classes all in the same
.
- Original Message -
From: "Jaroslaw Kowalski" <[EMAIL PROTECTED]>
To: "Ian MacLean" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Wednesday, January 07, 2004 7:45 AM
Subject: Re: [nant-dev] custom functions with the script task
> Nice.
>
> I also though about it some time ago. Wouldn't it be cleaner to write it
> like the following?
>
>
> [Function("test-func")]
> public string Testfunc( ) {
> return "some result ";
> }
>
>
> Most parts of the script code are constant, anyway. The parts could be
added
> automatically by the task.
> I also think that we shouldn't require the user to provide "Function"
> attributes here. We'd just take all public functions and add them to the
> TypeFactory. [Function] could be used to override the default name here.
>
> Jarek
>
> - Original Message -
> From: "Ian MacLean" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, January 07, 2004 4:31 PM
> Subject: [nant-dev] custom functions with the script task
>
>
> > I just committed a small change to ScriptTask to allow the definition of
> > custom functions inside a