Clone wiki

SCons / BugParty / IrcLog2009-11-03

16:19:19 * garyo ( has joined #scons 16:44:41 * Jason_at_intel (n=chatzill@ has joined #scons 16:48:34 * bdbaddog ( has joined #scons 16:58:21 <Jason_at_intel> so Gary question 16:58:26 <garyo> yes? 16:58:30 <Jason_at_intel> the scons site stuff 16:58:38 <Jason_at_intel> is this planned for after 1.3? 16:59:00 <Jason_at_intel> 2.0? 16:59:01 <garyo> It seems to be coming together. I'd be OK stuffing it into 1.3 if I can get the time to turn a few strings into lists. 16:59:15 <garyo> Bill, what do you think? 17:00:17 <bdbaddog> how long til u think it'd be ready? 17:00:23 <garyo> I kind of would like to get it in early so people on weird OSes will say "hey, what about FooOS where it should be in /xyz/foo?" 17:00:37 <garyo> I could do it in a (long) night, really. 17:00:45 <garyo> Testing would take longer. 17:01:19 <garyo> The Windows dir-searching stuff is most of the work, but there's some code in the SEP already... 17:01:35 <bdbaddog> URL? 17:01:53 <garyo> MoreSiteSConsDirs in the wiki. 17:02:14 <Jason_at_intel> on the discussion page of this area is code for it 17:02:19 <garyo> (sorry, typing on one machine w/ spreadsheet etc. open in the other one, it's confusing) 17:02:32 <garyo> yes, Jason contributed a bunch of it. 17:02:09 * GregNoel is no longer marked as being away 17:02:49 <GregNoel> Hey, ho 17:03:06 <Jason_at_intel> Hi Greg! 17:03:42 <GregNoel> I'm a little under the weather; please excuse any slow typing tonight. 17:03:06 <garyo> btw, speaking of the wiki, you're all supposed to subscribe to the BugParty page so you get an email when it gets updated. Hi Greg! 17:03:38 <garyo> Shall we get going? We clearly have a quorum. 17:03:52 <GregNoel> yes, start 17:03:59 <garyo> Jason, Bill, Gary, Greg, who'd I miss? 17:04:14 <bdbaddog> o.k. I'm subscribed to the page now. 17:04:19 <garyo> thx 17:04:21 <bdbaddog> Didn't know u could do that.. doh.. 17:04:25 <Jason_at_intel> same.. 17:04:31 * cdavid (i=82360a48Gateway/web/freenode/x-6ed6991a2ed30d5c) has joined #scons 17:04:34 <garyo> cool. 17:04:48 <garyo> Shall we dive into the bugs? It's been almost 3 months. 17:04:48 <GregNoel> 2427 17:04:51 <Jason_at_intel> Hi David! 17:04:57 <cdavid> Hi everyone 17:05:04 <cdavid> hope I am on time 17:05:05 <garyo> Hi David. 17:05:06 <bdbaddog> 4 time zones now represented :) 17:05:15 <garyo> :-) 17:05:29 <Jason_at_intel> 5 people? 17:05:45 <bdbaddog> btw. Heard from Steven - He wasn't sure if he'd make it tonight, but said not to wait for him on any decision. 17:05:55 <GregNoel> 2427, we agreed to document it, but didn't decide when 17:06:07 <bdbaddog> anytime? 17:06:08 <garyo> So let's doc 2427 ASAP. 17:06:12 <garyo> sure, anytime. 17:06:29 <GregNoel> OK, who? and priority? 17:06:44 <bdbaddog> I'll take it. 17:06:48 <garyo> thanks! 17:06:52 <GregNoel> priority? 17:07:03 <garyo> p3? 17:07:09 <GregNoel> worksforme 17:07:31 <GregNoel> 2443 17:08:25 <bdbaddog> is this taskman stuff? 17:08:31 <garyo> we looked at this last time. I thought line 699 of was a bug, Greg thought it was OK. 17:08:56 <GregNoel> No, Steven thought it was OK. 17:09:02 <garyo> (ok, sorry) 17:09:33 <GregNoel> There are two subst_list()s in different places. 17:09:14 <garyo> I say too late for 1.3, but p1 or p2 for 2.0. 17:09:21 <garyo> Steven or me. 17:09:24 <Jason_at_intel> honestly in Part i use action in Aliases a bit.. would break if they did not work 17:10:21 <GregNoel> 2.0 p2/3 garyo since Steven is so busy 17:10:25 <garyo> well his TypeError is coming from somewhere. Anyway, we can figure it out when we fix it, but it's clear there's some case that doesn't work. 17:10:29 <garyo> OK w/ me. 17:10:35 <bdbaddog> +1 17:10:48 <GregNoel> done 17:10:52 <GregNoel> 2444 17:11:11 <garyo> anytime, p4? 17:11:18 <GregNoel> ok, who? 17:12:01 <bdbaddog> I'll take it. Got one doc bug, another won't be much more pain. 17:12:06 <GregNoel> done 17:12:11 <GregNoel> 2445 17:12:44 <garyo> bug's invalid, but left there for python minversion discussion, right? 17:12:57 <GregNoel> I've fixed a couple and I have one queued up. 17:13:10 <bdbaddog> yes. So let's stick logic in to check 1.5.2 < current version < 3.0 ? 17:13:28 <garyo> That sounds simple enough. 17:13:44 <GregNoel> Er, 2.4 < ver < 3.0 17:13:47 <bdbaddog> we have the deprecation and such logic there already so shouldnt' be too bad. go ahead an assign to me. 17:13:59 <bdbaddog> for 1.3 , 1.5.2 < curr < 3.0, for 2.0 as you said. 17:14:17 <GregNoel> 1.3 p(what?) 17:14:29 <garyo> Yes. Bill, you have time to stick that check in soonish? 17:14:35 <bdbaddog> yes. 17:14:43 <garyo> +1 17:14:58 <GregNoel> p2 then? or p1? 17:15:04 <garyo> p2 17:15:07 <bdbaddog> plus 2.0 might take a bit to get out and 3.0, 3.1 will become more common. 17:15:11 <bdbaddog> p1. 17:15:18 <garyo> your call. 17:15:26 <GregNoel> p1, done 17:15:28 * jesterKing is now known as amino 17:15:35 <GregNoel> 2446 17:16:07 <GregNoel> only two comments; skip 17:16:12 <GregNoel> 2447 17:16:23 <GregNoel> only two comments; skip 17:16:35 <GregNoel> 2448 17:17:06 <bdbaddog> 2.x ? 17:17:07 <garyo> 3.x p3 unless Ken has a patch. 17:17:21 <bdbaddog> 3.x is fine. we could pull in if a patch appears. 17:17:24 <GregNoel> agree w/ gary 17:17:25 <garyo> (Bill, I'd love to have it earlier, but who would do it?) 17:17:54 <bdbaddog> I'm fine with 3.x 17:17:47 <GregNoel> I'll put ken on it; anybody want CC? 17:18:05 <bdbaddog> CC ? 17:18:10 <bdbaddog> cc on the bug? 17:18:15 <GregNoel> yes 17:18:24 <Jason_at_intel> yes 17:18:29 <bdbaddog> yes 17:18:39 <GregNoel> done 17:18:45 <GregNoel> 1449 17:18:56 <garyo> 2449 :-) 17:19:11 <GregNoel> oops, yes 17:19:13 <cdavid> can we use subprocess ? I am a bit confused by the version requirements of scons 17:19:30 <bdbaddog> 1.5.2 < current version < 3.0 for 1.3 17:19:35 <Jason_at_intel> 2.4 subprocess should be good 17:19:41 <bdbaddog> 2.4 < current version < 3.0 for 2.0 17:19:42 <cdavid> so we cannot use subprocess ? 17:19:46 <cdavid> for 1.3 17:19:47 <bdbaddog> nope. not for 1.3 17:19:48 <Jason_at_intel> plus we can remove the open() hack on teh win32 platform 17:19:49 <GregNoel> Subprocess is not the issue; we already have a backward-compatible version we're using now. 17:19:55 <Jason_at_intel> fixes issues on win7 17:19:59 <garyo> but we start working on 2.0 as soon as 1.3 is out the door 17:20:13 <bdbaddog> yes. 2.0/2.x for 2449 17:20:44 <GregNoel> not 2.0; that's only bug fixes and removing backward compatibility. 17:21:02 <bdbaddog> isn't this a bug fix? 17:21:15 <Jason_at_intel> agree 17:21:16 <GregNoel> No, it's an issue 17:22:23 <GregNoel> I should have said trivial bug fixes, as in fixes to documentation. 17:21:36 <Jason_at_intel> is it not.. since you have a subprocess copy in SCons 17:21:36 <garyo> I'd like to put as little into 2.0 as we can and just break back compat, then start on new stuff to build on that base. 17:21:39 <GregNoel> Yes, that's the intent. 17:21:40 <bdbaddog> -j sometimes breaks on windows seems like a bug. 17:21:51 <Jason_at_intel> I woudl think we would rather use the Scons version if we could 17:21:53 <bdbaddog> how hard to swap to subprocess ? 17:22:10 <bdbaddog> 2.1 then? 17:22:11 <Jason_at_intel> it easy.. it the SPAWN functions 17:23:04 <GregNoel> If it were that easy, we'd have done it already. It's not. 17:22:51 <bdbaddog> lets mark it 2.x, and hold on the waht goes into 2.0 discussion? 17:23:22 <Jason_at_intel> no.. you have not moved to Python 2.4 as a base requiremnet 17:23:27 <bdbaddog> I though we were precluded because of 1.5.2 compat requirement 17:23:31 <Jason_at_intel> in Parts we require 2.5 or better 17:23:51 <Jason_at_intel> we use Subprocess via replacing SPAWN with our version 17:23:51 <bdbaddog> Let's mark it 2.x and move on? 17:24:03 <bdbaddog> we can pull it in if it's easy. 17:24:04 <Jason_at_intel> it works great.. we even colorize output now 17:24:20 <GregNoel> Seeing no consensus, consider next time 17:24:34 <Jason_at_intel> wait till 2.0 .. it will not hurt 17:24:49 <garyo> Greg, let's mark it 2.x and move on. 17:24:58 <bdbaddog> +1 2.x 17:25:07 <GregNoel> garyo, what priority? 17:25:16 <bdbaddog> p2 17:25:16 <garyo> p1 or p2, it's big. 17:25:19 <bdbaddog> p1 17:25:20 <garyo> ok, p2 17:25:23 <bdbaddog> p2 17:25:25 <garyo> ok, p1 17:25:29 <garyo> :-) 17:25:36 <bdbaddog> ok p1. 17:25:40 <GregNoel> p1 is for emergencies; p2 17:25:44 <bdbaddog> p2 17:25:46 <garyo> fine 17:25:49 <bdbaddog> fine 17:26:07 <GregNoel> who? 17:26:17 <garyo> Jason, could you try it? 17:26:17 <bdbaddog> Jason? 17:26:30 <GregNoel> or make it part of the 2.x discussion? 17:26:36 <Jason_at_intel> is this 2449 17:26:42 <bdbaddog> yup 17:26:45 <cdavid> I could also look at it - I think I have tried using subprocess in scons 17:26:49 <Jason_at_intel> I can give you a patch 17:27:01 <cdavid> and I use -j option quite a bit on windows nowadays 17:27:04 <garyo> ok, David w/ jason as cc? 17:27:14 <GregNoel> yes, sounds good 17:27:18 <bdbaddog> +1 17:27:19 <GregNoel> done 17:27:26 <GregNoel> 2450 17:28:05 <garyo> I like this one. 17:28:31 <garyo> I think we should just put it in in 2.x. I'll do it. 17:28:36 <bdbaddog> +1 17:28:41 <GregNoel> I think it's badly entangled with 2446 and 2447, but if you want it, go for it. 17:28:45 <GregNoel> what priority? 17:28:49 * stevenknight ( has joined #scons 17:28:52 <garyo> I don't think it's that tangled. 17:28:54 <bdbaddog> p3 or p4 ? 17:28:58 <garyo> Hi Steven!!! 17:29:02 <Jason_at_intel> Hi steve 17:29:06 <stevenknight> hey guys 17:29:11 <garyo> How are you? 17:29:15 <GregNoel> Steven, we're considering 2450 17:29:17 <Jason_at_intel> long time no see! 17:29:19 <stevenknight> been better 17:29:22 <stevenknight> yeah 17:29:29 <stevenknight> sick kid and a sick laptop today 17:29:35 <garyo> :( 17:29:47 <bdbaddog> hmm. laptop got H1n1 ? 17:30:35 <stevenknight> bdbaddog: maybe, google remote tech support was stymied 17:30:43 <stevenknight> let me get caught up with you all 17:30:52 <stevenknight> (don't wait, though) 17:31:16 <cdavid> hi steven 17:29:01 <garyo> p3's fine. 17:30:15 <GregNoel> what priority? 17:30:21 <GregNoel> p3? 17:30:24 <garyo> 2450? p3. 17:30:28 <Jason_at_intel> p3? 17:30:26 <GregNoel> done 17:30:35 <GregNoel> 2451 17:31:23 <GregNoel> Gary, you're the expert on this one 17:31:18 <Jason_at_intel> so Gary did you think this was doable in 1.3 17:31:28 <Jason_at_intel> at least an early drop of it? 17:31:35 <garyo> so 2451: I'll try to put in the new site_scons dirs for 1.3, that'll help. The rest is toolchain related. 17:32:04 <GregNoel> Uh, I'd resist 1.3; already too delayed. 17:32:07 <garyo> I guess I don't feel that strongly about the module/package thing. 17:32:37 <garyo> How about if I try to get it into 1.3, given a late night, but don't hold 1.3 for it. 17:32:47 <bdbaddog> so "anytime" 17:32:54 <Jason_at_intel> good for me 17:32:57 <garyo> I guess that's right. 17:33:04 <bdbaddog> +1 17:33:16 <stevenknight> hey cdavid 17:33:19 <GregNoel> I don't like possibly destabilizing 1.3; 2.1? 17:33:31 <garyo> We 17:33:35 <garyo> (sorry) 17:34:02 <GregNoel> (and here I thought you were talking about my new Wii) 17:34:01 <bdbaddog> anytime pending code review into 1.3? otherwise 2.1? 17:34:03 <garyo> If we do another drop with David's code, I can put it into that. If it causes any issues, I'll back it out for 1.3. OK? 17:34:09 <stevenknight> at this point, i'd think 1.3 should be cut to bare minimum 17:34:38 <GregNoel> concur with stevenknight 17:34:14 <cdavid> what are the big things for 1.3 ? Just releasing what's out there in the trunk ? 17:34:20 <cdavid> I mean the goal of 1.3.0 ? 17:34:30 <garyo> msvc! 17:34:36 <bdbaddog> let's punt til 5:50 for 1.3 discussion? 17:34:37 <cdavid> ok 17:35:03 <garyo> OK, I'll hold back on the site_scons stuff. No prob. 17:35:14 <Jason_at_intel> 2.x then 17:35:30 <garyo> Yes, probably early like 2.1. 17:35:32 <GregNoel> consensus? 2.1? what priority? 17:35:37 <bdbaddog> 2.1 p3 ? 17:35:40 <garyo> p3 17:35:44 <stevenknight> 2.1 p3 17:35:44 <GregNoel> done 17:36:00 <GregNoel> 2452 17:36:38 <bdbaddog> future p1 for 2452 17:36:50 <cdavid> if 2.0 should only do backward incompatible changes, this would be 3.x ? 17:37:10 <bdbaddog> there's 2.x 17:37:17 <bdbaddog> and 2.1 17:37:23 <GregNoel> I'd like to assign Ludwig, but suggest very strongly that he work with Ken, since they have complementary insights on this 17:37:24 <garyo> right. 17:37:34 <bdbaddog> +1 17:37:38 <garyo> +1 17:37:52 <stevenknight> +1 and I'll raise another +1 17:38:06 <Jason_at_intel> so when is 3.x? 17:38:07 <GregNoel> Not 3.x; it's all internal, no user API affected 17:38:29 <Jason_at_intel> I agree with that 17:38:42 <Jason_at_intel> seen like a 2.x thing 17:38:46 <bdbaddog> so 2.x then or future? depends when we have a solution. 17:38:56 <bdbaddog> +1 2.x p1 17:39:03 <Jason_at_intel> +1 17:39:07 <stevenknight> 2.x p1 17:39:08 <GregNoel> 2198 already has a patch, but I want Ken to refine it. 17:39:31 <garyo> ok, maybe he can roll them all together. 17:39:39 <GregNoel> 2.x p2, it's not an emergency 17:39:48 <garyo> agreed. 17:40:11 <stevenknight> good point 17:39:49 <bdbaddog> +1 p2 17:40:15 <GregNoel> done 17:40:23 <GregNoel> 2453 17:40:40 <bdbaddog> 2.x p3 17:40:54 <garyo> ok w/ me 17:41:11 <garyo> Ludwig/Ken or Ken/Ludwig :-/ 17:41:37 <GregNoel> Ludwig/Ken; I have confidence that Ludwig will close it. 17:42:10 <GregNoel> No other objections? Done 2.x p3 Ludwig 17:42:16 <GregNoel> 2454 17:42:32 <garyo> Ken should just do this. It's easy. 17:42:42 <garyo> "Please submit a patch." 17:42:47 <GregNoel> Same stuff, same comments from me 17:42:55 <bdbaddog> 2.x p3 then? 17:42:59 <garyo> 2.x p3 Ken? 17:43:07 <stevenknight> sounds good 17:43:09 <GregNoel> I'd go with Ludwig 17:43:15 <garyo> (at least Ken to submit the patch?) 17:43:22 <GregNoel> I'll buy that 17:43:31 <bdbaddog> +1 17:43:34 <stevenknight> +1 17:43:37 <GregNoel> done 17:43:43 <GregNoel> 2455 17:44:13 <GregNoel> Looks like consensus research garyo 17:44:18 <GregNoel> what priority? 17:44:20 <garyo> OK. 17:44:28 <garyo> p3 or p4 17:44:38 <bdbaddog> p4 17:44:40 <cdavid> this would better be done at the same time as fixing configure IMO 17:44:41 <stevenknight> p4 if either is ok 17:44:51 <GregNoel> p4 17:44:52 <GregNoel> done 17:44:59 <GregNoel> 2455 17:45:01 <garyo> cdavid: what other configure fixes are related? 17:45:54 <cdavid> configure does not use the same process as normal scons, so everytime you change your configure context, scons is confused 17:45:54 <garyo> anyway I think this particular issue is easily solved. 17:46:26 <stevenknight> cdavid: agree, but that'll take a while to fix 17:46:39 <bdbaddog> so research, garyo, p4 ? 17:46:44 <garyo> cdavid: it's true, configure is a bit "unusual" in how it interacts w/ scons. But I can fix 2455 in limited time, fixing configure is... harder. 17:46:44 <GregNoel> I agree with cdavid that fixing configure would fix this, but it needs to be solved sooner. 17:46:56 <stevenknight> research garyo p4 17:46:57 <cdavid> yes, it will take time, but fixing confdefs without fixing configure seems wasteful 17:46:57 <garyo> bdbaddog: +1 17:47:25 <garyo> cdavid: nah, it's just a missing string assignment somewhere or something like that. 17:47:44 <garyo> It's not like configure isn't useful as it is, a lot of people use it. 17:47:48 <GregNoel> p4 17:48:04 <cdavid> ah, sorry, I thought it required adding a new arg to CheckHeader, I was confused by the different use cases on the wiki 17:48:37 <garyo> cdavid: that's the weird part; all the HAVE_XXX logic is all in there. It just never gets out properly. 17:48:05 <garyo> 2456: done. 17:48:11 <stevenknight> 2457 17:48:24 <bdbaddog> 2.x p3, me 17:48:38 <stevenknight> I like russel's suggestion, make it qt3 with qt as a backwards compatible alias? 17:48:52 <bdbaddog> +1 alias, with deprecation notice? 17:48:58 <stevenknight> yeah 17:49:03 <GregNoel> concur 17:49:02 <bdbaddog> most all new qt work will be qt4 17:49:39 <bdbaddog> I'm hoping qt40,41,42,43,45 won't be necessary 17:49:42 <GregNoel> 2.x p3 bdbaddog? 17:49:46 <bdbaddog> +1 17:49:51 <stevenknight> done 17:49:56 <GregNoel> done 17:50:06 <GregNoel> 2458 17:50:34 <garyo> invalid. 17:50:55 <garyo> can say: "sorry, we can't change it at this point." 17:50:58 <GregNoel> invalid 17:51:07 <bdbaddog> invalid, though once we rationalize tools/platofrms.. we might be able to handle better. 17:51:07 <stevenknight> i can live with that 17:51:11 <GregNoel> "and wait for new configure" 17:51:18 <Jason_at_intel> these can be overridden 17:51:26 <stevenknight> note added to doc, though? 17:51:40 <stevenknight> seems like potentially a common enough stumbling point 17:51:50 <garyo> not a bad idea. 17:51:45 <GregNoel> who, when? 17:51:59 <garyo> Bill, since you're doc guy today... ? 17:52:06 <bdbaddog> +1 doc, all we have to say is add -fwin32 for win32 right? 17:52:16 <stevenknight> believe so 17:52:13 <bdbaddog> yup. sign me up. 17:52:16 <GregNoel> could be 1.3 or 2.0 17:52:22 <GregNoel> if it's only doc 17:52:25 <bdbaddog> so anytime. 17:52:35 <bdbaddog> so anytime, p3, Bill 17:52:39 <GregNoel> done 17:53:01 <bdbaddog> how much more time does everyone have? 17:53:17 <garyo> I don't have to go anytime soon. 17:53:17 <bdbaddog> wanted to talke for 10 minutes about 1.3 before we all head off. 17:53:23 <Jason_at_intel> I am good 17:53:41 <GregNoel> I've got maybe 30 more minutes 17:53:57 <stevenknight> i'm okay for a while 17:53:58 <bdbaddog> ok. let's go mabye 10 more on bugs and then talke about 1.3 ? 17:54:00 <garyo> ok, let's stop at 10 after and talk about 1.3 17:54:02 <GregNoel> I'd like to finish these if possible 17:54:03 <bdbaddog> +1 17:54:13 <stevenknight> (positive side to laptop dying: i can't do any day-job work... :-)) 17:54:16 <cdavid> fine by me 17:52:51 <GregNoel> 2459 17:52:59 <garyo> invalid, imho. 17:53:24 <GregNoel> invalid 17:53:37 <bdbaddog> +1 invalid 17:54:58 <Jason_at_intel> 2459 seem invalid to me 17:53:53 <GregNoel> done 17:54:55 <GregNoel> 2460 17:55:30 <bdbaddog> 2460, 2.x, who, p2 ? 17:56:06 <Jason_at_intel> I agree that i would rather have Depends work with Alias.. not alias another alias 17:56:35 <garyo> Sure, Depends should work, but this kind of stuff can get complicated. If Steven could do it... 17:56:39 <Jason_at_intel> this seems to be a node issue.. who does the node code? 17:57:37 <garyo> I think it'd have to be Steven, or else 3.x when someone else may have time/knowledge. 17:57:45 <GregNoel> concur 17:57:50 <garyo> So that's why I said 3.x p3. 17:57:52 <Jason_at_intel> +1 17:57:56 <bdbaddog> +1 17:58:04 <stevenknight> go ahead and put my name on it 17:58:03 <GregNoel> done 17:58:32 <stevenknight> i'm going to go through my issues and re-prioritize, give back ones that others can do 17:59:04 <garyo> steven: ok, make a list of what needs to be re-triaged. 17:59:18 <stevenknight> garyo: will do 17:58:32 <bdbaddog> 2461, invalide 17:58:32 <garyo> 2461 looks invalid. 17:58:37 <GregNoel> done 17:59:07 <GregNoel> 2462 17:59:18 <cdavid> I can reproduce 2462 17:59:45 <cdavid> but in a big project only - I can try to make a small reproducible script to track it down 17:59:29 <bdbaddog> 2.1,p1, who? 17:59:49 <garyo> cdavid: me too. I'll take it, I fixed another one like it once. 17:59:54 <cdavid> ok 18:00:02 <Jason_at_intel> I have not seen this yet 18:00:23 <garyo> Happens when you rename or delete things and the .sconsign has a ref to them, typically. 18:00:36 <garyo> ... and if Glob is involved it's more likely. 18:00:52 <Jason_at_intel> ahh we don't use GLob 18:00:34 <GregNoel> garyo with cdavid as CC? 2.1, p1 18:00:38 <GregNoel> er, p2 18:00:44 <garyo> p2, thanks. 18:00:50 <cdavid> fine by me 18:00:51 <bdbaddog> 2.1, p2, garyo ? 18:01:00 <Jason_at_intel> +1 18:01:01 <GregNoel> done 18:01:08 <GregNoel> 2463 18:01:27 <bdbaddog> 2.x, garyo, p3 ? 18:01:29 <garyo> I'll remove it in 2.x (or even 2.1). 18:01:31 <GregNoel> 2.x p3 garyo 18:01:51 <GregNoel> do you want 2.1 or 2.x? 18:02:09 <garyo> 2.1. 18:02:11 <GregNoel> done 18:02:20 <GregNoel> 2465 18:02:37 <bdbaddog> 1.3,me, p2 or p3 18:02:50 <garyo> I'm ok w/ 1.3 since it's only 18:03:00 <GregNoel> OK, done 18:03:14 <garyo> woo hoo! 18:03:21 <GregNoel> and now for the 1.3 discussion... 18:03:28 <bdbaddog> :D 18:03:40 <bdbaddog> o.k. what's left? how much msvc stuff? 18:04:04 <garyo> I think we should seriously consider David's simplifications. 18:04:04 <Jason_at_intel> what are the issues? 18:04:05 <cdavid> there is the "how to deal with error" stuff 18:04:13 <Jason_at_intel> 1)cross build 18:04:17 <Jason_at_intel> 2) SDK? 18:04:18 <garyo> ... with a bit of error handling. 18:04:26 <garyo> Ah yes, SDK. 18:04:31 <cdavid> cross build works for me 18:04:40 <cdavid> SDK is much more difficult 18:04:48 <garyo> Cross build should work for me, but I have a test-machine issue. :-/ 18:04:55 <garyo> (w/ David's version) 18:05:02 <Jason_at_intel> I view SDK as have the users add it to tools they load 18:05:14 <garyo> +1, make users add it. 18:05:14 <Jason_at_intel> once we get toolchains then it will be easier 18:05:15 <cdavid> that would make the problem go away :) 18:05:28 <cdavid> ok, so don't handle sdk automatically 18:05:39 <Jason_at_intel> yes, let the user add it 18:05:42 <cdavid> what's the best way to print a user warning ? 18:05:44 <garyo> Does setting MSSDK_VERSION do it? 18:06:01 <Jason_at_intel> this way they can control is it add it stuff before or after the compiler lines 18:06:06 <cdavid> no, you would have to use the mssdk tool 18:06:25 <garyo> cdavid: oh yeah. That's fine. 18:06:26 <cdavid> so MSSDK_VERSION would control it, but you would have to explicitly load the mssdk tool 18:06:26 <Jason_at_intel> MSSDK_VERSION set which version you setup 18:06:46 <garyo> Needs to be documented 18:07:02 <cdavid> ah, I forgot about msvs 18:07:12 <cdavid> what's the need for MSVS_VERSION and MSVC_VERSION ? 18:07:14 <Jason_at_intel> so mssdk issue 18:07:19 <Jason_at_intel> agreeded? 18:07:23 <cdavid> agreed 18:07:26 <garyo> Jason: yes. 18:07:52 <cdavid> in the trunk, both vs and vc code look for a batch file 18:08:03 <cdavid> I don't know the rationale for this - I don't do it in the cleaned up branch 18:08:05 <garyo> cdavid: I always thought MSVS_VERSION was for making Visual Studio projects, but I don't really know. 18:08:06 <Jason_at_intel> so there was a talk that MSVS_VERSION is for teh project generation and the MSVC_VERSION is the compiler 18:08:27 <garyo> I'd be happy if we can make that true. 18:08:42 <cdavid> currently, my understanding is that MSVS_VERSION control devenv path 18:08:52 <garyo> ... which is what? 18:08:55 <garyo> IDE? 18:08:59 <cdavid> yes 18:09:07 <cdavid> you can build at the command line as well: 18:09:13 <cdavid> devenv foo.sln /build "Release" 18:09:22 <cdavid> which is my only use of the IDE, personally :) 18:09:24 <Jason_at_intel> that is a custom command 18:09:35 <garyo> got it. But still related to "solution generation", not compiler. 18:09:36 <cdavid> but this command is found by the msvc batch file 18:09:58 <garyo> ack 18:10:08 <Jason_at_intel> ?? 18:10:12 <cdavid> the problem is that currently, if MSVS and MVSC refer to different version, the environment is screwed up 18:10:13 <Jason_at_intel> found? 18:10:36 <cdavid> sorry, I meant if the msvc batch file is executed, devenv will be in the path 18:10:42 <garyo> cdavid: aha, that explains a lot. 18:10:54 <Jason_at_intel> yes that is true 18:11:11 <Jason_at_intel> even if you did what i have.. this would be true 18:11:21 <garyo> (like the SCONS_MSCOMMON_DEBUG trace I sent you earlier today) 18:11:25 <cdavid> the msvs project stuff requires any IDE stuff ? 18:11:34 <cdavid> or is it pure python code ? 18:11:40 <garyo> So what I'm hearing is MSVS_VERSION and MSVC_VERSION cannot realistically be different. 18:11:59 <garyo> at least how things are today. 18:12:05 <cdavid> it could if MSVS_VERSION would only control project generation, assuming project generation does not depend on any external tool 18:12:05 <Jason_at_intel> I think msvs is just python code 18:12:49 <garyo> So let's move in that general direction. 18:13:00 <Jason_at_intel> Steve.. do you have a better project generator for vs? 18:13:00 <cdavid> What about having a new variable to control the project generation, and deprecate MSVS_VERSION ? 18:13:00 <bdbaddog> but can we make the MSVS_VERSION change in 1.3? 18:13:11 <garyo> How about if we make sure that the msvs bat file doesn't get loaded by default? 18:13:27 <Jason_at_intel> I thought you said on the phone a long time ago that there was a native project generator in the works 18:13:57 <garyo> bdbaddog: maybe too short a time scale to do it all. 18:14:00 <Jason_at_intel> cdavid : agree 18:14:05 <cdavid> Gary Oberbrunner: yes, the msvs batch file would never be loaded, and if MSVS_VERSION is set by the user, we would print a warning (if MSVS_VERSION is set as well) 18:14:29 <garyo> How about for 1.3 we just say MSVC_VERSION and MSVS_VERSION should be the same. 18:14:38 <garyo> (or MSVS_VERSION unset) 18:14:57 <garyo> cdavid: +1 18:14:59 <cdavid> so the cases would be: 1: by default, do nothing, set MSVS_VERSION and MSVC_VERSION", 2: if MSVC_VERSION xor MSVC_VERSION set, set the tool to this version 3: if both are set and different, raise an error 18:15:01 <bdbaddog> SO if we take David's patch(s), and deprecate and ignore MSVS_VERSION in 1.3, are we far away from being done? 18:15:02 <Jason_at_intel> I think we want to migrate allow both.. but preffer MSVC_ 18:15:29 <Jason_at_intel> if both are set 18:15:38 <garyo> I like David's way. William Deegan: we just need error checking, which I have some of. 18:16:10 <cdavid> I think the main issue is testing 18:16:15 <garyo> David, I'll send you my error patch; can you do the MSVS_/MSVC_ stuff and update your git repo? Then we can all test. 18:16:19 <cdavid> yes 18:16:31 <cdavid> my changes are in the msvc_changes branch, BTW - master tracks the trunk 18:16:45 <garyo> cdavid: thanks, I'll check that. 18:16:51 <bdbaddog> o.k. can we put a matrix in the wiki which which combos of host/target's we can test with which VS & VC versions? 18:17:14 <cdavid> I think Jason started something in that direction, right ? 18:17:25 <garyo> Jason, don't you have some VMs? 18:17:26 <cdavid> which page, I don't remember 18:17:41 <Jason_at_intel> I need to put it online.. and it was for Parts work with the new tool chain stuff 18:17:51 <cdavid> I have a xp 64 vm with VS 2008, a xp32 vm with 2010, and a windows 7 vm with 2008 18:18:09 <bdbaddog> so we have no 2003, 2005, or vs6 ? 18:18:17 <Jason_at_intel> so it does not test the Scons version of the tools 18:18:18 <cdavid> I have VS 2003 somewhere 18:18:24 <garyo> I have VS 2003 & 2005 on the same machine, and some other stuff. Maybe an old vs6 machine or vm. 18:18:31 <cdavid> vs 6 is harder 18:18:35 <Jason_at_intel> I have vc6 -2008 18:18:52 <bdbaddog> can any of these be setup as buildbot slaves? ;) 18:19:03 <cdavid> not in my case, as it is on my laptop 18:19:03 <garyo> The tests have to be run manually though, for now. 18:19:25 <garyo> Mine are "corporate" and I don't think I can put buildbot on them. 18:19:26 <cdavid> you can automatically get the tarballs from github, at least 18:19:33 <Jason_at_intel> I was going to setup a bug for you .. but am having time issues with work processes in our build, and there is a security concern the IT has that I ahve to fix 18:19:36 <stevenknight> (bdbaddog: speaking of buildbot, master's down. i logged in to the system, any reason not to restart master?) 18:19:48 <Jason_at_intel> mean time i can test manually and report out 18:20:04 <bdbaddog> (steve: no reason not to restart, need to figure out why it's not restarting at reboot) 18:20:07 <garyo> Jason, you saw David's testcase hello.c/SConstruct, right? 18:20:23 <Jason_at_intel> nope 18:20:31 <garyo> I'll forward it to you. 18:20:34 <Jason_at_intel> ok 18:21:07 <Jason_at_intel> run it and give you the outputs? 18:21:10 <garyo> OK, so once that's all squared away, we put out another ckpoint? 18:21:16 <bdbaddog> yes. 18:21:16 <garyo> Jason: it'll be obvious. 18:21:19 <cdavid> yes 18:21:22 <Jason_at_intel> ok 18:21:26 <bdbaddog> then 2 weeks then 1.3 18:21:28 <Jason_at_intel> will wait to get it and see then 18:21:35 <cdavid> I will clean up a few things in the branch, normalize MSVC/MSVS 18:21:39 <cdavid> for the warnings ? 18:21:50 <cdavid> I try to use scons warnings but could not get them to pring 18:21:56 <cdavid> using SCons.warning 18:21:58 <garyo> I'll send you what I have which deals with missing cross-architectures 18:22:20 <garyo> but I use SCons.Error for a manually-specified missing TARGET_ARCH. 18:22:45 <garyo> Warnings don't print unless they're enabled by default somewhere. 18:22:50 <garyo> SCons.Warnings or something? 18:22:51 <Jason_at_intel> you mean bad TARGET_ARCH? 18:23:17 <garyo> Jason: uninstalled TARGET_ARCH, like I don't have the x86-64 compiler installed on my VS2003 machine. 18:23:39 <Jason_at_intel> ahh tool setup combo that can 't be done 18:23:46 <garyo> one other thing, there's a nice in mscommon, but I don't think it's used. 18:23:57 <Jason_at_intel> I do the same I think i have a toolset error based on Scons UserError 18:24:01 <garyo> (hm, maybe I was looking on trunk though.) 18:24:13 <garyo> Jason: right. 18:24:22 <cdavid> I have changed 18:24:29 <cdavid> using dict instead of objects 18:24:37 <Jason_at_intel> I thought arch was moved to Platform? 18:25:00 <cdavid> the best would be to push this in a more general manner for cross compilation on any platform 18:25:02 <garyo> ok. 18:25:13 <stevenknight> cdavid: Script/ has the list of warnings enabled by default 18:25:16 <cdavid> but currently, I don't see this happening with the current tool infrastructure 18:25:17 <bdbaddog> agreed, but let's minimize the changes for 1.3 18:25:41 <cdavid> so we can keep the arch values in the MS tools subdirectory for now ? 18:25:53 <garyo> David Moreno: right, impossible in limited time. 18:26:05 <Jason_at_intel> cdavid: have you seen what i did in Parts for this? based on current tool stuff? 18:26:27 <Jason_at_intel> it may not be that hard in reality 18:26:27 <cdavid> jason: I have started looking at the doc, but did not have the time to really go deep down 18:26:47 <Jason_at_intel> if you get time and have question/thought let me know 18:26:55 <GregNoel> (Got to go; dinner imminent. Since I don't seem to be contributing here, you shouldn't miss me. {;-} I'll read through what I missed later.) 18:26:58 <cdavid> steven: thanks, I will look there 18:27:32 <cdavid> I think I will send an email on the dev ML once I have done everything we have discussed, and maybe integrating gary's fixes 18:27:33 <Jason_at_intel> ok so for 1.3 18:28:17 <bdbaddog> guestimate on timeline? 18:28:35 <cdavid> I will do all the fixes discussed now within today 18:28:37 <garyo> it'll take a couple of days to test, I'll get my stuff to David tomorrow 18:28:43 <cdavid> so tomorrow for people in the US 18:28:43 <Jason_at_intel> 1) SDK - fixed 18:28:45 <Jason_at_intel> 2) testing needed .. but we think it is about there 18:28:46 <Jason_at_intel> 3)MSVC_ MSVS_ do what David suggests 18:28:48 <Jason_at_intel> 4) TARGET_ARCH?? 18:28:56 <cdavid> it is done 18:28:58 <garyo> TARGET_ARCH is working now. 18:29:01 <cdavid> I mean TARGET_ARCH is working 18:29:25 <cdavid> TARGET_HOST/TARGET_ARCH works for all combinations x86/amd64 with VS 2008 18:29:32 <Jason_at_intel> so then 2) is all that is needed? and a fix to make 3) happen 18:29:36 <bdbaddog> should I push a new checkpoint asap since we keep getting complains about x64, and then another when these changes are done? 18:29:42 <Jason_at_intel> what about ia64 18:29:44 <cdavid> I have no support for itanium, though 18:30:04 <garyo> William Deegan: no, I think we're close, just wait til Thursday or Friday if that's OK w/ you. 18:30:07 <Jason_at_intel> ok not a big deal .. I have it for my stuff 18:30:09 <cdavid> bdbaddog: would next monday be good for a ck ? 18:30:15 <bdbaddog> sure. 18:30:17 <garyo> +1 18:30:28 <cdavid> The pb with itanium is that I cannot test it in any way 18:30:38 <cdavid> vmware does not support itanium :) 18:30:46 <Jason_at_intel> you can only test cross build for ia64 18:31:02 <garyo> ... but you can't run the result. 18:31:04 <cdavid> I can test it runs, not that it produces the right binary 18:31:18 <Jason_at_intel> with out a ia64 window system native case is hard to test .. I know .. 18:31:36 <cdavid> I wonder if wine supports ia - I guess not 18:31:37 <Jason_at_intel> agree... can test the runs 18:31:44 <Jason_at_intel> can't test :-) 18:31:53 <cdavid> wine can runs 64 bits command line binaries, now 18:31:58 <bdbaddog> I think it's a very small percentage of users using IA64. 18:32:07 <Jason_at_intel> well I would not want to emulate ia64 18:32:09 <garyo> OK, sounds like a plan. fix/test ASAP, checkpoint, then 2 wks to 1.3. 18:32:11 <bdbaddog> lets assume compiling is fine, and wait for bugs to prove otherwise.. 18:32:13 <Jason_at_intel> ya very small 18:32:17 <Jason_at_intel> mostly cluster people 18:32:24 <bdbaddog> k. 18:32:34 <bdbaddog> I"m going to turn into a pumpkin in 5. 18:32:47 <garyo> send pix. 18:32:53 <stevenknight> this all sounds quite good 18:32:57 <bdbaddog> o.k. so I guess updates as to what progress on dev mailing list? 18:33:03 <cdavid> so gary, can you send me the patches ? 18:33:22 <garyo> yes, we'll all keep in touch. cdavid: tomorrow AM I hope. I have the right branch now :-) 18:33:51 <Jason_at_intel> I will update from trunk and run the Sconstruct from gary ( the one david made) and report out to you guys 18:34:06 <cdavid> Jason: the changes are in a git branch, not in svn for now 18:34:23 <Jason_at_intel> hmm does git work on windows? 18:34:24 <garyo> Jason: it's not on trunk, only David's git repo, and msvc_fixes branch in there. 18:34:39 <garyo> git works fine on Windows. Use msys git. 18:34:45 <bdbaddog> or cygwin git. 18:34:46 <Jason_at_intel> does git support a proxy servers? 18:34:47 <bdbaddog> ;) 18:34:51 <garyo> msys is better these days. 18:34:54 <bdbaddog> ahh. 18:34:57 <cdavid> yes, but throught http 18:35:03 <cdavid> better 18:35:05 <garyo> git can work via http or ssh. 18:35:07 <bdbaddog> o.k. I"m gone. Thanks to all! 18:35:08 <garyo> (or native) 18:35:13 <garyo> bye Bill! 18:35:17 <cdavid> I am removing some old stuff in github, and you can just grab a tarball 18:35:17 <bdbaddog> l8r 18:35:21 <Jason_at_intel> ok .. gary can you give me the link 18:35:23 <cdavid> bye Bill 18:35:28 * bdbaddog has quit ("ChatZilla 0.9.85 [Firefox 3.5.4/20091016081620]") 18:35:29 <Jason_at_intel> in teh e-mail you will give me 18:35:33 <garyo> Will do, Jason. 18:35:36 <Jason_at_intel> thanks 18:36:03 <garyo> OK, thanks all! Good night. 18:36:11 <Jason_at_intel> night! 18:36:17 <stevenknight> great work guys, good night 18:36:26 <cdavid> 18:36:34 <Jason_at_intel> oh one question 18:36:38 <garyo> ? 18:36:43 <Jason_at_intel> subst() 18:36:53 <Jason_at_intel> any idea when this will be addressed? 18:37:03 <Jason_at_intel> I am 90% sure this is why SCons is slow 18:37:06 <stevenknight> what part of it? how generally grungy it is? 18:37:07 <garyo> speed? functionality? quoting? 18:37:19 <Jason_at_intel> speed 18:37:29 <stevenknight> Jason_at_intel: re: 90%: kind of 18:37:42 <cdavid> Nodes are a big reason as well 18:37:48 <stevenknight> it's slow, but there are also algorithmic inefficiencies 18:37:57 <cdavid> depends on the projects, though 18:37:59 <stevenknight> we do a lot of string re-expansion multiple times 18:38:00 <Jason_at_intel> well there might be a node issues as well with speed 18:38:16 <Jason_at_intel> so the simple test is this 18:38:32 <cdavid> nodes cause memory pb and too many function calls, which are very slow in python 18:38:46 <Jason_at_intel> take 6000 node ( like read all the headers in Boost) and install them to a directory 18:38:52 <Jason_at_intel> take about 8 seconds 18:39:09 <Jason_at_intel> to process the env.Install() 18:39:16 <stevenknight> i have a half-finished prototype of a subst rewrite that uses the same general technique as the python string.Template class 18:39:21 <stevenknight> seems faster, but not benchmarked 18:39:29 <Jason_at_intel> remove the subst() call in Arg2Node.... 1 second 18:39:51 <garyo> ! 18:39:59 <stevenknight> yow 18:40:28 <cdavid> and you lose nothing by not calling subsg in Arg2Node ? 18:41:13 <Jason_at_intel> the builder has to turn the strings into nodes 18:41:31 <Jason_at_intel> the node creation in Arg2Node does a subst of teh string value first 18:41:46 <garyo> In real life you do have to do a subst there, but if it could be super fast... 18:41:48 <Jason_at_intel> even if the string is fine.. nothing to do, this takes time 18:42:14 <stevenknight> or if we can avoid work if it doesn't need subst() 18:42:25 <stevenknight> subst() itself checks for '$' in the string and just returns 18:42:26 <stevenknight> but 18:42:47 <stevenknight> Jason_at_intel's pointing out there's a bunch of work in before we even call subst() 18:43:03 <stevenknight> i wonder how much time gets saved if we move the '$' check 18:43:24 <Jason_at_intel> ya there is a lot of work in env... but it does not seem to be the critical path 18:43:42 <Jason_at_intel> in fact to help with speed issues.. if we can get this Scons to work in iron python 18:43:59 <Jason_at_intel> I can give you very detailed data on what is the performance issues 18:44:18 <stevenknight> ? env isn't critical path? that's where arg2nodes() lives 18:44:20 <garyo> but wait, stay on topic. You remove the subst, it drops the time from 8 to 1 sec. 18:44:21 <Jason_at_intel> as I can use our tools on .net code.. 18:44:43 <garyo> So where's the time going if subst() shortcuts when there's no $? 18:44:44 <Jason_at_intel> ya... arg2node is a big fish.. not it slow because of subst 18:45:07 <stevenknight> ? okay, you're really confusing me 18:45:08 <garyo> OK, good -- figure out which part of arg2node is causing the slowdown. 18:45:21 <stevenknight> you say if you remove the subst() call from arg2nodes() you get an 87.5% speedup 18:45:31 <Jason_at_intel> So when i tested this for a few days it was teh subst 18:45:34 <stevenknight> then you tell me that arg2nodes() is not slow because of subst() 18:45:46 <stevenknight> which is it? 18:46:09 <Jason_at_intel> I made sure the string i had where fully subst'ed before arg2node 18:46:20 <cdavid> By everone - I will work on updating scons in the meantime 18:46:26 <Jason_at_intel> the simple find was that something in the subst call itself is slow 18:46:29 <stevenknight> so your speedup wasn't removing subst() from arg2nodes() 18:46:35 <stevenknight> ? 18:46:48 <Jason_at_intel> so yes.. i did three basic tests 18:46:55 <Jason_at_intel> 1) my base line 18:47:05 <Jason_at_intel> 2) with string fully substed 18:47:20 <Jason_at_intel> 3) with subst in arg2node commented out 18:47:42 <Jason_at_intel> 1) 2) 8,6 seconds 18:47:51 <Jason_at_intel> 3) 1 ish 18:48:59 <garyo> Well that's pretty clear. 18:49:01 <Jason_at_intel> I could not find anything else that seemed to have such a large effect on the read time of the SConstruct as of yet 18:49:32 <garyo> So it must be that subst() isn't just returning... or the strings are really long and just searching for the $ is costly? 18:49:41 <stevenknight> no, there are two layers to subst 18:49:50 <stevenknight> there's the env.subst() wrapper that does a bunch of set up 18:49:51 <Jason_at_intel> I have not looked to what in subst is teh issue.. everyone at work wants to me to fix the sdk feature in Parts and speed up the build by not tell SCons stuff 18:50:08 <stevenknight> and there's the Subst.scons_subst() function that does the heavy lifting 18:50:33 <stevenknight> the Subst.scons_subst() function will look for a '$' and return if everything's expanded 18:50:46 <stevenknight> but that's after the env.subst() wrapper has done a bunch of set up 18:50:53 <stevenknight> originally, that was a thin layer 18:50:57 <stevenknight> but it's grown over time 18:51:35 <stevenknight> based on what Jason_at_intel's found, I bet if we move the '$' check into the env.subst() wrapper we get a huge win 18:51:51 <Jason_at_intel> I can give it a try 18:52:18 <Jason_at_intel> even after that it would be nice to speed up subst as i use it a lot in Parts 18:52:24 <stevenknight> yeah 18:52:40 <Jason_at_intel> I would rather not have to add more code to do it before 18:52:49 <stevenknight> i think the prototype i half-finished is promising 18:53:00 <stevenknight> but when i stepped back and tried to redo things fresh 18:53:13 <stevenknight> the big hassle is actually subst_list() 18:53:34 <Jason_at_intel> so i will see about reporting out number in the next day with scons 1.2 and hacking up the env.subst to look for $ in the string first 18:53:52 <stevenknight> our current rules for when something does or doesn't get expanded into separate arguments in a list are really arbitrary 18:54:10 <stevenknight> cool 18:54:28 <Jason_at_intel> ya honestly in parts i have my own code for this 18:54:46 <Jason_at_intel> the subst and return a list logic was odd for me 18:54:52 <Jason_at_intel> code not figure it out 18:54:57 <stevenknight> "odd" is putting it kindly 18:55:22 <Jason_at_intel> well I am trying to be postive 18:55:25 <Jason_at_intel> :-) 18:55:37 <stevenknight> much appreciated... :-) 18:56:46 <Jason_at_intel> anyways the speed items for me seem to be fixable by having better subst calls, faster disks ( when scanning for files) and in our case of a large project not reading data to components that don't nee to be built 18:56:58 <Jason_at_intel> nee->need 18:57:42 <Jason_at_intel> I think the node code coudl be a little better in the creation for the global file list 18:58:00 <Jason_at_intel> but that does not seem to be a big fish in speed so far 18:58:26 <Jason_at_intel> we have about 100,000 source files being process and copied in our builds 18:58:45 <stevenknight> we need a performance-testing infrastructure in the buildbots 18:59:16 <stevenknight> something that makes it easy to add tests like your 6000 node config 18:59:20 <Jason_at_intel> the only issue after read stage i have seen is that the task master takes a longer time if one node is to be rebuilt 18:59:21 <stevenknight> time and graph the results 18:59:51 <Jason_at_intel> I will try to send you a test sample based on boost 19:00:19 <stevenknight> okay, i need to finish 19:00:23 <Jason_at_intel> ok 19:00:34 <stevenknight> i'll send you guys some off-line thoughts about some things 19:00:36 <stevenknight> 'night 19:00:45 <Jason_at_intel> well I will try to give out some data on msvc for gary and give you stuff about subst by end of week 19:01:00 <Jason_at_intel> later! 19:03:16 * Jason_at_intel has quit ("ChatZilla 0.9.85 [Firefox 3.5.3/20090824101458]") 20:00:33 * garyo has quit ("Leaving.") 23:49:41 * cdavid has quit ("Page closed")