1 16:50:54 * Jason_at_Intel (~chatzilla@12.18.240.224) has joined #SCONS
2 16:52:29 * GregNoel is no longer marked as being away
3 16:53:51 <Jason_at_Intel> hello
4 16:53:59 * Garyo (~chatzilla@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) has joined #SCONS
5 16:54:12 <Jason_at_Intel> Hi Gary
6 16:54:21 <Garyo> Hi Jason.
7 17:02:17 <Garyo> Hi Greg -- feel free. I'm starting to get some SCons time in the next few months (I hope!)
8 17:05:34 * bdbaddog (~bdeegan@adsl-71-131-3-198.dsl.sntc01.pacbell.net) has joined #SCONS
9 17:06:03 <Garyo> Hi Bill!
10 17:06:19 <bdbaddog> hey
11 17:06:39 <Garyo> Thanks (again) for pushing out the checkpoint; this one is looking good.
12 17:06:45 <GregNoel> We're short Steven, but he commented in the spreadsheet; should we begin?
13 17:06:52 <bdbaddog> sure.
14 17:06:57 <Garyo> I think so too.
15 17:07:14 <GregNoel> 2517
16 17:07:36 <GregNoel> Steven says give it to him, but I don't like it as research.
17 17:08:02 <Garyo> I think it's his choice, is that OK?
18 17:08:36 <GregNoel> Yeah, but I don't think he should work on it until post-2.0.
19 17:09:06 <Garyo> Ah, I see. Spend his cycles getting the python 2.4 stuff in now instead?
20 17:09:16 <GregNoel> Yes.
21 17:09:43 <Garyo> That makes a lot of sense. I'm worried the 1.3 -> 2.0 transition will take a long time.
22 17:10:23 <GregNoel> It better not; I'll be flat on my back if it does...
23 17:09:42 <GregNoel> What's the priority on 2550? I didn't look.
24 17:10:02 <Garyo> 2550=p3
25 17:10:29 <GregNoel> What's the milestone?
26 17:10:45 <Garyo> research
27 17:11:03 <GregNoel> Ouch. OK, make them the same: research p3.
28 17:11:27 <Garyo> OK, or move both to 2.1 p3 if you like.
29 17:11:45 <GregNoel> I'll put in a note that this "research" is less priority than 2.0.
30 17:11:53 <Garyo> +1
31 17:11:58 <GregNoel> done
32 17:12:02 <GregNoel> 1549
33 17:12:09 <GregNoel> oops, 2549
34 17:12:48 <Garyo> Here's where I say I am really happy Russel is taking the lead in putting tools in a DVCS.
35 17:13:24 <GregNoel> I agree. I'm not sure I agree with his choice of DVCS, but any choice is better than none.
36 17:13:34 <bdbaddog> he's certainly bringing the email volume up..
37 17:14:09 <Garyo> So... can we make a new category of issues for external tools, and this can be one?
38 17:14:27 <Garyo> (I know it's half here & half there, so it's confusing.)
39 17:14:28 <GregNoel> Hmmm... Possible. Needs discussion.
40 17:14:47 <GregNoel> Not something to settle today, surely.
41 17:14:59 <Jason_at_Intel> +1
42 17:15:01 <Garyo> Agreed. Just let Russel work on it for now.
43 17:15:31 <GregNoel> so 2549, 3.x, what priority?
44 17:15:42 <Garyo> So 3.x p4?
45 17:15:53 <GregNoel> Hmmm...
46 17:16:15 <GregNoel> I think I'd like it to resurface sooner than that.
47 17:16:44 <Garyo> I'm hoping we'll decide some day to take the D tool out of SCons entirely instead.
48 17:16:53 <GregNoel> Yeah, along with Java.
49 17:17:02 <Garyo> ... and latex, and ...
50 17:17:03 <Jason_at_Intel> why?
51 17:17:16 <GregNoel> Make them all user-supported.
52 17:17:16 <Garyo> Because they can be developed and released asynchronously.
53 17:17:17 <Jason_at_Intel> oh make them add on
54 17:17:47 <Jason_at_Intel> in that case most of the tools can go that route
55 17:18:19 <Garyo> Jason: agreed. But we have to balance that with the python "batteries included" philosophy.
56 17:17:55 <Garyo> (We could do a linux distro thing and include the latest blessed version... or not even that. All up for discussion.)
57 17:18:08 <GregNoel> Yeah, 2549 3.x p4; reassign it when we have a separate user-supported flow.
58 17:18:27 <Garyo> Greg: +1
59 17:18:32 <GregNoel> done
60 17:18:39 <GregNoel> 2566
61 17:18:42 <Garyo> 2566 is already closed.
62 17:18:52 <Garyo> can't repro.
63 17:19:03 <GregNoel> WORKSFORME?
64 17:19:34 <Garyo> I said INVALID because he couldn't repro it either :-)
65 17:19:58 <GregNoel> worksforme, then. {;-}
66 17:19:27 <GregNoel> In any event, 2571
67 17:20:13 <Jason_at_Intel> 2571? is this calling Scons under the covers still?
68 17:20:29 <Garyo> Jason: sure.
69 17:20:15 <Garyo> 2571: tell OP good job, give some direction on compat, then integrate for 2.1?
70 17:20:28 <GregNoel> I'll go along.
71 17:20:38 <GregNoel> Who? Gary?
72 17:20:47 <Garyo> I'll take it.
73 17:21:17 <GregNoel> Obviously needs some test cases, but I like the scheduling.
74 17:21:04 <Garyo> (Not that I care about MSVS, but I do care about new contributors.)
75 17:21:27 <Jason_at_Intel> it start small then grows
76 17:21:41 <GregNoel> 2.1 p3 Garyo, done
77 17:22:09 <GregNoel> 2572, defer?
78 17:22:29 <Garyo> sure
79 17:22:33 <Jason_at_Intel> +1
80 17:22:37 <bdbaddog> +1
81 17:22:47 <GregNoel> done
82 17:22:56 <GregNoel> 2573
83 17:22:59 <Garyo> 2573: what is ".sx"?
84 17:23:10 <Jason_at_Intel> :-) was just going to ask that
85 17:23:15 <bdbaddog> some .net file?
86 17:23:22 <GregNoel> Man page says "preprocessed assembler"
87 17:23:33 <GregNoel> (It's in the spreadsheet comments.)
88 17:23:36 <Garyo> for what OS?
89 17:23:44 <GregNoel> Any?
90 17:23:56 <Garyo> what man page did you find it in?
91 17:24:24 <GregNoel> SCons man page.
92 17:24:48 <GregNoel> We currently preprocess those files, but apparently don't scan them for dependencies.
93 17:24:56 <Garyo> Oh?! Wow, that's a surprise!
94 17:25:05 <GregNoel> It was to me, too.
95 17:25:09 <Garyo> OK, I guess you guys are right, add it to the list.
96 17:25:37 <Garyo> I'll do that too. The work part is trivial.
97 17:25:49 <Garyo> 2.1 p4 garyo +easy
98 17:25:51 <GregNoel> OK, done, but watch for side-effects: it may try to compile the file.
99 17:26:07 <Garyo> ok, put a note in if you don't mind...
100 17:26:17 <GregNoel> Wilco
101 17:26:33 <GregNoel> 2574
102 17:27:02 <GregNoel> Another trivial change, but would work better post-2.0.
103 17:27:16 <Garyo> Agreed. Post 2.0.
104 17:27:33 <Garyo> 2.1 p2, who?
105 17:28:08 <GregNoel> Not seeing any volunteers...
106 17:28:19 <GregNoel> I can't take it; I'll be recovering.
107 17:28:36 <Garyo> Understood. Assign it to me then, I'll delegate if needed.
108 17:28:41 <GregNoel> done
109 17:28:48 <GregNoel> 2575
110 17:28:59 <Jason_at_Intel> 2575 ... it would be better if we had a src_dir which could be used as a root, to allow -j based builds to work
111 17:29:22 <Garyo> That's an excellent idea.
112 17:29:39 <Garyo> Jason, can you propose that to the OP and ask for a new patch?
113 17:29:50 <Jason_at_Intel> (zipfile in Parts :-) .. not as good as raw zip however in some cases)
114 17:30:09 <Jason_at_Intel> sure.. main problem is the call more than once issue
115 17:30:29 <Jason_at_Intel> the builders think the output is more than one environment
116 17:30:16 <GregNoel> Um, it would have to work for all builders, not just this one.
117 17:30:32 <Garyo> Would it, Greg? Couldn't it just be an env override?
118 17:31:07 <GregNoel> No, I don't think so. Think of LaTeX, for example, which wants to run in the build directory.
119 17:31:10 <Garyo> And Jason, if it's an env var, shouldn't it be constant for all calls anyway? (I think I see your point though, still causes a warning)
120 17:31:24 <Jason_at_Intel> that is why i made a zipfile() and not override zip() as this changes behavior of calling more than once
121 17:31:46 <Garyo> Greg: I don't think tar/zip need to *run* in any particular dir, they just need a reference point.
122 17:32:39 <Garyo> OK, maybe this is more complicated than it seems at first.
123 17:32:40 <Jason_at_Intel> however for 2575 his patch will work.. it will just break -j builds
124 17:33:00 <Garyo> Jason: that worries me.
125 17:33:07 <GregNoel> Actually, tar/zip can have multiple changes of directory in them; that's why I like the solution in 1890.
126 17:33:31 * Garyo looks at 1890
127 17:34:15 <Jason_at_Intel> ie use the tarfile module?
128 17:34:23 <Garyo> I see, use tarfile instead of calling tar. I totally agree.
129 17:34:34 <GregNoel> Garyo, basically, each entry is a duple of (name-in-archive, File-node).
130 17:34:48 <Jason_at_Intel> I have an impl in Parts for this
131 17:34:59 <Jason_at_Intel> but again i don't have it support more than one call
132 17:35:15 <Garyo> It's a call-once-with-all-sources builder?
133 17:35:28 <Jason_at_Intel> yep
134 17:35:44 <Jason_at_Intel> again the src_dir overide upsets teh builders
135 17:35:54 <Jason_at_Intel> spits out warnings or errors
136 17:35:58 <Garyo> Not ideal, of course, but probably best we can do given builder limitations
137 17:36:08 <GregNoel> I have a functional prototype for 1890, but I've been waiting for post-2.0 to implement it.
138 17:36:29 <Garyo> And calling with a single src dir is probably 90% of all use cases anyway.
139 17:37:11 <Jason_at_Intel> can you look at http://parts.tigris.org/source/browse/*checkout*/parts/trunk/parts/parts/pieces/tar.py?revision=143&content-type=text%2Fplain
140 17:37:13 <GregNoel> Then why not base it off of chdir=? It's the effect that counts, not the actual functioning.
141 17:37:51 <Garyo> because of breaking -j, right?
142 17:38:10 <Jason_at_Intel> I think the chdir in SCons means current dir change
143 17:38:26 <Jason_at_Intel> Scons needs a new idea to support the "root" area to use
144 17:38:38 <Garyo> OK, so for 2575: 2.1, p2, Jason and Greg to investigate Jason and Greg's work, and come up with a nice solution.
145 17:38:40 <Jason_at_Intel> src_dir is what i would propose
146 17:39:04 <GregNoel> I don't agree.
147 17:39:26 <Garyo> don't agree w/ src_dir, or don't agree w/ my assignment?
148 17:39:27 <Jason_at_Intel> to me .. not gary .. correct?
149 17:39:58 <GregNoel> don't agree with src_dir; again, the effect is the requirement, not the actuality.
150 17:40:15 <Jason_at_Intel> ??
151 17:40:38 <Garyo> I think you're saying it should get chdir before SCons actually changes the dir, and just use that dir itself.
152 17:40:52 <GregNoel> Yes
153 17:41:01 <Garyo> Might require a little core patching but not impossible of course.
154 17:41:15 <Jason_at_Intel> that is fine.. then does this mean we will fix command to do the same
155 17:41:21 <Garyo> (like a "builder_wants_chdir" flag or something)
156 17:41:35 <Jason_at_Intel> will it out add a cd <dir> && to the command?
157 17:42:15 <Garyo> Jason: at least the infrastructure would be there to handle it that way if we wanted to.
158 17:42:22 <GregNoel> I'm not going to design on the fly; my suggestion was to reject this issue as invalid, since it's the same problem with all builders where you use chdir=.
159 17:43:07 <GregNoel> If we change that paradigm, we need to make it consistent.
160 17:42:57 <Jason_at_Intel> so back to the issue
161 17:43:02 <Jason_at_Intel> this is a patch
162 17:43:11 <Jason_at_Intel> that is invalid?
163 17:43:13 <Garyo> Let's not say it's invalid then, but we think there's a better method.
164 17:43:24 <GregNoel> Garyo, yes.
165 17:43:51 <Jason_at_Intel> i see... not sure what the better method you have in mind is
166 17:44:08 <Garyo> Leave the issue open for this particular builder, but note that it requires a little infrastructure work to expose chdir to the builder, then we can do it better.
167 17:44:29 <Jason_at_Intel> agree
168 17:44:48 <Garyo> Jason: a builder flag that would tell scons not to chdir, but pass the chdir arg as a kwd arg to the builder. Or something like that.
169 17:45:11 <GregNoel> And you could have chdir= on each builder call.
170 17:45:13 <Jason_at_Intel> I guess... but you woudl always want it on.. never off
171 17:45:20 <Garyo> (Greg, is that basically your idea?)
172 17:45:42 <GregNoel> Still designing on the fly, but yes, I think so.
173 17:45:44 <Garyo> Jason: we can't turn it on for all builders because most of them don't understand it.
174 17:45:59 <loonycyborg> chdir is clearly hack in this case.
175 17:46:26 <GregNoel> Hi, Sergey; glad you could join us. Do you think users would understand a distinction there?
176 17:46:29 <loonycyborg> There should be more flexible ways to specify paths that'll be stored in the archive,
177 17:46:32 <Garyo> loonycyborg: yes, we'd be "repurposing it" a bit.
178 17:46:51 <Jason_at_Intel> Sure.. I will wait to see what greg proposes.. however from a generic pragma.. chdir is designed in SCons to mean something, changing its logic seem bad, better to add a new "verb" to say what we want clearly
179 17:47:34 <Garyo> OK, so given that let's not design it here but just say in the ticket that it needs thought and some internal changes before we can do it right.
180 17:47:45 <Jason_at_Intel> agree
181 17:48:02 <GregNoel> OK, then what should we do with the ticket?
182 17:48:37 <GregNoel> I'll suggest deferring to the mailing list.
183 17:48:43 <Garyo> How about this: mark it 2.1 p2, but with a note to say revisit at that time and discuss.
184 17:48:58 <Jason_at_Intel> +1
185 17:49:00 <GregNoel> Yes
186 17:49:08 <bdbaddog> +1
187 17:49:08 <Garyo> (rather than have a complete implementation by that time)
188 17:49:16 <GregNoel> done
189 17:49:18 <Garyo> good, consensus!
190 17:53:13 <loonycyborg> Zip builder should store paths relative to shortest common path of sources by default IMO..
191 17:53:35 <GregNoel> And that's what I'd like to do with 1890.
192 17:54:24 <GregNoel> Always put in a duple with relative path and File node.
193 17:53:49 <Garyo> loonycyborg: put a note in those 2 tickets if you want.
194 17:54:54 <Garyo> I like explicit rather than implicit in general though, even if it's a little more typing.
195 17:55:19 <GregNoel> Garyo, yes.
196 17:55:02 <Jason_at_Intel> lonnycyborg.. I agree.. that is what I have in Parts as well
197 17:55:04 <GregNoel> Remember, relative path is expensive to calculate; should try to avoid it when possible.
198 17:55:06 <Garyo> ...but we're trying to design it here.
199 17:55:15 <Garyo> let's not.
200 17:49:37 <GregNoel> 2576
201 17:50:00 <Garyo> 2576 looks like good potential for Russel to feed Steven things.
202 17:50:28 <GregNoel> Yes.
203 17:51:13 <GregNoel> I wonder if "anytime" would work for this, as they work out the interaction details.
204 17:51:19 <Garyo> 2.x p3, Steven to own, and work w/ Russel?
205 17:51:57 <Garyo> (Or vice versa, Russel to own, delegate work to Steven?)
206 17:52:08 <GregNoel> I could buy 2.x p3, but I'd like to see a procedure worked out first.
207 17:52:37 <GregNoel> Russel to own during design, Steven to own during implementation?
208 17:52:57 <Garyo> OK then, let's ask Steven to work something like that out & revisit next meeting. OK?
209 17:53:12 <GregNoel> yes, I like that.
210 17:53:18 <bdbaddog> +1
211 17:53:25 <Jason_at_Intel> +1
212 17:55:40 <GregNoel> We seem to have covered the issues; I have one thing on schedule.
213 17:56:21 <GregNoel> I can't make the next meeting; should we think about one week or three weeks for the next party?
214 17:55:21 <Jason_at_Intel> so 1.3
215 17:55:37 <Garyo> Yes, 1.3. I'm in favor of moving aggressively to release.
216 17:56:13 <Garyo> I have 2 issues to test and one which won't get into 1.3.
217 17:56:45 * loonycyborg really hopes that 2443 will be fixed in 1.3
218 17:57:30 <Garyo> :-( that's my one I thought wouldn't make it. I'll make an effort for it.
219 17:57:32 <GregNoel> loonycyborg, if the current checkpoint is the final candidate, that won't happen. Sorry.
220 17:57:34 <bdbaddog> seems unlikely. we're on the runway to 1.3 launch..
221 17:58:01 <Garyo> They're right, things I've looked at would destabilize.
222 17:59:00 <Jason_at_Intel> hmm 2443 works for me.
223 17:58:23 <Garyo> Let's get 1.3 and 2.0 out asap.
224 17:58:39 <Garyo> Then we can get back on a shorter & less constricted release cycle.
225 17:58:57 <bdbaddog> yaha
226 17:59:11 <bdbaddog> so 1.3 this weekend then?
227 17:59:14 <GregNoel> Can you get back to all the people who've had problems with vs_revamp and get them to try the checkpoint?
228 17:59:33 <GregNoel> If so, this weekend sounds fine to me.
229 17:59:35 <Garyo> Greg: yes, those are the 2 issues on my test list.
230 17:59:57 <Garyo> Bill: I'll try to review the release docs soon. I'm happy to help wordsmith.
231 18:00:56 <Garyo> Is the release process pretty much as documented on the wiki now?
232 18:02:09 <Garyo> I'll be skiing this wkend, but around this week and next.
233 18:02:12 <bdbaddog> yes. though I might move a few steps around to streamline
234 18:02:36 <Garyo> OK, let me help; you've done a lot.
235 18:03:00 <Garyo> Do you think this wkend is possible?
236 18:03:36 <bdbaddog> to get feedback on the couple of issues msvs/vc/sdk which have been reported?
237 18:04:13 <Garyo> I think that should be possible.
238 18:04:21 <GregNoel> If you can get it done this weekend, I can start on 2.0 on Tuesday after I get back from Cabo.
239 18:05:14 <Garyo> Bill: I have the "missing VCs on empty SConstruct" one and "wrong bat file for VS2005" and I think both are now fixed.
240 18:05:31 <bdbaddog> there's two more.
241 18:05:55 <bdbaddog> this one: http://scons.tigris.org/ds/viewMessage.do?dsForumId=1272&dsMessageId=2455554
242 18:06:23 <Garyo> Oh right, missing gdi32.lib.
243 18:06:50 <bdbaddog> and one with vc2010rc + a bunch of other isntalled vc's and it not picking up the requested one.
244 18:08:00 <bdbaddog> I had a win7 license from when they gave out the free trials, but it's expired.
245 18:07:51 <Garyo> I think we have to draw the line somewhere or we'll never get it out.
246 18:08:08 <bdbaddog> yeah. I think so too.
247 18:08:11 <bdbaddog> back in a minute..
248 18:08:12 <Garyo> I have a win7 machine now.
249 18:08:57 <Garyo> The missing gdi32.lib might be simple, or we might be able to give him a simple workaround (he hardcoded a bunch of stuff in his old version, as most people did.)
250 18:09:22 <Jason_at_Intel> what is win7 needed for?
251 18:09:54 <Garyo> I think bdbaddog's 2nd issue, from the ML.
252 18:09:58 <bdbaddog> I just needed a 64 bit some flavor of windows to build up a vm to try and reproduce some of the reported issues.
253 18:10:24 <Jason_at_Intel> ahh
254 18:10:49 <Jason_at_Intel> was masm tool fixed to use ml64?
255 18:11:04 <Garyo> I don't remember.
256 18:11:10 <bdbaddog> donno.
257 18:11:13 <Garyo> Try it :-)
258 18:11:22 <bdbaddog> or check the bug to see if it's marked fixed.
259 18:11:40 <Jason_at_Intel> I think it still uses ml
260 18:13:15 <Jason_at_Intel> yep.. still broken
261 18:11:51 <Garyo> So I say let's look at the missing gdi32 one, but with the vc2010 one let's say we are too close to 1.3 to change things now.
262 18:12:27 <bdbaddog> the gdi32 I think it's setting up right the first time,and the second time it's not. maybe default env and his initial Environmnet()
263 18:12:49 <Garyo> That's usually what that means.
264 18:14:04 <bdbaddog> I'm guessing somehow the sdk/vc logic combo is not quite right, but only in some corner cases.
265 18:13:51 <Garyo> I really want to get the site_scons dirs in too, so the sooner we can get moving on 2.0 the better.
266 18:13:26 <Garyo> Sorry. 2.1.
267 18:14:14 <bdbaddog> I hear u. I want 1.3 done.
268 18:14:19 <bdbaddog> I'm tired of py 1.5.2
269 18:14:19 <Jason_at_Intel> on that i have mirrored this in Parts (with part-site)
270 18:15:32 <Garyo> So let's forge ahead, hoping to get 1.3 out early next week? (Sounds like not all the test results will be in til then.)
271 18:15:34 <Jason_at_Intel> so go with what we have with vs_revamp and patch in 2.0?
272 18:15:57 <Garyo> Jason: yes, or 2.1 actually. 2.0 = 1.3 with python floor update.
273 18:15:58 <bdbaddog> what's in vs_revamp? it's all on trunk
274 18:16:11 <Garyo> yes, trunk.
275 18:16:25 <Jason_at_Intel> sorry mean the "feature" not branch
276 18:16:51 <Jason_at_Intel> so this mean 2.0 will be soon after 1.3?
277 18:17:06 <GregNoel> I'll have three weeks,
278 18:17:42 <GregNoel> which won't be enough, but I'm hoping I'll be far enough that someone else can finish getting out the checkpoints and release itself.
279 18:17:06 <Garyo> hopefully!
280 18:17:07 <bdbaddog> yes. that's the plan.
281 18:17:19 <Jason_at_Intel> great!
282 18:17:22 <bdbaddog> no features in 2.0, just remove 1.5.2->2.3 code.
283 18:17:24 <bdbaddog> right?
284 18:17:32 <Jason_at_Intel> 2.4?
285 18:17:34 <Garyo> agreed.
286 18:17:49 <Jason_at_Intel> thought 2.3 was broken on some platforms
287 18:18:00 <bdbaddog> we're dropping 2.3
288 18:18:04 <bdbaddog> and below.
289 18:18:09 <Garyo> 2.4 is the new floor.
290 18:18:13 <bdbaddog> yes.
291 18:18:17 <Jason_at_Intel> :-)
292 18:19:04 <Garyo> ok, let's do it!
293 18:19:13 <bdbaddog> k.
294 18:19:24 <GregNoel> OK, is that it for 1.3? When should the next party be? One week, two weeks, or three weeks? I can't be there if it's two weeks.
295 18:19:48 <bdbaddog> should we make the call next tues on 1.3?
296 18:20:00 <Garyo> +1
297 18:20:00 <Jason_at_Intel> +1
298 18:20:07 <bdbaddog> or we can handle on release mailing list if things are resolved sooner.
299 18:20:23 <Garyo> fine.
300 18:21:01 <GregNoel> One week, then?
301 18:21:16 <Garyo> good with me.
302 18:21:34 <bdbaddog> k. virtually c u all then.
303 18:21:44 <Jason_at_Intel> same!
304 18:21:49 <GregNoel> OK, see you all in one week.
305 18:21:54 <Garyo> bye 4 now.
306 18:22:00 <Jason_at_Intel> bye
307 18:22:04 <GregNoel> Got to go, dinner is calling.
308 18:22:12 <bdbaddog> l8r
309 18:22:22 <GregNoel> G'day all.
310 18:22:29 * GregNoel has been marked as being away
311 18:23:38 * bdbaddog (~bdeegan@adsl-71-131-3-198.dsl.sntc01.pacbell.net) has left #SCONS
312 18:32:20 * Jason_at_Intel has quit (Quit: ChatZilla 0.9.86 [Firefox 3.5.3/20090824101458])
313 18:38:08 * loonycyborg has quit (Quit: Zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz)
314 18:45:54 * Garyo has quit (Quit: ChatZilla 0.9.86 [Firefox 3.5.8/20100202165920])
315
