IrcLog2010 03 09

16:50:54 * Jason_at_Intel ([email protected]) has joined #SCONS 16:52:29 * GregNoel is no longer marked as being away 16:53:51 <Jason_at_Intel> hello 16:53:59 * Garyo ([email protected]) has joined #SCONS 16:54:12 <Jason_at_Intel> Hi Gary 16:54:21 Hi Jason. 17:02:17 Hi Greg -- feel free. I'm starting to get some SCons time in the next few months (I hope!) 17:05:34 * bdbaddog ([email protected]) has joined #SCONS 17:06:03 Hi Bill! 17:06:19 hey 17:06:39 Thanks (again) for pushing out the checkpoint; this one is looking good. 17:06:45 <GregNoel> We're short Steven, but he commented in the spreadsheet; should we begin? 17:06:52 sure. 17:06:57 I think so too. 17:07:14 <GregNoel> 2517 17:07:36 <GregNoel> Steven says give it to him, but I don't like it as research. 17:08:02 I think it's his choice, is that OK? 17:08:36 <GregNoel> Yeah, but I don't think he should work on it until post-2.0. 17:09:06 Ah, I see. Spend his cycles getting the python 2.4 stuff in now instead? 17:09:16 <GregNoel> Yes. 17:09:43 That makes a lot of sense. I'm worried the 1.3 -> 2.0 transition will take a long time. 17:10:23 <GregNoel> It better not; I'll be flat on my back if it does... 17:09:42 <GregNoel> What's the priority on 2550? I didn't look. 17:10:02 2550=p3 17:10:29 <GregNoel> What's the milestone? 17:10:45 research 17:11:03 <GregNoel> Ouch. OK, make them the same: research p3. 17:11:27 OK, or move both to 2.1 p3 if you like. 17:11:45 <GregNoel> I'll put in a note that this "research" is less priority than 2.0. 17:11:53 +1 17:11:58 <GregNoel> done 17:12:02 <GregNoel> 1549 17:12:09 <GregNoel> oops, 2549 17:12:48 Here's where I say I am really happy Russel is taking the lead in putting tools in a DVCS. 17:13:24 <GregNoel> I agree. I'm not sure I agree with his choice of DVCS, but any choice is better than none. 17:13:34 he's certainly bringing the email volume up.. 17:14:09 So... can we make a new category of issues for external tools, and this can be one? 17:14:27 (I know it's half here & half there, so it's confusing.) 17:14:28 <GregNoel> Hmmm... Possible. Needs discussion. 17:14:47 <GregNoel> Not something to settle today, surely. 17:14:59 <Jason_at_Intel> +1 17:15:01 Agreed. Just let Russel work on it for now. 17:15:31 <GregNoel> so 2549, 3.x, what priority? 17:15:42 So 3.x p4? 17:15:53 <GregNoel> Hmmm... 17:16:15 <GregNoel> I think I'd like it to resurface sooner than that. 17:16:44 I'm hoping we'll decide some day to take the D tool out of SCons entirely instead. 17:16:53 <GregNoel> Yeah, along with Java. 17:17:02 ... and latex, and ... 17:17:03 <Jason_at_Intel> why? 17:17:16 <GregNoel> Make them all user-supported. 17:17:16 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 Jason: agreed. But we have to balance that with the python "batteries included" philosophy. 17:17:55 (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> Yeah, 2549 3.x p4; reassign it when we have a separate user-supported flow. 17:18:27 Greg: +1 17:18:32 <GregNoel> done 17:18:39 <GregNoel> 2566 17:18:42 2566 is already closed. 17:18:52 can't repro. 17:19:03 <GregNoel> WORKSFORME? 17:19:34 I said INVALID because he couldn't repro it either :-) 17:19:58 <GregNoel> worksforme, then. {;-} 17:19:27 <GregNoel> In any event, 2571 17:20:13 <Jason_at_Intel> 2571? is this calling Scons under the covers still? 17:20:29 Jason: sure. 17:20:15 2571: tell OP good job, give some direction on compat, then integrate for 2.1? 17:20:28 <GregNoel> I'll go along. 17:20:38 <GregNoel> Who? Gary? 17:20:47 I'll take it. 17:21:17 <GregNoel> Obviously needs some test cases, but I like the scheduling. 17:21:04 (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> 2.1 p3 Garyo, done 17:22:09 <GregNoel> 2572, defer? 17:22:29 sure 17:22:33 <Jason_at_Intel> +1 17:22:37 +1 17:22:47 <GregNoel> done 17:22:56 <GregNoel> 2573 17:22:59 2573: what is ".sx"? 17:23:10 <Jason_at_Intel> :-) was just going to ask that 17:23:15 some .net file? 17:23:22 <GregNoel> Man page says "preprocessed assembler" 17:23:33 <GregNoel> (It's in the spreadsheet comments.) 17:23:36 for what OS? 17:23:44 <GregNoel> Any? 17:23:56 what man page did you find it in? 17:24:24 <GregNoel> SCons man page. 17:24:48 <GregNoel> We currently preprocess those files, but apparently don't scan them for dependencies. 17:24:56 Oh?! Wow, that's a surprise! 17:25:05 <GregNoel> It was to me, too. 17:25:09 OK, I guess you guys are right, add it to the list. 17:25:37 I'll do that too. The work part is trivial. 17:25:49 2.1 p4 garyo +easy 17:25:51 <GregNoel> OK, done, but watch for side-effects: it may try to compile the file. 17:26:07 ok, put a note in if you don't mind... 17:26:17 <GregNoel> Wilco 17:26:33 <GregNoel> 2574 17:27:02 <GregNoel> Another trivial change, but would work better post-2.0. 17:27:16 Agreed. Post 2.0. 17:27:33 2.1 p2, who? 17:28:08 <GregNoel> Not seeing any volunteers... 17:28:19 <GregNoel> I can't take it; I'll be recovering. 17:28:36 Understood. Assign it to me then, I'll delegate if needed. 17:28:41 <GregNoel> done 17:28:48 <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 That's an excellent idea. 17:29:39 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> Um, it would have to work for all builders, not just this one. 17:30:32 Would it, Greg? Couldn't it just be an env override? 17:31:07 <GregNoel> No, I don't think so. Think of LaTeX, for example, which wants to run in the build directory. 17:31:10 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 Greg: I don't think tar/zip need to run in any particular dir, they just need a reference point. 17:32:39 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 Jason: that worries me. 17:33:07 <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 I see, use tarfile instead of calling tar. I totally agree. 17:34:34 <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 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 Not ideal, of course, but probably best we can do given builder limitations 17:36:08 <GregNoel> I have a functional prototype for 1890, but I've been waiting for post-2.0 to implement it. 17:36:29 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 17:37:13 <GregNoel> Then why not base it off of chdir=? It's the effect that counts, not the actual functioning. 17:37:51 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 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> I don't agree. 17:39:26 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> don't agree with src_dir; again, the effect is the requirement, not the actuality. 17:40:15 <Jason_at_Intel> ?? 17:40:38 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> Yes 17:41:01 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 (like a "builder_wants_chdir" flag or something) 17:41:35 <Jason_at_Intel> will it out add a cd

&& to the command? 17:42:15 Jason: at least the infrastructure would be there to handle it that way if we wanted to. 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=. 17:43:07 <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 Let's not say it's invalid then, but we think there's a better method. 17:43:24 <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 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 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> 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 (Greg, is that basically your idea?) 17:45:42 <GregNoel> Still designing on the fly, but yes, I think so. 17:45:44 Jason: we can't turn it on for all builders because most of them don't understand it. 17:45:59 chdir is clearly hack in this case. 17:46:26 <GregNoel> Hi, Sergey; glad you could join us. Do you think users would understand a distinction there? 17:46:29 There should be more flexible ways to specify paths that'll be stored in the archive, 17:46:32 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 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> OK, then what should we do with the ticket? 17:48:37 <GregNoel> I'll suggest deferring to the mailing list. 17:48:43 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> Yes 17:49:08 +1 17:49:08 (rather than have a complete implementation by that time) 17:49:16 <GregNoel> done 17:49:18 good, consensus! 17:53:13 Zip builder should store paths relative to shortest common path of sources by default IMO.. 17:53:35 <GregNoel> And that's what I'd like to do with 1890. 17:54:24 <GregNoel> Always put in a duple with relative path and File node. 17:53:49 loonycyborg: put a note in those 2 tickets if you want. 17:54:54 I like explicit rather than implicit in general though, even if it's a little more typing. 17:55:19 <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> Remember, relative path is expensive to calculate; should try to avoid it when possible. 17:55:06 ...but we're trying to design it here. 17:55:15 let's not. 17:49:37 <GregNoel> 2576 17:50:00 2576 looks like good potential for Russel to feed Steven things. 17:50:28 <GregNoel> Yes. 17:51:13 <GregNoel> I wonder if "anytime" would work for this, as they work out the interaction details. 17:51:19 2.x p3, Steven to own, and work w/ Russel? 17:51:57 (Or vice versa, Russel to own, delegate work to Steven?) 17:52:08 <GregNoel> I could buy 2.x p3, but I'd like to see a procedure worked out first. 17:52:37 <GregNoel> Russel to own during design, Steven to own during implementation? 17:52:57 OK then, let's ask Steven to work something like that out & revisit next meeting. OK? 17:53:12 <GregNoel> yes, I like that. 17:53:18 +1 17:53:25 <Jason_at_Intel> +1 17:55:40 <GregNoel> We seem to have covered the issues; I have one thing on schedule. 17:56:21 <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 Yes, 1.3. I'm in favor of moving aggressively to release. 17:56:13 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 :-( that's my one I thought wouldn't make it. I'll make an effort for it. 17:57:32 <GregNoel> loonycyborg, if the current checkpoint is the final candidate, that won't happen. Sorry. 17:57:34 seems unlikely. we're on the runway to 1.3 launch.. 17:58:01 They're right, things I've looked at would destabilize. 17:59:00 <Jason_at_Intel> hmm 2443 works for me. 17:58:23 Let's get 1.3 and 2.0 out asap. 17:58:39 Then we can get back on a shorter & less constricted release cycle. 17:58:57 yaha 17:59:11 so 1.3 this weekend then? 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? 17:59:33 <GregNoel> If so, this weekend sounds fine to me. 17:59:35 Greg: yes, those are the 2 issues on my test list. 17:59:57 Bill: I'll try to review the release docs soon. I'm happy to help wordsmith. 18:00:56 Is the release process pretty much as documented on the wiki now? 18:02:09 I'll be skiing this wkend, but around this week and next. 18:02:12 yes. though I might move a few steps around to streamline 18:02:36 OK, let me help; you've done a lot. 18:03:00 Do you think this wkend is possible? 18:03:36 to get feedback on the couple of issues msvs/vc/sdk which have been reported? 18:04:13 I think that should be possible. 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. 18:05:14 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 there's two more. 18:05:55 this one: http://scons.tigris.org/ds/viewMessage.do?dsForumId=1272&dsMessageId=2455554 18:06:23 Oh right, missing gdi32.lib. 18:06:50 and one with vc2010rc + a bunch of other isntalled vc's and it not picking up the requested one. 18:08:00 I had a win7 license from when they gave out the free trials, but it's expired. 18:07:51 I think we have to draw the line somewhere or we'll never get it out. 18:08:08 yeah. I think so too. 18:08:11 back in a minute.. 18:08:12 I have a win7 machine now. 18:08:57 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 I think bdbaddog's 2nd issue, from the ML. 18:09:58 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 I don't remember. 18:11:10 donno. 18:11:13 Try it :-) 18:11:22 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 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 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 That's usually what that means. 18:14:04 I'm guessing somehow the sdk/vc logic combo is not quite right, but only in some corner cases. 18:13:51 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 Sorry. 2.1. 18:14:14 I hear u. I want 1.3 done. 18:14:19 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 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 Jason: yes, or 2.1 actually. 2.0 = 1.3 with python floor update. 18:15:58 what's in vs_revamp? it's all on trunk 18:16:11 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> I'll have three weeks, 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. 18:17:06 hopefully! 18:17:07 yes. that's the plan. 18:17:19 <Jason_at_Intel> great! 18:17:22 no features in 2.0, just remove 1.5.2->2.3 code. 18:17:24 right? 18:17:32 <Jason_at_Intel> 2.4? 18:17:34 agreed. 18:17:49 <Jason_at_Intel> thought 2.3 was broken on some platforms 18:18:00 we're dropping 2.3 18:18:04 and below. 18:18:09 2.4 is the new floor. 18:18:13 yes. 18:18:17 <Jason_at_Intel> :-) 18:19:04 ok, let's do it! 18:19:13 k. 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. 18:19:48 should we make the call next tues on 1.3? 18:20:00 +1 18:20:00 <Jason_at_Intel> +1 18:20:07 or we can handle on release mailing list if things are resolved sooner. 18:20:23 fine. 18:21:01 <GregNoel> One week, then? 18:21:16 good with me. 18:21:34 k. virtually c u all then. 18:21:44 <Jason_at_Intel> same! 18:21:49 <GregNoel> OK, see you all in one week. 18:21:54 bye 4 now. 18:22:00 <Jason_at_Intel> bye 18:22:04 <GregNoel> Got to go, dinner is calling. 18:22:12 l8r 18:22:22 <GregNoel> G'day all. 18:22:29 * GregNoel has been marked as being away 18:23:38 * bdbaddog ( [email protected]) has left #SCONS 18:32:20 * Jason_at_Intel has quit (Quit: 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 0.9.86 [Firefox 3.5.8/20100202165920])