hooya
I ran into loop invariants in my CS undergrad where they were teaching "formal logic" to prove correctness of programs. At the time, it was a bit above my head and i struggled with it. i'm just beginning to understand what it was that we were studying at the time. cool stuff. wish i could go back and re-learn that stuff. Also google TLA+ - there's a book on it by Leslie Lamport.
many moons ago when i was an undergrad, there was this one class that i hated. i got practically nothing out of it. and the reason was that the professor had prepared all the course material in powerpoint. every damn proof, every single block of code.. everything. he would come in and read the deck, line by line in the class. i can trace my hatred of powerpoint to that single class. i remember thinking "i can read damnit. if you're going to read the powerpoint back to me, why don't you email that to me and i can read it on my own. i am not a toddler that needs to be read to by an adult".
prepare ahead of time - by all means. plan the coursework, the lecture. but whatever you do, don't read your prepared material to the class.
incidentally, i was also taking a class on public speaking at the same time. and near the end of the semester we each had to give a speech as our final "project". and one gent stood out - Sean (don't remember his last name) - he put up one poster and gave a 20 minute speech that i remember to this day after some 20 years or so. he didn't "read down" to us with a wall of prepared material.
since then i have sat through countless presentations/meetings. i can recall any presentation as vividly as i remember Seans'.
P.S.: Sean, if you find this, you convinced me that day that BMWs are the ultimate driving machines.
all: data.loaded data2.loaded
data.csv: wget 'some url'
%.sql: %.csv sed/awk/custom-python-script $< > $@
%.loaded: %.sql psql < $< && touch $@
ZX Spectrum by any chance?
Really, I see college as a way to learn how to learn. You've done that with CS, it seems. Now learn how to learn in other areas. You'll probably never get another chance.
During college I hated having to take any non CS class. In hindsight, I'm really glad I had to.
Try this next time (only the pertinent lines are included):
SOURCES=$(wildcard $(SRCDIR)/*.erl)
OBJECTS=$(addprefix $(OBJDIR)/, $(notdir $(SOURCES:.erl=.beam)))
DEPS = $(addprefix $(DEPDIR)/, $(notdir $(SOURCES:.erl=.Pbeam))) $(addprefix $(DEPDIR)/, $(notdir $(TEMPLATES:.dtl=.Pbeam)))
-include $(DEPS)
# define a suffix rule for .erl -> .beam
$(OBJDIR)/%.beam: $(SRCDIR)/%.erl | $(OBJDIR)
$(ERLC) $(ERLCFLAGS) -o $(OBJDIR) $<
#see this: http://www.gnu.org/software/make/manual/html_node/Pattern-Match.html
$(DEPDIR)/%.Pbeam: $(SRCDIR)/%.erl | $(DEPDIR)
$(ERLC) -MF $@ -MT $(OBJDIR)/$*.beam $(ERLCFLAGS) $<
#the | pipe operator, defining an order only prerequisite. Meaning
#that the $(OBJDIR) target should be existent (instead of more recent)
#in order to build the current target
$(OBJECTS): | $(OBJDIR)
$(OBJDIR):
test -d $(OBJDIR) || mkdir $(OBJDIR)
$(DEPDIR):
test -d $(DEPDIR) || mkdir $(DEPDIR)
I've been using a makefile about 40 lines long and I've never needed to update the makefile as i've added source files. Same makefile (with minor tweaks) works across Erlang, C++, ErlyDTL and other compile-time templates and what have you. Also does automagic dependencies very nicely.> Generating all the targets to get around this is a nightmare that results in unreadable debug messages and horribly unpredictable call paths.
If you think of Makefiles as a series of call paths, you're going to have a bad time. It's a dependency graph. You define rules for going from one node to the next and let Make figure out how to walk the graph.