WEBVTT

00:00:00.700 --> 00:00:05.564
A watcher reacts to changes, while a timer schedules work at intervals.

00:00:05.714 --> 00:00:10.045
Both are useful for automation, and both naturally keep running.

00:00:10.195 --> 00:00:13.587
In this lesson we will make their lifetime explicit.

00:00:13.737 --> 00:00:16.595
First, a timer prints exactly three ticks.

00:00:16.745 --> 00:00:21.567
Then a file event triggers one small local build and the watcher exits.

00:00:21.717 --> 00:00:28.043
These bounded demonstrations are easier to test and understand than an unattended background process, and

00:00:28.043 --> 00:00:32.682
they give us a clear result to verify at the end.

00:00:34.830 --> 00:00:37.262
Every creates a stream of timer ticks.

00:00:37.412 --> 00:00:42.511
Here the interval is one hundred milliseconds, which keeps the demonstration quick.

00:00:42.661 --> 00:00:46.885
Take limits the stream to three values before for each consumes it.

00:00:47.035 --> 00:00:53.754
Each tick prints the same short label, and the final line proves that execution continued after the

00:00:53.754 --> 00:00:54.544
stream ended.

00:00:54.694 --> 00:00:59.579
The timer interval is not a precise real time scheduling guarantee.

00:00:59.729 --> 00:01:06.432
If downstream work takes time, the pipeline follows backpressure rather than promising overlapping

00:01:06.432 --> 00:01:09.009
executions for every clock interval.

00:01:11.160 --> 00:01:13.421
Now run the unbounded example.

00:01:13.571 --> 00:01:21.374
Collect needs the entire input before it can return a list, but an unlimited timer never supplies a final

00:01:21.374 --> 00:01:21.785
item.

00:01:21.935 --> 00:01:27.119
HHY rejects this with a plan error telling us to apply a bound.

00:01:27.269 --> 00:01:33.349
The fix is about the lifetime of the data, not about adding more memory or waiting longer.

00:01:33.499 --> 00:01:40.744
Put take before a collecting, sorting, or grouping barrier whenever your source is naturally infinite and

00:01:40.744 --> 00:01:43.461
your task requires a finite result.

00:01:45.610 --> 00:01:49.578
Our watcher observes the fixtures directory recursively.

00:01:49.728 --> 00:01:56.789
Debounce reduces rapid repeated events, and take limits this demonstration to one accepted event.

00:01:56.939 --> 00:02:03.249
The documentation describes leading edge behavior: the first event is emitted immediately, and repeated

00:02:03.249 --> 00:02:07.755
events with the same key are coalesced during the window.

00:02:07.905 --> 00:02:11.980
It is not a promise to wait for every editor to finish writing.

00:02:12.130 --> 00:02:19.626
For this lesson, we create a separate trigger file only after our source content is ready, making the

00:02:19.626 --> 00:02:21.709
build input deliberate and reproducible.

00:02:23.860 --> 00:02:30.431
Inside the event handler, run invokes the supplied Python build script with a two second timeout.

00:02:30.581 --> 00:02:35.381
The build reads source dot text and prints its contents with a built label.

00:02:35.531 --> 00:02:40.288
This is deliberately small so the lesson stays focused on orchestration.

00:02:40.438 --> 00:02:47.983
A nonzero process exit code needs an explicit decision: here we print standard error, while success

00:02:47.983 --> 00:02:49.398
prints standard output.

00:02:49.548 --> 00:02:57.342
You can later substitute your real build command without changing the basic event, process, and result

00:02:57.342 --> 00:02:58.316
handling structure.

00:03:00.470 --> 00:03:06.315
Start the watcher from the examples directory, then create the trigger file in another terminal.

00:03:06.465 --> 00:03:10.839
You should see change detected, the build output, and watch complete.

00:03:10.989 --> 00:03:16.727
The included verification driver performs this sequence and cleans up its trigger file.

00:03:16.877 --> 00:03:21.080
Filesystem event delivery varies by platform and editor.

00:03:21.230 --> 00:03:28.526
In our local validation, creating a file triggered reliably, while rewriting an existing file did not.

00:03:28.676 --> 00:03:36.006
That is why this demonstration uses a creation event and does not promise identical save behavior on

00:03:36.006 --> 00:03:36.868
every system.

00:03:39.020 --> 00:03:45.447
For a longer running tool, decide which event kinds should trigger work and which files should be

00:03:45.447 --> 00:03:45.825
ignored.

00:03:45.975 --> 00:03:51.927
Writing generated output into the watched source directory can cause an unwanted loop.

00:03:52.077 --> 00:03:56.963
Keep the outputs elsewhere and filter according to your actual build inputs.

00:03:57.113 --> 00:04:00.697
During this tutorial, take gives us a normal finish.

00:04:00.847 --> 00:04:09.706
If no event arrives, Control C stops the watcher; the verification driver also has an outer timeout so an

00:04:09.706 --> 00:04:13.903
unexpected platform issue cannot leave the test waiting indefinitely.

00:04:16.050 --> 00:04:22.301
For practice, update source dot text, start a fresh watcher, and create the trigger file again.

00:04:22.451 --> 00:04:25.565
Predict the build output before you run the sequence.

00:04:25.715 --> 00:04:32.265
Then change the timer example to five ticks and verify that done still appears exactly once.

00:04:32.415 --> 00:04:36.852
Keep these two sources separate until their lifetimes feel familiar.

00:04:37.002 --> 00:04:44.554
You can now schedule finite work and respond to a filesystem signal with an explicit stopping condition.

00:04:44.704 --> 00:04:50.485
In the next lesson, we will combine several earlier techniques into a real log report.