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

Next revision
Previous revision
haas:summer2015:data:projects:sln1 [2015/04/04 13:39] – external edit 127.0.0.1haas:summer2015:data:projects:sln1 [2015/05/31 12:08] (current) wedge
Line 11: Line 11:
 This section will document any updates applied to the project since original release: This section will document any updates applied to the project since original release:
  
-  * __revision 1__When compiling with debug support, an error state will occur in the **testing/node/app/** directory, but only for a **make debug** and NOT a **make**. (20150220+  * __revision #__<description> (DATESTAMP
-    * there was a typo in the debug rule, which has been corrected +
-  * __revision 2__: Made some infrastructure improvements to base Makefile (20150404)+
 =====Objective===== =====Objective=====
 To apply our recent list activities with structs and pointers, and see how these two things, when combined, produces an element central to our class explorations. To apply our recent list activities with structs and pointers, and see how these two things, when combined, produces an element central to our class explorations.
Line 256: Line 255:
  
 ====Obtain==== ====Obtain====
-On Lab46, in **/var/public/data/spring2015/**, is a project directory called **sln1**; you do not need to go there, but we will be referencing that path to obtain our own copy. In that path will be the skeleton structure of what we'll be using for many of our projects this semester.+On Lab46, in **/var/public/summer2015/data/**, is a project directory called **sln1**; you do not need to go there, but we will be referencing that path to obtain our own copy. In that path will be the skeleton structure of what we'll be using for many of our projects this semester.
  
 Please type the following (you can be anywhere on lab46): Please type the following (you can be anywhere on lab46):
  
 <cli> <cli>
-lab46:~$ make -C /var/public/data/spring2015/sln1/ copy+lab46:~$ make -C /var/public/summer2015/data/sln1/ copy
 </cli> </cli>
  
Line 273: 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 284: 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 384: 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 396: 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 413: 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 439: 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 481: 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 501: 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 513: 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 520: Line 522:
 </cli> </cli>
  
-===compile project===+====compile project====
 Next, compile the whole project: Next, compile the whole project:
  
Line 572: 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 579: 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 607: 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 641: 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.1428154765.txt.gz · Last modified: 2015/05/28 15:06 (external edit)