Skip to content

Commit 204f260

Browse files
committed
txs auto checkin
1 parent 460bb9f commit 204f260

File tree

1 file changed

+82
-55
lines changed

1 file changed

+82
-55
lines changed

rust.tex

Lines changed: 82 additions & 55 deletions
Original file line numberDiff line numberDiff line change
@@ -1491,7 +1491,7 @@ \section{Error Handling}
14911491

14921492
\begin{frame}[fragile]
14931493
\frametitle{Matching on Different Errors}
1494-
1494+
14951495
\inputminted[fontsize=\scriptsize]{rust}{./code/result3.rs}
14961496
\end{frame}
14971497

@@ -1505,8 +1505,8 @@ \section{Error Handling}
15051505
\begin{frame}[fragile]
15061506
\frametitle{Shortcuts for Panic on Error: unwrap and expect }
15071507
\scriptsize
1508-
The \mintinline{rust}|Result<T, E>| type has many helper methods defined on it to do various, more specific tasks. If the Result value is the Ok variant, unwrap will return the value inside the Ok. If the Result is the Err variant, unwrap will call the panic! macro for us.
1509-
1508+
The \mintinline{rust}|Result<T, E>| type has many helper methods defined on it to do various, more specific tasks. If the Result value is the Ok variant, unwrap will return the value inside the Ok. If the Result is the Err variant, unwrap will call the panic! macro for us.
1509+
15101510
\inputminted[fontsize=\scriptsize]{rust}{./code/result5.rs}
15111511

15121512
We use \mintinline{rust}|expect| in the same way as unwrap: to return the file handle or call the panic! macro.
@@ -1535,10 +1535,10 @@ \section{Error Handling}
15351535

15361536
\begin{frame}[fragile]
15371537
\frametitle{Where The \mintinline{rust}|?| Operator Can Be Used}
1538-
\begin{itemize}
1539-
\item The \mintinline{rust}|?| operator can only be used in functions whose return type is compatible with the value the \mintinline{rust}|?| is used on.
1540-
\item we’re only allowed to use the ? operator in a function that returns \mintinline{rust}|Result|, \mintinline{rust}|Option|, or another type that implements \mintinline{rust}|FromResidual|.
1541-
\end{itemize}
1538+
\begin{itemize}
1539+
\item The \mintinline{rust}|?| operator can only be used in functions whose return type is compatible with the value the \mintinline{rust}|?| is used on.
1540+
\item we’re only allowed to use the ? operator in a function that returns \mintinline{rust}|Result|, \mintinline{rust}|Option|, or another type that implements \mintinline{rust}|FromResidual|.
1541+
\end{itemize}
15421542

15431543
\inputminted{rust}{./code/result11.rs}
15441544
\end{frame}
@@ -1556,18 +1556,18 @@ \section{Generic Types, Traits, and Lifetimes}
15561556
\begin{frame}[fragile]
15571557
\frametitle{Generic Data Types}
15581558
We use generics to create definitions for items like function signatures or structs, which we can then use with many different concrete data types.
1559-
1559+
15601560
\begin{columns}
15611561
\column{0.5\textwidth}
1562-
\inputminted{rust}{./code/generic1.rs}
1562+
\inputminted{rust}{./code/generic1.rs}
15631563
\column{0.5\textwidth}
1564-
\inputminted{rust}{./code/generic2.rs}
1564+
\inputminted{rust}{./code/generic2.rs}
15651565
\end{columns}
15661566
\end{frame}
15671567

15681568
\begin{frame}[fragile]
15691569
\frametitle{Generic Data Types (3)}
1570-
\inputminted[fontsize=\scriptsize]{rust}{./code/generic3.rs}
1570+
\inputminted[fontsize=\scriptsize]{rust}{./code/generic3.rs}
15711571
\end{frame}
15721572

15731573
\begin{frame}[fragile]
@@ -1594,13 +1594,13 @@ \section{Generic Types, Traits, and Lifetimes}
15941594

15951595
\begin{frame}[fragile]
15961596
\frametitle{Monomorphization}
1597-
Monomorphization is the process of turning generic code into specific code by filling in the concrete types that are used when \textbf{compiled}. In this process, the compiler does the opposite of the steps we used to create the generic function: the compiler looks at all the places where generic code is called and generates code for the concrete types the generic code is called with.
1598-
1597+
Monomorphization is the process of turning generic code into specific code by filling in the concrete types that are used when \textbf{compiled}. In this process, the compiler does the opposite of the steps we used to create the generic function: the compiler looks at all the places where generic code is called and generates code for the concrete types the generic code is called with.
1598+
15991599
\end{frame}
16001600

16011601
\begin{frame}[fragile]
16021602
\frametitle{Monomorphization}
1603-
1603+
16041604
\inputminted[fontsize=\scriptsize]{rust}{./code/generic8.rs}
16051605
\end{frame}
16061606

@@ -1617,7 +1617,7 @@ \section{Generic Types, Traits, and Lifetimes}
16171617

16181618
\begin{frame}[fragile]
16191619
\frametitle{Traits: Defining Shared Behavior (2)}
1620-
\inputminted[fontsize=\scriptsize]{rust}{./code/Trait1.rs}
1620+
\inputminted[fontsize=\scriptsize]{rust}{./code/Trait1.rs}
16211621
\end{frame}
16221622

16231623

@@ -1698,20 +1698,20 @@ \section{Generic Types, Traits, and Lifetimes}
16981698

16991699
\begin{frame}[fragile]
17001700
\frametitle{Lifetime Annotation Syntax}
1701-
\begin{itemize}
1702-
\item Lifetime annotations \textbf{don’t change how long any of the references live}. Rather, they \textbf{describe the relationships of the lifetimes of multiple references to each other }without affecting the lifetimes.
1703-
\item Lifetime annotations have a slightly \textbf{unusual syntax}: the names of lifetime parameters must start with an apostrophe (') and are usually all lowercase and very short, like generic types. Most people use the name \mintinline{rust}|'a| for the first lifetime annotation. We place lifetime parameter annotations after the \mintinline{rust}|&| of a reference, using a space to separate the annotation from the reference’s type.
1704-
1705-
\inputminted{rust}{./code/lifetime3.rs}
1706-
\end{itemize}
1701+
\begin{itemize}
1702+
\item Lifetime annotations \textbf{don’t change how long any of the references live}. Rather, they \textbf{describe the relationships of the lifetimes of multiple references to each other }without affecting the lifetimes.
1703+
\item Lifetime annotations have a slightly \textbf{unusual syntax}: the names of lifetime parameters must start with an apostrophe (') and are usually all lowercase and very short, like generic types. Most people use the name \mintinline{rust}|'a| for the first lifetime annotation. We place lifetime parameter annotations after the \mintinline{rust}|&| of a reference, using a space to separate the annotation from the reference’s type.
1704+
1705+
\inputminted{rust}{./code/lifetime3.rs}
1706+
\end{itemize}
17071707
\end{frame}
17081708

17091709

17101710
\begin{frame}[fragile]
17111711
\frametitle{Lifetime Annotations in Function Signatures}
17121712
\inputminted{rust}{./code/lifetime4.rs}
17131713

1714-
The generic lifetime \mintinline{rust}|'a| will get the concrete \textbf{lifetime that is equal to the smaller of the lifetimes }of x and y. In practice, it means that the lifetime of the reference returned by the longest function is the same as the smaller of the lifetimes of the values referred to by the function arguments. These relationships are what we want Rust to use when analyzing this code.
1714+
The generic lifetime \mintinline{rust}|'a| will get the concrete \textbf{lifetime that is equal to the smaller of the lifetimes }of x and y. In practice, it means that the lifetime of the reference returned by the longest function is the same as the smaller of the lifetimes of the values referred to by the function arguments. These relationships are what we want Rust to use when analyzing this code.
17151715
\end{frame}
17161716

17171717

@@ -1723,11 +1723,11 @@ \section{Generic Types, Traits, and Lifetimes}
17231723

17241724
\end{frame}
17251725

1726-
\begin{frame}[fragile]
1727-
\frametitle{Lifetime Annotations in Function Signatures (3)}
1728-
\inputminted{shell}{./code/lifetime5.shell}
1729-
1730-
\end{frame}
1726+
\begin{frame}[fragile]
1727+
\frametitle{Lifetime Annotations in Function Signatures (3)}
1728+
\inputminted{shell}{./code/lifetime5.shell}
1729+
1730+
\end{frame}
17311731

17321732
\begin{frame}[fragile]
17331733
\frametitle{Lifetime Annotations in Struct Definitions}
@@ -1785,7 +1785,7 @@ \section{Generic Types, Traits, and Lifetimes}
17851785

17861786
\begin{frame}[fragile]
17871787
\frametitle{Generic Type Parameters, Trait Bounds, and Lifetimes Together}
1788-
1788+
17891789
\inputminted{rust}{./code/lifetime10.rs}
17901790
\end{frame}
17911791

@@ -1864,8 +1864,8 @@ \section{Writing Automated Tests}
18641864
\item We can pass the name of any test function to \mintinline{shell}|cargo test| to run only that test.
18651865
\item We can specify part of a test name, and any test whose name matches that value will be run.
18661866
\end{itemize}
1867-
\item Sometimes a few specific tests can be very time-consuming to execute, so you might want to exclude them during most runs of \mintinline{shell}|cargo test|. After \mintinline{shell}|#[test]| we add the \mintinline{shell}|#[ignore]| line to the test we want to exclude. If we want to run only the ignored tests, we can use \mintinline{shell}|cargo test -- --ignored|.
1868-
\inputminted[fontsize=\scriptsize]{rust}{./code/test8.rs}
1867+
\item Sometimes a few specific tests can be very time-consuming to execute, so you might want to exclude them during most runs of \mintinline{shell}|cargo test|. After \mintinline{shell}|#[test]| we add the \mintinline{shell}|#[ignore]| line to the test we want to exclude. If we want to run only the ignored tests, we can use \mintinline{shell}|cargo test -- --ignored|.
1868+
\inputminted[fontsize=\scriptsize]{rust}{./code/test8.rs}
18691869
\end{itemize}
18701870
\end{frame}
18711871

@@ -1875,34 +1875,34 @@ \section{Writing Automated Tests}
18751875
\frametitle{Test Organization}
18761876
\begin{itemize}
18771877
\item The Rust community thinks about tests in terms of two main categories: \textbf{unit tests} and \textbf{integration tests}.
1878-
\begin{itemize}
1879-
\item Unit tests are small and more focused, \textbf{testing one module in isolation at a time}, and \textbf{can test private interfaces}. You’ll put unit tests in the \mintinline{shell}|src| directory in each file with the code that they’re testing. The convention is to create a module named tests in each file to contain the test functions and to annotate the module with \mintinline{rust}|#[cfg(test)]|.
1880-
\item Integration tests are entirely external to your library and use your code in the same way any other external code would,\textbf{ using only the public interface and potentially exercising multiple modules per test}. Their purpose is to test \textbf{whether many parts of your library work together correctly}.
1878+
\begin{itemize}
1879+
\item Unit tests are small and more focused, \textbf{testing one module in isolation at a time}, and \textbf{can test private interfaces}. You’ll put unit tests in the \mintinline{shell}|src| directory in each file with the code that they’re testing. The convention is to create a module named tests in each file to contain the test functions and to annotate the module with \mintinline{rust}|#[cfg(test)]|.
1880+
\item Integration tests are entirely external to your library and use your code in the same way any other external code would,\textbf{ using only the public interface and potentially exercising multiple modules per test}. Their purpose is to test \textbf{whether many parts of your library work together correctly}.
1881+
\end{itemize}
18811882
\end{itemize}
1882-
\end{itemize}
18831883
\end{frame}
18841884

18851885

18861886
\begin{frame}[fragile]
18871887
\frametitle{Integration test}
18881888
We create a tests directory at the top level of our project directory, next to src. Cargo knows to look for integration test files in this directory. We can then make as many test files as we want, and Cargo will compile each of the files as an individual crate.
18891889

1890-
1891-
\begin{columns}
1892-
\column{0.4\textwidth}
1893-
\begin{figure}
1894-
\centering
1895-
\includegraphics[width=0.8\linewidth]{img/test.png}
1896-
\end{figure}
1897-
\column{0.6\textwidth}
1898-
\scriptsize
1899-
Filename: \mintinline{shell}|tests/integration_test.rs|
1900-
\inputminted[fontsize=\scriptsize]{rust}{./code/test9.rs}
1901-
1902-
\mintinline{shell}|$ cargo test|
1903-
1904-
\mintinline{shell}|$ cargo test --test integration_test|
1905-
\end{columns}
1890+
1891+
\begin{columns}
1892+
\column{0.4\textwidth}
1893+
\begin{figure}
1894+
\centering
1895+
\includegraphics[width=0.8\linewidth]{img/test.png}
1896+
\end{figure}
1897+
\column{0.6\textwidth}
1898+
\scriptsize
1899+
Filename: \mintinline{shell}|tests/integration_test.rs|
1900+
\inputminted[fontsize=\scriptsize]{rust}{./code/test9.rs}
1901+
1902+
\mintinline{shell}|$ cargo test|
1903+
1904+
\mintinline{shell}|$ cargo test --test integration_test|
1905+
\end{columns}
19061906
\end{frame}
19071907

19081908

@@ -1920,18 +1920,45 @@ \section{Writing Automated Tests}
19201920
\end{figure}
19211921
\column{0.6\textwidth}
19221922
\scriptsize
1923-
Filename: \mintinline{shell}|tests/common.rs|
1923+
Filename: \mintinline{shell}|tests/common.rs|
19241924
\inputminted[fontsize=\scriptsize]{rust}{./code/test10.rs}
19251925
\end{columns}
1926-
\scriptsize
1927-
Filename: \mintinline{shell}|tests/integration_test.rs|
1926+
\scriptsize
1927+
Filename: \mintinline{shell}|tests/integration_test.rs|
1928+
1929+
\inputminted[fontsize=\scriptsize]{rust}{./code/test11.rs}
1930+
1931+
\end{frame}
1932+
1933+
\section{An I/O Project: Building a Command Line Program}
19281934

1929-
\inputminted[fontsize=\scriptsize]{rust}{./code/test11.rs}
19301935

1936+
\begin{frame}[fragile]
1937+
\frametitle{minigrep example}
1938+
\begin{itemize}
1939+
\item We’ll make our own version of the classic command line search tool grep (globally search a regular expression and print). In the simplest use case, grep searches a specified file for a specified string.
1940+
\item The first task is to make \textbf{minigrep} accept its two command line arguments: the \textbf{file path} and \textbf{a string to search for}. That is, we want to be able to run our program with cargo run, \textbf{two hyphens to indicate the following arguments are for our program rather than for cargo}, a string to search for, and a path to a file to search in, like so: \mintinline{shell}|$ cargo run -- searchstring example-filename.txt|
1941+
\end{itemize}
1942+
19311943
\end{frame}
19321944
1933-
\section{An I/O Project: Building a Command Line Program}
1945+
\begin{frame}[fragile]
1946+
\frametitle{minigrep - Reading the Argument Values}
1947+
\inputminted[fontsize=\scriptsize]{rust}{./code/grep1.rs}
1948+
1949+
\inputminted[fontsize=\scriptsize]{shell}{./code/grep1.shell}
1950+
1951+
Notice that the first value in the vector is the name of our binary.
1952+
\end{frame}
1953+
1954+
\begin{frame}[fragile]
1955+
\frametitle{minigrep - Saving the Argument Values in Variables}
1956+
\inputminted[fontsize=\scriptsize]{rust}{./code/grep2.rs}
1957+
\end{frame}
1958+
1959+
19341960
\section{Functional Language Features: Iterators and Closures}
1961+
19351962
\section{More About Cargo and Crates.io}
19361963
\section{Smart Pointers}
19371964
\section{Fearless Concurrency}

0 commit comments

Comments
 (0)