This is the Clemson ACM Repo. We are the local chapter of the Association for Computing Machinery at Clemson University in Clemson, South Carolina. We do cool computing stuff for cool computing people!
This repository contains resources developed to aid with doing cool stuff in Computer Science. The main projects are as follows:
Depending on what you are doing you will need different tools:
git
- for tracking changesg++
- all code samples are in C++98 with C++11 listed as notedawk
- text processing tool needed for version directivespdflatex
- The Hackpack body is written in LaTeXmake
- Make is to automate compilation and testing of the documentsperl
- required to support renaming in version directivesfind
- the gnu version of find is required supporting extended posix
regular expressions for supporting version directives. On OSX the
findutils
package from homebrew can be usedFor all projects and improvements:
If you have any questions related to the issues in the tracker, comment on the issues and mention one of the owners.
All examples assume a topic called foo
and a sample problem bar
:
All file names should be lowercase with -
(hyphens) separating the words
in a file. For example, ten-commandments.tex
instead of
TenCommandments.tex
All sample contest problems should be in a subdirectory called problems
and in a further subdirectory based on the problem name. For example if the
topic foo
has a problem bar
the path to the code sample could be foo/problems/bar/bar.cpp
.
In the rare circumstance that your finished product is one tex
file,
place it in general
instead
See how the set
material is laid out for reference. It is in
structures/set
foo
the name of the branch where foo
is being worked on
foo.tex
the hackpack documentation on the algorithm
foo.cpp
reference code for the foo data structure in C++ if applicable
bar.in
sample input for foo.cpp if applicable
bar.out
sample output for foo.cpp if applicable
bar.exe
untracked compiled binary DO NOT ADD THIS. It makes it
easier to spot in the .gitignore
.
bar.py
a version of foo.cpp
in python if applicable. Alternate
versions of algorithms in languages other than C++ should be written after
the C++ code is written
bar.example
files such as .vimrc
that do not have an extension normally
bar.bats
Automated test case written in bats
bar-test.cpp
An automated unit test written in cpp
bar-test.in
Data for the automated unit test
bar-test.out
Expected output for the automated unit test
Documentation should be written in LaTeX
:
For each item in the Hackpack, please include the following in clearly delineated subsections:
\acmlisting
for code listings. A caption and label should be specified. If applicable, line ranges should be specified to limit the amount of text displayed.The condensed version of the hackpack should have the following removed:
Code Must meet the following standards:
g++ -g -O2 -std=gnu++0x -static $*
The condensed hackpack version should have the following removed:
#include
code that can be found in other sections of the hackpackAll code must have tests that meet the following requirements
tap
compliant mode. See the structures/set
section for an example.-test
prior to the extension. For
example, foo.cpp
test files should be called foo-test.cpp
and
foo-test.in
respectivelyTests should be runnable by calling make test
in the directory of the source
The hack pack is from one source built into two versions: one slim (hackpack
)
and one tome-like (hackpack++
, or as denoted in the build scripts,
hackpackpp
). But how? By a combination of awk
and dark magicks, authors can
use an extremely limited set of C-preprocessor-like #ifdef
s to denote a block
of text or code as part of one version or the other. Here's an example:
// #ifdef hackpackpp
cout << "This is the Hack Pack: plusplus edition!" << endl;
// #endif
// #ifdef hackpack
cout << "This is just the regular hack pack." << endl;
// #endif
The first cout
will only appear in the hackpack++'s code listing, and the
second will only appear in the normal hackpack. Note that the #ifdefs
are
commented out: as long as the line ends with the if directive, they'll work
properly. You might want to comment them out so that they don't break the compilers.
Make sure you have a new line after each directive somewhere!
Here's a list of filetypes where the if directives will work:
.tex
.cpp
.py
example
The hack pack uses a Makefile for building our PDF output. Here's a rundown of the make rules you'll probably be using:
make clean
wipes out the build directory if you don't have a version of
latexmk
that supports the -outdir
flag, and cleans it up with latexmk -c
if you do.make hackpack
builds the slim version of the hackpack into build/hackpack.pdf
.make hackpackpp
builds the bulky version of the hackpack into build/hackpack.pdf
.make show
launches evince
(a pdf viewer) to preview the hackpack.Contact one of the members of the Hackpack Developers groups with any questions.