1. explain the purpose of the existing code base and the original goal of your project; if you had to cut back or change goals, say so [1min]

2. recall the functionality of the existing code base, how to use it, and briefly demonstrate it [4min]

3. demo what you accomplished [5min]

4. describe the pre-existing code base, focusing on those modules with which your Rust code has to interface and/or the Rust code replaces [5min]

5. show-case your Rust extensions

   Do not simply walk us through the code line by line.

   Start with an overview of the key pieces—relating them to bullet 4—and then focus on those parts of the Rust code that posed problems—both in terms of integration and performance [10min]

• On Monday, we will wrap up the Rust-C interaction segment. We will reserve some time for general questions on Rust topics that have come up while you have been working on your project.

• The new due date for submitting the project is April 10.

• Use the additional time to get further feedback on your memo. Some of you need this feedback more than others; you know who you are.

• You will present the projects on April 13 and 20. Instructions on how to present the projects will appear here.

• I have also rewritten the last homework (Reflective Essay). Take a look.

• a description of the purpose of the code base;

• the original goal of your project;

• a description of the organization of the code base, as relevant to the changes that you are implementing;

• a write-up of your accomplishmentsDo not write up a history of your activities; assess your successes and failures., that is, what you actually did;

• a description of your failures, that is, discrepancies between your goals and achievements.

1. present your code base from a client perspective:

   • what does it do, overview

   • how do I use it, concrete examples, demo if possible

   • what kind of role do I play when I use it

2. what does the code base look like from the inside:

   • what are the key modules, architectures

   • how do they collaborate, process

   • which ones do we need to know about from the perspective of this project?

3. what do you wish to add to this code base? abstractly, examples, like bullet 1 above

4. how will you go about it? Which modules does my extension hook into? How?

• concurrency-philosophers.rs presents a solution for the “N dining philosphers” problem

• concurrency-barber.rs presents an Arc/Mutex solution for the basic “sleeping barber” problem, i.e., one barber serves an arbitrary number of customers

• concurrency-barber2.rs supplements the Arc/Mutex solution for the sleeping barber with Semaphores

• concurrency-barber3.rs presents a channel-based solution to the basic “sleeping barber” problem

• concurrency-barbers.rs shows how to extend the channel-based solution for the basic problem to a barber shop with many barbers.

• Any place you could return a new array, an iterator is probably better. (Think of iterators as optimizing arrays for one-pass access.)

• Methods should take arguments (except for small Copy types) by reference, except when they actually need to take ownership. The only reasons to take ownership of an argument are to send it to another thread, to store it in a data structure for later, or to destructively consume it (à la into_iter).

• Methods should take immutable references unless they actually need to mutate.

• The difference between &mut String and &mut str is that the former is a string buffer with dynamic size, whereas the latter has fixed size. Methods should take the latter unless they need to change the size, because the former can always be viewed as the latter by the client.

  (There's no use for &String for which &str isn’t better. [The exception is String::capacity(&self).])

  As the manual says for std:str, ``String is used for an owned string.''

• Clone when you need to both retain and give away ownership of something. (Typically this creates two copies of its mutable state.)

  Cloning is the caller’s job, not the callee’s.

• Boxes are for recursive data structures and owned trait objects, not for passing arguments or returning them.

• Use generic types whenever possible. For example, if your method takes a &mut BufferedReader<StdinReader>, but the only method used is lines(), then have it take &mut B where B: Buffer instead.

• the proposed project

• the organization and content, i.e., the description of the project and its code base

• and style items, ranging from sentence organization to choice of words, from grammar problems to layout.

1. The opening specifies the project that you wish to extend, describes its purpose, and indicates how you wish to modify its functionality.

2. The middle supplements the project description. It also explains how the project’s code base is organized.

3. The third part identifies a missing piece of functionality. It should list its purpose and sketch its workings.

4. The last part sketches how you will go about adding the functionality to the code base, making references to terms introduced in step 2.

• Leave a one-inch margin all around. It makes the page readable.

• Add a noun to uses of "this" and "these." Otherwise the reference remains unclear.

• Avoid "there is" and "there are". Certainly don’t pile them up.

• Use colons ":" to introduce enumerations.

• Reserve "you" for the recipient of the memo.

  Note I understand that, outside of computer science, the word "user" is reserved for consumers of illicit drugs. But the usage is common now, so get used to it, too.

• The word "however" is used to switch a paragraph’s line of argument from support for its thesis to a different/opposite point you wish to make in the following paragraph.

• An m-dash consists of three hyphens and is attached to the surrounding words.

• Replace "they" with "he/she" if you wish to accommodate the gender police. Otherwise you are likely to write sentences whose subject will fail to match the verb in numbers.

make-up class tomorrow (Friday) evening at 6pm in WVH 166

make-up class tomorrow (Friday) evening at 6pm in WVH 166

What’s a letter?

At the information level, let’s define letter as a .. z and A … Z. At the data level, choose the natural representation.

And in this context, how should we deal with apostrophes?

Consider them as word terminators.

• specify the chosen code (external purpose statement),

• describe its internal organization, and

• state the goal of your Rust extension.

tomorrow (Wedn. Feb 11) from 3pm to 7pm in WVH 308b

Optimization Coaching

make-up class tomorrow (Friday) evening at 6pm in WVH 366

Given this code snippet,

use std::collections::HashMap;

fn main() {

let s = & String::from_str("hello");

let h = create_string(s);

println!("{}",h.get("hello").unwrap());

}

fn create_string<'a>(s : & String) -> HashMap<&'a str, usize> {

let mut hm : HashMap<&str,usize> = HashMap::new();

hm.insert(s.as_slice(),1);

return hm;

}

Why does this fail with a message about "not being able to infer the correct life time?"

You can see that the life time parameter ’a shows up in the result type but not in the argument. So, how can s can possibly be used to create a string slice that survives long enough?All string constants are string slices with a static life time. That is, the compiler hoists them out and creates a unique pointer for them—like for symbols in a Lisp-style language.

Now fortunately, the compiler provides a rather suggestive error message and following this message corrects the mistake:

fn create_string<'a>(s : & 'a String) -> HashMap<&'a str, usize> {

let mut hm : HashMap<&str,usize> = HashMap::new();

hm.insert(s.as_slice(),1);

return hm;

}

Also, apparently our selection of the final project is due on Friday? I’m not really sure what the criteria is for what we select. The three projects you listed don’t particularly interest me, but if I wanted to find another, what sort of attributes should we be looking for?

We welcome any project

• whose source is in C (or C++ if you know enough to read the relevant part of the source),

• that appeals to you in some way, and

• for which you can think of some functionality that you would like to add.

fn parse_lines<'a, R: Reader>(mut reader: BufferedReader<R>)

-> HashMap<&'a str, usize> {

let mut wordcounts: HashMap<&str, usize> = HashMap::new();

...

}

that the string slices that get stuck into the hash map are created within parse_lines. By using String instead, this function gets through the borrow checker.

make-up class tomorrow (Friday) evening at 6pm in WVH 366

• "Python is like a tupperware container, you can put soup or a chicken sandwich in it."

• "Javascript is clay, she has borne children, she flirts."

For our Building Extensible System’s essay assignment, are you expecting something that sway’s more towards the "poetic" side (for the average reader) or do you want it to be purely technical.

The choice is yours as long as the essay is descriptive not judgmental. "The car is red" is good, "the car has beautiful curves" is bad. Okay?