User Tools

Site Tools


haas:summer2015:data:projects:sln1

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:summer2015:data:projects:sln1 [2015/05/28 15:06] – [Obtain] wedgehaas:summer2015:data:projects:sln1 [2015/05/31 12:08] (current) wedge
Line 272: Line 272:
 **NOTE:** You may move **sln1** to a different directory structure of your choosing (should you be using different names for things), but you **MUST** retain the **sln1** name for the directory-- there's a lot of administrative logic helping to make our lives easier that is based on that specific name for the project directory. **NOTE:** You may move **sln1** to a different directory structure of your choosing (should you be using different names for things), but you **MUST** retain the **sln1** name for the directory-- there's a lot of administrative logic helping to make our lives easier that is based on that specific name for the project directory.
 ====Overview==== ====Overview====
-You'll see various files and directories located here (one regular file, **Makefile**, and directories). The directory structure (note, not all these directories may yet be present) for the project is as follows:+You'll see various files and directories located here (one regular file, **Makefile**, and directories). The directory structure (note, not all these directories may yet be present) for the project is as follows:
  
 +  * **app**: subdirectory tree containing applications/demos using Data Structures implementations
 +    * **node**: location of node end-user applications
   * **bin**: compiled, executable programs will reside here   * **bin**: compiled, executable programs will reside here
   * **inc**: project-related header files (which we can **#include**) are here   * **inc**: project-related header files (which we can **#include**) are here
Line 283: Line 285:
     * **queue**: location of our queue implementation (a different manipulation of lists)     * **queue**: location of our queue implementation (a different manipulation of lists)
     * ...     * ...
-  * **testing**: subdirectory tree containing our test apps and unit tests +  * **unit**: subdirectory tree containing unit tests, helping to verify correct implementation 
-    * **node**: node-related testing files will be here +    * **node**: node-related unit tests will be here 
-      * **app**: end-user applications, demonstrating use +    * **list**: list-related unit tests will be here
-      * **unit**: unit tests, helping to verify correct implementation +
-    * **list**: list-related testing files +
-      * **app**: end-user applications, demonstrating use +
-      * **unit**: unit tests, helping to verify correct implementation+
     * ...     * ...
- +=====Operating=====
-====Operating====+
  
 The project is driven by a fleet of optimized **Makefile**s, which will facilitate the compiling process for us. The project is driven by a fleet of optimized **Makefile**s, which will facilitate the compiling process for us.
Line 383: Line 380:
 </cli> </cli>
  
-By typing **make upgrade-sll0**, your current work on **sln1** will be copied into a new **sll0** directory (peer to **sln1**), and any new files will be copied in from its project directory in **/var/public/data/spring2015/sll0/**+By typing **make upgrade-sll0**, your current work on **sln1** will be copied into a new **sll0** directory (peer to **sln1**), and any new files will be copied in from its project directory in **/var/public/summer2015/data/sll0/**
  
 As such, it is most advisable to have completed work on **sln1** before upgrading to the **sll0** project, so any work you've done will be immediately available to build upon in the next project (the projects will be comprehensive to one another-- **sll0** will rely on work completed in **sln1**, **sll1** (the project after **sll0**) will rely on the work done in **sll0**, etc.). As such, it is most advisable to have completed work on **sln1** before upgrading to the **sll0** project, so any work you've done will be immediately available to build upon in the next project (the projects will be comprehensive to one another-- **sll0** will rely on work completed in **sln1**, **sll1** (the project after **sll0**) will rely on the work done in **sll0**, etc.).
  
 +====error reporting====
 +To facilitate debugging and correction of errors and warnings in your code at compile time, such compiler messages will be redirected to a text file called **errors** in the base of the project directory.
 +
 +You can view this file to ascertain what errors existed in the last build of the project.
 +
 +With each new project build, this file is overwritten, so you always have the most up-to-date version of compile-time information.
 =====Project Task===== =====Project Task=====
  
Line 395: Line 398:
     * **cpnode()**     * **cpnode()**
     * **rmnode()**     * **rmnode()**
-  * completing some sample applications making use of the node library (**testing/node/app/**)+  * completing some sample applications making use of the node library (**app/node/**)
     * **node-app-arrtolist.c**     * **node-app-arrtolist.c**
     * **node-app-display.c**     * **node-app-display.c**
Line 412: Line 415:
   * **rmnode()** - removes/deallocates (frees the memory allocated to) a node    * **rmnode()** - removes/deallocates (frees the memory allocated to) a node 
  
-None of these files denote an entire runnable program. These are merely standalone functions. The various programs under the **testing/** directory will use these functions in addition to their application logic to create complete executable programs.+None of these files denote an entire runnable program. These are merely standalone functions. The various programs under the **app/** and **unit/** directories will use these functions in addition to their application logic to create complete executable programs.
  
 You will also notice there are function prototypes for these node library functions in the **node.h** header file, located in the **inc/** subdirectory, which you'll notice all the related programs you'll be playing with in this project are **#include**ing. You will also notice there are function prototypes for these node library functions in the **node.h** header file, located in the **inc/** subdirectory, which you'll notice all the related programs you'll be playing with in this project are **#include**ing.
Line 438: Line 441:
 Again, same details apply here, only the Makefile system automates the library linking. All we have to do is **#include** the appropriate files. Again, same details apply here, only the Makefile system automates the library linking. All we have to do is **#include** the appropriate files.
 ====Node application programs==== ====Node application programs====
-Upon successful implementation of the node library, take a look in **testing/node/app/**, which will have (among others) the following files:+Upon successful implementation of the node library, take a look in **app/node/**, which will have (among others) the following files:
  
   * **node-app-display.c**   * **node-app-display.c**
Line 480: Line 483:
  
 ====Node library unit tests==== ====Node library unit tests====
-In **testing/node/unit/**, you will find 3 files (along with a **Makefile**):+In **unit/node/**, you will find 3 files (along with a **Makefile**):
  
   * **unit-cpnode.c** - unit test for **cpnode()** library function   * **unit-cpnode.c** - unit test for **cpnode()** library function
Line 500: Line 503:
     * ask questions to get clarification!     * ask questions to get clarification!
  
-====Building the code====+=====Building the code=====
 You've made changes to your node library implementation, or **node-app-display.c**, and are ready to see your results. What do we do? You've made changes to your node library implementation, or **node-app-display.c**, and are ready to see your results. What do we do?
  
Line 512: Line 515:
 **OR:** You may want to have **two** terminals open- in one you are situated in **~/src/data/sln1/src/node/** editing away, and in the other you are in **~/src/data/sln1/**; this way you can take care of development activities AND easily check your results, without constantly navigating back and forth between various locations. **OR:** You may want to have **two** terminals open- in one you are situated in **~/src/data/sln1/src/node/** editing away, and in the other you are in **~/src/data/sln1/**; this way you can take care of development activities AND easily check your results, without constantly navigating back and forth between various locations.
  
-===cleaning things out===+====cleaning things out====
 If you've already done this a few times, you may want to clean things out and do a fresh compile (never hurts, and might actually fix some problems): If you've already done this a few times, you may want to clean things out and do a fresh compile (never hurts, and might actually fix some problems):
  
Line 519: Line 522:
 </cli> </cli>
  
-===compile project===+====compile project====
 Next, compile the whole project: Next, compile the whole project:
  
Line 571: Line 574:
  
  
-====Reference Implementation====+=====Reference Implementation=====
 As the layers and complexities rise, narrowing down the source of errors becomes increasingly important. As the layers and complexities rise, narrowing down the source of errors becomes increasingly important.
  
Line 578: Line 581:
 To aid you in your development efforts, you now have the ability to import a functioning node implementation into your project for the purposes of testing unit test functionality (so you can see what you SHOULD be getting, then go back and continue working on your implementation) To aid you in your development efforts, you now have the ability to import a functioning node implementation into your project for the purposes of testing unit test functionality (so you can see what you SHOULD be getting, then go back and continue working on your implementation)
  
-===Using the test reference implementation===+====Using the test reference implementation====
 You'll notice that, upon running **make help** in the base-level Makefile, the following new options appear (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):
  
Line 606: Line 609:
 **__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). **__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).
  
-===Reverting back to using your code===+====Reverting back to using your code====
 If you were trying out the reference implementation to verify queue functionality, and wanted to revert back to your own code, it is as simple as: If you were trying out the reference implementation to verify queue functionality, and wanted to revert back to your own code, it is as simple as:
  
Line 640: Line 643:
  
 This top-level **verify-node.sh** script gives you the 30,000 foot view... what is the current status of your node library implementation? From there, you take whatever appropriate action is necessary. This top-level **verify-node.sh** script gives you the 30,000 foot view... what is the current status of your node library implementation? From there, you take whatever appropriate action is necessary.
 +
 =====Submission===== =====Submission=====
- +{{page>haas:summer2015:common:submitblurb#DATA&noheader&nofooter}}
-====Project Submission=== +
-When you are done with the project and are ready to submit it, you simply run **make submit**: +
- +
-<cli> +
-lab46:~/src/data/sln1$ make submit +
-... +
-</cli> +
-  +
-====Submission Criteria==== +
-To be successful in this project, the following criteria must be met: +
- +
-  * Project must be submit on time, by the posted deadline. +
-    * Late submissions will lose 25% credit per day, with the submission window closing on the 4th day following the deadline. +
-  * All code must compile cleanly (no warnings or errors) +
-    * all requested functions must be implemented in the related library +
-    * all requested functionality must conform to stated requirements (either on this project page or in comment banner in source code files themselves). +
-  * Executed programs must display in a manner similar to provided output +
-    * output formatted, where applicable, must match that of project requirements +
-  * Processing must be correct based on input given and output requested +
-  * Output, if applicable, must be correct based on values input +
-  * Code must be nicely and consistently indented (you may use the **indent** tool) +
-  * Code must be commented +
-    * Any "to be implemented" comments **MUST** be removed +
-      * these "to be implemented" comments, if still present at evaluation time, will result in points being deducted. +
-    * Sufficient comments explaining the point of provided logic **MUST** be present +
-  * Any and all functions written must have, **at most**, 1 **return** statement +
-    * points will be lost for solutions containing multiple return statements in a function. +
-  * Track/version the source code in a repository +
-  * Submit a copy of your source code to me using the **submit** tool (**make submit** will do this) by the deadline. +
haas/summer2015/data/projects/sln1.1432825606.txt.gz · Last modified: 2015/05/28 15:06 by wedge