Use it up, wear it out, make it do, or do without.

This morning, when I came to work, my computer was working fine, but my mouse was dead. Thinking my computer had flaked over the weekend, I rebooted (my computer has been acting strange in other ways recently, such as crashing in the middle of a build with linker errors that don't reproduce on other machines, etc., so I thought perhaps the hardware had flaked). No dice. Then, I noticed that the mouse was warm.

I've never heard of a computer mouse actually wearing out before. That's pretty insane. I don't even use my mouse that much! Maybe it was lonely...

1. Don't pay for anything if you can make it or fix it yourself.
2. Prolong the life of whatever you own.
3. Use less.
4. Think creatively. The answer doesn't have to be "buy a new one."
5. Don't toss anything if it can be reused or recycled somehow.

Somehow I have managed to live my whole life without learning about this, but it is flooding the office with my tears... of laughter.

<Star Wars Christmas Special>

I think it is really hard to remember anything across a change in the way you think.

I mean a REAL change in the way you think, like the change from being, say, four or five years old, to being seven, ten, thirteen, fifteen. I was positing this driving in this morning as a way of explaining why so many people lose the memory of their childhood. Perhaps memories from the old time don't even look like memories to your brain when you are in the new time, so your brain doesn't call them up for you, and you "can't remember" them.

I've been remembering a lot of things recently that I hadn't thought of for 10, 15, or even more years. Most of them are not across a thought boundary. I have some memories going back to about six, and then I have a lighter concentration of memories from my earlier years, going back to (perhaps) the later threes or twos. And I have approximately one memory from being an infant. It took me years to even figure out what that one was all about, because I was such a different size.

I don't think day-to-day about a lot of things that happened when I was a kid, and you could even consider them lost because nobody has the key. For me, this blurs the question of whether I had a phase change in my thought patterns causing memories to be lost behind a barrier. However, I know some very smart people who don't remember anything before they were 13 or 15 or so. Surely someone has the keys for those people, yet they have no recollection.

I guess it doesn't have to be an organic change in the way you think. Maybe a change in setting can lock away memories, if the new setting is vivid enough to completely displace the old one. My only examples of this are moving when I was 3 (which is not relevant because I was far too young for me to be able to separate the "natural" loss of childhood memory from the memory loss due to scene displacement), and when I was 18/21 when I moved to/from college, respectively. The college examples are also not useful because I've been back there a lot, and I stayed in touch with my college friends for a long time, so I didn't lose a lot of college memories. Also because when I came back, my college town seemed much more real to me than the place I returned to, so if anything, I should look for displaced memories there.

Also, when I was a teenager, I was unable to remember most things from my childhood—especially the way I felt. When I got to 19 or my early 20's, suddenly all my childhood memories came back. It was something about the way I just was when I was a teenager, that suppressed them. I am not sure what.

What memories play in the background of our minds constantly, every day, but we don't even notice them, because we are so used to them being there?

This post is dedicated to the one I love, mlink57, who (presumably) just finished her last law school final of the school year. Sweetheart,

LET'S PARTY!!!

Or, more likely,

LET'S SLEEP FOR 3 WEEKS!!!

YES!!!
> Is it really that irritating?
>> It reverses the flow of conversation and makes relating
>> reponses to their originating comments difficult.
>>> Why? Outlook and so many other clients default to that.
>>>> Top posting; it's absolute email heresy.
>>>>> What is the worst faux pas to commit in email?

DrX is 421 octal dog years old today. Happy birthday DrX!

I am 15 hexadecimal people years old today. I was yesterday, etc. too because my birthday is in the first two-digit octal month. (Gregorian calendar, naturally.)

Happy New Year 2005!

Far too much champaigne... whiskey...

Why is Marguerite's laptop out? The world may never know. But, it is allowing me to post on LJ. W00t!

penutsgirl8321 (12:09:15): baby
penutsgirl8321 (12:09:20): lol
penutsgirl8321 (12:09:22): oops wrong im
penutsgirl8321 (12:09:27): that was suppposed to go to steve
penutsgirl8321 (12:13:51): ok anyway hi billy
penutsgirl8321 signed off at 12:25:56.

§4.14 of the GNU Make Manual lies.

Well, not exactly. But a naïve implementation of this § leads to problems with make clean, at least if you want make clean to remove the generated dependency file(s). Our Makefiles have to do this, since our make clean means "make it the way it was before I ran make." I read in GNU Autoconf, Automake, and Libtool by Vaughan et al. that some in some open-source projects, "clean" puts the project back to a semi-built state. For example, in a project like Subversion, it could* leave all the work done by gen-make.py, so that dist.sh can put a Makefile in their tarballs.

A Makefile written according to §4.14

This Makefile implements §4.14, as best as I can tell. But it also adds a make clean feature, which they don't talk about in the §.

# $Id: Makefile 20 2004-12-10 14:13:15Z wunnas $

bin := bin/

OBJECTS := $(bin)mydeps.o

#
# Build the main target(s).
#

all: $(bin)mydeps.exe

# I don't have .PHONY: all in my actual Makefiles.  I wonder if it caused
# problems or something?
.PHONY: all

$(bin)mydeps.exe: $(OBJECTS)
    link -nologo -out:'$@' '$<' libc.lib

$(OBJECTS): $(bin)%.o: %.c $$(@D)/empty-file
    cl -nologo -c -Fo'$@' -ML '$<'

#
# Create target folder(s).
#

%/empty-file:
    mkdir -p '$(@D)'
    touch '$@'

#
# Clean up.
#

clean:
    rm -rf '$(bin)'

.PHONY: clean

#
# Additional dependencies.
#

$(bin)mydeps.mk:
    test -d '$(@D)' || mkdir -p '$(@D)'
    touch '$@'

#
# Cause all hell to break loose.
#
# NOTES
# (1) Unconditionally including this, here, means it will be generated even for
#     a "clean."
#

include $(bin)mydeps.mk

# vim: set noexpandtab shiftwidth=8:

Now, starting from a clean WC, this Makefile appears to DTRT:

Z:\Projects\mydeps>make
Makefile:54: bin/mydeps.mk: No such file or directory
test -d 'bin' || mkdir -p 'bin'
touch 'bin/mydeps.mk'
mkdir -p 'bin'
touch 'bin/empty-file'
cl -nologo -c -Fo'bin/mydeps.o' -ML 'mydeps.c'
mydeps.c
link -nologo -out:'bin/mydeps.exe' 'bin/mydeps.o' libc.lib

And a subsequent make clean appears to DTRT as well:

Z:\Projects\mydeps>make clean
rm -rf 'bin/'

But all is not well in pixieland. Let's try another make clean. It should be idempotent (at least according to my desired semantics):

Z:\Projects\mydeps>make clean
Makefile:54: bin/mydeps.mk: No such file or directory
test -d 'bin' || mkdir -p 'bin'
touch 'bin/mydeps.mk'
rm -rf 'bin/'

Uh-oh. What have we here in red? Uhm. It appears to be creating the dependencies (which were missing, remember, we cleaned twice in a row?), and then deleting them. That would go over REALLY well with Eunny. "It SUCKS! I just want to do a make clean, and it creates the dependencies only to delete them." And it would suck, because regenerating dependencies for ~445 files (or however many we have today) can take a *long* time.

Ready for more fun? Try this (from an empty WC):

Z:\Projects\mydeps>make clean all
Makefile:54: bin/mydeps.mk: No such file or directory
test -d 'bin' || mkdir -p 'bin'
touch 'bin/mydeps.mk'
rm -rf 'bin/'
mkdir -p 'bin'
touch 'bin/empty-file'
cl -nologo -c -Fo'bin/mydeps.o' -ML 'mydeps.c'
mydeps.c
link -nologo -out:'bin/mydeps.exe' 'bin/mydeps.o' libc.lib

Note the part, highlighted in red, where it runs the recipe for clean, removing $(bin)mydeps.mk as soon as it creates it. This means that *this* invocation of the Makefile gets to read $(bin)mydeps.mk, but no other Makefiles get to read it, because we erase it immediately. Oops.

So, when I wrote our original Makefiles way back in the day, I (being a Makefile dumbass with access to the GNU Make Manual and very little knowledge of logic programming) thought, "oh, the problem is that make doesn't know not to generate the dependency file when we are cleaning. So I wrote code* that started out like this:

ifeq (,$(filter clean clobber,$(MAKECMDGOALS)))
ifeq (,$(making-depend))
...
    include $(dep)

OK, you can see where this is going. Clearly make clean all is not going to work under these circumstances, and in fact that's why I had the clobber target (I think). ISTR it turned out make clean all did work, but I didn't think it would originally. Or something. The code is a mess. Which is why, when I gained more make-fu, I...

...completely rewrote our Makefile system. So thank GOD we don't have the old mess anymore. However, when I rewrote the Makefiles, I didn't have time to do anything other than the simplest possible dependency code, which is why I am working on dependency code now.

I just found this. Fascinating.

The point

Last night, I realized that, since we have a two-level Makefile system, with the top-level Makefile handling clean and in fact all targets that we aren't supposed to build dependencies for,* I can solve the dependency problem one of two ways:

• I could use the §4.14 method, combined with Dependency scanning using GNU make + Visual C++ and my "good thoughts" from yesterday.

  This solution is LESS PREFERRED, because it means I still have to deal with people changing .cpp files in another library, as I mentioned in my "bad thoughts" yesterday.

• OR, I could say screw §4.14 and just procedurally build all the dependent libraries (using the packaging system from "good thoughts") in the top-level Makefile before trying to build the app (or whatever level I am on, assuming we ever get more than two package levels). I could still use the idea from Dependency scanning using GNU make + Visual C++, or I could do it the way I originally planned. The method in that email (which, I have to admit, is the official §4.14 GNU method, adapted by someone who actually knew what he was doing—unlike me) has many advantages, the chief ones being, I wouldn't have to write another dependency crawler, and I would get preprocessor support.

  This solution is MORE PREFERRED, because I just thought of it last night and haven't had time to figure out why it is mortally wounded and won't get off the ground in time to avoid being attacked by the compys.

The summary

I've talked this out enough, so now I feel like I can go and try it! Byeç.

Well, there is always this this.

Good thoughts I had yesterday.

(app/Makefile) user-libs := libplot libreport ...
...
(c++/c++.mk) include $(foreach lib,$(user-libs),$(depth)build/c++/lib/$(lib).mk)

Does the preceding line even work in GNU Make? I guess I should check the GNU Make Manual. One moment... Yes.

Gratuitous links in the preceding paragraph sponsored by Xeroxen® A Choice Blend of Choice Oxen.

I wish there was a way to use Subversion on a single file at a time. I guess I could use the script someone posted the other day that was based on this, but svn.haxx.se has been down the whole day, so I can't find the derivative script. Damn not being subscribed to dev@ anymore. (Even though I never posted anything.)

Enough rambling, back to good thoughts.

(app/Makefile) user-libs-packages :=
(app/Makefile) user-libs-files    :=
...
(c++/lib/$(lib).mk) user-libs-packages += $(depth)c++/common/.../
(c++/lib/$(lib).mk) user-libs-files    += \
        $(...)$(bin.release)app.a                  \
        $(...)$(bin.release)app/$(app).o           \
        $(...)$(bin.release)language/$(language).o \
        $(...)$(bin.release)scope/$(scope).o       \
        $(...)$(bin.release)security/$(security).o

OK, so those were my good thoughts. My bad thoughts were, rather than having the app Makefiles know about the dependencies of libplot, libreport, etc. I could just put a procedural

for lib in $(patsubst %,'%',$(user-libs-packages)); do \
    $(make) -C "$lib" || exit 1; \
done

right before the link step, where it actually calls link.exe. Well, this works fine if you change a file in libplot that the app #includes, e.g. a .h file. But what if you change a .cpp file, or even a .h file that the app doesn't #include? The app's .exe still depends on that file, since it depends on the library and the library depends on that file: but make won't detect that the app needs relinked (triggering the link step and hence the procedural recursive call to $(make)), because no .o files depend on these. Oops. I can hear it now:

So, it looks like what I have to do, in a nutshell, is keep the app.exe: ... libplot.a rule. And then have a way for app.exe's Makefile to include, *and know how to rebuild*, the libplot dependency chart. Oh, and it should know to rebuild libplot when anything in that chart changes. Dammit.