Wiki

Clone wiki

SCons / BugParty / IrcLog2009-12-01

16:02:51 * sgk (n=stevenkn@nat/google/x-ncfwmskxkmsbaijr) has joined #scons 17:00:59 <sgk> anyone else here yet for bug party? 17:01:48 * You are no longer marked as being away 17:02:05 <GregNoel> Hi, Steven, just got here; give me a minute to set up. 17:04:39 <sgk> np, i'm still getting set up myself 17:05:57 * sgk really needs to install colloquy 17:06:41 <GregNoel> What's that? Some flavor of wave? 17:07:18 <sgk> better mac irc client than x-chat aqua 17:07:34 <sgk> i've installed it on my desktop mac at work, but not my macbook 17:07:43 <GregNoel> Why is it better? 17:12:27 <GregNoel> Where is everybody? 17:13:07 <sgk> yeah, where is everyone? i know bill's on a plane, but i thought for sure garyo would be here 17:13:25 <GregNoel> ditto 17:13:29 * sgk sighs 17:14:56 <sgk> then i say we just start assigning all the issues to garyo+bdbaddog+Jason_at_intel in rotation 17:15:07 <GregNoel> worksforme 17:18:26 <GregNoel> We can talk a bit about QMTest if you want. I have a couple of things I want to mention. 17:19:43 <sgk> sure 17:19:48 <GregNoel> About QMTest (and SCons testing in general): 17:19:48 <GregNoel> In brief, I think we should drop QMTest, for all of the reasons Steven said in his message, and more. I think that it would only take a few modifications to runtest.py to get a better display like QMTest, and we could probably do more. I've been looking at making this sort of change, but I think a revised configure and new Taskmaster are more important, so I haven't said anything. 17:19:48 <GregNoel> I think unittest should be made a base class for the SConsTest hierarchy, making those functions available for integrated tests as well. 17:19:48 <GregNoel> I think tests should always make a positive assertion about what happened, so we don't get any more of those cases where flow accidentally runs off the bottom. 17:19:48 <GregNoel> I think the tests should be timed, and the times reported. 17:19:48 <GregNoel> I think there should be a timeout on the tests, so if they run more than NNN seconds (start with 300 and move down) the test is aborted. 17:19:48 <GregNoel> I think there should be four types of test returns: 17:19:48 <GregNoel> -1- PASSED meaning that the test was run and everything succeeded. 17:19:48 <GregNoel> -2- UNRUNABLE meaning that the test was not run and nothing can be done to make it work on this hardware/OS combination (e.g., wrong OS, wrong instruction set, wrong Python version, whatever) 17:19:48 <GregNoel> -3- NO RESULT meaning that the test was not run, but some change to the environment would allow it to be run (e.g., TeX not present but could be, old version of SWIG, VS not installed, whatever) 17:19:48 <GregNoel> -4- FAILED meaning that the test was run and found some problem. 17:19:48 <GregNoel> The last two should be summarized (separately!) at the end of the run. 17:19:48 <GregNoel> (I've been practicing my typing speed; how'm I doing?) 17:21:25 <sgk> impressive! 17:22:11 <sgk> seems reasonable to me 17:23:00 <GregNoel> I suppose I should write it up in a design note in the wiki, now that I've written it once already. 17:23:08 <sgk> not a bad idea 17:23:01 * garyo (n=garyo@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) has joined #scons 17:23:08 <GregNoel> Ah-HA! 17:23:15 <garyo> Hi guys 17:23:23 <GregNoel> A bit late, are we? 17:23:30 <sgk> i have to run to the shuttle, i'll be back on after it shows up in ~5 - 10 minutes 17:23:34 * sgk has quit ("This computer has gone to sleep") 17:23:46 <GregNoel> Good timing, I guess... 17:23:54 <garyo> sorry, too much kids stuff 17:24:09 <garyo> what'd I miss? 17:24:12 <GregNoel> Just some QMTest stuff. 17:24:16 <GregNoel> So, would you like to chat about QMTest while we're waiting for Steven to get back? 17:24:21 <garyo> ok 17:24:25 <GregNoel> About QMTest (and SCons testing in general): 17:24:25 <GregNoel> In brief, I think we should drop QMTest, for all of the reasons Steven said in his message, and more. I think that it would only take a few modifications to runtest.py to get a better display like QMTest, and we could probably do more. I've been looking at making this sort of change, but I think a revised configure and new Taskmaster are more important, so I haven't said anything. 17:24:25 <GregNoel> I think unittest should be made a base class for the SConsTest hierarchy, making those functions available for integrated tests as well. 17:24:25 <GregNoel> I think tests should always make a positive assertion about what happened, so we don't get any more of those cases where flow accidentally runs off the bottom. 17:24:25 <GregNoel> I think the tests should be timed, and the times reported. 17:24:25 <GregNoel> I think there should be a timeout on the tests, so if they run more than NNN seconds (start with 300 and move down) the test is aborted. 17:24:25 <GregNoel> I think there should be four types of test returns: 17:24:25 <GregNoel> -1- PASSED meaning that the test was run and everything succeeded. 17:24:25 <GregNoel> -2- UNRUNABLE meaning that the test was not run and nothing can be done to make it work on this hardware/OS combination (e.g., wrong OS, wrong instruction set, wrong Python version, whatever) 17:24:25 <GregNoel> -3- NO RESULT meaning that the test was not run, but some change to the environment would allow it to be run (e.g., TeX not present but could be, old version of SWIG, VS not installed, whatever) 17:24:25 <GregNoel> -4- FAILED meaning that the test was run and found some problem. 17:24:25 <GregNoel> The last two should be summarized (separately!) at the end of the run. 17:24:25 <GregNoel> (I've been practicing my typing speed; how'm I doing?) 17:25:04 <garyo> :-) 17:25:40 <garyo> re: dropping qmtest in general, I'm fine with it. Don't think it provides us much more than a simpler python test fwk. 17:25:59 <GregNoel> (fwk?) 17:26:04 <garyo> framework 17:26:09 <GregNoel> Ah. 17:26:23 <GregNoel> I agree. 17:26:40 <garyo> Probably most of what we use QMtest for is in the higher-level TestSCons etc. classes anyway. 17:26:58 <GregNoel> Yeah, I think so, too. 17:26:45 <GregNoel> QMTest has a lot going for it, but we use so little of it. 17:27:22 <garyo> agreed. However, to get to all of what you propose is perhaps a big project. Still, that shouldn't stop us from getting started. 17:27:39 <GregNoel> One step at a time. 17:27:49 <garyo> (Like timing, timeouts, new & interesting reports, etc.) 17:28:29 <GregNoel> The timeout is primarily for KeyboardInterrupt which still stalls now and again. 17:28:24 <garyo> So we just make --noqmtest the default, right? That's the 1st step? 17:28:48 <GregNoel> I think so; it gets rid of a diagnostic. 17:29:03 <garyo> yes, I've seen it. That kind of thing will be easier with subprocess support I think (?) 17:29:26 <garyo> So this would be a post-1.3 thing? 17:29:54 <GregNoel> Post 1.3, yes. Newer Python constructs will help. 17:30:51 * sgk (n=stevenkn@67.218.106.196) has joined #scons 17:30:57 <GregNoel> I should write up a wiki page, now that I've written it once already. Sigh, yet more words cast into the blue. 17:30:58 <garyo> sounds good. I also like it because although it's a big project it has lots of little parts that people can bite off now & then, unlike some of the more central things (toolchain, tmng, etc.) 17:31:02 <sgk> back. what'd i miss? 17:31:15 <GregNoel> Continuing on QMTest. 17:31:17 <garyo> Hi, Greg just gave me his =noqmtest spiel 17:31:22 <garyo> :-) 17:31:22 <sgk> cool 17:31:28 <garyo> I basically agree 17:31:38 <sgk> i basically agree too 17:31:46 <garyo> just take it in small steps 17:31:32 <sgk> couple comments / questions 17:31:53 <sgk> clarification: perceived advantage of unittest as base? 17:31:59 <sgk> i have mixed emotions about unittest 17:32:16 <garyo> Our QA person is using it here; I can ask her what she thinks of it. 17:32:30 <garyo> I think we do want some framework underneath. 17:32:48 <GregNoel> It has some useful functions, some duplicated in the TestScons stack; harmless at worst if we're keeping it as a basis for unit tests. 17:33:03 <sgk> my main hesitation is that our system tests aren't unit tests in the classic sense 17:33:20 <garyo> Does that matter? 17:33:21 <sgk> concerned that shoehorning them into an unsuitable framework may mislead people or have other drawbacks 17:33:26 <GregNoel> The system tests, no, but it doesn't matter. 17:33:28 <sgk> not sure if it does or not 17:33:32 <GregNoel> jinx 17:33:58 <garyo> Is there an alternative fwk? 17:34:13 <sgk> homebrew, which is one of the reasons unittest is attractive 17:34:38 <garyo> Right, let's not reinvent the wheel. 17:34:41 <sgk> but what does the underlying framework buy us over homebrew? 17:35:31 <GregNoel> Actually, the major reason I suggested it is that I'd like some of the TestSCons functions in unittest, so make it a base class of some class there; once you've done that, you may as well make it a base class overall. 17:34:59 <garyo> A long time ago I remember looking at 'nose' which did some more auto-discovery. 17:35:03 <garyo> (compared to unittest) 17:36:12 <garyo> http://pycheesecake.org/wiki/PythonTestingToolsTaxonomy has a big list. 17:36:25 <GregNoel> Anyway, I'll write it up in my copious spare time. 17:36:36 <sgk> well, i've already done some adaptation of TestCmd + TestCommon to gtest (google's flavor of unittest) 17:37:06 <sgk> so it wouldn't be too bad to do unittest itself 17:36:48 <garyo> what does it buy us? IMHO, reporting is big, plus lots of assertions, exception handling, etc. 17:37:40 <sgk> well, that's what i don't get. it wouldn't be too hard to just have a unittest wrapper that executes our current scripts 17:38:10 <sgk> but all of the failure conditions and the like don't lend themselves to the inside-the-functiona sserts that unittest gives you 17:38:31 <GregNoel> Not to be a wet blanket, but we should triage some bugs. 17:38:53 <sgk> (garyo, good link re: test taxonomy) 17:39:10 <GregNoel> ditto 17:39:28 <GregNoel> I've already bookmarked it. 17:39:21 <sgk> fair enough, let's table the test specifics and get to the bugs 17:39:23 <garyo> ok, just one more round -- asserts are possibly less valuable then than the reporting -- how many failures, which tests failed. I just want to be able to find the failure as easily as possible and go reproduce it. 17:39:35 <garyo> ok, I'm ready 17:39:56 <GregNoel> 2446 reprise 17:40:00 <garyo> 2446: remove that line? 17:40:19 <GregNoel> I think so. It doesn't appear to be used. 17:40:28 <garyo> ok, done. I'll do it, assign it to me. 17:40:37 <GregNoel> done; thanks 17:41:09 <sgk> concur, it looks unnecessary 17:41:09 <GregNoel> 2485 17:41:16 <garyo> research garyo 17:41:36 <GregNoel> done 17:41:55 <GregNoel> 2469 consensus 17:41:59 <garyo> yup 17:42:09 <sgk> agree 17:42:19 <GregNoel> 2470 17:43:16 <GregNoel> Is it something that should be fixed? 17:42:25 <garyo> 2470: I asked OP for more details, he didn't have a user-level failure associated with it. 17:42:27 <sgk> garyo already asked 17:42:57 <garyo> He'd like to know if there is a better way to get the variant dir associated with a source dir. 17:43:35 <GregNoel> Dir('.')? 17:43:02 <sgk> no user failure => invalid, i think 17:43:22 <GregNoel> yes, invalid. 17:44:02 <sgk> he should be able to query a node directly for that 17:44:14 <sgk> oh, wait 17:44:18 <garyo> But... the code does look suspicious. Seems like his fix is valid in the abstract; maybe everything works OK today just because nobody calls alter_targets with paths like his. 17:44:27 <sgk> that's one of those issues where there's no "the" variant dir 17:44:35 <sgk> you could be building multiple variants 17:44:59 <garyo> Right, he wants to go the reverse direction (as it were). 17:45:26 <garyo> I don't really want to make an API for him to do it, I just want to make adjust_targets do what it's supposed to do. 17:45:30 <garyo> (whatever that is) 17:45:43 <garyo> adjust -> alter, sorry 17:45:43 <GregNoel> Best he can do is get the current variant dir, using Dir(). 17:45:57 <garyo> I'll mention that to him. 17:46:31 <sgk> k, invalid, garyo follows up with Dir('.") 17:46:36 <GregNoel> Since Gary's already on it, let him run with it and report back next time? 17:46:45 <garyo> well, ok. 17:46:54 <GregNoel> done 17:47:23 <GregNoel> 2471 17:47:59 <GregNoel> It seems like future is too far out; I'd like it sooner. 17:48:36 <GregNoel> Searching also needs a magic token for "dir of source file" 17:47:36 <sgk> is it real or theoretical? 17:47:43 <garyo> It's real. 17:47:55 <garyo> <> never searches the current dir. 17:47:58 <sgk> which compiler(s)? 17:48:05 <garyo> gcc, msvc. 17:48:32 <sgk> ? if <> doesn't do that it's a regression 17:48:31 <garyo> So if you have a stdio.h in the current dir, scons will think that's the one you mean, but the compiler won't. 17:48:42 <sgk> oh 17:49:17 <garyo> In the limit it's quite complicated though (and compiler-specific). 17:50:01 <GregNoel> It's well into undefined territory in the C/C++ spec, but the convention seems common. 17:49:04 <sgk> that sounds like an outright bug in the behavior then 17:49:27 <sgk> that can just be fixed in the current code 17:50:05 <garyo> I agree, I don't think it's a huge deal as long as we know which kind of include it is 17:50:31 <sgk> so perhaps change scons' <> search in the current code for the short term 17:50:43 <garyo> I'd be happy w/ that. 17:50:55 <sgk> and a future to invent a CPPPATH replacement that allows separate "" vs. <> configuration? 17:51:00 <garyo> (It's not perfect but better than today) 17:51:07 <GregNoel> If we can do that short term, pushing the general case to future is fine with me. 17:51:44 <garyo> ok, steven 2.x p? 17:51:47 <GregNoel> OK, what priority on the short case? 17:51:56 <garyo> p3? 17:52:01 <GregNoel> works 17:52:20 <GregNoel> What priority when it goes into the future? 17:52:26 <sgk> if the current code doesn't mimic gcc + msvc practice, then i think any backwards compatibility issues are negligible; let's change it 17:53:05 <garyo> I'd say p4 for the future because people won't usually even notice. 17:53:08 <sgk> maybe 2.0 p2 for the short term fix 17:53:12 <sgk> future p3 for the long term 17:54:00 <GregNoel> Agree w/ Steven 17:53:49 <garyo> either way, I'm fine w/ p2/p3 or p3/p4. I guess I lean toward p3/p4 just because there's a lot of other stuff to do 17:53:32 <GregNoel> And note that '.' isn't right for the local search path; it's "directory of source file" 17:54:14 <garyo> Greg: I'm not sure gcc and msvc agree 100% there. 17:54:47 <garyo> I think one of them uses the dir of the source file, the other uses the dir of the including file (but I ould be wrong) 17:55:55 <GregNoel> Same thing; it's relative to the file that includes it. 17:54:34 <GregNoel> Oops, Steven said 2.0. It should be 2.x. 17:54:43 <sgk> okay, 2.x 17:54:49 <GregNoel> 2.x p2 then future p3 17:54:55 <sgk> done 17:54:55 <garyo> fine 17:55:04 <GregNoel> done 17:55:23 <garyo> 2472 I already closed 17:55:26 <GregNoel> done 17:55:31 <garyo> & 2473 17:55:37 <garyo> hope you guys don't mind 17:55:38 <GregNoel> ++ 17:55:40 <sgk> garyo++ 17:56:07 <GregNoel> 2474 17:56:17 <sgk> research, who? 17:56:37 <sgk> sign up bdbaddog? 17:56:40 <garyo> don't know, not me 17:56:42 <GregNoel> I don't think research is right 17:57:18 <garyo> Well, we don't know what's going on... 17:57:20 <GregNoel> We know about the problem with directories; there's even a SEP about it. 17:57:20 <sgk> seems like it needs some characterization... back to op? 17:57:47 <garyo> "back to op" to me is a lot like "research" 17:58:50 <GregNoel> Seeing no consensus, pass to next time. 17:59:00 <garyo> OK w/ me. 17:59:01 <GregNoel> 2475 17:59:14 <GregNoel> consensus 17:59:28 <GregNoel> 2476 17:59:52 <sgk> ok 18:00:07 <garyo> option 1 seems good to me. 18:00:19 <GregNoel> I disagree with second option; some values cannot be modified (platform, for one) 18:00:26 <GregNoel> For the others, maybe. 18:00:37 <garyo> all the more reason to take option 1 :-) 18:01:30 <sgk> okay, first option is fine with me 18:01:14 <GregNoel> OK, I'll include a commentary; 2.x p4 who? 18:01:37 <garyo> Greg, maybe you could do it? Or Bill? 18:01:48 <GregNoel> Or for 2.x, not a strong motivation to assign an owner now. 18:02:07 <garyo> ok, esp. w/ +Easy 18:02:16 <sgk> agree 18:02:35 <GregNoel> done 18:02:18 <GregNoel> Actually, a lot of it should be subsumed by revamped configure. 18:02:35 <garyo> and/or toolchain 18:02:41 <sgk> right 18:02:48 <GregNoel> Er, yes, that's what I meant. 18:03:01 <GregNoel> Closely related in my mind. 18:02:57 <garyo> 2477: 2.1 p2 bdbaddog 18:03:08 <GregNoel> done 18:03:23 <sgk> 2478: 2.x p3 bdbaddog 18:03:27 <GregNoel> done 18:03:53 <sgk> 2479: ask OP if he'd like to contribute 18:03:56 <garyo> 2479: invalid, unless OP wants to work on it 18:04:06 <GregNoel> How can it be invalid+symlink? 18:04:17 <sgk> ? 18:04:51 <garyo> 1: ask OP if he's interested. If yes, then it's him +symlink. Else, invalid & close. 18:04:51 <GregNoel> If it's invalid, it goes away. If it's +symlink, it's assigned with the other symlink issues. 18:05:00 <garyo> jinx 18:05:08 <GregNoel> concur w/ garyo 18:05:14 <sgk> oh, i see 18:05:36 <sgk> done 18:05:40 <GregNoel> done 18:05:44 <garyo> 2480: research bdbaddog 18:05:52 <sgk> go badbaddog! 18:05:58 <GregNoel> done 18:05:57 <garyo> 2481: already fixed. 18:06:28 <GregNoel> 2481 done 18:06:38 <GregNoel> 2482 18:07:09 <garyo> how about mark as future, hope it goes away w/ sconf revamp? 18:06:57 <sgk> 2482 is hairy; no obvious course of action; defer to next time? 18:07:16 <sgk> lame, I know, but i don't think time here on it is productive 18:07:20 <GregNoel> yeah, I'll look at it between now and then 18:07:21 <garyo> agreed. 18:07:27 <sgk> done 18:07:33 <GregNoel> 2483 18:07:46 <sgk> 2.x p3 bdbaddog 18:08:04 <sgk> w/note re: clarifying whether the behavior is specific 18:08:11 <garyo> sounds good. 18:08:29 <GregNoel> OK. (There's really only one java compiler, short of what GNU is doing, and we don't support that yet.) 18:08:48 <sgk> ? there's sun, there's blackdown, there's gcj... 18:09:31 <sgk> anyway 18:09:33 <garyo> Not my world. Let me know when any of them can process 33Mpixels in 16msec. 18:09:37 <GregNoel> gcj is GNU, I don't know what its command line is like; blackdown follows Sun as far as I know. 18:09:51 <garyo> ok, let's keep moving... 2484 18:09:54 <sgk> 2484: 2.1 p2 bdbaddog 18:10:03 <garyo> good. 18:10:22 <GregNoel> done 18:10:32 <garyo> 2486: Steven, can you take that one? 18:10:45 <sgk> okay 18:10:57 <sgk> still 2.x p2 ? 18:11:10 <sgk> sure 18:11:16 <garyo> Sure (or p3, your call) 18:10:47 <GregNoel> done 18:11:27 * sgk has about 5 minutes to the shuttle stop 18:11:42 <GregNoel> 2487, wontfix 18:11:43 <sgk> 2.x p3 stevenknight 18:11:47 <garyo> 2487: let's mark invalid. The filter idea we can take up later. 18:11:48 <sgk> done 18:12:05 <GregNoel> ok, invalid 18:12:09 <sgk> 2488: 2.x p2 bdbaddog 18:12:19 <garyo> yep 18:12:24 <GregNoel> done 18:12:42 <garyo> 2489: future or 2.x? Maybe 3.x? 18:12:59 <GregNoel> I don't use it; no opinion 18:13:09 <sgk> 3.x sounds about right 18:13:15 <sgk> 2.x would be nice, but there's already enough there 18:13:20 <GregNoel> too much 18:13:25 <garyo> It would take me a while to refactor my code to use it too. Agree w/ Steven re: 3.x. 18:13:31 <GregNoel> p? 18:13:34 <garyo> 3 18:13:37 <sgk> p3 18:13:39 <GregNoel> done 18:13:54 <garyo> 2490: I asked for a patch. We'll see. 18:14:01 <GregNoel> defer to next time 18:14:02 <sgk> 2490: is it passible he just added a C# module somewhere? 18:14:07 <sgk> defer++ 18:14:21 <garyo> steven: definitely possible. 18:14:39 <sgk> i may take a look for the module while waiting for tests to run 18:14:39 <garyo> 2491: anytime p4 sounds fine. 18:14:51 <sgk> anytime p4 18:15:02 <GregNoel> done 18:15:11 <GregNoel> oops, er, who? 18:15:41 <GregNoel> anytime needs an owner 18:15:09 <garyo> sgk: or you could knock of a +Easy one... better way to spend the time perhaps? 18:15:11 <garyo> :-) 18:15:40 <garyo> Steven, I think only you understand the packaging stuff well enough I think. 18:15:50 <sgk> garyo: feel free to prioritize my time that way... 18:15:54 <GregNoel> I sure don't 18:16:03 <sgk> okay, me 18:16:14 <GregNoel> done 18:16:55 <garyo> btw speaking of time & priorities you have been very productive recently -- good to see! 18:16:49 <GregNoel> 2492, assign to rob? 18:17:03 <sgk> 2492: could be draconian and also mark it fixed with invitation to re-open if that's hasty 18:17:19 <garyo> 2492: agree w/ steven 18:17:36 <GregNoel> yes, concur. done 18:17:55 <garyo> 2493 consensus 18:17:58 <GregNoel> done 18:17:59 <sgk> done 18:18:14 <sgk> 2494 anytime +Easy 18:18:24 <GregNoel> then who? 18:18:40 <sgk> doesn't +Easy mean it doesn't need a who? 18:18:41 <garyo> if we need an owner for an anytime, then I'd say 2.x or 3.x instead. 18:18:51 <sgk> okay, 2.x 18:19:04 <sgk> anything to avoid the dread "who?" question... :-) 18:19:12 <GregNoel> Hmmm... you're right, we have some +Easy anytime 18:19:13 <garyo> sgk: I think that makes sense, anytime +Easy no owner is fine w/ me. 18:19:26 <sgk> okay, anytime 18:19:25 <GregNoel> done 18:19:41 * sgk has < 1 minute 18:19:46 <garyo> 2495 is for me 18:19:50 <sgk> done 18:19:55 <GregNoel> 2496 garyo 18:20:07 <GregNoel> oops, 2495 18:19:57 <garyo> see you later, Steven 18:20:03 <garyo> yes 18:20:15 <sgk> and 2496 too 18:20:12 <GregNoel> time to quit? 18:20:26 <garyo> sure, let's stop here. 18:20:32 <sgk> okay, i'm gone 18:20:33 <garyo> I'll spend some time tonight on 1.3 issues. 18:20:37 <sgk> thanks for a very productive time 18:20:41 <GregNoel> cul 18:20:45 <garyo> thx, sorry I was late. 18:20:46 * sgk has quit ("Leaving") 18:20:59 <GregNoel> it happens, and we made up for it. 18:21:11 <garyo> & thanks Greg for all the behind-the-scenes work. 18:21:36 <GregNoel> you're welcome 18:21:19 <GregNoel> what was the final on 2496? 18:21:26 <garyo> mine 18:21:32 <GregNoel> ok. 18:21:59 <garyo> see you on the mailing list... :-) 18:22:09 <GregNoel> Ah, good timing for me; dinner just announced. 18:22:01 <garyo> bye for now 18:22:13 <GregNoel> cul 18:22:08 * garyo (n=garyo@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) has left #scons 18:24:04 * You have been marked as being away

Updated