tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
Today I worked a bit more on issue 5683 (which, for now, just means turning more of the rustpkg test cases into executable #[test] tests and not just English descriptions in a text file. We'll do something fancier later.

I attempted to figure out why my pull request for rustpkg versions failed tests on the Linux bot, but got nowhere, since the test that failed passes on my Mac, and rather than trying to remember how to ssh into one of our Linux machines, I decided to work on my talk instead.

My talk is in a little over two weeks. I got through about half the slides today, and will probably try to blow through the other half tomorrow. I mean just getting them into a rough form without any "fill this in" -- I expect to spend a lot of my time between now and June 19 working on the slides. I'm trying to turn off my inner critic and just write stuff down for now -- it's much easier to edit something that's rough than to turn nothing into something, which is what I'm doing now -- but it's hard, as usual. Also hard is striking the right balance between accessibility and realism with code examples. So far, I've found tiny examples to use from Servo, sprocketnes, and the Rust standard libraries. It's hard to find a non-trivial example that doesn't require explaining too many new concepts at once, though. So the ones I've pulled are very simple. Given that, I'm wondering how much it adds to be using real examples; I wonder if I should stick to using examples from Rust standard libraries or just make up my own examples. I originally thought the talk would be more interesting if I used examples from real Rust applications, but I just don't know if the details of those applications (not so interesting until you spend time immersed in them) justify the benefits of verisimilitude.
tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
Today felt a lot more productive than the last couple days have, even though I got in late and will have to make it up over the weekend since I have a farewell-to-Vancouver dinner planned with some folks. (Last day here is tomorrow!)

I submitted a pull request for extern mod inference. It's one of those things that seems simple but turns out to involve a lot of moving parts.

I started working on extracting the version from a source control repository, which looks significantly easier. The main thing has been figuring out git's arcane --git-dir and --work-tree flags in order to execute a git tag without cd'ing into the git directory (easier to automate, since no calls to os::change_dir and therefore explicit locks are necessary).

As per my discussion with Graydon earlier, I started consolidating the tests in lieu of writing a proper test runner right now. I had some English descriptions of tests that I'm trying to turn into #[test] unit tests that shell out and call rustpkg as a separate process. I've written them all up as pseudocode and now it's just down to implementing the helper functions I need. Of course, most of them will be marked as ignore for now since they depend on not-yet-implemented features.

So, by tomorrow, if things go well, I could still be up to May 20... these things always take longer.
tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
I don't know how long I've been saying that extern-mod inference was almost working, but now... it's working. What took so long? Just being consistent about paths and naming conventions and such, plus a bug I found today that had to do with the aforementioned copying-the-session hack. Turns out that was a bad idea, because when you build a new session, it makes a copy of the filesearch object and copies the entire additional-library-search-paths vector... exactly the thing I was mutating in the meantime with a mutable reference. So that was no good. I found a way to do it without copying, but I had to change the driver; I've been trying to avoid changing code in rustc itself just to make rustpkg work, but this seemed pretty reasonable. I just made the additional-library-paths vector an @mut ~[Path] instead of a ~[Path]. This seemed fine, since there's plenty of mutable data in sessions already. Since you need a session to call parsing/macro expansion, and finding extern mods has to be done after macro expansion, it's pretty unavoidable that someone will have to modify the library search paths after creating the session.

Just running a final round of make check and I can finally submit a pull request on this. Next, the last bit of extern-mod-related work, which is actually changing the syntax of extern mod so you can put in a full URL and not just an identifier. That's mostly parser work, which shouldn't be hard (famous last words).

I also started filling in the code examples in my Open Source Bridge slides. So far I'm worried that it's too basic, but I guess you can never be too basic.

Thinking ahead a bit:
  • I didn't know, but the compiler already parses extern mod foo ( id = "a/b/c" );, so for now, I'll just have rustpkg look for a special attribute there, and save #6407 for later.
  • Graydon and I agreed to do the most obvious thing for the test runner and have #[test] unit tests that shell out to call rustpkg, and check the output. I already have some unit tests, so it's just a matter of converting the remaining ones.
  • Getting the version (#5684) shouldn't be hard.

And... that'll bring me up to May 20.
tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
Today:
  • Did my Monday randomly-assigned-bug triage.
  • Tried again to get some test-case pull requests to pass.
  • Learned about build automation from Graydon.
  • Almost finished up extern-mod inference for rustpkg. I really wish I could say that I finished it and not that I almost finished it, but I got all my automated tests to pass (something I've been trying to do for days)... and then found that my one manual test didn't work, because I'd changed the expected directory format again without really thinking about it. I look forward to having only automated tests, but the test runner is a separate issue. Though, the more I think about it, the less I'm sure I need to write a special test runner for rustpkg -- maybe it would be enough just to have unit tests that use os::set_args and then call into rustpkg's main.
tim: "System Status: Degraded" (degraded)
I stayed at the office until about 11 PM trying to git bisect this performance regression (that it's possible that only I am experiencing; perhaps the space-time continuum around me and my MacBook is just flawed; 20 seconds for parsing libcore instead of 8 seconds seems like a big deal, though, and that applies to other phases as well), got results that didn't make sense, started over, and left without finishing (each bisecting step takes 5 to 15 minutes, depending whether it's rebuilding LLVM). If I were cleverer, I'd have figured out how to write a script to automate it.

In any case, as I so often do, I left feeling like I was the worst programmer ever *and* hadn't even succeeded in doing anything that was just for me today. I'm way behind schedule on rustpkg, what I'm ostensibly supposed to be working on; I started bisecting performance stuff because that was blocking me on rustpkg, and I started doing other stuff in the background like bug triaging since I needed *something* to do while waiting for compiles, but still, there's something I'm supposed to be doing and I hadn't gotten very far on it.

But before I left, I read the news that the I-5 bridge over the Skagit River -- over which I would otherwise have been driving tomorrow night (I'm driving down to Seattle so I can catch a plane to San José so I can look for apartments on Saturday and Sunday, then fly back up to Seattle and drive back to Vancouver on Sunday for my last week) -- collapsed, because a truck driver ran into part of the bridge, which caused the bridge to collapse.

I started thinking about how it would feel to be that truck driver. If I make a mistake at my job, usually I just feel bad about it, or in the worst case, a few people get annoyed with me. This person made a mistake at their job and caused a bridge to collapse. All by themself! (Probably some of the blame goes to the civil engineers who designed the bridge, but even so, lots of other people managed to drive over the bridge and not make it collapse.)

When I get frustrated with my work, lately I've been thinking, "well, if all else fails, I could become a truck driver." I like driving and I'm happier when I'm in motion. There are lots of things that appeal to me about it, actually.

But the fact remains that as a programmer, no matter what I do, I know I'm not going to make a mistake that will immediately destroy a bridge.

So I think I'll keep my day job for now.
tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
Today featured: the mystery of the overlapping node IDs -- which was causing yesterday's unsolved problem. Due to my get-around-the-borrow-checker hack, I was copying the session in a way that didn't actually copy all the state. So I was resetting the unique-ID counter to zero after doing the initial parsing, expansion, and injection of various primitives. This caused the obvious problems. Once I fixed that, I ran into the driver... not generating output when I called it from rustpkg on a library. That's bad. Haven't figured out why yet.

Unrelatedly, I've been trying to bisect a performance regression that I noticed in the compiler, though I'm not sure anyone else is seeing it (others have commented on a memory regression, but I'm noticing a time regression too). The first round of bisecting pointed to the commit from 5 days ago that updated the snapshot. So that suggests a performance problem that had been in stage2 and then snuck into stage1 when the snapshot got updated. So now I'm doing a second round of bisecting to figure out when the stage2 problem showed up, which is much slower.

And when both of those things are compiling, fixing warnings, which is almost done.
tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
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.
tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
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...
tim: 2x2 grid of four stylized icons: a bus, a light rail train, a car, and a bicycle (public transportation)
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.
tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
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.
tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
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.
tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
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.
tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
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).
tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
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.
tim: "Bees may escape" (bees)
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.
tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
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...
tim: 2x2 grid of four stylized icons: a bus, a light rail train, a car, and a bicycle (public transportation)
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 [livejournal.com profile] 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"


tim: Mike Slackernerny thinking "Scientific progress never smelled better" (science)

Brain Hacks

Almost a year ago, a friend and I had an offhand email exchange that led 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:

  1. 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).
  2. 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.
  3. 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... )

tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
"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.
tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
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...

Profile

tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
Tim Chevalier

November 2021

S M T W T F S
 123456
78 910111213
14151617181920
21222324252627
282930    

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags