RE: [nant-dev] trycatch task ?... discussion of task communication
How about this stuff? I think that XML-based communication between tasks and the trycatch task have different purposes. Specifically, trycatch is a flow control device. Flow control can certainly be reproduced with increased task verbosity, but using a flow control device to describe flow conveys much more intent, which makes build files (IMHO) easier to read... or rather, easier to interpret correctly. Hmm. I think inter-task communication could be used for flow control as well. But no problem with trycatch task :) Currently there is resultproperty of exec task as only way to get result from any task (except of onfailure but it is not very useful on large build scripts). I think this should be enhanced to be able to read stdoutput/stderr for execed program and even more - number of compiled projects from solution etc. I hope something like this will get in 1.0 timeframe Martin --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] trycatch task ?... discussion of task communication
Hi, * Troy Laurin wrote on 13.07.2004 (09:24): Sascha Andres wrote: Added above line. Deleted too much, and don't wanted to use undo after I wrote all of the text ;) can be accessed from all tasks. The last function adds a protected object to the store only readable from a task of the same type. The protected Load operations would work analog to this. The idea of protected data items sounds interesting, but could it be implemented without extending Project, just through static properties in the task class? What do public data items offer that can't be done with properties? Would it be better (or is it equivalent?) to implement references, similar to Ant? Just short, cause I'm on my way to work: I think there should be a difference between public data and properties. Public data would be part of the communication, the other is generally part of the build file, used to control how the build is done. The risk overwriting a user property and what may result (broken build, hard build file debugging) led me to propose public data seperated from properties. A few words to persistence. Imagine two more overloads, that indicate using a boolean variable if an object should be persistent. When a data store property on the project is set, a datastore with all variables marked persistent will be saved to the given file (and loaded at the beginning of the next run). Just a comment on overloads: They're generally evil. If two methods do different things, they should have different names. Compile errors are preferable to strange program behaviour if you call a method incorrectly. I agreee that there is potential for wrong calls. I don't have a problem splitting it into Save, SaveProtected, SavePersistent and the respective Load methods. Perhaps something like Protected.Save Public.Save Persistent.Save Whether storing xml or storing objects, I'm a little wary about the idea of adding magic communication to a build system. It feels too much like accessing the internal API of a system. If one task relies on the output of another task to be in a particular format, then there's usually a good chance that the task will break if the other task changes its output format. You're right on this point. But using a tasks output is a risk. And changing a tasks output should occur only in beta and / or a major release change. A communication system would be most helpful when there is a large number of user defined tasks - where you could use public and/or protected information. The magic may be useful for debugging issues (a crash in the csc task that occurs only from time to time). -sa -- sa at programmers-world dot com http://www.livingit.de Internet sites: http://www.not2long.net - Make long links short Boomarks online: http://www.mobile-bookmarks.info --- 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] trycatch task ?... discussion of task communication
Comments inline... -T -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sascha Andres When I think a bit more of sharing information throughout tasks I come to these points: In a programming language, data can be: * private * public * protected * static and with a bit more work * persistent IMO there is no situation where I can think of a need for 'declaring' something static in NAnt if there would be task communication[1]. Correct me if you can imagine. How about introducing a 'DataStore' that is working comparable to the properties: this.Project.DataStore.Save(object); this.Project.DataStore.Save(name, object); this.Project.DataStore.Save(name, object, type); First function would be the magic variable. If set in a task, this value remains. If not set, the output of the task could be written to this special variable. So a load operation always refers to the task running before. Second function would lay an object in the data store with a key so it can be accessed from all tasks. The last function adds a protected object to the store only readable from a task of the same type. The protected Load operations would work analog to this. The idea of protected data items sounds interesting, but could it be implemented without extending Project, just through static properties in the task class? What do public data items offer that can't be done with properties? Would it be better (or is it equivalent?) to implement references, similar to Ant? A few words to persistence. Imagine two more overloads, that indicate using a boolean variable if an object should be persistent. When a data store property on the project is set, a datastore with all variables marked persistent will be saved to the given file (and loaded at the beginning of the next run). Just a comment on overloads: They're generally evil. If two methods do different things, they should have different names. Compile errors are preferable to strange program behaviour if you call a method incorrectly. [From a previous post] I don't like the we-do-anything-in-xml approach. XML is a nice thing, but it certainly adds some overhead to communications. I would prefer an invisible property system based on keys. This would allow to store informations in one task and to read it in another one, without dealing with properties set by the user. Whether storing xml or storing objects, I'm a little wary about the idea of adding magic communication to a build system. It feels too much like accessing the internal API of a system. If one task relies on the output of another task to be in a particular format, then there's usually a good chance that the task will break if the other task changes its output format. -T 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 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] trycatch task ?... discussion of task communication
Martin, just read through your previous thread. I think that XML-based communication between tasks and the trycatch task have different purposes. Specifically, trycatch is a flow control device. Flow control can certainly be reproduced with increased task verbosity, but using a flow control device to describe flow conveys much more intent, which makes build files (IMHO) easier to read... or rather, easier to interpret correctly. I'm not sure how much I agree with xml output for tasks. I can see how it would be useful in theory for chaining together tasks with strong dependencies... but in practice, if a particular task is so dependent on the output of another task, then why doesn't it extend (or compose) the other task. This allows the task to communicate with its predecessor in the trivial way, through object properties and method calls, without having to modify how NAnt works. The best example I have of this concept is the solution task. All of the tools and tasks (more or less) required to simulate the solution task are available... they could be extended with verbose outputs to allow chaining them together, but it is much more useful as a single task, which composes its required tasks and facilitates communication between the tasks. Perhaps the problem is just that I can't think of an example for which verbose inter-task communication would be a good fit. Do you have an example that is more extensive than the exec example that you can share? Regards, -- Troy -Original Message- From: Martin Aliger [mailto:[EMAIL PROTECTED] Sent: Friday, 9 July 2004 2:40 PM To: Gert Driesen; Troy Laurin; Nant-Developers (E-Mail) Subject: Re: [nant-dev] trycatch task ? I think both are cases of inter-task communication. IMO current nant is totally missing such communication. errorproperty proposal is very limited implementation of such communication. I'd rather prefer making something more robust enabling more advanced scenarios like examining what failed or what was skipped (mainly in complex tasks like solution) etc. Some time ago I propose XML-like based communication - maybe its time comes? How do you see it now when there was enough time to consider it? trycatch task is also good addition in mine eyes. I personally dont see anything bad in implementing both - trycatch and some kinf of communication in the same time. Different scenarios should use different approaches Regards, Martin 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 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] trycatch task ?... discussion of task communication
Hi again, Some time ago I propose XML-like based communication - maybe its time comes? How do you see it now when there was enough time to consider it? I don't like the we-do-anything-in-xml approach. XML is a nice thing, but it certainly adds some overhead to communications. I would prefer an invisible property system based on keys. This would allow to store informations in one task and to read it in another one, without dealing with properties set by the user. I'm in no way xml guy. XML is nice thing for some purpose but definitely not usable for everything. What I propose is to introduce _some_ system how to pass information from one task to other. Since speed is not main interest in automated builds (sorry Matt - I still appreciate your optimization work!) XML should be straightforward solution. But I never think we will serialize XML on every task. XML hierarchy is pretty efficiently stored in memory like object tree and that should be enough (what is exactly what you propose, isn't it?) --- Perhaps the problem is just that I can't think of an example for which verbose inter-task communication would be a good fit. Do you have an example that is more extensive than the exec example that you can share? More complex example? Ok here is one from mine real needs: I have solution without .sln file but I include fileset of projects. But compilation itself is only small part of every complex build. I need to check,sign,ftp,copy,... builded assemblies. If one of those assemblies failed to compile, whole solution failed and now I'm forced to scan directory what is builded to know what I have to process further. And I'm totally short to make some meaningful error log in such case. If solution have ability to construct some result block I could parse it and construct result-fileset as well as error-log and whatever information I need. E.g. (in xml syntax) it could return: solution-result projects errorproperty value=true/ project name=prj1 status=successful output=prj1.dll/ project name=prj2 status=successful output=prj2.exe warnings=2 / project name=prj3 status=error warnings=5 errors=1 error class=Bar file=foo1.cs line=15 text=class Xyz not found/ /project project name=prj4 status=skipped text=skipped because of dependancy on failed project prj3/ /projects /solution-result Having that one could easily condition other tasks with if+xmlpeek. --- dependencies... but in practice, if a particular task is so dependent on the output of another task, then why doesn't it extend (or compose) the other task. This allows the task to communicate with its predecessor in the trivial way, through object properties and method calls, without having to modify how NAnt works. True. But why contruct some task for everything? This is case of solution or even csc (which calls resgen) and it is ok. I do not want to call every task myself - solution is great! On the other hand I do not want to write task for every one time stuff. Regards, Martin --- 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] trycatch task ?... discussion of task communication
Hi, * Martin Aliger wrote on 09.07.2004 (13:43): to pass information from one task to other. Since speed is not main interest in automated builds (sorry Matt - I still appreciate your optimization work!) XML should be straightforward solution. But I never think we will serialize XML on every task. XML hierarchy is pretty efficiently stored in memory like object tree and that should be enough (what is exactly what you propose, isn't it?) Task communication is no more than sharing information in the mean of a variable all tasks can read (or a memory location with XML or what-ever in it). When I think a bit more of sharing information throughout tasks I come to these points: In a programming language, data can be: * private * public * protected * static and with a bit more work * persistent IMO there is no situation where I can think of a need for 'declaring' something static in NAnt if there would be task communication[1]. Correct me if you can imagine. IMHO private data is always task-instance specific and doesn't need to be tracked by a NAnt wide communication system. Public data can be shared with other tasks without restrictions. Protected data can only be accessed by tasks of the same type (like my stopwatch task). I'll focus on persistent data later. How about introducing a 'DataStore' that is working comparable to the properties: this.Project.DataStore.Save(object); this.Project.DataStore.Save(name, object); this.Project.DataStore.Save(name, object, type); First function would be the magic variable. If set in a task, this value remains. If not set, the output of the task could be written to this special variable. So a load operation always refers to the task running before. Second function would lay an object in the data store with a key so it can be accessed from all tasks. The last function adds a protected object to the store only readable from a task of the same type. The protected Load operations would work analog to this. A few words to persistence. Imagine two more overloads, that indicate using a boolean variable if an object should be persistent. When a data store property on the project is set, a datastore with all variables marked persistent will be saved to the given file (and loaded at the beginning of the next run). Personally I would restrict the use of persistent data to objects that are serializable for the sake of easy save and restore. In a first version I would try a datastore based on hashtables. But that's a step further. And after a second thought there are some things certainly coming up if task communication is possible: * How can I list all key / value combinations in the datastore? * Can there be persitence over the bounds of a buildfile? * Can I persist data only accessible to one specific task-instance? The persistence feature is certainly very interesting, but would definitly lead to much more possible complexity in both the build files and the tasks. This should be taken into account. Nevertheless I would call me a supporter for the idea of communication as it would have been great if I could have used this in my own version task and probably the stopwatch task. And to close the run with XML: If a task lays XML to the store or not would be up to the tasks author. In some cases this is a nice, straightforward way to organize information, in others not. Who cares if you can use the store for all kind of objects? -sa [1] This is IMHO true as long as NAnt doesn't use a high level language to write buildfiles ;) -- sa at programmers-world dot com http://www.livingit.de Internet sites: http://www.not2long.net - Make long links short Boomarks online: http://www.mobile-bookmarks.info --- 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
