User Tools

Site Tools


Sidebar

projects

pct0 (bonus; due 20230823)
wcp1 (due 20230823)
abc0 (due 20230830)
btt0 (due 20230830)
pct1 (bonus; due 20230830)
pct2 (due 20230830)
wcp2 (due 20230830)
mpg0 (due 20230906)
pct3 (bonus; due 20230906)
wcp3 (due 20230906)
pct4 (due 20230913)
ttb0 (due 20230913)
wcp4 (due 20230913)
pct5 (bonus; due 20230920)
ttb1 (due 20230920)
wcp5 (due 20230920)
dap0 (due 20230927)
gfo0 (due 20230927)
pct6 (due 20230927)
wcp6 (due 20230927)
cgf0 (due 20231004)
pct7 (bonus; due 20231004)
wcp7 (due 20231004)
bwp1 (bonus; due 20231018)
cgf1 (due 20231018)
pct8 (due 20231018)
wcp8 (due 20231018)
cgf2 (due 20231025)
pct9 (bonus; due 20231025)
wcp9 (due 20231025)
cgf3 (due 20231101)
gfo1 (due 20231101)
pctA (due 20231101)
wcpA (due 20231101)
pctB (bonus; due 20231108)
waq0 (due 20231108)
wcpB (due 20231108)
pctC (due 20231115)
waq1 (due 20231115)
wcpC (due 20231115)
bwp2 (bonus; due 20231129)
pctD (bonus; due 20231129)
wcpD (bonus; due 20231129)
gfo2 (due 20231206)
pctE (bonus; due 20231206)
wcpE (bonus; due 20231206)
EoCE (due 20231214)
haas:fall2023:data:projects:sln1

Corning Community College

CSCS2320 Data Structures

PROJECT: Singly-Linked Nodes (SLN1)

OBJECTIVE

To enhance our ability to explore various algorithmic and computing realms through the exploration and cultivation of debugging and troubleshooting skills, and collaboratively authoring and documenting the project and its specifications.

GRABIT

To assist with consistency across all implementations, data files for use with this project are available on lab46 via the grabit tool. Be sure to obtain it and ensure your implementation properly works with the provided data.

lab46:~/src/SEMESTER/DESIG$ grabit DESIG PROJECT

OVERVIEW

Your task is to implement the core node library functions and make sure that they conform to specifications.

Contributing to project documentation is also a core part of this project. If from reading the existing documentation or through your own exploring, you find something lacking, unclear, or outright missing, that is an opportunity to potentially contribute content.

You want the project documentation to provide you (as if coming in with no awareness of the project) with sufficient information so as to allow you to proceed. Asking questions on the discord is a great way of getting more information that you can use to add content.

Additional files

Turns out, two directories are not copied, so once you grabit, change into your project directory and do the following:

lab46:~/src/SEMESTER/DESIG/PROJECT$ cp -a /var/public/SEMESTER/DESIG/PROJECT/.datastore .
lab46:~/src/SEMESTER/DESIG/PROJECT$ cp -a /var/public/SEMESTER/DESIG/PROJECT/.eval .
lab46:~/src/SEMESTER/DESIG/PROJECT$ cp -a /var/public/SEMESTER/DESIG/PROJECT/.updates .

EDIT

You will want to go here to edit and fill in the various sections of the document:

BACKGROUND

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. 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.

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 (may find information pertaining to the various node options)

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.





Our task is to ask questions on Discord or in class and document our findings on this wiki page collaboratively, regarding the functionality of this project. For anybody interested in editing the wiki page, here is the dokuwiki user guide: https://www.dokuwiki.org/wiki:syntax#basic_text_formatting -Ash

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.
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:

  • /inc/ contains your header files used in most programs(contains options used such as “right” and “info”)
  • /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/ supplemental information/tests to further your understanding of the “node code”

OUTPUT SPECIFICATIONS

There does not appear to be any direct output required for this project.

Stay tuned for any updates!

UNIT TESTS

It is part of our evaluation to get as many tests as possible to match. Ideally, all should match.

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.

USERNAME@lab46:~/src/fall2022/sln1$ make
Building the NODE library
=======================================
[CC]   cp.c                 ... OK
[CC]   mk.c                 ... OK
[CC]   rm.c                 ... OK
       libnode.{a,so}       ... SUCCESS

Building NODE library unit tests
=======================================
[CC]   unit-cpnode.c        ... OK
[CC]   unit-mknode.c        ... OK
[CC]   unit-rmnode.c        ... OK
[CP] Copying to sln1/bin/   ... SUCCESS
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
======================================================

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:

USERNAME@lab46:~/src/fall2022/sln1$ make help

Verify that the implementation of your nodes is functional:

USERNAME@lab46:~/src/fall2022/sln1$ make check

Remove all compiled binaries:

USERNAME@lab46:~/src/fall2022/sln1$ make clean

Make and print errors immediately:

USERNAME@lab46:~/src/fall2022/sln1$ make debug

Submit assignment:

USERNAME@lab46:~/src/fall2022/sln1$ make submit

Update project (if any verify scripts/etc changed)

USERNAME@lab46:~/src/fall2022/sln1$ make update

Upgrade to the next project (sll0)
Note this takes current sln1 directory and copies your codes into sll0, use only when done.

USERNAME@lab46:~/src/fall2022/sln1$ make upgrade-sll0

NULL vs UNDEFINED

As you explore this project and it's related files, you'll likely find this definition in support.h:

#if !defined(UNDEFINED)
    #define UNDEFINED ((void*)1)
#endif

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.

 

SUBMISSION

To be successful in this project, the following criteria (or their equivalent) must be met:

  • Project must be submit on time, by the deadline.
    • Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline.
  • All code must compile cleanly (no warnings or errors)
    • Compile with the -Wall and –std=gnu18 compiler flags
    • all requested functionality must conform to stated requirements (either on this document or in a 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
  • Code must be consistently written, to strive for readability from having a consistent style throughout
  • 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
  • No global variables (without instructor approval), no goto statements, no calling of main()!
  • Track/version the source code in your lab46 semester repository
  • Submit a copy of your source code to me using the submit tool (make submit on lab46 will do this) by the deadline.

Submit Tool Usage

Let's say you have completed work on the project, and are ready to submit, you would do the following (assuming you have a program called uom0.c):

lab46:~/src/SEMESTER/DESIG/PROJECT$ make submit

You should get some sort of confirmation indicating successful submission if all went according to plan. If not, check for typos and or locational mismatches.

RUBRIC

I'll be evaluating the project based on the following criteria:

78:sln1:final tally of results (78/78)
*:sln1:obtained project by the Sunday prior to duedate [13/13]
*:sln1:clean compile, no compiler messages [13/13]
*:sln1:implementation passes unit tests [13/13]
*:sln1:adequate modifications to code from template [13/13]
*:sln1:program operations conform to project specifications [13/13]
*:sln1:code tracked in lab46 semester repo [13/13]

Pertaining to the collaborative authoring of project documentation

  • each class member is to participate in the contribution of relevant information and formatting of the documentation
    • minimal member contributions consist of:
      • near the class average edits (a value of at least four productive edits)
      • near the average class content change average (a value of at least 256 bytes (absolute value of data content change))
      • near the class content contribution average (a value of at least 1kiB)
      • no adding in one commit then later removing in its entirety for the sake of satisfying edit requirements
    • adding and formatting data in an organized fashion, aiming to create an informative and readable document that anyone in the class can reference
    • content contributions will be factored into a documentation coefficient, a value multiplied against your actual project submission to influence the end result:
      • no contributions, co-efficient is 0.50
      • less than minimum contributions is 0.75
      • met minimum contribution threshold is 1.00

Additionally

  • Solutions not abiding by spirit of project will be subject to a 50% overall deduction
  • Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction
  • Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction
  • Solutions not organized and easy to read (assume a terminal at least 90 characters wide, 40 characters tall) are subject to a 25% overall deduction
haas/fall2023/data/projects/sln1.txt · Last modified: 2022/09/15 11:26 by 127.0.0.1