tim | Recent Entries

I have not been writing this week, obviously, because I've been mired in a maze of twisty little issues, all different, and haven't felt I've had anything interesting to say about them. That is absurd, of course, because my entire goal in this blog is to write everything about everything I do, whether it's interesting or not! But that goal can still get a bit intimidating.

Also, it's seemed that the chances of pulling something from our incoming branch that actually builds are getting monotonically lower; plus the 0.3 release, which happened today (yay!) meant that the tree was closed and some things couldn't be fixed immediately. (Don't worry, folks-who-just-want-to-use-Rust who are reading this -- you can always download either the shiny new release, or the master branch on git, and know you'll have something that will build. If your platform is supported. Most likely.) ( Read more... )

Today: more work on the paper. Writing is hard... and all I was doing was minor editing today. Need to do some more substantive work over the weekend.

Also worked on issue 2771 some more, but had one of those annoying moments when you spend 1-2 hours working on something, finally get it compiling, and then get the exact same observable behavior when you originally did. It's like the universe telling you to eff off.

Yeah, at least work-wise, and work-politics-wise, this week is fired.

("ICE" stands for "internal compiler error" in Rust-land... just a bit of '90s humor there.)

Today: not such a great productivity day either. Bug triage, so I turned all the remaining TODOs in the code into FIXMEs with issue numbers. I love when I can delete a "FIXME [when feature X works]" altogether because I know that feature X does work now and I can change the code to use it! In this case, it was a very simple change: changing a class in the parser to have an empty destructor to enforce that the type is non-copyable. This is kind of a hack, since we don't have an explicit way to say that a class should be non-copyable (the rules are that a class is non-copyable if it has a destructor; has one or more non-copyable fields; or both), but it seems like a pretty benign hack.

In case you're wondering about the "non-copyable" business, Rust classifies types into kinds, like many typed languages, but unusually, one of the kinds is the "copyable" kind. That lets us write type-parameterized functions that can be boundedly parameterized over only types such that values in that type are allowed to be copied. In case you're wondering why that matters, Brian explained it pretty extensively on the mailing list today.

Then I shifted into fixing bugs, or trying to, and narrowed down issue 2771 a bit. Looks like the interaction between intrinsics, inlining, and the little-used "list metadata" command is not going too well, as the metadata parser is failing to find a descriptor in a side table for one of the entries. That entry happens to be for a compiler-generated built-in function that's marked inlineable. I'm not sure whether the right thing is to not print out anything about those functions (since they were introduced by the compiler), or for the metadata pretty-printer to generate all the information the parser needs.

All I did today was work on the POPL paper. I should probably not *just* do that until the POPL deadline, but it is slightly tempting, given that the last bug I looked at involved scary runtime system stuff. I don't want to talk about the content of the (yet-to-be-submitted) paper much since I'm not the primary author, but you can read a related blog post from Niko if you're curious what the paper was about.

Not directly related to research, but indirectly related as various events have meant that this issue has, once again, been compromising my ability to focus on it: Mozilla still lacks a code of conduct, and that's a problem. The Rust project itself does have a code of conduct; I wish the Mozilla community as a whole could do the same and come to a basic agreement that in this community, we do not arbitrarily exclude people -- and their contributions -- based on traits as opposed to behavior, and that we do not tolerate harassment or insults based on membership in protected classes.

I've got a much longer post about related issues (which won't be posted under the "research" tag, though it might be linked) coming up sometime this month. I hope folks will pardon the foray into not-exactly-research in this post; people write code and being a person who writes code isn't all about formal rules and symbol manipulation.

I think it's time for me to institute a comment policy. I already had something like one on my user info page, but I'm not sure how many people look at that.

Comment policy

I like comments, especially those that disagree with me or challenge me to think further, as such comments encourage me to grow and learn. I don't like or need comments that undermine my narrative of my own experience or suggest, no matter how subtly, that I or my friends aren't fully human or shouldn't be treated equally to others; as abuse doesn't encourage me to grow and learn. This journal is heavily moderated; if you object to that, please seek out a different forum.

If you comment, I have a few requests:

Refrain from phobic or discriminatory speech, or speech that (in the words of s.e. smith) suggests that "people don't deserve autonomy, dignity, and a place in society."
Refrain from comments that have the effect of silencing or derailing (see Derailing for Dummies for additional examples).
As a corollary, refrain from questioning the existence of privilege or systematic oppression. There are many resources available online and offline for learning about these issues.
Provide a name or pseudonym that reflects a consistent online presence (as opposed to so-called "throwaway" or "sockpuppet" identities).

My journal settings don't allow comments that are completely anonymous, but it's easy to set up an effectively anonymous account, though I'll still see your IP address. I do screen all comments from people not on my Dreamwidth access lists. The last rule isn't hard-and-fast, as there are good reasons for allowing anonymous comments. However, if you violate rule #1 and/or #2, and do it anonymously, I’m very unlikely to publish your comment. If you violate rules #1 or #2 repeatedly, I will ban your account from commenting.

Just as I'm allowed to decide who's allowed in and what goes on in my living room, the same goes for my journal. I reserve the right to:

Moderate comments from people not known to me.
Not publish your comment at all or delete it after it’s been published.
Restrict comments for a particular post, or never allow them in the first place.
Make any comments on this blog public, even when I have screening enabled by default. When you write a comment on this blog, you should assume it will be visible to everyone on the Web. (This doesn't apply to respectful comments if you explicitly ask that they not be made public.)
Repost any comment as part of a public post. (See previous item.)
Modify these rules at any time.

This policy is adapted from Christie Koehler's comment policy.

While I feel like I got nothing done today, I should post anyway, for accountability's sake.

- I tried to figure out issue 2724, and failed. That is, I have a patch that I think fixes most of it... except now I get a mysterious segfault in the cycle collector while running the core library tests. Clearly, something is messed up, probably to do with different data representation expectations between the rustc back-end and the RTS (specifically do with how I changed the class-with-dtor representation to try to get rid of what valgrind was flagging as "uninitialized" data). It all makes my brain taste like burning.

- Rewrote the abstract for our POPL paper. I feel like I made it better (where better is defined by Kent Beck's advice on abstracts), but I also made it longer; woe.

- Met with Dave, who's my boss, and talked about how I'm doing and stuff. Further details redacted.

"There’s a theme here: that silence and secrecy are the paramount values, and open discussion is to be avoided. It’s a basic function of institutions, but often of informal social networks as well, to protect the body from reputational damage. That’s what colleges do with rape: they use nondisclosure agreements so that whatever the result, nobody can talk about it. When I was in college and there was an accusation of a sexual assault on a woman I sort of knew, I got the account from her, and she said it happened and I believed her, so I told anyone who would listen about the perp. So the administration told me I’d be punished if I didn’t shut up. That’s how it happens. Not talking about it is rule #1."

-- Thomas MacAulay Millar, There’s A War On Part 3: A Fungus Among Us (TW for descriptions of rape and of personal and cultural abuse)

This makes me realize that when I was at Portland State and I ended up getting kicked out because I requested to not have to work with the guy I witnessed making a "joke" about raping another student, I didn't just get kicked out because the faculty didn't like having their authority questioned. It was also that if I had been granted that exemption (an exemption that was, of course, granted to every other graduate student -- nobody had to work with someone they didn't want to work with), I would have also talked about *why* that was. Especially if there were new students who were women, or who were non-heterosexual, or who were gender non-conforming, I would have told them that this guy was a creep, that he was still in the program, and that it's best to avoid him. And that would have undermined their confidence in the ability of the department and the university to create a safe working environment. So rather than addressing the problem and making the environment safer, the answer was to kick me out so I couldn't tell.

(It was Thomas Dubuisson, I have it on good authority that he's not sorry, and I hope he never works in a position where he'll have power over anybody.)

I am still assuming that universities, churches, and other social institutions have a purpose other than to shelter the abuse of vulnerable people... but I'm also still having a hard time seeing what it is, on a practical level. And I think the passage above points out how secrecy and silencing aren't to protect the victim's privacy, because the victim doesn't usually get asked for their say in the matter. No... it's to protect the institution so that the institution can keep on hosting abuse.

All I did today was work on issue 2734, but happily, I fixed it!

I turned out to be wrong in my initial hypothesis about the bug, and that led me to spend too much time barking up the wrong tree. I'd thought the wrong tydesc (type descriptor) was getting generated for the call to perform_hax at type @int. The compiler automatically generates header fields containing tydescs to handle operations like incrementing and decrementing reference counts and freeing memory when the refcount goes to zero (also, the cycle collector, part of the RTS, needs to know about these headers as well). It avoids generating multiple tydescs with the same values at different addresses, since that would just waste memory. I'd assumed that in the case of either an iface type, or an opaque box type (the latter type isn't visible to Rust programmers but gets used internally to represent ifaces), a tydesc was getting re-used when it shouldn't have been, and that was why I was seeing behavior that looked like the str drop glue getting called on an int. (The drop glue is the bit of code that lowers the refcount for a given thing.)

But that wasn't it; commenting out the code that results in tydescs getting re-used didn't fix the bug. I'd been working on this for over a day, and I finally got frustrated enough to ask Patrick and Brian, "can you explain how, at runtime, the code knows how to free the contents of an opaque box?" Patrick said, "by pulling the tydesc out of the object", and that was more or less what I'd figured out by staring at the code, but it all looked okay to me. I started explaining the bug to Brian in the hopes that he would be able to explain the opaque box code, and he asked me whether the bug was in code not getting monomorphized correctly, or in how one of the monomorphized instances got generated. I'd assumed the latter, and said so, but that I wasn't totally sure. He said the person I really wanted to talk to was the one who's on sabbatical right now, to which I said that I was going to go drinking. And I did!

...While the friend I was drinking with was in the bathroom, I pulled out my laptop, like you do, and Brian's question came back to me. Based on some print statements I'd inserted, I'd assumed that two *different* monomorphized instances of perform_hax, were getting created one for int and one for str, but when I modified the print statement, I realized that wasn't so. For some reason, perform_hax wasn't getting monomorphized at all and both callers were just calling the original version. Why was that?

...Thanks to printing out the monomorphic function's hashed ID, I saw it was the same as the original function's def ID (defining ID), with something attached called mono_any... well, what's that? I saw the mono_any was introduced in only one place, in trans::base::make_mono_id. It gets introduced if the type parameter that a function is being monomorphized on has zero "uses", meaning its function body doesn't depend on it in any way. But why would that be? perform_hax has one type parameter, T, and the function body clearly depends on it: it has to return a record pointing to a tydesc that's correct for the contents of the contents of the opaque box (which is to say, for whatever type T gets instantiated with).

The type_uses analysis is what determines the number of uses of each type parameter -- that is, how the function body depends on each of the type parameters, and it had a bug: it wasn't looking under @s; as well, it wasn't noting the dependency of the whole function body on e's actual static type, if it has a cast like e as frobbable, if frobbable is an iface ty. In that case, you have to return a boxed record containing a ty desc that's *specific* to whatever e's type really is, so you really do depend on e's type. When I fixed these bugs, the test worked. Splendid!

And this is why I love debugging: that moment when you go from knowing nothing to complete understanding. At least complete understanding of a fix. I still don't claim to understand type_uses all that well, but in my defense, there is a comment at the beginning saying "This unfortunately depends on quite a bit of knowledge about the details of the language semantics, and is likely to accidentally go out of sync when something is changed." I don't think casting to ifaces is newer than type_uses itself, but it is an infrequently used feature and not well-tested.

So the moral of the story is: if you think going drinking might help, go drinking :-D

Today was bug triage day, but after last week's stupendous FIXME revolution (Graydon finished tagging all the FIXMEs and wrote a script that enforces, as part of running the test suite, that every FIXME has an issue number), my usual pastime (annotating FIXMEs) was no longer needed.

Except! There are still TODOs! haHA. Actually, there weren't that many TODOs in the codebase; I guess most people were pretty good about being consistent and using FIXME. Still, there were some, so I got started on fixing or annotating the ones in the libraries. Something drew me into refactoring quite a bit of (older) code in the rope library to use classes where possible, and generally be more concise: for example, call option::map_default, which is equivalent to Haskell's Maybe::maybe function, where possible, instead of explicitly pattern-matching. As an aside, there aren't too many times when I miss laziness, but this was one of them: I can write map_default where the default is an immediate value (like an integer literal), but if it's anything more expensive to compute, or even worse, a fail, I have to write the explicit alt because that's what gives me lazy evaluation. It's true, I could write another version of map_default that takes a thunk for the default, but meh.

On the other laptop, I banged my head against issue 2734 for a while. I have a vague theory that trans re-uses the same type descriptor for the opaque_box (or possibly opaque_iface) type... as the name "opaque" suggests, the ty descs would look the same at compile time but would call different glue to free the contained values at runtime. Combine that with monomorphization, and you get a bug where reordering functions affects whether or not the code tries to free a non-pointer. Fun times! I think I'm close to narrowing it down, though.

Well, somehow that was all I got done in 8 hours. Oh well, there's always tomorrow.

Here's a comment I wrote on a locked post by a friend discussing frustration (as a non-programmer) about being in conversations about programming where people talking about code weren't really making an effort to be understandable. I thought it was worth posting elsewhere.

I can sympathize with this because even though I've been programming for 17 years, I *still* get that "it might as well be Russian" (or Japanese in my case... I know a bit of Russian) feeling quite often when listening to people talk about code... and often, people I feel like I should be able to understand, like my immediate co-workers, or people at conferences (that are dedicated to the small, specialized area I used to focus on). I think part of it has to do with my difficulty processing speech (I can handle small talk just fine, but combine speech processing with any sort of difficult/complicated/abstract *content* and my brain falls over and dies), part of it is anxiety caused by impostor syndrome that ends up being a self-fulfilling prophecy (when I can't understand something because I'm devoting too much effort to being worried that I won't understand it), and part of it is that CS and software are just so ridiculously specialized that even confident people with good communication skills just can't understand what each other are talking about if their specialties are different.

But believe it or not, I do know the feeling of alienation that comes from being in one of those conversations... and as with you, I hardly ever get it with any other conversation topic, even ones I know much less about than CS (well, maybe once in a while with physics or math, but most physics and math conversations I'm in on these days are people bullshitting and I'm well aware of that, so...)

Anyway, I'm not sure what the point of this comment is -- I don't think that my lack of confidence in my area of expertise should magically erase your lack of ease talking about an area you have no expertise in -- so I'm not sure what my conclusion is. One is that Bay Area tech culture can be really exclusive (when certain kinds of knowledge are used as a proxy for having had certain life experiences and *not* having had to deal with certain kinds of problems; I didn't have a computer when I was 5 and sometimes I feel like if I did, I'd be able to keep up with my peers). And another is that, well, often geeks just have a really hard time talking (or thinking?) about anything non-technical, and that's a flaw on their part, because part of being polite is to talk about things that won't exclude your conversational partners. I get the feeling people who sell insurance don't talk about it all night while hanging out at the pub. Why can't geeks extend others a similar courtesy? (And I think that also relates to my first point: privilege is *not* having to accommodate other people socially, and if you learned to talk about something besides code you might actually end up including people you'd prefer to exclude.)

ETA: I just came across this post on "technical entitlement", which overlaps with some of what I'm saying but says it more clearly.

I ended up only working a half-day today, as life and its endless cavalcade of errands and paperwork intervened. (Life is what we do in between sessions of paperwork, I guess?) But one of the things that intervened was a doctor's appointment that will result in me becoming hella more productive... we'll hope.

I'm still working on the two outstanding bugs I worked on yesterday, one being the shape code for comparing resources. While my post yesterday was rather elliptical, the basic idea here is that Rust has some polymorphic -- very polymorphic -- operations, such as logging and comparison, that are baked into the runtime system, that does some dynamic magic to figure out how to compare arbitrary values to each other. I still don't have the comparison operations for classes-with-destructors working, but I think I actually got a better grip on the runtime system code in the meantime. I also figured out that valgrind has an option (--track-origins=yes) to tell you who created the uninitialized values it's complaining about, and surprisingly, in this case, the values were created in... code generated from Rust code. Knowing that was very helpful, and led me to guess an alignment bug: a class with a destructor has an 8-bit unsigned int field that's the "drop flag" (which the destructor sets on entry, preventing multiple destructor calls in the case of cyclic structures) and then a field that's a pointer to the class itself. My guess is the struct fields were getting 64-bit aligned, leaving three bytes of uninitialized junk that makes valgrind unhappy. I haven't confirmed this for sure, but did try changing the u8 field in trans to a uint instead (haven't tested it yet... I got distracted).

The other one is the ifaces refactor, which isn't as annoying, it's just a matter of chasing down the places that are wrong and fixing them. Thank $deity for a regression test suite.

I went on a four-day trip to Portland, during which I found it hard to write blog posts, so I didn't... even though I was working two of those days, somehow the challenges of working remote (especially from the train -- omg, Amtrak wifi, but I'll rant about that somewhere else) made it hard to do anything but get code in.

And because I didn't write daily blog posts, the past couple days of work are already a bit of a blur in my mind... but the big news is that I was able to remove resources from Rust! And there was much rejoicing. Really, it doesn't help with that much except for getting rid of one more redundant construct from the language; resources are just a special case of classes that have destructors, no methods, and only one field. In any case, I was able to replace classes with resources everywhere (mostly monkey work), fix the bugs that that exposed (there were some), and most happily, make resources callable from the cycle collector; that bug had been blocked on my lack of understanding of the RTS code for a while. I can't say I came to any grand conclusions about the RTS; I got the call to the class destructor to work mostly by trial and error.

Also, making the snapshot that I needed to make in order to land that change was really hard, maybe because the bots were being flaky, maybe because I kept messing up and uploading a version that wasn't quite right. Anyway, it's done now.

Now I'm trying to clean up my outstanding bugs; having some fun with a minor refactor and banging my head against the shape code, the latter of which is also part of the RTS, and involves C++ features I don't really understand. I'll probably have to ask for help with that tomorrow... but for now, lots of "why did this code even work?" moments.

Almost ten years ago, I posted this to LiveJournal:

From Nora Ephron's essay about the tenth Wellesley Class of '62 reunion, in _Crazy Salad_:

I never went near the Wellesley College chapel in my four years there, but I am still amazed at the amount of Christian charity that school stuck us with, a kind of glazed politeness in the face of boredom and stupidity. Tolerance, in the worst sense of the word. Wellesley was not alone in encouraging this for its students, but it always seemed to sad that a school that could have done so much for women put so much energy into the one area women should be educated out of. How marvelous it would have been to go to a women's college that encouraged impoliteness, that rewarded aggression, that encouraged argument.

And she summarizes everything I've thought about Wellesley, 35 years before I even got there.

Today, Ms. Ephron died. May she rest in snark, as peace would probably bore her, as it would me.

(Oh yeah and I heard she did some movies or something.)

Hmm, today was exceptionally lacking in productivity! Except for one thing that will hopefully have a very positive long-term effect on productivity, but that's nothing to do with Rust.

Made a few edits to the POPL paper. I should talk to Niko when he's here about what the priorities are.

Finally finished the minor library change (adding some uses of classes to core::comm) that I've been working on for eons, which meant finishing the accompanying destructor fixes and getting a snapshot together. I don't even. Still waiting for the bots to finish building the snapshot. I don't want to say it's done until the snapshot is officially done and I can run tests locally with the new snapshot.

Decided not to check in my fix for issue 2242 -- I had an easy fix to resolve that makes performance much worse, and it seemed like there's no point in coming up with a better fix when Patrick is almost done rewriting resolve and that might fix the bug from scratch anyway.

Fixed issue 2642 -- totally straightforward except for when I couldn't figure out why the test case that I added for it runs forever, and it was because... it contains an infinite loop, and I didn't add any code to bypass it when it actually runs. ^_^ (So many things would be easier if we just compiled code and didn't execute it.)

That's more or less it. Have resorted to typing ps -ef repeatedly while logged into the only buildbot that hasn't finished making the snapshot, to see whether it's running a command that's late in the build process.

Today was full of things that took time away from debugging, but that's okay, because there sure has been a lot of debugging lately.

First, the weekly meeting, during which we agreed on a solution to issue 2633, yay! And quite a lot of type system discussion.

In my limited coding time, I did do something exciting, which was solve the "nested class" problem from yesterday. It turned out the solution to the "duplicate definition" error was that my fix affected one part of resolve that deals with scopes, but another part adds things to an index and that was already correct, so my fix caused entries for the same class constructor to be added multiple times. I fixed that and make check ran with my comm changes... all the way through. That branch hadn't compiled all the way through in quite a while. But then I needed a new snapshot (I'd made one locally, but to check in code I need ones for all the platforms built), and as an aside, despite over a year of Rust being self-hosting, I have to read these instructions every single time... it's bad. In any case, something went not-quite-right with the snapshot and I'm a bit hazy on the details now, since I ended up working on other stuff for the rest of the day.

I went to Brian (former and future Mozilla Research intern who was visiting)'s talk on Timelapse, which was excellent, and it was good to go to a talk since I don't usually go to them... something about how my brain doesn't work that way. But when it's a good speaker like Brian who also puts in a lot of effort into delivery, I can get something out of it. And after that, we went to lunch... for two hours. Hey, we don't have visitors every day.

After lunch I worked on the POPL paper a bit; I added an example that I think will tie the "intro to Rust" section together with some more work. Then there was a mixer for current interns and ex-interns-who-became-fulltimers, but there was a mix-up with the food so I left after a while and worked on the paper some more. This paper-writing thing is strange. I haven't worked on a conference paper in months and months (and if you don't count the typestate paper draft that didn't get very far, I haven't worked on one in almost two years), but working on a paper again seemed totally natural. But hopefully someone likes my contributions besides me.

When I left off, I was wondering why my memory leak had turned into an LLVM assertion failure. Fortunately, I didn't need to hack LLVM to make its error message more useful, at least not this time. Mental static analysis did the job: I looked at my code for translating class destructors again, and realized that the code that was monomorphizing destructors (making specialized copies in the case where the containing class has type parameters) was re-using the same instance for destructors that had different type parameters.( Cut for length )

One of the things about working on compilers that I find satisfying is that what looks like a completely mundane bug at first can expose an interesting question. (Maybe it goes the other direction sometimes too, but I can't think of any examples offhand.)

I mentioned on Wednesday that I was working on trying to isolate a segfault bug resulting from a combination of my (seemingly trivial) changes to trans (that is, what we call the code generation pass), and Eric's changes to trans. After spending a lot of Friday on this too, I was able to isolate the code in trans that was causing the crash: ( Cut for length )

I don't have much to say about work today, except that I finished annotating (*all* the) FIXMEs! So almost every FIXME comment in the Rust repo has an issue tracker number associated with it. That means all the bugs are in one place and FIXMEs are more accessible for newcomers looking for their first bug to find. (Admittedly, some of the descriptions are pretty cryptic since I didn't always understand exactly what the comment meant, but I tried to label everything with at least one area label so at least people who are interested in a particular part of the compiler can find the open issues related to it.)

I didn't actually *fix* a lot of the FIXMEs except really minor ones (but oh, a minor refactor can be quite satisfying); the one interesting one I tried to fix, and ended up backing out of, involved two different functions corresponding to different stages of the compiler that were potentially evaluating the same constant expression more than once. Since it's a *constant* expression, that should never be necessary! In principle, it should have been possible to make the first function (in the typechecker) update a cache that the second function (mainly called from the code generator, though sometimes elsewhere) would consult. In practice, it turned out that due to the order that the typechecker checks items in (no particular order, since top-level items are mutually recursive), and the fact that the typechecker actually does call the second function too (indirectly), the second function might get called on a given item before the first. Making the second function call back into the first one was too complicated, so the change I ended up making was just to make the first function update the same cache that the second one uses. Now, the second one avoids recomputation sometimes, but it still might happen depending on the dependency graph of the program.

And in a week from now, all I'll do on bug triage day is triage all the new bugs since the last bug janitor looked at bugs, and fix any incoming bugs that look easy, since surely no one will add a new FIXME anymore without an issue number -- right? ;-)

Also trying to make this brief, since I have work in progress (and am trying not to get sucked back into it tonight! Important when the train home only runs once an hour.)

Yesterday I talked about the bug involving a memory leak in comm, and successfully fixed the first memory leak. Today (well, really, late last night) I isolated the comm unit test that was resulting in a memory leak (exactly one string that was alloc'ed without being freed). ( Cut for length )

It's late and I've been too hot on the trail of various bugs (or at least feeling like I was) to write a post, but I don't want to get too much out of the habit of writing.

On Friday I was working on two bugs. The first had to do with changing comm to use classes. The bug wasn't what I thought it was at all. Instead, it was just that the destructors for port_ptrs weren't running at all when the call to port was in a different crate than core. That explained the behavior where the destructor would run if it was called from within the core crate, but not when run from the driver. ( Cut for length )

S	M	T	W	T	F	S
	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30

Tim's journal

Taking metaphors too far since 1995

TMI: It is dark; you are likely to be eaten by an ICE

TMI: TGIF?

TMI: ICE, ICE, baby

TMI: Papering

Comment policy

Comment policy

TMI: Placeholder post

Secrecy and exclusion

TMI: When in doubt...

TMI: Maybe they're more like "translucent boxes"?

Exclusion, conversation, knowledge, power, and geek culture

TMI: Short day

TMI: No more resources!

Nora Ephron

TMI: Infinite loops take a long time

TMI: Things that are not debugging

TMI: Sleepy Monday

TMI: From the ridiculous to the sublime

TMI: bug triage

TMI: Memory leaks and segfaults (or, what compiler writers eat for breakfast)

TMI: Loose ends

Profile

November 2021

Links

Syndicate

Most Popular Tags

Page Summary

Style Credit

Expand Cut Tags