@@ -61,7 +61,7 @@ \section{Introduction}
61
61
62
62
\emph {Filters } are functions that can be repeatedly invoked
63
63
with chunks of input, successively returning processed
64
- chunks of output. More importantly , the result of
64
+ chunks of output. Naturally , the result of
65
65
concatenating all the output chunks must be the same as the
66
66
result of applying the filter to the concatenation of all
67
67
input chunks. In fancier language, filters \emph {commute }
@@ -81,11 +81,12 @@ \section{Introduction}
81
81
times along the way. Chains connect these nodes together.
82
82
The initial and final nodes of the network are
83
83
\emph {sources } and \emph {sinks }, respectively. Less
84
- abstractly, a source is a function that produces new data
85
- every time it is invoked. Conversely, sinks are functions
86
- that give a final destination to the data they receive.
87
- Naturally, sources and sinks can also be chained with
88
- filters to produce filtered sources and sinks.
84
+ abstractly, a source is a function that produces new chunks
85
+ of data every time it is invoked. Conversely, sinks are
86
+ functions that give a final destination to the chunks of
87
+ data they receive in sucessive calls. Naturally, sources
88
+ and sinks can also be chained with filters to produce
89
+ filtered sources and sinks.
89
90
90
91
Finally, filters, chains, sources, and sinks are all passive
91
92
entities: they must be repeatedly invoked in order for
@@ -95,8 +96,8 @@ \section{Introduction}
95
96
96
97
In the following sections, we start with a simplified
97
98
interface, which we later refine. The evolution we present
98
- is not contrived: it recreates the steps we followed
99
- ourselves as we consolidated our understanding of these
99
+ is not contrived: it recreates the steps we ourselves
100
+ followed as we consolidated our understanding of these
100
101
concepts within our application domain.
101
102
102
103
\subsection {A simple example }
@@ -290,8 +291,8 @@ \subsection{The C part of the filter}
290
291
\end {C }
291
292
\end {quote }
292
293
293
- When designing your own filters, the challenging part is to
294
- decide what will be in the context. For line breaking, for
294
+ When designing filters, the challenging part is usually
295
+ deciding what to store in the context. For line breaking, for
295
296
instance, it could be the number of bytes that still fit in the
296
297
current line. For Base64 encoding, it could be a string
297
298
with the bytes that remain after the division of the input
@@ -408,8 +409,8 @@ \subsection{Filtered sources}
408
409
Filtered sources are useful when working with
409
410
functions that get their input data from a source (such as
410
411
the pumps in our examples). By chaining a source with one or
411
- more filters, the function can be transparently provided
412
- with filtered data, with no need to change its interface .
412
+ more filters, such functions can be transparently provided
413
+ with filtered data, with no need to change their interfaces .
413
414
Here is a factory that does the job:
414
415
\begin {quote }
415
416
\begin {lua }
@@ -434,11 +435,11 @@ \subsection{Filtered sources}
434
435
435
436
\subsection {Sinks }
436
437
437
- Just as we defined an interface for source of data,
438
- we can also define an interface for a data destination.
439
- We call any function respecting this
440
- interface a \emph { sink }. In our first example, we used a
441
- file sink connected to the standard output.
438
+ Just as we defined an interface for a source of data, we can
439
+ also define an interface for a data destination. We call
440
+ any function respecting this interface a sink. In our first
441
+ example, we used a file sink connected to the standard
442
+ output.
442
443
443
444
Sinks receive consecutive chunks of data, until the end of
444
445
data is signaled by a \nil \ input chunk. A sink can be
@@ -665,7 +666,7 @@ \section{A complex example}
665
666
with the server, and simply pumps the data. The message is never
666
667
assembled in memory. Everything is produced on demand,
667
668
transformed in small pieces, and sent to the server in chunks,
668
- including the file attachment that is loaded from disk and
669
+ including the file attachment which is loaded from disk and
669
670
encoded on the fly. It just works.
670
671
671
672
\section {Conclusions }
@@ -685,11 +686,10 @@ \section{Acknowledgements}
685
686
The concepts described in this text are the result of long
686
687
discussions with David Burgess. A version of this text has
687
688
been released on-line as the Lua Technical Note 012, hence
688
- the name of the corresponding LuaSocket module,
689
- \texttt {ltn12 }. Wim Couwenberg contributed to the
690
- implementation of the module, and Adrian Sietsma was the
691
- first to notice the correspondence between sources and Lua
692
- iterators.
689
+ the name of the corresponding LuaSocket module, LTN12. Wim
690
+ Couwenberg contributed to the implementation of the module,
691
+ and Adrian Sietsma was the first to notice the
692
+ correspondence between sources and Lua iterators.
693
693
694
694
695
695
\end {document }
0 commit comments