Lab46 Wiki

User Tools

Site Tools

You are here: start » haas » fall2020 » discrete » projects » bdt2
haas:fall2020:discrete:projects:bdt2

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
haas:fall2020:discrete:projects:bdt2 [2020/09/29 21:37] – [Basic functionality] wedgehaas: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't think of any other way to do it").     * **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't think of any other way to do it").
   * 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 "ungetting" data back into the file).   * 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 "ungetting" data back into the file).
   * All "arrays" must be declared and referenced using ONLY pointer notation, NO square brackets.   * All "arrays" must be declared and referenced using ONLY pointer notation, NO square brackets.
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, a number, that would alter the behavior of your tool. Such as: +=====Access variables in your C program===== 
-    * 0: display as project specifies +Setting a variable in your terminal (or even on the command-line prefixing the execution of your bdt2 tool) allows you to communicate information to your program, enabling it to change or alter its default behaviour (just as command-line arguments do)
-    * 1: display on separate lines, vs. the same line of difference (first file, newline, second file). +
-    * additional modes as justified +
-  * accept numeric offset arguments, 1 for each file, to instruct your tool where they should start reading/comparing +
-    * this would be a way for your tool to natively support "additional" points of difference without needing an overly-complicated algorithm. You would be able to specify the starting points, from visual inspection on previous runs of the tool or **xxd(1)**, which would add considerable debugging value. +
-    * 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 (pictures coming soon) of desired output:+ 
 +Excerpted from the **getenv(3)** manual page:
  
 <cli> <cli>
-lab46:~/src/discrete/bdt1$ ./bdt1 in/sample0.txt in/sample0.off +NAME 
-00000090: 0011 2233 4455 6677 8899 aabb ccdd eeff | 0011 2233 4455 6677 8899 aabb ccdd eeff +       getenv - get an environment variable 
-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:~/src/discrete/bdt1$ +       #include <stdlib.h> 
 + 
 +       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 
 +       corresponding value string. 
 + 
 +RETURN VALUE 
 +       The getenv() function returns a pointer to the value in the 
 +       environment, or NULL if there is no match.
 </cli> </cli>
 +
 +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)**; in the event of an error (or no such variable being set), a NULL tends to cause a segmentation fault.
 +=====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/ref_bdt2.aarch64 (use on the Raspberry Pi)
 +  * bin/ref_bdt2.x86_64 (use on lab46, or an intel-compatible system)
 +
 +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>
 +
 +<cli>
 +yourpi:~$ uname -m
 +aarch64
 +</cli>
 +
 +Your bdt2 implementation should match the behaviour and appearance of these reference implementations.
 +=====Output=====
 +An example of expected output:
 +
 +{{ :haas:fall2020:discrete:projects:bdt2_output.jpg |}}
 +
 =====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 bdt1 bdt1.c +lab46:~/src/desig/bdt2$ submit discrete bdt2 bdt2.c 
-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:
  
 <code> <code>
-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 [26/26] +*:bdt2:bdt2.c implements and utilizes THROTTLE usage [13/13] 
-*:bdt1:bdt1 eval check tests succeed [26/26] +*:bdt2:bdt2.c implements and utilizes a flag in logic [13/13] 
-*:bdt1:bdt1 committed, pushed to lab46 repository [13/13]+*:bdt2:bdt2 runtime output conforms to reference [26/26] 
 +*:bdt2:bdt2 runtime output matches reference [26/26] 
 +*:bdt2:bdt2 committed, pushed to lab46 repository [26/26]
 </code> </code>
 +
 +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
haas/fall2020/discrete/projects/bdt2.1601415468.txt.gz · Last modified: 2020/09/29 21:37 by wedge

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki