Hit `raw` to get a wrapped version.

gistfile1.txt

Conversation about lifetimes on #rust, on mozilla's irc network,
prompted by hamnox and lahwran attempting to understand lifetimes.

Timestamps are in Mountain time. 

1-30 07:09.06pm <lahwran> so we're reading this http://doc.rust-lang.org/book/ownership.html
1-30 07:09.28pm <lahwran> it mentions lifetimes a lot, and gives examples of where to use lifetimes, and the effects of lifetimes, but it has yet to actually, you know, describe what a lifetime is
1-30 07:09.48pm <theme> lahwran, I actually treat lifetimes as dependency markers
1-30 07:10.05pm <lahwran> we (my partner and I) have made several guesses as we read as to what lifetimes are, based on inference, but then we got to the point where a function used a lifetime both for an input and an output
1-30 07:10.06pm <Havvy> They're descriptions to how long a value lives.
1-30 07:10.07pm <lahwran> the same lifetime
1-30 07:10.09pm <theme> which sort of makes sense to me
1-30 07:10.13pm <lahwran> and we were like "wait what"
1-30 07:10.28pm <lahwran> because if it lives for the body of the function, how can it be returning it?!
1-30 07:10.34pm <lahwran> wouldn't that need to be a new lifetime?
1-30 07:10.42pm <Havvy> It means that the output value will live at most as long as the input value.
1-30 07:10.46pm <lahwran> assuming we inferred the meaning of "lifetime"
1-30 07:10.51pm <lahwran> yeah! what?
1-30 07:10.55pm <lahwran> how can that work?
1-30 07:10.56pm <Havvy> For instance, a reference to a value in a struct.
1-30 07:11.04pm <theme> I treat `fn foo<'a>(x: &'a Foo) -> &'a Bar` as `fn foo<'a, 'b>(x: &'a Foo) -> &'b Bar where 'b: 'a`
1-30 07:11.14pm -*- lahwran wanders away babbling incoherently after encountering the Great Old Ones
1-30 07:11.17pm <theme> lahwran, is that what you mean?
1-30 07:11.41pm <lahwran> theme: that doesn't explain aaaannnythinnggg
1-30 07:11.53pm <theme> I treat input lifetimes and output lifetimes as if they are in different scopes, and thus, different identities
1-30 07:11.54pm <lahwran> how in the world can it live past the end of the function if its lifetime is the same as the function?
1-30 07:12.21pm <theme> lahwran, it restrains the lifetimes of x in `let x = foo(y)`
1-30 07:12.22pm <lahwran> I'm getting the feeling that nobody has any idea how to explain lifetimes
1-30 07:12.27pm <Havvy> struct Foo { bar: Bar };  fn getBar(foo: 'a Foo) -> &'a Bar { foo.bar; }
1-30 07:12.31pm <lahwran> and so is just trying to make the reader infer them
1-30 07:12.48pm <lahwran> wait new inference data
1-30 07:13.02pm <Havvy> Err, &foo.bar
1-30 07:13.08pm <theme> lahwran, I interpret that as "the return value of foo would live no longer than 'a"
1-30 07:13.11pm <lahwran> it's *parameterized with an existing lifetime, associated with the incoming value, and returns something that has whatever the passed-in lifetime was*?
1-30 07:13.26pm <theme> where 'a is "the lifetime of the value referred to by the parameter of foo"
1-30 07:13.29pm <lahwran> theme: I haven't understood anything you've said so far :(
1-30 07:13.37pm <lahwran> I mean, I understand the individual words, as long as they aren't put together
1-30 07:13.45pm <theme> lahwran, maybe because I interpret "lifetime" as "dependencies"
1-30 07:14.10pm <Sharp> lahwran: Lifetimes are constraints, currently based on scope.
1-30 07:14.11pm <theme> "the return value of Foo depends on the parameter marked as 'a"
1-30 07:14.16pm <Sharp> lahwran: They have a subtyping relationship.
1-30 07:14.17pm <lahwran> "the dependencies of the value referred to by the parameter of foo"
1-30 07:14.20pm <theme> that's how I interpret that
1-30 07:14.24pm <lahwran> use smaller words please
1-30 07:14.27pm <lahwran> and lifetime is taboo
1-30 07:14.29pm <Sharp> lahwran: 'a outlives 'b means 'a is a subtype of 'b.
1-30 07:14.41pm <lahwran> explain lifetimes without using the word lifetime
1-30 07:14.45pm <lahwran> aaaaand that makes even less sense
1-30 07:14.47pm <Sharp> lahwran: aka you can use 'a anywhere you can use 'b.
1-30 07:14.54pm <Sharp> lahwran: Why doesn't it make sense?
1-30 07:14.56pm <theme> lahwran, "dependant on ( the value referred to by (the parameter of foo))"
1-30 07:14.56pm <lahwran> yes, but what does it mean to use 'a?
1-30 07:15.13pm <Sharp> lahwran: If a reference is tagged with 'a (&'a, for example) or 'a is a lifetime parameter
1-30 07:15.21pm <Havvy> A lifetime is a kind of type that describes how long a value is referencable.
1-30 07:15.22pm <Sharp> lahwran: i.e., if you have a type parameterized by 'a
1-30 07:15.28pm <theme> lahwran, "'b: 'a" means that 'b borrows from 'a
1-30 07:15.33pm <Sharp> theme: No it doesn't.
1-30 07:15.41pm <theme> in other words, 'b depends on 'a
1-30 07:15.45pm <Sharp> Still not true?
1-30 07:15.51pm <lahwran> theme: okay, that makes sense! except if it's not true, making sense is not useful!
1-30 07:15.56pm <theme> or 'b borrows from the things labelled by 'a
1-30 07:16.06pm <lahwran> bwaaaaaaaaahhhh
1-30 07:16.13pm <Sharp> theme: 'b: 'a just means 'b is a subtype of 'a
1-30 07:16.17pm <lahwran> subtype?
1-30 07:16.30pm <theme> lahwran, Sharp is speaking about inheritance, I guess
1-30 07:16.35pm <Sharp> lahwran: http://en.wikipedia.org/wiki/Subtyping
1-30 07:16.40pm <lahwran> I know what a subtype is, I think. inheritance without any actual behavioral changes being necessarily required
1-30 07:16.53pm <lahwran> (though in some contexts, a subtype can change behavior of the type)
1-30 07:16.56pm <theme> whoops... "Subtyping should not be confused with the notion of (class or object) inheritance from object-oriented languages"
1-30 07:17.00pm <lahwran> but ... what in the world does that have to do with this
1-30 07:17.03pm <Sharp> lahwran: Right.  Basically, 'b: 'a means that you can substitute 'b anywhere you use 'a
1-30 07:17.08pm <Sharp> lahwran: Think about scopes
1-30 07:17.16pm <lahwran> I'm thinking about scopes
1-30 07:17.19pm <lahwran> nothing's happening
1-30 07:17.19pm <Sharp> lahwran: Let's say 'a is a label for a scope, and we have another scope, 'b, inside that scope
1-30 07:17.21pm <theme> Sharp, I think about dependencies, not scopes
1-30 07:17.28pm <Sharp> theme: I don't know what you mean by dependencies.
1-30 07:17.34pm <theme> Sharp, borrowing?
1-30 07:17.35pm <lahwran> Sharp: but what does it mean for 'a to be a label for a scope
1-30 07:17.42pm <Sharp> lahwran: You can literally label a scope, like, give it a name
1-30 07:17.45pm <Sharp> lahwran: That's what a lifetime currently is.
1-30 07:17.49pm <lahwran> like, you're assuming some basic level of knowledge about what 'a means that I don't have
1-30 07:17.54pm <lahwran> because the page I just read didn't explain it
1-30 07:17.57pm <Sharp> lahwran: No no, that's literally what it is, let me show you
1-30 07:18.14pm <lahwran> what's literally what it is
1-30 07:18.15pm <lahwran> who's on first
1-30 07:18.20pm <theme> Sharp, can't I treat 'b:'a as "the thing labeled with 'b might borrow from the thing labeled with 'a"?
1-30 07:18.31pm <Sharp> playbot: 'a: loop { 'b: loop { println!("Go to 'a"); break 'a; } println!("This won't be reached."); }
1-30 07:18.32pm [playbot] Go to 'a
1-30 07:18.32pm [playbot] ()
1-30 07:18.37pm <Sharp> lahwran: See?
1-30 07:18.40pm <theme> lahwran, things are defined by what it does
1-30 07:18.43pm -*- Havvy thinks that 'b : 'a   is too advanced compared to where lahwran's comfused by.
1-30 07:18.58pm <lahwran> Sharp: no!
1-30 07:19.06pm <lahwran> Havvy++
1-30 07:19.09pm <Sharp> lahwran: Each loop is a scope (a block starts a new scope)
1-30 07:19.19pm <theme> Havvy, I think that the most general thing possible is the key to understanding the simpler cases
1-30 07:19.20pm <Sharp> lahwran: Like Java's labeled break syntax, you can use a lifetime there
1-30 07:19.22pm <lahwran> also there are two people at this computer (though only one typing) and we're both equally confused
1-30 07:19.25pm <theme> at least that's how my brain works
1-30 07:19.31pm <Sharp> lahwran: Are you familiar with labeled break in languages like Java?
1-30 07:19.42pm <lahwran> Sharp: okay, so that makes sense. you just stick a label in your code, and it marks a place that can be jumped to
1-30 07:19.43pm <Havvy> Labeled break is also probably not gonna help explain.
1-30 07:19.50pm <lahwran> but it can be put in any old place
1-30 07:20.01pm <lahwran> it's really just a goto marker, that goes in your output code and can be jumped to
1-30 07:20.01pm <theme> Sharp, if 'a is the scope of certain braces, I treat "'b:'a" as "the thing labeled with 'b" depends on the braces
1-30 07:20.02pm <Sharp> lahwran: Well, it can only be put at the beginning of blocks in Rust
1-30 07:20.21pm <lahwran> okay, that seems orthogonal to lifetimes, unless I've inferred absolutely nothing
1-30 07:20.25pm <Sharp> lahwran: So the entire block basically counts as its own thing, the label refers to everything within the block.
1-30 07:20.28pm <Sharp> lahwran: It's related.
1-30 07:20.32pm <theme> in other words, "the thing labeled with 'b must be destructed before the braces end"
1-30 07:20.41pm <theme> Sharp, does my interpretation make sense?
1-30 07:20.42pm <lahwran> well so okay
1-30 07:20.43pm <Havvy> It's related, but ancillory to their main definition.
1-30 07:20.45pm <Sharp> lahwran: Anything inside the block is considered to be in "the lifetime" 'a.
1-30 07:20.51pm <lahwran> but what does it mean for a variable or function to "have" a lifetime?
1-30 07:21.03pm <lahwran> is the lifetime a variable? is 'a a lifetime variable, which contains a lifetime?
1-30 07:21.10pm <theme> if x depends on y, x must be destroyed before y
1-30 07:21.21pm <lahwran> or is it a lifetime label, where anything using the name 'a is ... I don't even know
1-30 07:21.23pm <Havvy> Guys: Try explaining lifetimes with a single value...
1-30 07:21.26pm <theme> can't I treat it like that?
1-30 07:21.33pm <Sharp> lahwran: Lifetimes when they show up in like, function definitions, are generic type parameters
1-30 07:21.38pm <theme> Sharp, hello?
1-30 07:21.45pm <lahwran> Sharp: that's certainly what they look like
1-30 07:21.51pm <Sharp> lahwran: Yeah, that's all they are
1-30 07:21.58pm <lahwran> but they don't behave anything like that
1-30 07:22.00pm <Sharp> lahwran: They don't have any specific value by themselves
1-30 07:22.09pm <theme> lahwran, lifetimes in variables mean that "let 'a be the lifetime of x" or something like that
1-30 07:22.20pm <lahwran> okay so if I do fn print<'a>(...) ..., then I'm *NOT DECLARING 'A*
1-30 07:22.25pm <lahwran> I'm *TAKING IT AS A PARAMETER*
1-30 07:22.25pm <Sharp> lahwran: Right, it's just a parameter.
1-30 07:22.27pm <Sharp> Yep.
1-30 07:22.29pm <lahwran> okay.
1-30 07:22.29pm <Havvy> Right.
1-30 07:22.32pm <theme> lahwran, no... it's declaring 'a
1-30 07:22.38pm <lahwran> that would have been super good to explain to begin with noooooooooooooooooooo
1-30 07:22.42pm <Sharp> theme: No?
1-30 07:22.48pm <theme> and then I associate 'a with a certain parameter
1-30 07:22.51pm <Sharp> lahwran: You are correct.
1-30 07:22.54pm <Havvy> lahwran:  Yeah...the explanations I'm seeing in here aren't looking very good. :(
1-30 07:22.55pm <lahwran> okay
1-30 07:22.56pm <theme> or output
1-30 07:23.06pm <lahwran> Havvy: no worse than the book's page, at least.
1-30 07:23.23pm <theme> seriously, does my explanation sound like garbage?
1-30 07:23.29pm <Havvy> theme:  Yes.
1-30 07:23.31pm <Sharp> theme: I'm not sure you have a correct understanding of lifetimes.
1-30 07:23.48pm <theme> I just get confused dealing with scopes, so I think it as DAG instead of intervals
1-30 07:24.28pm <theme> btw is it always possible to turn Foo<'a> into Foo<'b> if there is 'b:'a right?
1-30 07:24.34pm <Sharp> lahwran: Anyway.  So it's a type parameter, subject to the usual type parameter rules (like if you take a single lifetime parameter 'a, and then use it twice in the function signature (like, fn foo<'a>(&'a Foo, &'a Foo)) it's the same in both arguments.
1-30 07:24.50pm <theme> Havvy, Sharp, what is wrong with my understanding?
1-30 07:24.53pm <lahwran> so lifetimes are types?
1-30 07:24.56pm <Sharp> lahwran: Yeah.
1-30 07:24.56pm <lahwran> what are the values?
1-30 07:25.03pm <lahwran> where do the values come from?
1-30 07:25.07pm <lahwran> what do the values mean?
1-30 07:25.07pm <Havvy> Lifetimes are types, but they are not shape types.
1-30 07:25.09pm <theme> can you create any tricky cases that my explanation doesn't work?
1-30 07:25.15pm <lahwran> (where are they going?)
1-30 07:25.22pm <lahwran> Havvy: ...shape types?
1-30 07:25.40pm <Sharp> lahwran: The easiest way to understand concrete lifetimes is as referring to scopes (like in the labeled break example).
1-30 07:25.42pm <Havvy> Shape types, like what you define with `struct` and `enum`.
1-30 07:25.50pm <Havvy> Or `class` is Java.
1-30 07:25.51pm <lahwran> so the value of a lifetime is a scope
1-30 07:25.55pm <Sharp> Pretty much.
1-30 07:25.57pm <Havvy> Yes.
1-30 07:26.14pm <theme> Sharp, Havvy, is it always possible to turn `Foo<'a>` into `Foo<'b>` if there is `'b:'a`
1-30 07:26.16pm <Havvy> A lifetime represents the scope that you can refer to variables that have that lifetime.
1-30 07:26.21pm <lahwran> so the value of a lifetime is a length, with the start being tied to the start of one scope, and the end being tied to the end of some other scope. right?
1-30 07:26.29pm <Havvy> theme:  Yes.
1-30 07:26.33pm <Sharp> theme: Other way around.
1-30 07:26.34pm <lahwran> someone needs to save this conversation for use in the book
1-30 07:26.42pm <theme> Sharp, Havvy, what?
1-30 07:26.47pm <lahwran> Sharp: PSH
1-30 07:26.51pm <lahwran> (tcp packet)
1-30 07:26.54pm <Havvy> theme:  Well, I'm not sure which way the subclassing direction goes.
1-30 07:26.58pm <Sharp> Havvy: 'b is a subtype of 'a there.
1-30 07:27.02pm <Havvy> But the basic idea is right.
1-30 07:27.10pm -*- lahwran throws a pebble at Sharp
1-30 07:27.27pm <theme> does 'b:'a mean that 'a outlives 'b?
1-30 07:27.29pm <Sharp> lahwran: It's kinda... all just one scope?
1-30 07:27.52pm <Sharp> theme: No, it means 'b outlives 'a.
1-30 07:27.55pm <tjakubow> theme: other way around
1-30 07:28.01pm <Havvy> Kk.
1-30 07:28.06pm -*- theme realizes that he's getting something seriously wrong
1-30 07:29.09pm <Sharp> lahwran: Okay so... in Rust, the rule is that when you give a reference a lifetime (aka a scope), it doesn't get to outlive that scope.
1-30 07:29.14pm -*- theme rethinks everything with the relationship backwords
1-30 07:29.25pm <Sharp> lahwran: i.e., it can't escape the scope.
1-30 07:29.44pm <lahwran> okay I think I'm following it now
1-30 07:30.00pm <lahwran> Sharp: can you confirm or reject my proposed interpretation, please?
1-30 07:30.05pm <lahwran> 1-30 07:26.21pm <lahwran> so the value of a lifetime is a length, with the start being tied to the start of one scope, and the end being tied to the end of some other scope. right?
1-30 07:30.05pm <Sharp> lahwran: Sure.
1-30 07:30.30pm <Sharp> lahwran: Yes, with the caveat that today the start and end are both for the same scope.
1-30 07:30.37pm <lahwran> wait, they have to be?
1-30 07:30.41pm <lahwran> it can't cross scopes?
1-30 07:30.41pm <Sharp> lahwran: Right now, yes
1-30 07:30.44pm <lahwran> oh.;
1-30 07:30.49pm <lahwran> well, that's interesting.
1-30 07:30.59pm <Sharp> lahwran: That's why the borrow checker makes you do dumb things sometimes, like randomly introduce scopes {}
1-30 07:31.16pm <Sharp> lahwran: Because it can't handle anything but a simple enclosing scope.
1-30 07:31.24pm <lahwran> Sharp: how is the scope decided?
1-30 07:31.35pm <lahwran> presumably the scope that declares the thing?
1-30 07:31.40pm <Sharp> lahwran: Yeah.
1-30 07:31.57pm <theme> Sharp, Havvy, can the borrow checker be implemented as a topological sort?
1-30 07:31.59pm <lahwran> so how does this interact with moves? is a move the deletion of one lifetime and creation of another?
1-30 07:32.30pm <Sharp> lahwran: So, you can't actually move something with references in it to a scope that didn't already contain the lifetimes of those references.
1-30 07:32.34pm <Havvy> theme:  I don't know.
1-30 07:32.39pm <Sharp> lahwran: So it doesn't change their lifetimes.
1-30 07:32.57pm <lahwran> Sharp: if you move the thing that the lifetime belongs to, then that sets the end of the lifetime to that line, right?
1-30 07:33.21pm <Havvy> lahwran:  The scope is decided by the same rules that values are given scopes in C.
1-30 07:33.22pm <Sharp> lahwran: Well, it definitely has to last at least that long
1-30 07:33.28pm <Sharp> lahwran: If it doesn't Rust will bitch at you
1-30 07:33.42pm <Havvy> Sharp:  Use a different word. ;)
1-30 07:33.47pm <lahwran> Sharp: what do you mean "if" it doesn't?
1-30 07:33.48pm <Sharp> lahwran: If it doesn't Rust will complain at you
1-30 07:33.58pm <lahwran> how can it not?
1-30 07:34.10pm <Sharp> lahwran: Well, like this
1-30 07:34.32pm <lahwran> because if I move something halfway down a scope, its lifetime is now owned by something entirely different, and from the point of view of any references in the originally owning scope, the lifetime is over, right?
1-30 07:34.36pm <theme> Havvy, Sharp, so... can I interpret 'b:'a as "the stuff labeled with 'a depends on the stuff labeled with 'a"?
1-30 07:34.50pm <Sharp> playbot: fn foo<'a>() -> &'a u8 { let x = 0; let y = &x; y }
1-30 07:34.50pm [playbot] <anon>:14:54: 14:55 error: `x` does not live long enough
1-30 07:34.51pm [playbot] <anon>:14         fn foo<'a>() -> &'a u8 { let x = 0; let y = &x; y }
1-30 07:34.51pm [playbot] output truncated; full output at: http://bit.ly/1BC8LQu
1-30 07:35.16pm <Sharp> lahwran: See, x's initial scope was entirely inside foo
1-30 07:35.21pm <Havvy> theme:  I haven't thought about lifetimes enough to be able to answer that definitively.
1-30 07:35.23pm <Sharp> lahwran: So nothing with a reference to x could move out of foo
1-30 07:35.37pm <Sharp> lahwran: You can *try* but Rust won't let you.
1-30 07:35.47pm <theme> Havvy, ok... so does it mean that 'a must end before 'b?
1-30 07:35.52pm <lahwran> Sharp: wat?
1-30 07:36.04pm <Sharp> lahwran: Look at the above example.  Do you see why Rust won't let you return y there?
1-30 07:36.22pm <Sharp> lahwran: Like, according to the lifetime rules, not the vague "it's on the stack!" sense.
1-30 07:36.26pm <lahwran> no, mostly because I can't read the punctuation soup
1-30 07:36.36pm <theme> Actually, it's "the stuff labeled with 'a depends on the stuff labeled with 'b"
1-30 07:36.39pm <Sharp> lahwran: <'a> is defining the lifetime parameter, like we discussed.
1-30 07:36.57pm <theme> Sharp, I'd say that it declares it
1-30 07:37.06pm <Sharp> lahwran: &'a u8 is a labeled reference.  It means "the thing this reference is pointing to must live at least as long as the scope defined by 'a."
1-30 07:37.14pm <lahwran> Sharp: okay say I do this. fn main() { let derp = Box::new(5); blah(derp); ... more stuff here ...}; fn blah(herp: Box<i32>) { ... stuff here }
1-30 07:37.28pm <theme> Sharp, except if it's an output value
1-30 07:37.32pm <Sharp> lahwran: Well, there are no lifetimes involved there.
1-30 07:37.38pm <lahwran> Sharp: wait, what?
1-30 07:37.42pm <lahwran> there aren't?
1-30 07:37.43pm <Sharp> lahwran: In your example?
1-30 07:37.51pm <lahwran> there's no borrowing, but there are lifetimes, right?
1-30 07:37.56pm <Sharp> lahwran: Oh... I see what you're saying
1-30 07:37.58pm <lahwran> the lifetimes just don't get used to track borrowing
1-30 07:38.01pm <Sharp> lahwran: Yeah, there are lifetimes, but there aren't lifetime parameters.
1-30 07:38.08pm <lahwran> anyway the first lifetime ends at the call to blah(), right?
1-30 07:38.11pm <Sharp> lahwran: Lifetime parameters are what actually constrain things.
1-30 07:38.15pm <Sharp> lahwran: Oh... no.
1-30 07:38.17pm <lahwran> and a new, separate lifetime is created in blah
1-30 07:38.24pm <Sharp> lahwran: The first lifetime lasts for all of main()
1-30 07:38.32pm <Havvy> Types are constraints on code, by definition @ Sharp.
1-30 07:38.32pm <Sharp> lahwran: The second lifetime lasts for blah(), *inside* the first lifetime
1-30 07:38.38pm <Sharp> Havvy: Sure :)
1-30 07:38.45pm -*- theme thinks that his way of interpreting lifetimes is just a strange way that only he can understand
1-30 07:39.14pm <lahwran> Sharp: so blah can't, like, put herp off to the side somewhere, and make it live longer than main()?
1-30 07:39.33pm <Sharp> lahwran: Well, it could put it on the heap
1-30 07:39.38pm <lahwran> (...assuming that something lives longer than main in the first place *cough cough badly thought through example cough*)
1-30 07:39.42pm <Sharp> lahwran: As long as there's no lifetime parameter, Rust treats it like it has the lifetime 'static
1-30 07:39.53pm <Sharp> lahwran: Which is basically "longer than every lifetime"
1-30 07:40.02pm <theme> lahwran, Sharp, I think that it doesn't involve lifetime here
1-30 07:40.11pm <lahwran> sharp said that, and I still don't see why not
1-30 07:40.27pm <Sharp> lahwran: Like I said: yes, there are lifetimes, but Rust doesn't care about them :)
1-30 07:40.30pm <theme> what happens for a function like `fn foo(x: Box<i32>, y: Box<i32>) -> Box<i32>`?
1-30 07:40.56pm <theme> does the returned box come from x or y or somewhere else?
1-30 07:41.05pm <theme> it just cannot be determined in compile time
1-30 07:41.52pm <theme> So... no lifetimes directly involved here
1-30 07:42.05pm <Sharp> lahwran: I definitely see your question ("is the lifetime moving when I move the Box") and I guess the answer is yes, in some sense
1-30 07:42.16pm <theme> lahwran, blah can put it to the side if you have a static mut Box
1-30 07:42.34pm <Sharp> theme: static mut is always unsafe and not subject to Rust's usual lifetime rules.
1-30 07:42.38pm <Sharp> (And may be going away soon).
1-30 07:43.30pm <lahwran> Sharp: anyway, I think we both get it now
1-30 07:43.33pm <Sharp> lahwran: Awesome!
1-30 07:43.52pm <Sharp> lahwran: Sorry for the long winded explanation... I am pretty sure there are much better explanations out there.
1-30 07:43.54pm <lahwran> (for future reference, the other person at the computer uses the nickname hamnox)
1-30 07:44.03pm <Sharp> Cool.