Differences

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

--- notes:data:fall2022:projects:sln1 [2022/09/11 13:41] – [PROGRAM] hcordell
+++ notes:data:fall2022:projects:sln1 [2022/09/15 02:22] (current) – [Useful commands] bbarrow1
@@ Line 1: / Line 1: @@
 =====BACKGROUND=====
-Building on top of what we did in sln0 of making pseudocode and pictures of what happened in our pseudocode. We are actually starting to implement that into actual c code. The pseudocode and pictures should give you a good idea of what we are actually trying to accomplish in this project, sln1.
+In this project, we will be building on top of what we did in sln0. In sln0, we made pseudocode and submitted pictures of what happened in our pseudocode. For sln1, we are beginning to implement that into actual c code. The pseudocode and pictures should give us a good idea of what we are actually trying to accomplish in this project. Remember: Nodes only hold a value and a pointer. This pointer will point to the next node, unless it is the last node, in which case it points to NULL. If it is the only node, it qualifies as the last node.
 =====SPECIFICATIONS=====
-In simple words, after you've grabbed the project files, it is our task to edit the cp.c mk.c, and rm.c files inside the '//sln1/src/node/ //' directory and make them work.
+In simple words, after you've grabbed the project files, it is our task to edit the cp.c mk.c, and rm.c files inside the '//sln1/src/node/ //' directory and make them work. cp.c standing for copy, mk.c is our program that creates node, and rm.c is our program to remove nodes.
 We have many files for reference at our disposal. The most important files to execute, read, and analyze are contained within the '//sln1/unit/node/ //' directory. These source code files will be your guides, to get your files to work.
@@ Line 9: / Line 11: @@
 As explained down below in the Unit Test section, another set of important files is contained within the '//sln1/bin/ //' directory. Run these files for testing.
-//You will find a "node.h" file in the provided include directory (sln1/inc/node.h) which provides a **struct node** that will serve as the structure of the Node that you will be manipulating //
+//You will find a "node.h" file in the provided include directory (sln1/inc/node.h) which provides a **struct node** that will serve as the structure of the Node that you will be manipulating // (may find information pertaining to the various node options)
-===Reminder===
+The mknode() program should allocate memory for a new node, verify that the allocation was successful, and then populate and return the address to the new node. The rmnode() program should only de-allocate the node passed into the program.
+=====Reminder=====
 Whenever you allocate a resource, check that the memory allocation, be that for a file or a pointer, is valid. In other words, check that your pointer/file is not NULL.
@@ Line 25: / Line 28: @@
 </blockquote>
 =====PROGRAM=====
-Program should be able to perform specifications displayed inside the files. For example, inside src/node/mk.c, rm.c, and cp.c should be able to make nodes, remove nodes, and copy nodes, respectively. Some files inside app/node/ have little to no needed code and only test your src/node/ files. If your files are made correctly and to project specifications it should work well and similar to some of your sln0 pseudocode. Most, if not all, of the specifications will be commented inside the files with what you need to do.
+Program should be able to perform specifications displayed inside the files. For example, inside src/node/mk.c, rm.c, and cp.c should be able to make nodes, remove nodes, and copy nodes, respectively. Some files inside app/node/ have little to no needed code and only test your src/node/ files. If your files are made correctly and to project specifications it should work well and similar to some of your sln0 pseudocode. Most, if not all, of the specifications will be commented inside the files with what you need to do.\\
+When making the three programs, first look at "node.h" as it will tell you how to go about programing them, for example when making a node you know that the node will have a node->right and a node->info.
+When copying the node you do not need to allocate space, rather use an existing function.
+When removing you should think about how malloc works and what the node would become.
+In each of these codes think about what it is you want to be returned.\\
 **Directories containing vital project information:**
-  * ''/src/node/''
+  * ''/inc/'' contains your header files used in most programs(contains options used such as "right" and "info")
-  * ''/app/node/''
+  * ''/unit/node/'' contains your unit tests for mk.c, rm.c, and cp.c
-  * ''/unit/node/''
+  * ''/src/node/'' contains the mk.c, rm.c, and cp.c files
-  * ''/inc/''
+  * ''/app/node/'' supplemental information/tests to further your understanding of the "node code"
-  * /inc/ contains your header files used in most programs
-  * /unit/node/ contains your unit tests for mk.c, rm.c, and cp.c
-  * /src/node/ contains the mk.c, rm.c, and cp.c files
-  * /app/node/ is the main part of the project and your tasks to do
 =====OUTPUT SPECIFICATIONS=====
-This may refer to output in regards to the ''/app/node/'' files.
+There does not appear to be any direct output required for this project.
+<fs small>Stay tuned for any updates!</fs>
-<fs small>update with more information</fs>
 =====UNIT TESTS=====
 It is part of our evaluation to get as many tests as possible to match. Ideally, all should match.
-For your initial unit tests of mknode(), cpnode(), and rmnode() you need to build your unit tests first. To do this you are going to want to run **make all** inside of your src/node folder. Alternatively, you can run the **make** command on your base //sln1// directory. If you don't do this, the next makefile will produce errors. This process can be done on lab46 or a linux-esque device(your pi),  however implementation on other OS is not guaranteed. The example will be using lab46.
+To test your implementation, **navigate to your base //sln1// directory**, run **make** and then **make check**.
+Note- If you are not in your base directory you might run into issues with make and make check.
+This process can be done on lab46 or a linux-esque device(your pi),  however implementation on other OS is not guaranteed. This example will be done using lab46.
 <cli>
-USERNAME@lab46:~/src/fall2022/sln1/src/node$ make all
+USERNAME@lab46:~/src/fall2022/sln1$ make
 Building the NODE library
 =======================================
@@ Line 56: / Line 59: @@
 [CC]   rm.c                 ... OK
        libnode.{a,so}       ... SUCCESS
-</cli>
-{{ :notes:data:fall2022:projects:make_librarysln.jpg?nolink |}}
-Afterwards, you will want to navigate to the unit/node directory and run **make all** there as well.
-<cli>
-USERNAME@lab46:~/src/fall2022/sln1/unit/node$ make all
 Building NODE library unit tests
 =======================================
@@ Line 70: / Line 66: @@
 [CC]   unit-rmnode.c        ... OK
 [CP] Copying to sln1/bin/   ... SUCCESS
+</cli>
+<cli>
+USERNAME@lab46:~/src/fall2022/sln1$ make check
+======================================================
+=    Verifying Singly-Linked  Node Functionality     =
+======================================================
+    [mknode] Total:   4, Matches:   4, Mismatches:   0
+    [cpnode] Total:   5, Matches:   5, Mismatches:   0
+    [rmnode] Total:   2, Matches:   2, Mismatches:   0
+======================================================
+   [RESULTS] Total:  11, Matches:  11, Mismatches:   0
+======================================================
 </cli>
-Afterwards, your unit tests will be available inside of the bin folder of your sln1 directory.
-Run these by executing the verify scripts. Example outputs are below.
-CP Node Verify:
+If you run into any issues (perhaps from running make **not** in the base directory), try **make clean && make** to rebuild your project.  Typing **cat errors** at the prompt, may quite beneficial in figuring out what exactly is making your unit tests come back as mismatches. You can also run **make debug** instead of **make**, to get the errors immediately.
+You can run single unit tests via **bin/<unit test name>**.
+=====Useful commands=====
+Get a full list of options:
 <cli>
-USERNAME@lab46:~/src/fall2022/sln1/bin$ ./verify-cpnode.sh
+USERNAME@lab46:~/src/fall2022/sln1$ make help
-[test  0] MATCH
-[test  1] MATCH
-[test  2] MATCH
-[test  3] MATCH
-[test  4] MATCH
-Total: 5, Matches: 5, Mismatches: 0
 </cli>
-MK Node Verify:
+Verify that the implementation of your nodes is functional:
 <cli>
-USERNAME@lab46:~/src/fall2022/sln1/bin$ ./verify-mknode.sh
+USERNAME@lab46:~/src/fall2022/sln1$ make check
-[test  0] MATCH
-[test  1] MATCH
-[test  2] MATCH
-[test  3] MATCH
-Total: 4, Matches: 4, Mismatches: 0
 </cli>
-RM Node Verify:
+Remove all compiled binaries:
 <cli>
-USERNAME@lab46:~/src/fall2022/sln1/bin$ ./verify-rmnode.sh
+USERNAME@lab46:~/src/fall2022/sln1$ make clean
-[test  0] MATCH
-[test  1] MATCH
-Total: 2, Matches: 2, Mismatches: 0
 </cli>
-====Another set of useful commands are:====
+Make and print errors immediately:
 <cli>
-USERNAME@lab46:~/src/fall2022/sln1/bin$ Make help
+USERNAME@lab46:~/src/fall2022/sln1$ make debug
 </cli>
-//Make help displays all available options for the Make command//
+Submit assignment:
 <cli>
-USERNAME@lab46:~/src/fall2022/sln1/bin$ Make check
+USERNAME@lab46:~/src/fall2022/sln1$ make submit
 </cli>
-//Make check will help you verify that the implementation of your nodes is functional.//
+Update project (if any verify scripts/etc changed)
+<cli>
+USERNAME@lab46:~/src/fall2022/sln1$ make update
+</cli>
+Upgrade to the next project (sll0)\\
+**Note this takes current sln1 directory and copies your codes into sll0, use only when done.**
+<cli>
+USERNAME@lab46:~/src/fall2022/sln1$ make upgrade-sll0
+</cli>
+=====NULL vs UNDEFINED=====
+As you explore this project and it's related files, you'll likely find this definition in //support.h//:
+<code c>
+#if !defined(UNDEFINED)
+    #define UNDEFINED ((void*)1)
+#endif
+</code>
+You might be wondering the need for this line; why not just use NULL? Conceptually, NULL and UNDEFINED mean the same thing: nothing. However, due to the nature of our unit tests, we need a way to differentiate between untouched (undefined) memory and memory that has been modified to be NULL. It is for this reason that rmnode() is to return NULL and not UNDEFINED.
+=====NOTE=====
+Before running the 'make' command, remove the "errors" file because running make appends new errors onto the end of the errors file. This means that when you read the errors file you will be reading old errors that may or may not exist since 'make' does not delete the old errors file in this project.
+Also, use the 'make clean' command before running 'make' after adjusting your code, I found that I was rerunning old executables with non-functional code even after I made changes to it until I ran 'make clean'. If your code is failing to compile or if it is mismatched, try a make clean as well.

Lab46 Wiki

User Tools

Site Tools

Differences

Page Tools