Filter for side effects

Any chance of being able to filter the build log to only show actions that have side effects? I’ve got some pretty complicated file parsing logic, and it takes a long time to go through the log and see what actually happens after all that. 2000 actions can take place of which only a hundred or so actually do anything like copy a file - the rest are reading, testing regular expressions, looping, iffing etc.Steve

Not sure what you mean exactly? How would we determine if an action has side effects or not?

Steve,

In my scripts, I use the Write File action with the append option to write a little mini-log.
The structure looks like this:
Try
(Do some steps here)
Log Success
Catch
Log Failure
End

The “Log Success” and “Log Failure” actions are the File Write actions.
So I end up with a file that looks like this:
Group 1: Success
Group 2: FAILURE
Group 3: Success
etc.

That makes a nice at-a-glance summary of what groups of steps completed or crashed. Using that as a reference I know where to drill down in the log to troubleshoot failures.

One complaint I do have with Final Builder is that it marks an action as complete even when child actions of that action fail. That sure makes it a pain to find problems, having to drill all the way down to the lowest nested level actions to see if they completed or not.

Posted By Tate Needham on 12 Dec 2006 10:51 PM
Not sure what you mean exactly? How would we determine if an action has side effects or not?


By going through them all by hand and setting a flag :)If/then: NoCreate text file: YesSwitch: NoWrite to file: YesSet variable: NoText find/replace: Maybe...Steve
Posted By Mike Ratzlaff on 13 Dec 2006 3:22 PM
Steve,

In my scripts, I use the Write File action with the append option to write a little mini-log.
Not a bad idea, but sort of replicates one of the things FB should be doing - monitoring task execution. I probably will need something of this sort though.
One complaint I do have with Final Builder is that it marks an action as complete even when child actions of that action fail. That sure makes it a pain to find problems, having to drill all the way down to the lowest nested level actions to see if they completed or not.


Yes, there are a couple of things of that nature which really could work better, but I don't have any concrete suggestions atm. IMHO, the "succeeded/failed" dichotomy is too simplistic. I really don't like if statements "failing", and nor do I like seeing "error ignored" on a "Check if file exists" action. There's also something not quite right about the nesting behaviour: it's only meaningful to nest normal items if you use the "Ignore failure" flag. I guess a genuine if statement with full expressions would solve some of these...Anyway these aren't genuine complaints, they're sort of musings from a purist CS point of view. In practice they (apart from the log issue) don't pose any problem in actually carrying out builds :)Steve

Hi Steve,

Unfortunately, FinalBuilder is way too complicated to automatically tell about “side effects” in the same way that a programming language can. Almost every FinalBuilder action has a side effect with respect to the rest of the FinalBuilder system.

To take some of your examples to task, Set Variable definitely has a side effect - it changes a variable value. Any action with script attached to it can create side effects. How do you tell whether a “Version Control Get” operation changed anything or not? Ditto a Check In operation. A user can create dedicated checks (like the File Dependency action) but automating them is next to impossible.


I really don’t like if statements “failing”, and nor do I like seeing “error ignored” on a “Check if file exists” action.

Agreed, but most (if not all) of the “if” type actions will only actually fail if you explicitly specify it. Normal behaviour is to skip child actions if the condition evaluates false.

Different levels of failure is something which we have talked about expanding several times, to provide different levels of feedback. If you have any suggestions along these lines then we’d be glad to hear them.


I guess a genuine if statement with full expressions would solve some of these…

What do you mean by this?

Posted By Angus Gratton on 13 Dec 2006 8:41 PM
Hi Steve,

Unfortunately, FinalBuilder is way too complicated to automatically tell about "side effects" in the same way that a programming language can.
Definitely not automatically, agreed. Remember my original goal here is just to help the user focus in on the events that affect the outside world, rather than the logic of the build process itself...
Almost every FinalBuilder action has a side effect with respect to the rest of the FinalBuilder system.

To take some of your examples to task, Set Variable definitely has a side effect - it changes a variable value.
I guess how you categorise that is debatable. When I'm looking through my thousands of actions in the log, though, I'm really looking for file copies, deletions, compilations etc.
Any action with script attached to it can create side effects. How do you tell whether a "Version Control Get" operation changed anything or not? Ditto a Check In operation.
I was thinking primarily in terms of "Show the actions that typically affect the outside world", rather than "Analyse the log and tell me exactly which actions actually did something". Showing a check-in operation that hadn't actually done anything would be ok.If you prefer, consider a general category of filters: "Show only (x) File operations ( ) Revision control operations (x) Internet operations"? A user can create dedicated checks (like the File Dependency action) but automating them is next to impossible.


Different levels of failure is something which we have talked about expanding several times, to provide different levels of feedback. If you have any suggestions along these lines then we'd be glad to hear them.
Cool, will do. In the meantime, I can give you another instance of an awkward situation. I have a Copy File action which I only want to copy if the destination file already exists. So I set the "fail if file already exists" option and "Ignore failure". But that means that if the file is not copied (perfectly normal), I end up with "error ignored" in the log. Not ideal.Maybe the "Ignore failure" needs to be more specific: "Do what on failure: Abort run, pause run, ignore, continue with warning, run children" (the last option is dubious :)).
I guess a genuine if statement with full expressions would solve some of these...[/quote]
What do you mean by this?
[/quote]
I'll think a bit more about this and get back to you :)Steve

A suggestion which came up the other day was tags. A user wanted to be able to tag actions as the responsibilities of different developers.

In a similar vein, tag support would let you mark the actions which you felt had the most potent side effects (how you implemented the tagging would be up to you.) Then we could provide some IDE and log file functions to sort out different tags.

It’s currently just a “wish list” item, but would this give you the functionality you want?

- Angus

Yes, in practice that would let me achieve the same effect. I’d just tag the actions that actually “do something” and filter for them in the log.

And no need for Vsoft employees to stay up all night deciding whether an action type has side effects or not! (like that was ever going to happen…:))

Steve