-
-
Notifications
You must be signed in to change notification settings - Fork 309
IrcLog2010 03 09
William Deegan edited this page Jan 14, 2016
·
2 revisions
16:50:54 * Jason_at_Intel (~[chatzilla@12.18.240.224](mailto:chatzilla@12.18.240.224)) has joined #SCONS
16:52:29 * [GregNoel](GregNoel) is no longer marked as being away
16:53:51 <Jason_at_Intel> hello
16:53:59 * Garyo (~[chatzilla@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com](mailto:chatzilla@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com)) has joined #SCONS
16:54:12 <Jason_at_Intel> Hi Gary
16:54:21 <Garyo> Hi Jason.
17:02:17 <Garyo> Hi Greg -- feel free. I'm starting to get some SCons time in the next few months (I hope!)
17:05:34 * bdbaddog (~[bdeegan@adsl-71-131-3-198.dsl.sntc01.pacbell.net](mailto:bdeegan@adsl-71-131-3-198.dsl.sntc01.pacbell.net)) has joined #SCONS
17:06:03 <Garyo> Hi Bill!
17:06:19 <bdbaddog> hey
17:06:39 <Garyo> Thanks (again) for pushing out the checkpoint; this one is looking good.
17:06:45 <[GregNoel](GregNoel)> We're short Steven, but he commented in the spreadsheet; should we begin?
17:06:52 <bdbaddog> sure.
17:06:57 <Garyo> I think so too.
17:07:14 <[GregNoel](GregNoel)> 2517
17:07:36 <[GregNoel](GregNoel)> Steven says give it to him, but I don't like it as research.
17:08:02 <Garyo> I think it's his choice, is that OK?
17:08:36 <[GregNoel](GregNoel)> Yeah, but I don't think he should work on it until post-2.0.
17:09:06 <Garyo> Ah, I see. Spend his cycles getting the python 2.4 stuff in now instead?
17:09:16 <[GregNoel](GregNoel)> Yes.
17:09:43 <Garyo> That makes a lot of sense. I'm worried the 1.3 -> 2.0 transition will take a long time.
17:10:23 <[GregNoel](GregNoel)> It better not; I'll be flat on my back if it does...
17:09:42 <[GregNoel](GregNoel)> What's the priority on 2550? I didn't look.
17:10:02 <Garyo> 2550=p3
17:10:29 <[GregNoel](GregNoel)> What's the milestone?
17:10:45 <Garyo> research
17:11:03 <[GregNoel](GregNoel)> Ouch. OK, make them the same: research p3.
17:11:27 <Garyo> OK, or move both to 2.1 p3 if you like.
17:11:45 <[GregNoel](GregNoel)> I'll put in a note that this "research" is less priority than 2.0.
17:11:53 <Garyo> +1
17:11:58 <[GregNoel](GregNoel)> done
17:12:02 <[GregNoel](GregNoel)> 1549
17:12:09 <[GregNoel](GregNoel)> oops, 2549
17:12:48 <Garyo> Here's where I say I am really happy Russel is taking the lead in putting tools in a DVCS.
17:13:24 <[GregNoel](GregNoel)> I agree. I'm not sure I agree with his choice of DVCS, but any choice is better than none.
17:13:34 <bdbaddog> he's certainly bringing the email volume up..
17:14:09 <Garyo> So... can we make a new category of issues for external tools, and this can be one?
17:14:27 <Garyo> (I know it's half here & half there, so it's confusing.)
17:14:28 <[GregNoel](GregNoel)> Hmmm... Possible. Needs discussion.
17:14:47 <[GregNoel](GregNoel)> Not something to settle today, surely.
17:14:59 <Jason_at_Intel> +1
17:15:01 <Garyo> Agreed. Just let Russel work on it for now.
17:15:31 <[GregNoel](GregNoel)> so 2549, 3.x, what priority?
17:15:42 <Garyo> So 3.x p4?
17:15:53 <[GregNoel](GregNoel)> Hmmm...
17:16:15 <[GregNoel](GregNoel)> I think I'd like it to resurface sooner than that.
17:16:44 <Garyo> I'm hoping we'll decide some day to take the D tool out of SCons entirely instead.
17:16:53 <[GregNoel](GregNoel)> Yeah, along with Java.
17:17:02 <Garyo> ... and latex, and ...
17:17:03 <Jason_at_Intel> why?
17:17:16 <[GregNoel](GregNoel)> Make them all user-supported.
17:17:16 <Garyo> Because they can be developed and released asynchronously.
17:17:17 <Jason_at_Intel> oh make them add on
17:17:47 <Jason_at_Intel> in that case most of the tools can go that route
17:18:19 <Garyo> Jason: agreed. But we have to balance that with the python "batteries included" philosophy.
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.)
17:18:08 <[GregNoel](GregNoel)> Yeah, 2549 3.x p4; reassign it when we have a separate user-supported flow.
17:18:27 <Garyo> Greg: +1
17:18:32 <[GregNoel](GregNoel)> done
17:18:39 <[GregNoel](GregNoel)> 2566
17:18:42 <Garyo> 2566 is already closed.
17:18:52 <Garyo> can't repro.
17:19:03 <[GregNoel](GregNoel)> WORKSFORME?
17:19:34 <Garyo> I said INVALID because he couldn't repro it either :-)
17:19:58 <[GregNoel](GregNoel)> worksforme, then. {;-}
17:19:27 <[GregNoel](GregNoel)> In any event, 2571
17:20:13 <Jason_at_Intel> 2571? is this calling Scons under the covers still?
17:20:29 <Garyo> Jason: sure.
17:20:15 <Garyo> 2571: tell OP good job, give some direction on compat, then integrate for 2.1?
17:20:28 <[GregNoel](GregNoel)> I'll go along.
17:20:38 <[GregNoel](GregNoel)> Who? Gary?
17:20:47 <Garyo> I'll take it.
17:21:17 <[GregNoel](GregNoel)> Obviously needs some test cases, but I like the scheduling.
17:21:04 <Garyo> (Not that I care about MSVS, but I do care about new contributors.)
17:21:27 <Jason_at_Intel> it start small then grows
17:21:41 <[GregNoel](GregNoel)> 2.1 p3 Garyo, done
17:22:09 <[GregNoel](GregNoel)> 2572, defer?
17:22:29 <Garyo> sure
17:22:33 <Jason_at_Intel> +1
17:22:37 <bdbaddog> +1
17:22:47 <[GregNoel](GregNoel)> done
17:22:56 <[GregNoel](GregNoel)> 2573
17:22:59 <Garyo> 2573: what is ".sx"?
17:23:10 <Jason_at_Intel> :-) was just going to ask that
17:23:15 <bdbaddog> some .net file?
17:23:22 <[GregNoel](GregNoel)> Man page says "preprocessed assembler"
17:23:33 <[GregNoel](GregNoel)> (It's in the spreadsheet comments.)
17:23:36 <Garyo> for what OS?
17:23:44 <[GregNoel](GregNoel)> Any?
17:23:56 <Garyo> what man page did you find it in?
17:24:24 <[GregNoel](GregNoel)> SCons man page.
17:24:48 <[GregNoel](GregNoel)> We currently preprocess those files, but apparently don't scan them for dependencies.
17:24:56 <Garyo> Oh?! Wow, that's a surprise!
17:25:05 <[GregNoel](GregNoel)> It was to me, too.
17:25:09 <Garyo> OK, I guess you guys are right, add it to the list.
17:25:37 <Garyo> I'll do that too. The work part is trivial.
17:25:49 <Garyo> 2.1 p4 garyo +easy
17:25:51 <[GregNoel](GregNoel)> OK, done, but watch for side-effects: it may try to compile the file.
17:26:07 <Garyo> ok, put a note in if you don't mind...
17:26:17 <[GregNoel](GregNoel)> Wilco
17:26:33 <[GregNoel](GregNoel)> 2574
17:27:02 <[GregNoel](GregNoel)> Another trivial change, but would work better post-2.0.
17:27:16 <Garyo> Agreed. Post 2.0.
17:27:33 <Garyo> 2.1 p2, who?
17:28:08 <[GregNoel](GregNoel)> Not seeing any volunteers...
17:28:19 <[GregNoel](GregNoel)> I can't take it; I'll be recovering.
17:28:36 <Garyo> Understood. Assign it to me then, I'll delegate if needed.
17:28:41 <[GregNoel](GregNoel)> done
17:28:48 <[GregNoel](GregNoel)> 2575
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
17:29:22 <Garyo> That's an excellent idea.
17:29:39 <Garyo> Jason, can you propose that to the OP and ask for a new patch?
17:29:50 <Jason_at_Intel> (zipfile in Parts :-) .. not as good as raw zip however in some cases)
17:30:09 <Jason_at_Intel> sure.. main problem is the call more than once issue
17:30:29 <Jason_at_Intel> the builders think the output is more than one environment
17:30:16 <[GregNoel](GregNoel)> Um, it would have to work for all builders, not just this one.
17:30:32 <Garyo> Would it, Greg? Couldn't it just be an env override?
17:31:07 <[GregNoel](GregNoel)> No, I don't think so. Think of LaTeX, for example, which wants to run in the build directory.
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)
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
17:31:46 <Garyo> Greg: I don't think tar/zip need to *run* in any particular dir, they just need a reference point.
17:32:39 <Garyo> OK, maybe this is more complicated than it seems at first.
17:32:40 <Jason_at_Intel> however for 2575 his patch will work.. it will just break -j builds
17:33:00 <Garyo> Jason: that worries me.
17:33:07 <[GregNoel](GregNoel)> Actually, tar/zip can have multiple changes of directory in them; that's why I like the solution in 1890.
17:33:31 * Garyo looks at 1890
17:34:15 <Jason_at_Intel> ie use the tarfile module?
17:34:23 <Garyo> I see, use tarfile instead of calling tar. I totally agree.
17:34:34 <[GregNoel](GregNoel)> Garyo, basically, each entry is a duple of (name-in-archive, File-node).
17:34:48 <Jason_at_Intel> I have an impl in Parts for this
17:34:59 <Jason_at_Intel> but again i don't have it support more than one call
17:35:15 <Garyo> It's a call-once-with-all-sources builder?
17:35:28 <Jason_at_Intel> yep
17:35:44 <Jason_at_Intel> again the src_dir overide upsets teh builders
17:35:54 <Jason_at_Intel> spits out warnings or errors
17:35:58 <Garyo> Not ideal, of course, but probably best we can do given builder limitations
17:36:08 <[GregNoel](GregNoel)> I have a functional prototype for 1890, but I've been waiting for post-2.0 to implement it.
17:36:29 <Garyo> And calling with a single src dir is probably 90% of all use cases anyway.
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](http://parts.tigris.org/source/browse/*checkout*/parts/trunk/parts/parts/pieces/tar.py?revision=143&content-type=text%2Fplain)
17:37:13 <[GregNoel](GregNoel)> Then why not base it off of chdir=? It's the effect that counts, not the actual functioning.
17:37:51 <Garyo> because of breaking -j, right?
17:38:10 <Jason_at_Intel> I think the chdir in SCons means current dir change
17:38:26 <Jason_at_Intel> Scons needs a new idea to support the "root" area to use
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.
17:38:40 <Jason_at_Intel> src_dir is what i would propose
17:39:04 <[GregNoel](GregNoel)> I don't agree.
17:39:26 <Garyo> don't agree w/ src_dir, or don't agree w/ my assignment?
17:39:27 <Jason_at_Intel> to me .. not gary .. correct?
17:39:58 <[GregNoel](GregNoel)> don't agree with src_dir; again, the effect is the requirement, not the actuality.
17:40:15 <Jason_at_Intel> ??
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.
17:40:52 <[GregNoel](GregNoel)> Yes
17:41:01 <Garyo> Might require a little core patching but not impossible of course.
17:41:15 <Jason_at_Intel> that is fine.. then does this mean we will fix command to do the same
17:41:21 <Garyo> (like a "builder_wants_chdir" flag or something)
17:41:35 <Jason_at_Intel> will it out add a cd <dir> && to the command?
17:42:15 <Garyo> Jason: at least the infrastructure would be there to handle it that way if we wanted to.
17:42:22 <[GregNoel](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=.
17:43:07 <[GregNoel](GregNoel)> If we change that paradigm, we need to make it consistent.
17:42:57 <Jason_at_Intel> so back to the issue
17:43:02 <Jason_at_Intel> this is a patch
17:43:11 <Jason_at_Intel> that is invalid?
17:43:13 <Garyo> Let's not say it's invalid then, but we think there's a better method.
17:43:24 <[GregNoel](GregNoel)> Garyo, yes.
17:43:51 <Jason_at_Intel> i see... not sure what the better method you have in mind is
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.
17:44:29 <Jason_at_Intel> agree
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.
17:45:11 <[GregNoel](GregNoel)> And you could have chdir= on each builder call.
17:45:13 <Jason_at_Intel> I guess... but you woudl always want it on.. never off
17:45:20 <Garyo> (Greg, is that basically your idea?)
17:45:42 <[GregNoel](GregNoel)> Still designing on the fly, but yes, I think so.
17:45:44 <Garyo> Jason: we can't turn it on for all builders because most of them don't understand it.
17:45:59 <loonycyborg> chdir is clearly hack in this case.
17:46:26 <[GregNoel](GregNoel)> Hi, Sergey; glad you could join us. Do you think users would understand a distinction there?
17:46:29 <loonycyborg> There should be more flexible ways to specify paths that'll be stored in the archive,
17:46:32 <Garyo> loonycyborg: yes, we'd be "repurposing it" a bit.
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
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.
17:47:45 <Jason_at_Intel> agree
17:48:02 <[GregNoel](GregNoel)> OK, then what should we do with the ticket?
17:48:37 <[GregNoel](GregNoel)> I'll suggest deferring to the mailing list.
17:48:43 <Garyo> How about this: mark it 2.1 p2, but with a note to say revisit at that time and discuss.
17:48:58 <Jason_at_Intel> +1
17:49:00 <[GregNoel](GregNoel)> Yes
17:49:08 <bdbaddog> +1
17:49:08 <Garyo> (rather than have a complete implementation by that time)
17:49:16 <[GregNoel](GregNoel)> done
17:49:18 <Garyo> good, consensus!
17:53:13 <loonycyborg> Zip builder should store paths relative to shortest common path of sources by default IMO..
17:53:35 <[GregNoel](GregNoel)> And that's what I'd like to do with 1890.
17:54:24 <[GregNoel](GregNoel)> Always put in a duple with relative path and File node.
17:53:49 <Garyo> loonycyborg: put a note in those 2 tickets if you want.
17:54:54 <Garyo> I like explicit rather than implicit in general though, even if it's a little more typing.
17:55:19 <[GregNoel](GregNoel)> Garyo, yes.
17:55:02 <Jason_at_Intel> lonnycyborg.. I agree.. that is what I have in Parts as well
17:55:04 <[GregNoel](GregNoel)> Remember, relative path is expensive to calculate; should try to avoid it when possible.
17:55:06 <Garyo> ...but we're trying to design it here.
17:55:15 <Garyo> let's not.
17:49:37 <[GregNoel](GregNoel)> 2576
17:50:00 <Garyo> 2576 looks like good potential for Russel to feed Steven things.
17:50:28 <[GregNoel](GregNoel)> Yes.
17:51:13 <[GregNoel](GregNoel)> I wonder if "anytime" would work for this, as they work out the interaction details.
17:51:19 <Garyo> 2.x p3, Steven to own, and work w/ Russel?
17:51:57 <Garyo> (Or vice versa, Russel to own, delegate work to Steven?)
17:52:08 <[GregNoel](GregNoel)> I could buy 2.x p3, but I'd like to see a procedure worked out first.
17:52:37 <[GregNoel](GregNoel)> Russel to own during design, Steven to own during implementation?
17:52:57 <Garyo> OK then, let's ask Steven to work something like that out & revisit next meeting. OK?
17:53:12 <[GregNoel](GregNoel)> yes, I like that.
17:53:18 <bdbaddog> +1
17:53:25 <Jason_at_Intel> +1
17:55:40 <[GregNoel](GregNoel)> We seem to have covered the issues; I have one thing on schedule.
17:56:21 <[GregNoel](GregNoel)> I can't make the next meeting; should we think about one week or three weeks for the next party?
17:55:21 <Jason_at_Intel> so 1.3
17:55:37 <Garyo> Yes, 1.3. I'm in favor of moving aggressively to release.
17:56:13 <Garyo> I have 2 issues to test and one which won't get into 1.3.
17:56:45 * loonycyborg really hopes that 2443 will be fixed in 1.3
17:57:30 <Garyo> :-( that's my one I thought wouldn't make it. I'll make an effort for it.
17:57:32 <[GregNoel](GregNoel)> loonycyborg, if the current checkpoint is the final candidate, that won't happen. Sorry.
17:57:34 <bdbaddog> seems unlikely. we're on the runway to 1.3 launch..
17:58:01 <Garyo> They're right, things I've looked at would destabilize.
17:59:00 <Jason_at_Intel> hmm 2443 works for me.
17:58:23 <Garyo> Let's get 1.3 and 2.0 out asap.
17:58:39 <Garyo> Then we can get back on a shorter & less constricted release cycle.
17:58:57 <bdbaddog> yaha
17:59:11 <bdbaddog> so 1.3 this weekend then?
17:59:14 <[GregNoel](GregNoel)> Can you get back to all the people who've had problems with vs_revamp and get them to try the checkpoint?
17:59:33 <[GregNoel](GregNoel)> If so, this weekend sounds fine to me.
17:59:35 <Garyo> Greg: yes, those are the 2 issues on my test list.
17:59:57 <Garyo> Bill: I'll try to review the release docs soon. I'm happy to help wordsmith.
18:00:56 <Garyo> Is the release process pretty much as documented on the wiki now?
18:02:09 <Garyo> I'll be skiing this wkend, but around this week and next.
18:02:12 <bdbaddog> yes. though I might move a few steps around to streamline
18:02:36 <Garyo> OK, let me help; you've done a lot.
18:03:00 <Garyo> Do you think this wkend is possible?
18:03:36 <bdbaddog> to get feedback on the couple of issues msvs/vc/sdk which have been reported?
18:04:13 <Garyo> I think that should be possible.
18:04:21 <[GregNoel](GregNoel)> If you can get it done this weekend, I can start on 2.0 on Tuesday after I get back from Cabo.
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.
18:05:31 <bdbaddog> there's two more.
18:05:55 <bdbaddog> this one: [http://scons.tigris.org/ds/viewMessage.do?dsForumId=1272&dsMessageId=2455554](http://scons.tigris.org/ds/viewMessage.do?dsForumId=1272&dsMessageId=2455554)
18:06:23 <Garyo> Oh right, missing gdi32.lib.
18:06:50 <bdbaddog> and one with vc2010rc + a bunch of other isntalled vc's and it not picking up the requested one.
18:08:00 <bdbaddog> I had a win7 license from when they gave out the free trials, but it's expired.
18:07:51 <Garyo> I think we have to draw the line somewhere or we'll never get it out.
18:08:08 <bdbaddog> yeah. I think so too.
18:08:11 <bdbaddog> back in a minute..
18:08:12 <Garyo> I have a win7 machine now.
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.)
18:09:22 <Jason_at_Intel> what is win7 needed for?
18:09:54 <Garyo> I think bdbaddog's 2nd issue, from the ML.
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.
18:10:24 <Jason_at_Intel> ahh
18:10:49 <Jason_at_Intel> was masm tool fixed to use ml64?
18:11:04 <Garyo> I don't remember.
18:11:10 <bdbaddog> donno.
18:11:13 <Garyo> Try it :-)
18:11:22 <bdbaddog> or check the bug to see if it's marked fixed.
18:11:40 <Jason_at_Intel> I think it still uses ml
18:13:15 <Jason_at_Intel> yep.. still broken
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.
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()
18:12:49 <Garyo> That's usually what that means.
18:14:04 <bdbaddog> I'm guessing somehow the sdk/vc logic combo is not quite right, but only in some corner cases.
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.
18:13:26 <Garyo> Sorry. 2.1.
18:14:14 <bdbaddog> I hear u. I want 1.3 done.
18:14:19 <bdbaddog> I'm tired of py 1.5.2
18:14:19 <Jason_at_Intel> on that i have mirrored this in Parts (with part-site)
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.)
18:15:34 <Jason_at_Intel> so go with what we have with vs_revamp and patch in 2.0?
18:15:57 <Garyo> Jason: yes, or 2.1 actually. 2.0 = 1.3 with python floor update.
18:15:58 <bdbaddog> what's in vs_revamp? it's all on trunk
18:16:11 <Garyo> yes, trunk.
18:16:25 <Jason_at_Intel> sorry mean the "feature" not branch
18:16:51 <Jason_at_Intel> so this mean 2.0 will be soon after 1.3?
18:17:06 <[GregNoel](GregNoel)> I'll have three weeks,
18:17:42 <[GregNoel](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.
18:17:06 <Garyo> hopefully!
18:17:07 <bdbaddog> yes. that's the plan.
18:17:19 <Jason_at_Intel> great!
18:17:22 <bdbaddog> no features in 2.0, just remove 1.5.2->2.3 code.
18:17:24 <bdbaddog> right?
18:17:32 <Jason_at_Intel> 2.4?
18:17:34 <Garyo> agreed.
18:17:49 <Jason_at_Intel> thought 2.3 was broken on some platforms
18:18:00 <bdbaddog> we're dropping 2.3
18:18:04 <bdbaddog> and below.
18:18:09 <Garyo> 2.4 is the new floor.
18:18:13 <bdbaddog> yes.
18:18:17 <Jason_at_Intel> :-)
18:19:04 <Garyo> ok, let's do it!
18:19:13 <bdbaddog> k.
18:19:24 <[GregNoel](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.
18:19:48 <bdbaddog> should we make the call next tues on 1.3?
18:20:00 <Garyo> +1
18:20:00 <Jason_at_Intel> +1
18:20:07 <bdbaddog> or we can handle on release mailing list if things are resolved sooner.
18:20:23 <Garyo> fine.
18:21:01 <[GregNoel](GregNoel)> One week, then?
18:21:16 <Garyo> good with me.
18:21:34 <bdbaddog> k. virtually c u all then.
18:21:44 <Jason_at_Intel> same!
18:21:49 <[GregNoel](GregNoel)> OK, see you all in one week.
18:21:54 <Garyo> bye 4 now.
18:22:00 <Jason_at_Intel> bye
18:22:04 <[GregNoel](GregNoel)> Got to go, dinner is calling.
18:22:12 <bdbaddog> l8r
18:22:22 <[GregNoel](GregNoel)> G'day all.
18:22:29 * [GregNoel](GregNoel) has been marked as being away
18:23:38 * bdbaddog (~[bdeegan@adsl-71-131-3-198.dsl.sntc01.pacbell.net](mailto:bdeegan@adsl-71-131-3-198.dsl.sntc01.pacbell.net)) has left #SCONS
18:32:20 * Jason_at_Intel has quit (Quit: [ChatZilla](ChatZilla) 0.9.86 [Firefox 3.5.3/20090824101458])
18:38:08 * loonycyborg has quit (Quit: Zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz)
18:45:54 * Garyo has quit (Quit: [ChatZilla](ChatZilla) 0.9.86 [Firefox 3.5.8/20100202165920])