LearningToTalk/Segmentation — pull request #12 by tjmahr (2014-04-15 19:21:07+00:00)
Title: Start-up wizard refactored into procedures

The start-up wizard has been substantially simplified. We now build [bricks, not monoliths](http://www.burns-stat.com/bricks-not-monoliths/).

* The code for each step of the start-up process is now encapsulated in a procedure.
* These procedures don't have any hard-coded special knowledge about the previous or next steps in the wizards. Instead, each of these procedures produces a `.result_node$` value which tells whether the wizard should go backward, forwards or abort. This interface allows these procedures to be recycled for other tasks/scripts.
* Each of these procedures are supported by another `log_` procedure which prints out info-lines about the values of the variables inside the procedure. This logging is toggled by a global variable `debug`.

Below are some lines from the logging:

```
Node: initials

---- log_initials() ----
Exit Status: next
derived values:
.initials$: TM
.drive$: L:/
.audio_drive$: L:/

---- log_testwave() ----
Exit Status: next
derived values:
.task$: RealWordRep
.testwave$: TimePoint1
```

By packing some lines of code away in subroutines, variables created in those lines of code are no longer part of the script's global namespace. I've made an effort to re-introduce some of those variables back into the global namespace with lines like:

```
# [global variable] = [procedure name].[matching variable in procedure]
drive$ = startup_initials.drive$
audio_drive$ = startup_initials.audio_drive$
task$ = startup_testwave.task$
testwave$ = startup_testwave.testwave$
segmenters_initials$ = startup_initials.initials$
```

But if there is a variable I haven't yet put into the global namespace, these variables will not be found and the script will crash. I have had UW users test the script for the past week, so we should be okay for the NWR and RWR tasks.