Debra, aka badasstronaut, was the first person I added as a friend on LiveJournal who I didn't already know, back in 2002. This was mainly on the basis of both of us having Nina Paley in our interests list. I met her in person when I visited her in Bristol, England in 2006 while I was interning at Microsoft Research. Unexpectedly, we became lovers. That didn't last (living on different continents will do that, though for a brief period, things were such that I actually considered moving to the UK), but we always remained friends. She visited me once when I lived in Portland, and I visited her twice more in Bristol; the last time I saw her was a year ago when she was visiting New York City with her wife Kris, and I flew out to NYC to see them.

Debra was creative, intellectually probing, and very funny. She made indie comics and was an educational developer and university lecturer; in that order (at least as I saw her). Unfortunately, most of her comics don't seem to be online, except for a few. She started out as a hairdresser before she went to grad school, and at one point planned to write a Ph.D dissertation on hairdressers' professional culture (but, like me, she never finished her Ph.D). When she lived in New Zealand, she also did feminist and other political activism.

She liked robots and bunnies and had a great sense of style. One of the times with her that I remember best was when I visited her after going to ICFP in Edinburgh, in September 2009; we went to a bed and breakfast in Hay-on-Wye for two nights and went kayaking and, one night, sat in the pub attached to the B&B drinking scrumpy (or at least I did) and listening to some guys literally talk about how to "make Britain great again".

There's so much more, but nothing I could say would be adequate. For the past year I've known that Debra was ill with breast cancer; she didn't seem to want to talk about it much, preferring to go on as normal, so I generally didn't press the issue. We did exchange emails on the subject of top surgery; rather than having a mastectomy with breast reconstruction, she wanted to have a male chest reconstructed so that she could present a more genderqueer appearance. She wrote to me back in September 2012:

Strangely, I am quite excited about it! It's funny - some women I've
talked to say they'd be most worried about the hair loss (what???) and
losing their bust. Those were the least of my concerns, and if I come
through all this successfully I feel I will be able to celebrate with
new clothes and almost a new persona. And I might take up running...

I will miss her so much. I know that her wife Kris and her mother took good care of her over the past year, and she wasn't lacking for support. Even so, I wish I'd been a bit more in touch with her instead of assuming she would prefer to be left alone.

This is the one picture of her I could find that I took (I have more, but am disorganized with my data), on that trip to Hay-on-Wye in 2009):

With rustpkg I'm trying as much as I can to stick to a tests-first/docs-first approach (I suppose strictly speaking, tests-first/docs-second), so this is my pull request for today: adding a draft of a manual (without much actual content, but starting to write things down) and rearranging the test scenarios again to have the directory structure that we agreed on.

I figure when I don't know exactly what I'm doing, writing things down as I go along (rather than waiting until the end to write the docs) helps me see if there's an area I'm still not clear on. I don't know why it's so hard for me to remember that that's the case for me :-)

Today's work on rustpkg is all in my pending pull request. I wrote out a schedule containing all the significant pieces-of-work remaining on rustpkg that Graydon and I could think of right now, and estimated times for each task (like all software engineers I'm terribly bad at estimating time for things). I'm hoping having everything laid out in a linear fashion will help me stay on-track, though.

I'm also glad to have spent some time writing down hypothetical-rust-package-commands-that-should-work (in a text file in the pull request), even though we can't do automatic testing yet. It's good to know what you're doing before you do it...

As an end-of-the-day small task, I made the typechecker able to survive more errors; generally the typechecker should be able to emit a type error and then keep going (since most people like to see as many errors as possible so they can try to fix them in one go, rather than one at a time) but there are a few cases here and there where it's tricky to set up the right data in various environments for the typechecker to keep going. So there's two less of those cases now.

I landed this commit from the end of last week, cleaning up tests and error handling in rustpkg, and I submitted this pull request that allows rustpkg to build executables.

When talking to Graydon about how to do regression tests for rustpkg, I realized I'd been doin' it wrong, at least a bit -- the new policy for rustpkg is that you're going to have to name your crate files main.rs if you want to get an executable and lib.rs if you want to get a library (both can coexist), with additional options for building tests and benchmarks. I'd been allowing an additional option, which is naming your main crate foo.rs for a package named foo, and inferring whether or not it was a library based on the presence or absence of a main function. This was all wrong, so I'll have to undo that work tomorrow. I'm trying to tell myself I'm "exhibiting flexibility and willingness to admit mistakes" rather than "spending all my time writing code that I then delete".

For an easy end-of-the-day task, I decided I'd try to kill off a few bad copies, but that involved rebasing a branch, which involved rebuilding LLVM, which is evidently going to involve deleting my build/ directory and starting from scratch. Which, amusingly, emphasizes the need for a functional rustpkg!

So I finally submitted a pull request with my initial work on rustpkg. I'm embarrassed at how little this patch actually does; I've tested it with one command, build, on one package, my fork of rust-sdl. The difference now is that as per #5679, rustpkg doesn't require a package to explicitly declare its ID and version number; instead, it just looks for a directory with the name you give it. So if you write rustpkg build rust-sdl, rustpkg will expect the current directory to contain a directory called rust-sdl that contains the package. Likewise, if it was rustpkg build rust-sdl-0.1, it would infer the version to be 0.1 (though I don't think I actually implemented that part yet).

I still have to figure out how to write unit tests for this. Also, rather than trying to do everything at once, I made several of the commands other than build fail with "not yet implemented". rustpkg wasn't in a great state anyway, so I don't think this will make anyone too unhappy. I think it's better to explicitly fail than quietly do something not-quite-right.

Hopefully I can proceed faster now that I'm past the awkward initial "what am I doing?" stage of the project.

Today was the beginning of the research work week here in Vancouver, and I don't know about you, but I can't follow a discussion for 8 hours straight -- even with a break for lunch in the middle. So I tried to listen as well as I could to the parts that overlapped more with my knowledge, and during the rest, hack on stuff and listen with one ear.

I started cleaning up my rustpkg changes in preparation for submitting a pull request. Part of that was adding more documentation and such, part was removing bits of code that aren't needed now that we're using package IDs and not requiring a package script. I'm not sure whether to break existing code that uses rustpkg (not that there's a lot of it yet) or try to be backwards-compatible.

After that, it'll be submitting a pull request for the changes I made to rust-sdl, making the clean command work (since it's annoying to have to manually delete files every time to make sure my changes still worked), and making rust-http-client build as my second test project. And then, of course, making all the other commands work. That's just the beginning.

Figuring out how to write unit tests for rustpkg will be interesting as well. Necessary, but I'm not sure how.

Rust 0.6 happened!

I set aside the trans bug I was working on before, just like I said I would do, because trans badly needs the Hatchet of Refactoring, but now is not the time.

Instead, I went back to working on rustpkg; the work that needs to be done is now better outlined (by Graydon). In the meantime, though, I'd wanted to make rustpkg able to build an actual, existing package and infer the package name and version from the path name. I succeeded in doing this today, with rust-sdl, except that I got some warnings at the end about the Android back-end that I need to investigate. The notable thing is that rust-sdl previously had a Makefile that renamed a symbol in the existing SDL library before building; I ported that logic into a package script -- a Rust file -- instead, so now it builds without a Makefile.

Of course, one of the things rustpkg needs to do is build packages that don't have a pkg.rs file -- in the current trunk version, it always requires one -- so perhaps I didn't pick the best example package to start with.

How this works:
You comment, I give you an age (please tell me how old you currently are - I don't know all of your ages unfortunately) and you fill out the meme questions with what applied to you back then, and now.

wordweaverlynn gave me 9.

I lived in:

A studio apartment on the 19th floor of an apartment complex on the Boston side of the Boston/Cambridge border, near the Science Museum, with my mother. My idea of a proper dwelling for an adult has always been an apartment in a high-rise building, and I've never really realized that vision given that I moved to the West Coast when I grew up, and that's less of a thing (unless you're into the condo-buying class, which I'm not; not too long after that, we got booted out of our subsidized apartment because the developer decided to flip Boston off and break his promise to maintain affordable housing, instead converting it all to condos).

I drove:

Nothing, because I was too old for my Smurf Big Wheels and hadn't yet learned how to ride a bike without training wheels.

I was in a relationship with:

The Boston Public Library, West End branch.

I feared:

People. Not knowing what to say. Embarrassment. Boredom. (This is not *too* different from now.)

I worked at:

My dissociation skills.

I wanted to be:

A librarian *and* a bookstore owner (just one or the other wasn't enough).

We're down to 46 open issues for the release! I spent most of my time today working on #4439, which may be behind a few other open bugs. Bugs that cause the compiler to generate seg-faulting code are bad, so I figured I would see if I could fix it before the release. Turns out trait methods that take their self by-move... are implemented strangely. As usual, many bits of undocumented code in trans (the Rust-to-LLVM pass) combine to create confusion.

I thought the best way to go forward would be to convert the data structure representing the self object in trans to use a Datum -- a type that wraps up an LLVM value with data about whether it's meant to be passed by reference or by value -- instead of a raw value. I still think it is, but getting everything consistent means debugging many LLVM assertion failures.

Today, landed the patch I've been working on for a month to make the typechecker's handling of the error and _|_ types more sensible. I've already written about this; I'm just glad to have it done now, and know that the Rust typechecker won't complain about derived errors anymore! I think this is important for usability; I know from experience that too much noise (error messages that don't matter) can be demoralizing when you're trying to get your code compiling.

Except... then I went back and ran the test for this issue and still got a derived error. Oh no! It turned out I didn't edit the code in the pattern-match-checking part of the typechecker, and it was still calling span_fatal (a function that, as you might guess, unconditionally prints out an error message and then kills the whole compiler) rather than report_type_error (a function I wrote that checks for errors involving error types and suppresses them). So I started fixing that, but ran out of time.

In the meantime, I also finished triaging my allotted quota of randomly selected 0.6-milestone bugs, with the goal of getting everything either closed or un-milestoned unless it's SUPER IMPORTANT; the plan is to try to release 0.6 next week. We're going to shift towards priorities rather than milestones in the bug tracker, since it's become clear that labelling bugs with milestones doesn't help that much when doing time-based releases.

Tomorrow, finishing the pattern-checking stuff, doing my quota of doc work for the release, and going back to rustpkg.