haas:fall2018:discrete:projects:bdt0
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
| haas:fall2018:discrete:projects:bdt0 [2017/10/03 14:25] – external edit 127.0.0.1 | haas:fall2018:discrete:projects:bdt0 [2018/08/26 13:20] (current) – [Submission] wedge | ||
|---|---|---|---|
| Line 3: | Line 3: | ||
| < | < | ||
| </ | </ | ||
| - | |||
| - | ~~TOC~~ | ||
| ======Project: | ======Project: | ||
| =====Objective===== | =====Objective===== | ||
| - | To apply our binary data knowledge | + | To explore |
| =====Background===== | =====Background===== | ||
| Line 16: | Line 14: | ||
| Yet- we've also seen how that inserted layer of abstraction between us and the computer has provided an opportunity to omit and later properly learn what is actually going on: it isn't just about integers and floating point values and ASCII characters... and while each has its own unique ways of accessing and manipulating, | Yet- we've also seen how that inserted layer of abstraction between us and the computer has provided an opportunity to omit and later properly learn what is actually going on: it isn't just about integers and floating point values and ASCII characters... and while each has its own unique ways of accessing and manipulating, | ||
| - | As the computer and all data is largely the same, it is important we increasingly see it as just sequences of 1s and 0s, accessed in units of bytes. | + | As the computer and all data is largely the same, it is important we increasingly see it as just sequences of 1s and 0s, accessed in units of bytes (these days, and likely for the foreseeable future, consisting of groupings of 8 bits). |
| Binary data merely refers to data as the computer stores it. The computer is a binary device, so its raw data (as it exists on various forms of storage and media) is often referred to as binary data, to reflect the 1s and 0s being represented. | Binary data merely refers to data as the computer stores it. The computer is a binary device, so its raw data (as it exists on various forms of storage and media) is often referred to as binary data, to reflect the 1s and 0s being represented. | ||
| =====Task===== | =====Task===== | ||
| - | Your task is to write a hex viewer, along the lines of the **xxd(1)** tool found on the system. We have made use of **xxd(1)** rather extensively to help us in identify encoding deviations with our dcfX implementations against proper specification-generated output. | + | Your task is to write a hex viewer, along the lines of the **xxd(1)** tool found on the system. |
| - | + | ||
| - | An insightful exploration is, while we've been utilizing this tool to aid us in our debugging, there is some important concepts to be gleaned by exploring the implementation of such a tool, which is what this project is about. | + | |
| =====Grabit===== | =====Grabit===== | ||
| Line 33: | Line 29: | ||
| ‘/ | ‘/ | ||
| ‘/ | ‘/ | ||
| - | ‘/ | + | ‘/ |
| ‘/ | ‘/ | ||
| + | ‘/ | ||
| ‘/ | ‘/ | ||
| ‘/ | ‘/ | ||
| + | ‘/ | ||
| make: Leaving directory '/ | make: Leaving directory '/ | ||
| lab46: | lab46: | ||
| Line 62: | Line 60: | ||
| <cli> | <cli> | ||
| lab46: | lab46: | ||
| - | 0000000: 3e41 4243 4445 4647 4849 4a4b 4c4d 4e4f > | + | 00000000: 3e41 4243 4445 4647 4849 4a4b 4c4d 4e4f > |
| - | 0000010: 5051 5253 5455 5657 5859 5a3c 0a5b 6162 PQRSTUVWXYZ< | + | 00000010: 5051 5253 5455 5657 5859 5a3c 0a5b 6162 PQRSTUVWXYZ< |
| - | 0000020: 6364 6566 6768 696a 6b6c 6d6e 6f70 7172 cdefghijklmnopqr | + | 00000020: 6364 6566 6768 696a 6b6c 6d6e 6f70 7172 cdefghijklmnopqr |
| - | 0000030: 7374 7576 7778 797a 5d0a 3031 3a09 0920 stuvwxyz].01: | + | 00000030: 7374 7576 7778 797a 5d0a 3031 3a09 0920 stuvwxyz].01: |
| - | 0000040: 4249 4e41 5259 0a30 3132 3334 3536 373a BINARY.01234567: | + | 00000040: 4249 4e41 5259 0a30 3132 3334 3536 373a BINARY.01234567: |
| - | 0000050: 0920 4f43 5441 4c0a 3031 3233 3435 3637 . OCTAL.01234567 | + | 00000050: 0920 4f43 5441 4c0a 3031 3233 3435 3637 . OCTAL.01234567 |
| - | 0000060: 3839 3a09 2044 4543 494d 414c 0a30 3132 89:. DECIMAL.012 | + | 00000060: 3839 3a09 2044 4543 494d 414c 0a30 3132 89:. DECIMAL.012 |
| - | 0000070: 3334 3536 3738 3941 4243 4445 463a 4845 3456789ABCDEF: | + | 00000070: 3334 3536 3738 3941 4243 4445 463a 4845 3456789ABCDEF: |
| - | 0000080: 5841 4445 4349 4d41 4c0a 2921 4023 2425 XADECIMAL.)!@# | + | 00000080: 5841 4445 4349 4d41 4c0a 2921 4023 2425 XADECIMAL.)!@# |
| - | 0000090: 5e26 2a28 0a2e 0a ^&*(... | + | 00000090: 5e26 2a28 0a2e 0a ^&*(... |
| lab46: | lab46: | ||
| </ | </ | ||
| Line 102: | Line 100: | ||
| * The second command-line argument is a sizing throttle (controlling the number of lines your program will display). If no argument, or a **0** is given, display the entire file. | * The second command-line argument is a sizing throttle (controlling the number of lines your program will display). If no argument, or a **0** is given, display the entire file. | ||
| * Each row will display: | * Each row will display: | ||
| - | * a 7-digit hex offset (referring to the first data byte on a given line) | + | * a zero-padded, 8-value |
| * followed by a colon and a single space | * followed by a colon and a single space | ||
| * then eight space separated groups of two bytes | * then eight space separated groups of two bytes | ||
| Line 140: | Line 138: | ||
| An **ioctl(2)** is a method (and system/ | An **ioctl(2)** is a method (and system/ | ||
| - | Here we are accessing the information on our terminal file, retrieving the width and height so that we can make use of them productively in our programs. | + | Here we are accessing the information on our terminal file, retrieving the current |
| Compile and run the above code to see how it works. Try it in different size terminals. Then incorporate the logic into your hex viewer for this project. | Compile and run the above code to see how it works. Try it in different size terminals. Then incorporate the logic into your hex viewer for this project. | ||
| Line 265: | Line 263: | ||
| * no forced redirection of the flow of the process (no seeking to the end of the file to grab a max size only to zip back somewhere else: deal with the data in as you are naturally encountering it). | * no forced redirection of the flow of the process (no seeking to the end of the file to grab a max size only to zip back somewhere else: deal with the data in as you are naturally encountering it). | ||
| * With the exception of any negative values, all numbers should be transacted in hexadecimal (as in the values you assign and compare and manipulate in your code). | * With the exception of any negative values, all numbers should be transacted in hexadecimal (as in the values you assign and compare and manipulate in your code). | ||
| - | * No line must exceed 80 characters in width. | + | * No line of output |
| + | * For code readability, | ||
| * All " | * All " | ||
| * For the highlighted address and lengths, store them in an array of structs (containing the //address// and //length// members). | * For the highlighted address and lengths, store them in an array of structs (containing the //address// and //length// members). | ||
| Line 274: | Line 273: | ||
| * Code must compile cleanly (no warnings or errors) | * Code must compile cleanly (no warnings or errors) | ||
| - | * Use the **-Wall** and **--std=c99** flags when compiling (which occurs automatically when using **make**). | + | * Use the **-Wall** and **--std=gnu99** flags when compiling (which occurs automatically when using **make**). |
| * Code must be nicely and consistently indented (you may use the **indent** tool) | * Code must be nicely and consistently indented (you may use the **indent** tool) | ||
| * Code must utilize the algorithm/ | * Code must utilize the algorithm/ | ||
| Line 300: | Line 299: | ||
| Submitting discrete project " | Submitting discrete project " | ||
| - | -> ../bdt0-20170925-05.tar.gz(OK) | + | -> ../bdt0-20180826-09.tar.gz(OK) |
| SUCCESSFULLY SUBMITTED | SUCCESSFULLY SUBMITTED | ||
| Line 307: | Line 306: | ||
| You should get some sort of confirmation indicating successful submission if all went according to plan. If not, check for typos and or locational mismatches. | You should get some sort of confirmation indicating successful submission if all went according to plan. If not, check for typos and or locational mismatches. | ||
| + | |||
| + | =====Evaluation Criteria===== | ||
| + | |||
| + | What I will be looking for: | ||
| + | |||
| + | < | ||
| + | 130: | ||
| + | *: | ||
| + | *: | ||
| + | *: | ||
| + | *: | ||
| + | *:bdt0:bdt0 runtime output conforms to specifications [26/26] | ||
| + | *:bdt0:bdt0 make check tests succeed [13/13] | ||
| + | *:bdt0:bdt0 make checklines tests succeed [13/13] | ||
| + | *:bdt0:bdt0 make checkcolors tests succeed [13/13] | ||
| + | </ | ||
| + | |||
| + | Additionally: | ||
| + | * Solutions not abiding by spirit of project will be subject to a 25% overall deduction | ||
| + | * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction | ||
| + | * Solutions not utilizing indentation to promote scope and clarity will be subject to a 25% overall deduction | ||
| + | * Solutions not organized and easy to read (assume a terminal at least 90 characters wide, 40 characters tall) are subject to a 25% overall deduction | ||
haas/fall2018/discrete/projects/bdt0.1507040715.txt.gz · Last modified: 2017/10/03 14:25 by 127.0.0.1
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
