Differences

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

--- haas:fall2014:data:projects:dls0 [2014/11/03 14:22] – [Reference Implementation] wedge
+++ haas:fall2014:data:projects:dls0 [2014/11/19 14:42] (current) – [Errata] wedge
@@ Line 11: / Line 11: @@
 This section will document any updates applied to the project since original release:
-  * __revision #__: <description> (datestring)
+  * __revision 1__: logic error fix and output tweaks to various unit tests (20141105)
+    * logic error in **unit-cpstack**, preventing most of its tests from running (FIXED)
+      * changed ending while to do-while loop
+      * loop conditions were originally (i == 0) && (status != 0), should have been != -1 for both
+    * missing double newline after certain "should be" outputs in **unit-pop** (FIXED)
+    * Some additional aesthetic enhancements to the base Makefile were made.
+  * __revision 2__: Makefile enhancements to facilitate project usage (20141107)
+    * test reference implementation feature enhancements
+      * a slight change to the option to enable (**make use-test-reference**)
+      * a new option to restore your own code (**make use-your-own-code**)
+    * **src/stack/Makefile** now cleans up vim .swp and nano .save files
+    * **testing/stack/unit/Makefile** fixes an off-by-one pretty display spacing issue
+  * __revision 3__: verify-stack.sh enhancements (20141119)
+    * now includes absolute totals
 =====Objective=====
@@ Line 73: / Line 86: @@
   * **peek**: the ability to gain access to the top node without removing it from the stack
   * **is the stack empty?**: the ability to query the stack and determine if it is empty or non-empty (or perhaps if non-empty, how full is it?)
-  * **purge**: the ability to empty/clear out the stack
 While we may be implementing these supplemental functions, it should be noted that not only are they in no way necessary for using a stack, they could be detrimental (just as relying on **qty** in the sll projects was), as one could rely on them as a crutch.
@@ Line 222: / Line 234: @@
 ===Using the test reference implementation===
-You'll notice that, upon running **make help** in the base-level Makefile, the following new option appears (about halfway in the middle):
+You'll notice that, upon running **make help** in the base-level Makefile, the following new options appear (about halfway in the middle):
 <cli>
 **                                                                    **
-** make test-reference      - use working implementation object files **
+** make use-test-reference  - use working implementation object files **
+** make use-your-own-code   - use your node/list implementation code  **
 **                                                                    **
 </cli>
-In order to make use of it, you'll need to run **make test-reference** from the base of your **dls0** project directory, as follows:
+In order to make use of it, you'll need to run **make use-test-reference** from the base of your **dls0** project directory, as follows:
 <cli>
-lab46:~/src/data/dls0$ make test-reference
+lab46:~/src/data/dls0$ make use-test-reference
 make[1]: Entering directory '/home/wedge/src/data/dls0/src'
 make[2]: Entering directory '/home/wedge/src/data/dls0/src/list'
@@ Line 275: / Line 288: @@
 ...
 </cli>
-===Caveats===
-**__NOTE__:** The test reference node and list implementations are considered temporary-- any potential project-wide change (such as a **make update** or a **make clean**, or anything that could update the timestamps on source files) will cause it to be discarded on a subsequent build (running **make** or **make debug**).
-You can tell from the compile output if it is in place (none of the individual node or list library source files get built, only the libraries themselves are assembled).
-And again, clearing out the test reference implementation is as easy as running **make clean**; if you have a working node and list implementation (from successfully completing the prerequisite project(s)), you can still try out the test reference implementation- it will not touch your code in any way. It merely copies in pre-compiled object files and convinces the make system that they are more up-to-date than your source code, and so it opts not to recompile those files.
-This could also be a good way to verify that your node and list implementations are up to par, as you can now run the unit tests and verification scripts against your implementation, and my test reference implementation.
 **__Debugging__:** When using the test reference implementation, you will not be able to debug the contents of the node and list functions (the files provided do not have debugging symbols added), so you'll need to take care not to step into these functions (it would be just like stepping into **printf()**. You can still compile the project with debugging support and debug (as usual) those compiled functions (ie the stack functions).
-===Keeping Reference Implementation Longer Term===
+===Reverting back to using your code===
-Let's say, for whatever reason, you'd like to keep some or all of the reference implementation object files around, leaving them impervious to project-wide changes.
+If you were trying out the reference implementation to verify stack functionality, and wanted to revert back to your own code, it is as simple as:
-This is possible, and all it involves is an edit of 2 Makefiles.
-If you'd like to do this:
+<cli>
+lab46:~/src/data/dls0$ make use-your-own-code
-Edit **src/node/Makefile** and **src/list/Makefile**, at the bottom of both files you'll see:
+Local node/list implementation restored, run 'make clean; make' to build everything.
+lab46:~/src/data/dls0$
-<code>
+</cli>
-clean:
-        rm -f *.swp *.o $(OBJ) core
-</code>
-Let's say you want to keep all of the reference implementation around for both node and list. To do that, change the **clean** rule in both files as follows:
-<code>
-clean:
-        rm -f *.swp core
-</code>
-We basically removed any and all references to the compiled object files "**<nowiki>*.o $(OBJ)</nowiki>**" from the **clean** rule (which is responsible for removing them). This will keep them in place permanently, and unless you make changes to the particular source files, they will remain untouched and continue to be utilized.
-This isn't something I would consider a recommended action- it really would only be useful for those who have not successfully completed prior projects, and are looking to not fall further behind. If you've got a working node and list implementation (and it passes all the unit test and verification scripts), use yours.
 ====List Library unit tests====
 As a result of the required changes to **display()** and the incorporation of **qty**, pertinent list unit tests will be enhanced, so you can make use of them to ensure implementation compliance.
+Be sure to run the various list unit tests and verification scripts to see which functions have fallen out of compliance with the list struct specification changes issued in this project. The **verify-list.sh** script can be especially useful in getting a big picture view of what work is needed.
 ====Stack library unit tests====
 In **testing/stack/unit/**, you will find these files:
@@ Line 353: / Line 342: @@
 Note this is a DIFFERENT approach than you would have taken in the program with sll2- you're to use stack functionality to aid you with the heavy lifting. While you will still make use of list functionality for grabbing the initial input, the actual palindrome comparison processing needs to heavily involve stacks.
+=====Expected Results=====
+To assist you in verifying a correct implementation, a fully working implementation of the node, list, and stack libraries should resemble the following (when running the respective verify script):
+====node library====
+Here is what you should get for node:
+<cli>
+lab46:~/src/data/dls0$ bin/verify-node.sh
+====================================================
+=    Verifying Doubly-Linked Node Functionality    =
+====================================================
+  [mknode] Total:   5, Matches:   5, Mismatches:   0
+  [cpnode] Total:   6, Matches:   6, Mismatches:   0
+  [rmnode] Total:   2, Matches:   2, Mismatches:   0
+====================================================
+ [RESULTS] Total:  13, Matches:  13, Mismatches:   0
+====================================================
+lab46:~/src/data/dls0$
+</cli>
+As no coding changes were needed in the node library, these results should be identical to that of a fully functioning node implementation from the **dll0** project.
+====list library====
+Here is what you should get for list:
+<cli>
+lab46:~/src/data/dls0$ bin/verify-list.sh
+====================================================
+=    Verifying Doubly-Linked List Functionality    =
+====================================================
+  [mklist] Total:   6, Matches:   6, Mismatches:   0
+  [cplist] Total:  30, Matches:  30, Mismatches:   0
+  [rmlist] Total:   3, Matches:   3, Mismatches:   0
+  [append] Total:  22, Matches:  22, Mismatches:   0
+  [insert] Total:  22, Matches:  22, Mismatches:   0
+  [obtain] Total:  23, Matches:  23, Mismatches:   0
+ [display] Total:  10, Matches:  10, Mismatches:   0
+[findnode] Total:  11, Matches:  11, Mismatches:   0
+[sortlist] Total:   6, Matches:   6, Mismatches:   0
+[swapnode] Total:   7, Matches:   7, Mismatches:   0
+====================================================
+ [RESULTS] Total: 140, Matches: 140, Mismatches:   0
+====================================================
+lab46:~/src/data/dls0$
+</cli>
+Due to the re-introduction of **qty** into list (impacting actions performed by **mklist()**, **append()**, **insert()**, and **obtain()**), along with feature additions to **display()**, those functions saw additional tests performed, so our original max total of **102** from **dll0** has now changed to **140** (ie various **qty** and **display()**-related tests adding to the previous total).
+Remember though- aside from the minor change of adding **qty** and enhancing **display()**, all remaining list functions need no change (and **mklist()/append()/insert()/obtain()** remained largely unchanged).
+====stack library====
+Here is what you should get for stack:
+<cli>
+lab46:~/src/data/dls0$ bin/verify-stack.sh
+===================================================
+=   Verifying Doubly-Linked Stack Functionality   =
+===================================================
+[mkstack] Total:   3, Matches:   3, Mismatches:   0
+[cpstack] Total:   8, Matches:   8, Mismatches:   0
+[rmstack] Total:   3, Matches:   3, Mismatches:   0
+   [push] Total:  30, Matches:  30, Mismatches:   0
+    [pop] Total:  25, Matches:  25, Mismatches:   0
+   [peek] Total:  24, Matches:  24, Mismatches:   0
+[isempty] Total:  13, Matches:  13, Mismatches:   0
+===================================================
+[RESULTS] Total: 106, Matches: 106, Mismatches:   0
+===================================================
+lab46:~/src/data/dls0$
+</cli>
 =====Submission Criteria=====
 To be successful in this project, the following criteria must be met:

Lab46 Wiki

User Tools

Site Tools

Differences

Page Tools