Assignment 4b
Problems 5-7: Thursday at 9:00pm (Week 4)
Problem 8: extended until Monday Oct 2nd at 9:00pm
Purpose To practice designing functions on lists, and extending and refining earlier programs.
Exercise 1 HtDP Exercise 110
Exercise 2 HtDP Exercise 115
Exercise 3 HtDP Exercise 130
Exercise 4 Design the function du, which consumes a list of strings and computes their total length.
Hint: Remember string-length.
Graded Exercises
Exercise 5 Picture frames
Design a function that takes a list of images and frames them all. That is, it turns this:
into this:
Exercise 6 Image areas
Design a function that can take a list of images and produce a number representing their total area. (Remember: a picture’s area depends only on its size, not on its contents. The four input images in the problem above all are the same size, and so have the same area, despite appearing to show different shapes. The circle and square in the images above have the same width and height, and so have the same area, despite appearing to be different shapes. The triangle and star have the same height as the other shapes, but different widths; they definitely have different areas.)
Exercise 7 Trailing off...
Design a function that, for example, can turn this input:
into this example output:
A longer list would produce something like
Specifically, the function should take a list of images and place them beside each other, aligned at the bottoms, and such that the composite images are shrunk by some scale factor (here I used 0.9). There’s nothing special about the images themselves; the example images above used the answer to the Picture Frames exercise above, so you can easily see the sizes of the component images.
Exercise 8 NOTE: Extended until Monday
In Assignment 3a we asked you to design the world program simple-forum. Before proceeding, fix your solution in response to our feedback.
Now we will update the forum program so that it actually communicates with a server to send posts there, and receive everyone’s posts back from the server. Your client program now has three responsibilities:
User input – slightly changed from last week
User interface – unchanged, except for error handling
Network interaction – all new!
1. User input: The program interacts with the user, who may edit one-line text fields:
Just like last week, its key handler accepts keyboard characters of length 1—
except for "\r" (enter) and "\b" (backspace)— and adds them to the end of the text. When the user presses the backspace ("\b") key, the program must erase the last 1String that was added (if any). Changed: When the user presses enter ("\r"), the program sends the current string in the text field to the server and clears the text field.
Feel free to equip your program with additional edit capabilities. Also, your program may display its state in any way you like; the only constraint is that the canvas should contain the contents and authors of the posts that have been made as well as the text the user is currently typing.
2. Network interaction: The program also must be prepared to receive messages from the server. All messages from the server are plain strings.
Connect to the server using a register clause and a port clause in your big-bang call. The register clause should use a server name of "dictionary.ccs.neu.edu", and port should use a number between 10001 and 10005 (inclusive). You also need to specify a name clause with your login credentials. Read the description of client programs to see the format we expect for your credentials.
If the string begins with "ERROR" it is an error message from the server and your client should display this message. (This is the only new piece of user interface you need to worry about this week.) Note that such an error should not terminate your program; the user should have some way of continuing to interact with your client even after making a mistake.
"id:name:content"
For example, "0:ben:hello" and "1:alan:world" are legitimate messages. The ID # is not important at the moment but will become essential in later iterations of Piazza. For now it is enough to display only the author and contents of a post.Note: Last week, when the user pressed enter, your program immediately added the post to the growing image of posts. This week, it does not: because it is sending the message to the server, it will only add a post to the prior posts (however you choose to represent them) when it receives a message back from the server.
Designing your data: This week, we aren’t giving specific suggestions how you should design your data. But the image representation from last week is probably not going to suffice, and you now have some practice with a new form of data that might work better for you...
Grading We will grade the design of each handler separately. So turn in your program even if it remains incomplete and cannot connect to the server.