This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
haas:fall2020:discrete:projects:bdt2 [2020/09/29 21:37] – [Basic functionality] wedge | haas:fall2020:discrete:projects:bdt2 [2020/09/30 16:35] (current) – [Implementation Restrictions] wedge | ||
---|---|---|---|
Line 63: | Line 63: | ||
* **justification** implies some thoughtful why/how style comments explaining how a particular use of one of these statements is effective and efficient (not: "I couldn' | * **justification** implies some thoughtful why/how style comments explaining how a particular use of one of these statements is effective and efficient (not: "I couldn' | ||
* absolutely **NO** infinite loops (**while(1)** or the like). | * absolutely **NO** infinite loops (**while(1)** or the like). | ||
+ | * ALL variables must be well and pertinently named, and be no fewer than 4 symbols in length | ||
* 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 telling; no " | * 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 telling; no " | ||
* All " | * All " | ||
Line 84: | Line 85: | ||
In bdt1, the focus is the FIRST byte of difference. Here in bdt2, we are looking at supporting multiple bytes of difference, perhaps even occurring on the same line. | In bdt1, the focus is the FIRST byte of difference. Here in bdt2, we are looking at supporting multiple bytes of difference, perhaps even occurring on the same line. | ||
- | ====Bonus opportunities==== | ||
- | Some ideas to enhance your program for potential bonus points: | ||
- | * accept some sort of mode argument, | + | =====Access variables in your C program===== |
- | * 0: display as project specifies | + | Setting |
- | * 1: display | + | |
- | * additional modes as justified | + | |
- | * accept numeric offset arguments, 1 for each file, to instruct your tool where they should start reading/ | + | |
- | * this would be a way for your tool to natively support " | + | |
- | * this would likely require displaying the pertinent offsets for each file. | + | |
- | * you could endeavor to explore some algorithmic enhancements to automatically detect additional points of difference. Note that this could be rather fragile, depending on the identified differences. | + | |
- | =====Output===== | + | For this project, you can make use of the **getenv(3)** function, provided in the C standard library (symbols included via the **stdlib.h** file). |
- | A basic mockup | + | |
+ | Excerpted from the **getenv(3)** manual page: | ||
<cli> | <cli> | ||
- | lab46: | + | NAME |
- | 00000090: 0011 2233 4455 6677 8899 aabb ccdd eeff | 0011 2233 4455 6677 8899 aabb ccdd eeff | + | |
- | 000000a0: 55aa 66bb 0401 77cc 88dd 99ee aaff 89af | 55aa 66bb 0501 77cc 88dd 99ee aaff 89af | + | |
- | 000000b0: 9988 7766 5544 3322 1100 ffee ddcc bbaa | 9988 7766 5544 3322 1100 ffee ddcc bbaa | + | SYNOPSIS |
- | lab46: | + | # |
+ | |||
+ | char *getenv (const char *name); | ||
+ | |||
+ | DESCRIPTION | ||
+ | The getenv() function searches the environment list to find | ||
+ | the environment variable name, and returns a pointer to the | ||
+ | | ||
+ | |||
+ | RETURN VALUE | ||
+ | The getenv() function returns a pointer to the value in the | ||
+ | environment, | ||
</ | </ | ||
+ | |||
+ | Your "const char *name" is the name of the variable set (for the purposes of this project, call it **THROTTLE**). Check the example execution to see it in use. | ||
+ | |||
+ | You may notice similarity in parameter usage to that of other standard library functions that you've utilized, like **atoi(3)**. | ||
+ | |||
+ | **NOTE:** You may **not** want to nest your **getenv(3)** call as a parameter to **atoi(3)**; | ||
+ | =====Reference Implementations===== | ||
+ | To assist you in your off-system development efforts, the **bin/** directory in the bdt2 project (available on lab46 via grabit) has 2 compiled binaries: | ||
+ | |||
+ | * bin/ | ||
+ | * bin/ | ||
+ | |||
+ | Since the Raspberry Pi uses an ARM processor and lab46 uses an Intel processor, binaries are not compatible across architectures. | ||
+ | |||
+ | If you are not sure what architecture your development system uses, run the **uname -m** command: | ||
+ | |||
+ | <cli> | ||
+ | lab46:~$ uname -m | ||
+ | x86_64 | ||
+ | </ | ||
+ | |||
+ | <cli> | ||
+ | yourpi:~$ uname -m | ||
+ | aarch64 | ||
+ | </ | ||
+ | |||
+ | Your bdt2 implementation should match the behaviour and appearance of these reference implementations. | ||
+ | =====Output===== | ||
+ | An example of expected output: | ||
+ | |||
+ | {{ : | ||
+ | |||
=====Submission===== | =====Submission===== | ||
To successfully complete this project, the following criteria must be met: | To successfully complete this project, the following criteria must be met: | ||
Line 122: | Line 159: | ||
<cli> | <cli> | ||
- | $ submit discrete | + | lab46: |
- | Submitting discrete project "bdt1": | + | Submitting discrete project "bdt2": |
- | -> bdt1.c(OK) | + | -> bdt2.c(OK) |
SUCCESSFULLY SUBMITTED | SUCCESSFULLY SUBMITTED | ||
Line 130: | Line 167: | ||
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. | ||
+ | |||
+ | What I will be looking for: | ||
< | < | ||
- | 156:bdt1:final tally of results (156/156) | + | 195:bdt2:final tally of results (195/195) |
- | *:bdt1:bdt1.c compiles cleanly, no compiler messages [13/13] | + | *:bdt2:bdt2.c compiles cleanly, no compiler messages [13/13] |
- | *:bdt1:bdt1.c implements only specified algorithm [26/26] | + | *:bdt2:bdt2.c implements only specified algorithm [26/26] |
- | *:bdt1:bdt1.c code conforms to project specifications [26/26] | + | *:bdt2:bdt2.c code conforms to project specifications [26/26] |
- | *:bdt1:bdt1.c implementation free from restrictions [26/26] | + | *:bdt2:bdt2.c implementation free from restrictions [26/26] |
- | *:bdt1:bdt1 runtime output conforms to specifications | + | *:bdt2:bdt2.c implements and utilizes THROTTLE usage [13/13] |
- | *:bdt1:bdt1 eval check tests succeed | + | *: |
- | *:bdt1:bdt1 committed, pushed to lab46 repository [13/13] | + | *: |
+ | *:bdt2:bdt2 runtime output matches reference | ||
+ | *:bdt2:bdt2 committed, pushed to lab46 repository [26/26] | ||
</ | </ | ||
+ | |||
+ | 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 are subject to a 25% overall deduction |