uva-cs / pdr Goto Github PK

I feel that it would be beneficial to teach Makefiles earlier in the course, because it is much easier for students to run make rather than clang++ file1.cpp file2.cpp file3.cpp ....

The in-lab component of lab 1 would especially be suitable for a makefile tutorial, as this lab component requires students to split a C++ program into multiple .h and .cpp files. This fits in well with the concept of dependencies (e.g. LifeCycle.cpp depends on LifeCycle.h).

Additionally, the various stages of compiling a C++ program were taught at the beginning of the semester (preprocessor, linker, assembler, etc.), which would fit in well with the concept of compiling .cpp files into .o files (with the -c flag), linking these .o files, etc.

I am dumbfounded. This basically means, short of installing Clang as through https://gist.github.com/datlife/c754535f18b422f6b8d59028c7f31bac, there is no way to easily get memory leak detection on macOS.

We need to fix this before Lab 2 is released.

More info coming later

People got very confused.
https://piazza.com/class/k5bqcfbzltk49c?cid=936

• How to efficiently insert so you don't need a helper node (head -> node1; head -> node2 -> node1)
• How to delete

Or some type of tutorial for how students can check for memory leaks. Because right now we expect submissions to be leak-free when we never explain to them how to check for leaks...

Just an idea; I feel like introducing students to smart pointers is a much better use of time than introducing them to Objective-C.

Smart pointers are key to avoiding memory leaks, and are highly recommended for "modern" C++ development.

They are conflating the 5 required iterations with the number of iterations for counter.cpp.
https://piazza.com/class/k5bqcfbzltk49c?cid=639
https://piazza.com/class/k5bqcfbzltk49c?cid=634
https://piazza.com/class/k5bqcfbzltk49c?cid=618

Some also need extra guidance to realize that this script is completely separate from lab 6's.
https://piazza.com/class/k5bqcfbzltk49c?cid=639
https://piazza.com/class/k5bqcfbzltk49c?cid=627

Others also are confused about how to call a.out.
https://piazza.com/class/k5bqcfbzltk49c?cid=629

Right now we syntax highlight all source files using source-highlight.

It would be nice to also syntax highlight all the code in the slides and labs. Would reduce eyestrain, especially for the labs.

The good news is that this can be done already:

• pandoc supports named code blocks, so all we need to do is add cpp to all our code blocks.
• reveal.js has

  pdr/slides/js/settings.js

  Line 22 in 2dcae87

  { src: 'plugin/highlight/highlight.js', async: true, callback: function() { hljs.initHighlightingOnLoad(); } },

  . It's broken currently, but can be fixed by just adding reveal.js/ in front.

Ideally, the highlighting would be consistent across all sources. The labs will most likely stay in light mode, and probably the source files as well, but the slides are dark mode. That doesn't mean we can't have consistent highlighting, though, as many themes have both light and dark variants.

So all we need to do is find a theme! I personally have a soft spot for One Dark and One Light, having worked on Atom as they were being developed (they also have corresponding Emacs variants), but I understand that this really isn't a decision for me to make 😁.

Notes:

• Pandoc does not use CSS for its theming, which is...slightly annoying. I should be able to figure out the CSS --> JSON conversion required, though, or just manually override the colors with CSS anyway after they've been generated.
• source-highlight takes in the --style-css-file argument.

I'm going over lab 4 right now (probably the last one for a while) and have a few suggestions to restructure it.

• Remove the inlab4.cpp requirement. There's nothing we can really grade for that part other than "did they write it?". The real benefit is from using the debugger on that file. If removing it as a submittable requirement makes people skip over it, well then shucks, that's on them and they still need to complete the doc somehow.
• Move the floating point conversion portion back to the inlab, so that the pre-lab becomes code-submission only and the in-lab becomes worksheet-submission only. Heck, maybe even radix conversion as well from the post-lab. Then we don't need to repeat ourselves thrice about PDFs :). Also, this makes positioning the Hints section a whole lot easier!

I don't know...overall, Lab 4 feels like one of the labs with the least amount of cohesion, even after these proposed changes. It's just a bunch of functions and worksheets all over the place with minimal or no relation to each other. It would be nice to come up with a reworked lab that ties everything together.

Lab 5:

• AVL rotations

Lab 6:

• getWordInGrid duplicate words
• How to write your own hash table

Lab 8:

• Is missing hints in its entirety

Lab 9:

• #111

Lab 11:

• Is missing hints in its entirety

I think that the links to the 32-bit assembly files on the labs/index.html page should be removed, as 32-bit assembly is no longer being taught in the course.

The crossed-out links aren't really necessary because students won't be accessing them anyway. Obviously the 32-bit materials can still remain in the repo for students' reference.

A hard-coded test harness may make it simpler for students to run the main method without having to pipe in input each time (e.g. ./a.out < testfile1.txt). A hard-coded test harness could show actual (what the student's code is returning) vs. expected (the output that the graders are looking for) values, making it easier for students to quickly see if their code is running properly.

Example

For post-lab 5, instead of having students do this execution:
./a.out < testfile1.txt
AVL path: can't created
AVL numNodes: 17

head testfile1.out.txt
AVL path: problems can't kind created
AVL numNodes: 18

They can do this execution:
./a.out
AVL path (actual): can't created
AVL path (expected): problems can't kind created
AVL numNodes (actual): 17
AVL numNodes (expected): 18

The code for such a test harness would be like:

AVLTree t1;
t1.insert("We");
t1.insert("can't");
t1.insert("solve");
t1.insert("problems");
t1.insert("by");
t1.insert("using");
t1.insert("the");
t1.insert("same");
t1.insert("kind");
t1.insert("of");
t1.insert("thinking");
t1.insert("we");
t1.insert("used");
t1.insert("when");
t1.insert("we");
t1.insert("created"); 
t1.insert("them");
t1.insert("-Albert");
t1.insert("Einstein");
cout << "Actual  : " << t1.pathTo("created") << endl;
cout << "Expected: problems can't kind created" << endl;
cout << "Actual  : " << t1.numNodes() << endl;
cout << "Expected: 18" << endl;

server doesn't seem to be piping in the correct input for this lab at the moment.

link directs students to https://uva-cs.github.io/pdr/labs/slides/08-assembly-64bit.html#/3/8
but should direct them to https://uva-cs.github.io/pdr/slides/08-assembly-64bit.html#/3/8

Because implementing your hash table using a...hash table...might not be the best idea.

Other than the benefit of using a more recent HTML specification, the pandoc HTML5 template also allows for better rendering on mobile (it's not bad as-is, but the code blocks are currently very tiny).

If this is given the go-ahead, I can create a PR.