Tim's journal

TMI: Slowness

Thu, 23 May 2013 03:13:35 GMT

A frustrating day. On the plus side, I did solve yesterday's problem with the duplicate __test identifier. It turned out I was calling the driver functions wrong and it was literally synthesizing a test module twice. I was able to fix that bug.

Once I fixed that, I got this horrible resolve error:

<intrinsic>:58:37: 58:41 error: found value name used as a type: def_fn({crate: 1, node: 160381}, impure_fn)
<intrinsic>:58         fn visit_estr_uniq(&self) -> bool;

The error refers to the code for intrinsics (primops, basically) that rustc injects everywhere. It's complaining that bool is a function but is being used like a type. But... bool is a type! A primitive one, at that. I'd expect this to happen if there was a function somewhere called bool (maybe), but there isn't.

This was when I was trying to use rustpkg to build a test module. So next I decided to just compile a regular main module. So then I got:

rust: task failed at 'ty_fn_ret() called on non-fn type: &ty_nil', /Users/tjc/rust2/src/librustc/middle/ty.rs:2822

as an ICE in trans.

Given that all of this just comes from changing search paths so rustpkg can find libstd and not treat it as a remote-package-to-download, I'm... flummoxed.

Also, rustc as a whole seemed to get a lot slower sometime in the past two days. As in, even running three builds in different workspaces, at the same time, resulted in a longer than usual wait for any one of them to complete. And I wasn't running out of physical RAM.

Because of that, I spent some time while waiting for compiles to finish nominating bugs. I sorted github issues by least-recently-commented-on. As a result, all the open issues have been touched sometime in the past 2 months, and there are now 142 nominated bugs. I... don't think we'll get through all of them in the triage meeting tomorrow.

comments

TMI: Adventures in the front-end

Wed, 22 May 2013 01:36:38 GMT

Still working on #5681, external crate inference. I resolved one of the remaining problems, which was how to not try to download-and-build std in directives like extern mod std; (where std is obviously already installed). But now, much to my dismay, I'm seeing some strange rustc behavior:

<core-macros>:1:0: 1:0 error: duplicate definition of type `__test`
<core-macros>:1 pub mod macros {
                ^
<core-macros>:1:0: 1:0 note: first definition of type __test here:
<core-macros>:1 pub mod macros {

This is only when compiling a file with a #[test] in it. What's weird is I haven't changed anything affecting how I interface with rustc. I'm not sure where the duplicate definitions of __test (the name that gets used for the automatically-created test module) are coming from, nor do I have any clear idea how to debug this.

Otherwise, today was bug triage and cleaning up warnings and stuff, in the moments when rustpkg was recompiling (of which there were many, since the compiler seems to have gotten quite a bit slower over the long weekend).

Better luck tomorrow, maybe...

comments

Dept. of Transportation

Tue, 21 May 2013 04:07:47 GMT

I found the following on a sticky note (an electronic one, that is) that I wrote while without wifi on a trip on the Coast Starlight sometime in the past year or so:

"This is like going to the frozen food section while stoned, but paying double for it." -- someone in the cafe car

announcement: "We're turning inland and the reason for that is to get away from some of these more unstable sand dunes." Actually, I thought the reason we were turning inland is because that's where the tracks are.

In Salinas, someone put a bunch of tires on the tracks, which "compromised" the main brake lines so the train had to sit in Salinas for a while while they fixed it. You know what I say to that? Fuck Salinas.

comments

TMI: ionmonkey generator syntax changes aren't dead yet!

Mon, 20 May 2013 04:03:40 GMT

This isn't Rust-related, but I wanted to report that I spent much of this evening developing a revised version of my Ionmonkey patch to implement generator syntax changes for Harmony, and finally submitted the patch for review, after a 9-month break since the last time I worked on this.

I want to emphasize that I only worked on the syntax changes and haven't touched any related semantics changes at all. Why did it take so long? Well, mostly because I spent most of the time not working on it. When faced with urgent work on Rust (inside my comfort zone) or JavaScript work (outside my comfort zone), it's pretty obvious what I'll pick! But also, it's just hard to work on a compiler for a language that I don't know (JavaScript) that's also implemented in a language I don't know well (C++).

Anyway, for the first time in 9 months I can actually relax and wait for a review, instead of feeling like I should work on this the next time I have a free moment and enough energy for work! I'll enjoy the feeling while it lasts.

comments

TMI: external crates: lost and found

Fri, 17 May 2013 01:10:09 GMT

I more-or-less finished external crate inference, at least in the local-crate case. I spent most of the time on that fighting with the borrow checker. To add the right directories into the session's list of additional library search path, I wrote some visitor code that looks at all the view_items in the crate. There are two types of view_items: extern mod directives and use directives. For this, I only care about extern mod directives.

The problem is that the visitor wants an @-closure, which can't use borrowed pointers, so accumulating a mutable vector of found extern mod thing seems... hard. I eventually gave up and worked around it with massive amounts of copying.

Once I get some tidy stuff cleaned up, and figure out the copy issue, I'll be ready to check that in and close #5681.

If I can finish #6407 (allowing extern mod directives to name remote packages) and #5683 (the test runner for rustpkg, which I've already started a rudimentary version of) tomorrow, then I'll be on-schedule so far. It might happen.

comments

TMI: Finding external crates

Thu, 16 May 2013 02:33:04 GMT

The remote-package-ID patch landed, so I'm on to teaching rustpkg how to find external crates.

Currently, if you include an extern mod directive at the top of a Rust file, like:

extern mod foo;

supposing foo lives in some arbitrary (non-system) directory like /home/tjc/quux/lib, you have to pass in a -L flag to rustc, like: -L /home/tjc/quux. That's so it knows where to find the foo library to link with.

But in rustpkg we're trying to make it possible for files to self-describe, and get away from compiler flags as much as possible. So rustpkg will, itself, scan files in the crate it's trying to build for extern mods and try to build their dependencies automatically. So far, it only looks in the same workspace that the package it's building is in, since it only knows about one workspace (the current directory). But once I implement RUST_PATH, that'll be a lot more powerful.

Even more so, the plan is to change the syntax of extern mod directives so they don't have to just name identifiers. So you'll be able to write:

extern mod foo = "github.com/catamorphism/foo";

Eventually, this will cause rustpkg to try to fetch the foo package from my repository on github and install it. The package can be referred to in the code with the short name foo, since the entire URL fragment isn't a valid Rust identifier.

So far, I've implemented the part where rustpkg scans for extern mods and builds the named packages and dependencies if possible. I'm working on getting it to pass the right directories to the rustc driver so as to actually find the resulting libraries.

comments

TMI: Almost conquering remote package IDs

Wed, 15 May 2013 01:03:04 GMT

Back once again from another (shorter) absence -- I had to go down to Olympia to say goodbye to my 11-year-old rabbit, who'd had a stroke and needed to be euthanized. This spring, I'm telling you...

This morning, Ron Garcia came over to the office from UBC to visit us and hear about Rust. It's always good to get a bit of external validation, and it seems like he and our team have at least some research interests in common.

After lunch, I got down to hacking, having previously gotten somewhat derailed by adding a few more tests to #6418, the URL-like package-ID pull request. I hit the "computing fictitious type" ICE that a lot of other people had hit, and so I figured it was time for me to fix it, since I knew it probably related to my recent changes to do with derived errors. Turned out the ICE has to do with erroneous matches on patterns of the form (foo, bar) where the scrutinee doesn't have a tuple type -- this is a common error because of, among other reasons, argument patterns where it should really be &(foo, bar). So I fixed that, but that was all over the weekend.

Today, that patch having landed, I went back to finishing #6418. Partly this required resolving merge conflicts, due to the intervening make-vectors-not-implicitly-copyable change which made PkgIds non-implicitly copyable. Partly, I fixed the ugly hack I was using where output file names would be of the form foo-0-1 instead of foo-0.1, where 0.1 is the version number. I was doing that so that rustc wouldn't drop the portion after the last dot in order to make the output .o filename. But it turns out the correct output file to pass is just foo, since for libraries, rustc pulls the version number out of the metadata (not the filename) anyway.

And so I can get this checked in before I leave the office tonight, I hope (which is a bit of a race against time, since all the bathrooms in the office are out of order).

comments

TMI: rustpkg can download and build remote packages!

Sat, 11 May 2013 01:41:16 GMT

I finished yesterday's work, in the "tests pass" sense, so now rustpkg can recognize package IDs that resemble URL fragments. For example, I can write:

rustpkg build github.com/catamorphism/test-pkg

and rustpkg will fetch the test-pkg repository from github, then build a local cached copy of it.

We also had a useful meeting today to discuss what Servo needs from rustpkg, resulting in ten or so new github issues. (The rustpkg metabug collects them all.) One thing we talked about will actually obviate the need for the tedious string-munging that I talked about in yesterday's post. Specifically, we'll change the syntax of the extern mod directive -- which says "link this external crate with this program" -- to take a string rather than an identifier. So instead of:

extern mod foo;

we'll allow:

extern mod "foo";

or

extern mod "github.com/catamorphism/foo";

But in the latter case, how will I refer to foo in my code, since the package ID here is not an identifier? The Rust compiler will either guess the package's short name from the package ID's file stem if it's a valid identifier; in other cases, it will support this syntax too:

extern mod foo = "github.com/catamorphism/foo-bar";

that gives a package with arbitrary characters in its package ID a valid Rust identifier.

Not rocket science, but incremental progress towards the dream of writing the Rust build system in Rust.

comments

Fri, 10 May 2013 05:07:24 GMT

A comment on a post I can't link to (friends-only), but that basically compared certain recreational programming language conferences to church, reminded me that I stopped being an atheist right about the same time as when I started to stop worshiping CS, hackers, and hacker culture. Funny, that.

comments

TMI: Back to rustpkg

Fri, 10 May 2013 00:28:17 GMT

After taking three days off to fly to Europe, attend a funeral, and fly back, then some time to catch up on the inevitable email and bug-triage backlog, I'm back to working on remote package IDs for rustpkg.

On the plane over the weekend, I was working on getting rustpkg to accept package IDs that resemble URLs. For example: rustpkg build github.com/catamorphism/test-pkg. So, not really a URL, but a URL fragment. rustpkg should do the obvious thing and use git to clone the remote repo into a local directory, then build the local cached copy as usual.

You'd think this wouldn't be hard, but I ran into issues because internally, rustpkg normalizes hyphens into underscores so that all package IDs can be legal Rust identifiers. (Rust identifiers can't contain dashes, but can contain underscores.) But for a remote package, you still need to keep track of the original package ID since that dictates the URL you need to fetch from. I solved this by adding two fields, a local path and a remote path, into rustpkg's internal representation of package IDs, but I'm still not sure this is the right solution. It beats calling a normalize function in an ad hoc way everywhere, as I was doing before, though.

Then the second thing is being consistent about which build artifacts contain the version number as part of their name (for example, the library name does, but the installed executable doesn't...) though I'm not sure why this wasn't coming up before.

And, doubtless, more than that. Details, details...

comments

YVR->MSP->LHR, BRS->AMS->YVR

Thu, 09 May 2013 02:39:54 GMT

Saturday, four days ago, I flew from Vancouver to Minneapolis, spent my layover chatting with my dear friend ADB who had come out to the airport to meet me, and then flew to London on a red-eye. (But not before ending my 31-month streak of never getting either groped or pornoscanned in an airport; there was only one checkpoint open at MSP that Saturday night, with only a scanner option. I had been planning to opt out if that happened, but at the last minute I decided I didn't want a random cis person touching me. In any case, I couldn't think of a better reason to end the streak.)

Sunday, I arrived in London feeling like a zombie, since I'd only slept for about four hours on the plane, if that. Plan A had been to go to a coffee shop for a few hours and noodle around pointlessly on the Internet, I mean catch up on work, I mean... In any case, my laptop was almost dead and the power adapter I'd bought at the airport wasn't grounded, which of course I didn't notice when buying it, in my zombified state. So I collected all my belongings and headed down the road to the Superdrug, where I bought another adapter. Nope, that one wasn't grounded either, and so I embarked on a long, long journey to the Apple store in Covent Garden to get the "world traveler kit". I ended up finding out just how long it can take me to find the Covent Garden market starting out from the Covent Garden tube stop (answer: a long time), and by the time I got back to the coffee shop where I'd planned to meet jasonelvis, he was waiting there.

After dinner with Jason, Tracey, and their adorable three-year-old, we all agreed that I'd want to collapse... except instead, Jason and I stayed up for a while talking about Debra. I was able to put my tiredness aside, because getting time to talk about her with someone who knew her the way I did was really important to me and meant a lot.

Monday, we accumulated more people and headed out to Bath in various cars. We went to a park and (unexpectedly) saw hot air balloons take off, then Indian take-out food was had and silly TV was watched.

And then, Tuesday, the big event. Prefaced by hat shopping with the three of us guys in our little entourage, since we'd been told that Debra wanted the funeral to reflect her Jewish heritage, though it wouldn't be entirely traditional. So part of that was that the men would cover their heads, and the women would too if they wanted to. That was fine, but none of us had hats. Then it turns out to be difficult to find a funeral-appropriate hat in May, but the clearance rack at Debenhams saved the day.

Fully equipped with hats, we drove the 45 minutes to Bristol and got to the chapel and cemetery, in South Bristol, a bit early but not too early. I met various people who I'd only known from their LiveJournal comments before, and before we knew it, we were being called in for the service. The opening music, "Good Morning Starshine", let us know that this wasn't going to be an entirely traditional funeral. Debra wasn't a traditional person, so that was appropriate.

There were several eulogies, including one delivered by Jason, which captured the playful, caring, bum-joke-loving Debra who I knew. But the moments I remember most clearly were actually the music: Kate Bush's "Feel It" in the middle, and Lemon Jelly's "Space Walk" at the end. Someone had posted a link to "Space Walk" on Debra's Facebook wall soon after she died, and I listened to it in my apartment. Hearing it again at the end of the service took me back to that confused, surreal state.

We milled out to the grave site, which was facing out on a hillside with a really nice view of the river and the green hills beyond. I thought to myself that maybe someday, years from now, I would have some reason to be back in England again, and I would rent a bike and ride from Bristol up to the cemetery; it would be a nice ride. And they laid her in her grave, in a wicker casket, which seemed very fitting.

A group of us went to a pub nearby for lunch afterward, and comics that Debra had been involved in making got passed around; I got to look at some I hadn't seen before. Then we headed to Debra's house to pay our respects to the family and such friends as were still there. Talking to Debra's mother and stepfather, I found myself struggling for words; I found it hard to explain what Debra and I were to each other, and resorted, as so many queer folks do, to the language of "friends". Maybe it's something to do with that whole queer thing of not being able to assume there's a framework your relationships will fit into; maybe it's something to do with how none of it really makes sense if you can't assume the other person understands the notion of deep, meaningful, partially computer-mediated relationships. Probably some of both.

Debra's last LiveJournal post was about hummus. There are worse things one's last LiveJournal post could be about. Or rather... the last one I can see; due to me moving from LiveJournal to Dreamwidth, I'm no longer able to see a lot of her posts that I was able to see before, which is a little sad; I would have liked to re-read her posts from around the first time we met in person, especially.

And then the next morning, Jason did what only a true friend would do and drove me to the airport bus stop at 5:45 in the morning, and eventually I made it back to Vancouver, a place I can't lay any permanent claim on.

"well, it could be love
Or it could be just lust but it will be fun
It will be wonderful"

comments

How To Do Things: Some Preliminary Notes

Sat, 04 May 2013 23:41:10 GMT

Brain Hacks

Almost a year ago, a friend and I had an offhand email exchange that let to me saying I wanted to write a blog post about what I've discovered so far in re: managing myself and getting myself to do things in a way leading to more happiness for myself. These tips apply to both work and personal goals (whether it's a hobby, household maintenance, making art, or keeping up friendships); I suspect for many people like me, the lines between can be blurry.

"Time management" is the best phrase for what this post is about, I suppose, though it's a phrase that has bad connotations for me (as I'll explain later). Though it's less succinct, I could also say it's a post about how to hack your brain in order to get what you want. (Are you not your brain? It's been a while since I took sophomore philosophy, but to a very rough approximation, I'm going to assume each of us is made up of communicating subprocesses that sometimes cooperate and sometimes conflict. An example is when part of you knows you have to get up for work at 7 AM tomorrow and that you need 8 hours of sleep per night if you're not going to feel awful, but you stay up until 2 AM looking at cat macros anyway, beccause another part of you needs to be soothed with something silly and familiar.) I could also describe it as self-organization or as being your own project manager. I suspect a lot of people know what I mean, though, and it certainly hasn't gotten any easier to deal with distractions and focus on what's important now that lots of us have the Internet next to our butts all day and night.

I feel a bit silly giving advice on self-organization, because I still feel pretty disorganized and that I'm pretty inefficient about how I do a lot of things. But this post isn't really advice so much as my notes on a collection of ongoing experiments. If these notes give you some ideas you can use, great! If not, well, science isn't always useful.

So here's what I've learned about getting things done. I only because willing to learn about it in past 5-6 years or so. That was about when I read the book Getting Things Done (GTD) by David Allen; it wasn't super helpful to me (partly because of its orientation towards using physical file folders rather than a computer, but maybe there is an updated edition now), but I did take away three good points from it:

Keeping one's email inbox zero -- the book may even have been talking about a literal physical inbox, but it's the same zero. The author says that whenever you have an item in an inbox, that's something screaming out for your attention, and it causes anxiety because you don't know what the next step is towards addressing it. That's certainly true for me. So I've made more of an effort than I did before I read the book to keep email not in my inbox, and, if something is complicated, to make a to-do item to address is as opposed to just leaving it in my inbox. To-do items are better than emails in my inbox since they're attached to a particular day, if not a particular time (more about this later).
GTD talks about knowing what the next step is rather than just having a huge, vague item on your to-do list; and also identifying the next step anytime you stop working on a given project to go rest or to work on something else. For example, if my to-do list says "start working on rustpkg", I will put that off, because it's a huge task and I don't know where to start. If it says "write a unit test for the install command", that's a much more approachable step, and will probably lead to more work beyond just that one little sub-task. I could make the first step even more specific than that, but get the idea.
This is a bit like the first point, but: GTD talks about the importance of writing everything down. I'm still working on this, but it's one of the major principles that has allowed me to become a more functional person. I don't know if my memory is unusually bad, I just know I forget things if I don't write them down. This applies to both week-by-week schedules and, sometimes, just to sequences of tasks I do regularly. For example, a year or two ago I made a list of everything I do to get ready in the morning, and another one of everything I do before I go to bed at night (the latter one starts something like "take meds, brush teeth, use neti pot...", though actually I've even broken up some of those into more steps). This is because I noticed that I would forget to do things, as well as put off getting ready for bed because there were too many things to do and it was easier to be on the computer. It seems silly, but just having these lists has helped me a lot when it comes to going to bed when I'm actually tired (as opposed to staying up late because I'm too tired to coordinate getting to bed) as well as not sitting around for hours in the morning doing absolutely nothing because again, thinking about getting dressed and ready is overwhelming.

I'm pretty sure I have some sort of executive function issues; when people who are on the autism spectrum talk about executive function issues, it strikes a chord with me (though I've never been diagnosed with autism and many other aspects of being autistic don't seem to be things I've experienced), though I've never been formally diagnosed. I was provisionally diagnosed with inattentive ADD once, as an adult; unfortunately, the meds had no effect on me and so to me, there isn't much point knowing whether I have ADD, anxiety that acts like ADD, or something else. In any case, maybe it doesn't matter (for me), if I can find the right accommodations to make for myself and learn to be okay with making those accommodations for myself, with taking specific action to make things easier that might already be easier for a lot of people. But so what -- I'm not a lot of people.

While I'm talking about diagnoses, I'll also note that a lot of anxiety and maladaptive coping mechanisms come from having been treated very badly in the past. It's helpful to talk about these past experiences, but at least for me, that on its own doesn't make me able to function as an adult. I want to say this in as simple words as possible: I think the story that is often told about depression and anxiety as "chemical imbalances" is wrong or at least misleading. There is no doubt some amount of truth to it (though possibly not as much as we've been thinking) but the neat, tidy story that such illnesses are the result of random brain misfirings shifts blame from a society that enables systematic abuse of children and everyone else placed in a position of lesser power, onto individuals who can be deemed as defective and disregarded. Politically, I would feel dishonest if I didn't mention this, but on a pragmatic, day-to-day-survival-so-you-can-pay-the-rent-and-not-get-fired level, at least sometimes I have to occupy a mode where I'm just working with what I have.

How To Do Things

So here's what I've figured out about how to do things. I present it here not assuming that it will necessarily work for anyone else, but in the hopes that some of it might be adaptable or at least inspiring. I certainly wouldn't want to try to generalize, since then I would just be making stuff up, so I'm sticking to what specifically has worked for me. ( Read more... )

comments

Book recommendation of the year

Sat, 04 May 2013 05:27:06 GMT

"If it weren't for the unconventionality of my desires, my mind might never have been forced to reckon with my body."

Just finished reading Alison Bechdel's new (okay, not all that new, but I'm behind the times) graphic memoir _Are You My Mother?_. DTWOF was, of course, awesome; I enjoyed _Fun Home_; but this one is her best work, IMO. I hope she writes many more books that are as personal and insightful.

comments

TMI: Adventures in library loading

Fri, 03 May 2013 01:28:03 GMT

Life does not, apparently, go on as fast as one hopes; yesterday I was too exhausted and depressed to work and took a day off. To which I credit me being semi-functional today.

In any case, today I learned about the magic of rustc's filesearch module. What seems like eons ago but probably only a week ago, I set up some wacky symbolic link inside my build directory to get rustpkg to be able to find the core library. After pulling a new LLVM version, I had to blow away my build directory, as one often does. And thus, the rustpkg tests no longer ran because once again, it couldn't find core. And of course, the same thing happened on the bots, causing tests to fail, because my hack was a truly terrible hack (that only worked on my local machine).

rustc infers the sysroot -- which is the root directory that it uses for searching for standard libraries -- from the name of the executable you're running. Keep in mind that rustc is just-a-library so there's more than one possible executable name. Most executables sit under build/x86_64-apple-darwin/stage2/bin/whatever in our build system (not even talking about installed builds here, just in-place builds). The stages refer to the stages of compiler bootstrapping, but for testing we usually run stage 2. And of course, the host and But it happens that the test executable containing all the #[test] functions lives in build/x86_64-apple-darwin/tests/ and so the parent directory getting inferred was totally wrong. The answer is basically for me to just add in some terrible hacks to override the sysroot from my test functions, but it took me a while to get to that.

They didn't tell me in grad school that there'd be days like these...

comments

TMI: rustpkg install

Fri, 26 Apr 2013 01:49:46 GMT

The past couple days, I've been unsurprisingly not very focused on work; you'll know why if you read my most recent blog post that doesn't have the "research" tag.

But life does go on. Having landed the file searching patch that I talked about in my previous Rust post, I went on to working on rustpkg install. Like a good little software developer, I wrote the tests first, making the actual implementation pretty painless. Right now my tests are failing because apparently, I'm creating directories with the wrong permissions. Although lsing the directories, they look fine, so the Rust permission-checking code I wrote was probably wrong.

That (and a triage meeting) was about all I could manage today.

comments

Debra Boyask, 1966-2013

Wed, 24 Apr 2013 01:59:15 GMT

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):

comments

TMI: rustpkg can find files

Tue, 23 Apr 2013 01:29:44 GMT

Today's work was on bringing the reality of rustpkg up to the point described in my doc pull request, at least up to the point of the directory and file structure of packages and having rustpkg look for package source files in a src directory inside a workspace. Also, now it uses a one build directory per workspace for putting object files and other temporary files in, instead of one per package. A workspace is just a container for packages; right now, always a directory on your local filesystem, but in the future, also on github or some other remote server containing version control repositories.

Now most of the test scenarios that I checked in build, and I've crossed off one more task on the schedule. Yay crossing things off. This pull request contains the work I'm talking about.

comments

TMI: Documentation: what a concept

Fri, 19 Apr 2013 00:13:04 GMT

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 :-)

comments

Because I do write about topics other than Rust hacking occasionally...

Thu, 18 Apr 2013 18:16:03 GMT

I've got a new blog post up at geekfeminism.org about structureless organizations and whether or not they are good for people experiencing marginalization in the tech industry. You can also read my past posts on geekfeminism.org.

comments

TMI: More rustpkg work

Thu, 18 Apr 2013 02:46:33 GMT

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.

comments

TMI: Today in rustpkg

Wed, 17 Apr 2013 00:28:20 GMT

I'd given feedback on a rustc pull request saying "try to get rid of that copy" in a pull request, but when asked how, I looked at the code and realized it wasn't easy to rewrite without a copy. So that was an hour gone!

Then, back to rustpkg; I started testing it on the test cases I wrote yesterday (just manually, for now, though writing a test runner needs to happen soon) and noticed that I wasn't naming the output executables or libraries correctly. So I added code to synthesize the link crate attributes with the inferred name and version, so you don't have to write it explicitly in the package file. Now, 2 out of 3 of my test cases work.

And finally, to round the day off, removing a few more bad copies.

Next:

Error out in the case where no lib.rs, main.rs, bench.rs, or test.rs fine is found
Split tests into pass and fail subdirectories (for tests expected to build correctly, and tests expected to fail)
Add a test case to test that a package without a lib, main, bench, or test file fails.
Submit a new pull request.

comments

TMI: rustpkg marches on

Tue, 16 Apr 2013 01:37:02 GMT

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!

comments

TMI: rustpkg: landed!

Sat, 13 Apr 2013 00:52:21 GMT

My pull request from yesterday landed, so I'm on to further cleanup. First, I submitted another pull request to use a condition for error handling instead of making a function return an Option. Conditions are supposed to be for rare errors; this particular case was the situation where creating the build directory in the package directory to put the build output in fails. I figured that would be pretty rare. I hadn't really written code with conditions before, but they're about as simple as it gets. Sort of like exceptions, but simpler and implemented in terms of Rust macros.

For my next trick, I wanted to make sure that rustpkg could compile a package that doesn't have a package script. For realism, I decided to see which of the Servo submodules had a relatively simple Makefile, meaning that rustpkg should be able to build it as-is; I picked rust-core-foundation, and am working on getting it to build now.

comments

TMI: First rustpkg pull request!

Fri, 12 Apr 2013 01:19:15 GMT

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.

comments

TMI: rustpkg progress

Thu, 11 Apr 2013 01:34:52 GMT

My titles are un-creative lately.

So remember when I said I'd gotten rust-sdl building with rustpkg? I really... didn't. Or else, I broke a whole lot of code while rebasing. Either way, I spent today and yesterday (when not paying attention to the work week proceedings) getting it to work again. And, just now, I finally did, after learning a valuable lesson about Unix command line argument processing that doubtless I knew in 2004 but didn't know yesterday.

Next, continue cleaning up code so I'm not embarrassed by "oops, how did that get in there?" moments when I submit a pull request.

comments