This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
notes:data:fall2022:projects:sll2 [2022/09/29 16:06] – [PROGRAM] zswartwo | notes:data:fall2022:projects:sll2 [2022/10/05 18:05] (current) – [Basic GDB] gsuber | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | =====BACKGROUND===== | + | =====FIXES===== |
+ | If you are getting unexplainable build errors on your own system when you run 'make default' | ||
+ | Firstly, it can be because your using the wrong version of gcc, the sll2 project files can only compile with version 9 of gcc. You can use the same version of gcc as lab46 by using the following commands (assuming you are using a Raspberry Pi with it's default OS) in this link: | ||
+ | [[https:// | ||
+ | |||
+ | If that does not fix the problem then you need to edit one of the Makefiles in the sll2 project directory. The offending Makefile is in the /src/list/ directory. Run the following command to edit that file: | ||
+ | <cli> | ||
+ | USER@SYSTEM: | ||
+ | </ | ||
+ | remove the following line of code (after the line that says '' | ||
+ | <cli> | ||
+ | @date +' | ||
+ | </ | ||
+ | Then try building the project again. | ||
+ | |||
+ | =====BACKGROUND===== | ||
+ | In previous weeks we have been building our list library to include some tools to check our lists for various things. This week we will add functionality modify its contents with a bit more precision. Ever thought you might want to clear the contents and/or remove your list entirely; once you are done with it, of course... Maybe you want to sort your list by the values its nodes contain or simply remove a node and move some things around yourself? If so, cool. Make it do the thing. | ||
| | ||
+ | This week we will finish up the core functions by adding obtain to our list library. | ||
+ | The three core functions are insert, append, and obtain. | ||
+ | |||
+ | This week you will find five new '' | ||
We have 5 tasks to do for full credit. These are: | We have 5 tasks to do for full credit. These are: | ||
- | * clear() | + | * clear() |
- | * obtain() | + | * obtain() contains a double pointer (should use getpos() and setpos() from previous sllX) |
- | * rm() | + | * rm() should be making use of the clear() |
- | * sort() | + | * sort() |
- | * swap() | + | * swap() |
- | You also have an extra task, for extra credit, inside app/list/ of your sll2 base directory. The extra credit task is to build a linked list based on input from the user. You will also determine whether or not this linked list is a palindrome linked list or not. In case you don't know what a palindrome list is, here is an example. A palindrome list is a list that would look the same if you reversed it. For example, if you have a list, 1 2 3 2 1, that would be a palindrome, because if you display it backwards or forwards, it would display the same thing. | + | You also have an extra task, for extra credit |
- | Another thing to note is that the sll0 project files can only compile with version 9 of gcc. If you are not on lab46 and the project fails to build the library or unit tests, this may be because you are using a newer or older version of gcc. | + | The palindrome should accept values either from the CLI, stdin, or both. Be able to determine if the created list is a palindrome. Reverse |
- | + | ||
- | You can use an older version of gcc off of lab46 by using the following commands | + | |
- | [[https:// | + | |
*Our task is to ask questions on Discord or in class and document our findings on this wiki page collaboratively, | *Our task is to ask questions on Discord or in class and document our findings on this wiki page collaboratively, | ||
Line 23: | Line 40: | ||
=====PROGRAM===== | =====PROGRAM===== | ||
Recommended Order to make functions: | Recommended Order to make functions: | ||
- | 1. Obtain()\\ | + | - obtain() |
- | 2. clearlist()\\ | + | |
- | 3. rmlist()\\ | + | |
- | 4. swap()\\ | + | |
- | 5. sort()\\ | + | |
Details as to the behaviour of the functions can be found as comments inside the .c files of the programs themselves, located in src/list. If confusion arises in the make check process to verify then the .c code of the verify files can be found inside the unit/list directory. Do note that the verify code can rely upon some of the functions you are making to check the others, hence the recommended order. | Details as to the behaviour of the functions can be found as comments inside the .c files of the programs themselves, located in src/list. If confusion arises in the make check process to verify then the .c code of the verify files can be found inside the unit/list directory. Do note that the verify code can rely upon some of the functions you are making to check the others, hence the recommended order. | ||
+ | |||
+ | The unit tests for sll2 make use of several of the functions made in previous projects as well. So if some of those other functions aren’t working as they should be, it could cause mismatches in the unit tests for sll2. It may be helpful to run the unit tests individually to check the output of specific functions. | ||
+ | |||
+ | Make sure to not overestimate what you are trying to do, especially in obtain(), do not try to optimize your program by removing the node, because the node will be held in the double pointer thatNode. | ||
+ | |||
+ | If you have difficulty debugging **obtain()**, | ||
=====OUTPUT SPECIFICATIONS===== | =====OUTPUT SPECIFICATIONS===== | ||
=====UNIT TESTS===== | =====UNIT TESTS===== | ||
+ | =====Basic GDB===== | ||
+ | GDB is a very useful tool, especially if you are running into segmentation faults on any unit test. GDB allows you to set breakpoints, | ||
+ | |||
+ | To launch gdb (obtain used as example): | ||
+ | <cli> | ||
+ | USER@lab46: | ||
+ | </ | ||
+ | |||
+ | ===Basic Operations=== | ||
+ | |||
+ | Placing a breakpoint at line #5: | ||
+ | <cli> | ||
+ | (gdb) b 5 | ||
+ | </ | ||
+ | |||
+ | Placing a breakpoint at function //main()//: | ||
+ | <cli> | ||
+ | (gdb) b main | ||
+ | </ | ||
+ | |||
+ | Run program until next breakpoint: | ||
+ | <cli> | ||
+ | (gdb) r | ||
+ | **or** | ||
+ | (gdb) run | ||
+ | </ | ||
+ | |||
+ | Continue after breakpoint is hit: | ||
+ | <cli> | ||
+ | (gdb) c | ||
+ | </ | ||
+ | |||
+ | Display variable state: | ||
+ | <cli> | ||
+ | (gdb) print var | ||
+ | </ | ||
+ | |||
+ | Execute one line (after breakpoint is hit): | ||
+ | <cli> | ||
+ | (gdb) n | ||
+ | </ | ||
+ | |||
+ | Step into function: | ||
+ | <cli> | ||
+ | (gdb) s | ||
+ | </ |