IrcLog2008 11 19

17:24:12 * garyo-home (n=[email protected]) has joined #scons 17:24:42 Hi Greg. 17:27:55 * stevenknight (n=stevenkn@nat/google/x-93de785fa2957b48) has joined #scons 17:28:18 Hi, Steven. 17:28:24 hey garyo 17:28:38 * Greg_Noel just got here 17:28:46 <Greg_Noel> Hi, all... 17:28:51 hi greg 17:29:20 <Greg_Noel> Give me a chance to set up... 17:29:26 Hi Greg. 17:34:58 <Greg_Noel> I'm ready; shall we proceed? 17:35:32 yes, let's start. 17:35:39 all right then... 17:35:53 1895 consensus 17:36:02 2127 consensus 17:36:06 <Greg_Noel> 1895 and 2127 look like consensus 17:36:37 2248: I say maybe invalid due to vs_revamp. 17:36:46 <Greg_Noel> I'll go with research, David 17:36:50 yes, vs_revamp should take care of it 17:37:00 probably nicer to the user to close as FIXED by vs_revamp, though 17:37:09 q: when should we integrate vs_revamp? (Steven: yes, good idea) 17:37:51 how about right after 1.2? 17:37:56 <Greg_Noel> Can't close it until there's a fix in place; bad practice 17:37:57 (which we should discuss) 17:38:12 greg: right, sorry I meant after vs_revamp is integrated 17:38:24 steven: sounds good. 17:38:41 okay, so mark this 1.3 p3 keyword 'vs_revamp' ? 17:38:48 ok\ 17:38:50 <Greg_Noel> ok, 1.3, p?, who? 17:39:13 <Greg_Noel> p3 is ok 17:39:16 I'll do it, it's only closing the bug when vs_revamp is in. 17:39:20 <Greg_Noel> done 17:39:57 2250? 17:40:25 probably end up with me 17:40:32 <Greg_Noel> Wide range of opinion... 17:40:41 how about 1.3 p3? (or p4?) 17:41:05 I'd prefer 2.x, there's too much going on already. 17:41:17 i can go with 2.x 17:41:30 <Greg_Noel> I still think that a revamp of Configure, which would take over the functionality of not only Configure, but also Option/Variable and other stuff (including getting options from the shell environment), is the right strategy, but as a short term hack, I can agree with a convenience function 17:43:09 Good. 17:43:37 <Greg_Noel> ok, 2.x, p?, steven? 17:43:43 2.x p3 steven 17:44:13 <Greg_Noel> I could also go with p4, not as important as other things. 17:44:24 either way's ok w/ me 17:44:36 <Greg_Noel> Steven? You're the deciding vote. 17:44:39 p4 maybe better 17:44:57 sorry, distracted -- i just broke the chrome build... :-/ 17:45:11 <Greg_Noel> Naughty, naughty... 17:45:18 can we help? :-) 17:45:14 2.x p3 me 17:45:20 <Greg_Noel> done 17:45:24 2251: threading issues are hard 17:45:39 ... to test, at least 17:45:50 yeah, and I'm far from a threading guru 17:46:10 but I'm starting to rope more people here into issues like this... 17:46:44 <Greg_Noel> Well, I've been one in the past, but it's nasty work. 17:46:48 in this case though it seems likely to be something like that, so I'd vote for something that "ought to fix it" even w/o a hard testcase; the testcase should just exercise it a bit. 17:47:03 <Greg_Noel> garyo-home, agree 17:47:05 garyo-home: agreed, i'll take that approach 17:47:29 ok, 1.x p3 steven? 17:47:35 done 17:47:48 oh, wait, we were saying 2.x, yes? 17:47:50 <Greg_Noel> We don't have a model for making (and keeping) SCons thread-safe and we should. Right now, it's completely ad-hoc and we've been pretty lucky that so few issues have surfaced. How should we go about developing a model, including possible thread locks? 17:48:20 Greg: without redesigning it for safety? Nearly impossible. 17:48:24 Greg_Noel, good point, excellent question, I have no idea 17:49:03 Greg: but thinking about it and discussing it and a few well-placed comments won't hurt :-) 17:49:08 <Greg_Noel> Yeah, but an idea about where to go from here is needed; for example, should this issue have been fixed with a lock rather than a delayed-action flag? No model, so we're working in the dark. 17:49:44 I agree. 17:50:01 okay, how about a TASK in the tracker to come up with a model? 17:50:14 or define it, really 17:50:15 But we do have a basic model about when threads are created etc. 17:50:18 at least we track the issue 17:50:24 <Greg_Noel> I'll go for that, but you can't put multiple people on a task. 17:50:25 steven: can't hurt. 17:50:41 wiki page in the design doc section? 17:50:48 <Greg_Noel> good idea 17:50:48 mark it something like 2.0, and either Greg (if you want to drive it) or me (if we want it to lie fallow for a good long while... :-)) 17:50:58 wiki page ++ 17:51:04 <Greg_Noel> {;-} I'll drive it, then 17:51:15 great! 17:51:19 cool, thanks 17:51:55 <Greg_Noel> OK, what did we decide for 2151? 17:52:16 2.x p3 stevenknight 17:52:22 <Greg_Noel> done 17:52:26 good 17:52:28 and a new TASK for the larger issue of a coherent thread model 17:52:31 <Greg_Noel> yes 17:52:53 <Greg_Noel> "coherent" ==> good word 17:52:46 2252: trivial fix 17:52:53 2252: consensus 17:52:55 2253: moot 17:53:09 2254: consensus 17:53:44 2255: Greg, can you go w/ Steven's idea? 17:53:51 2255: consensus except for Greg -- you okay with the proposal on the table? 17:54:10 * Greg_Noel still catching up; hadn't read all the new comments before 17:55:27 <Greg_Noel> Yes, add compat layer; only the one is needed post 2.0, but the other is, ah, problematic. 17:55:58 how? 17:56:34 <Greg_Noel> no Python support to get the needed information 17:57:03 Could it be made to be a noop on old pythons or something? 17:57:42 if it's a real problem, i'll do something like that rather than spend huge amounts of time on it 17:57:53 hopefully 1.5.2 support only lives for another couple months anyway 17:57:58 right. 17:58:31 <Greg_Noel> Are you suggesting that we add a new get_text_contents? I'm not sure I like that solution, unless it becomes a noop on systems that don't need it (memory impact) 17:58:59 ??? i don't think it should be, IIRC how it was implemented 17:59:12 it's not going to hang on to the decoded text 17:59:33 <Greg_Noel> I'm not so sure... 18:00:12 <Greg_Noel> how about research rather than committing to a fixed release? 18:00:31 <Greg_Noel> and bring it back to triage when there's more information? 18:00:53 Not sure what that more information would be. Whether it would be a memory hog? 18:00:57 well, i can live that, i guess 18:01:08 if you specify what information you're looking for, i'll bring it back 18:01:17 I think there's no system on which it's not needed. 18:01:58 <Greg_Noel> Where/how get_text_contents would be used, whether text would be saved/cached, that sort of thing. I18n text is expensive. 18:02:50 It would be used in scanners. Any utf-8 source code could have this problem. 18:03:02 just checked the code, the text is not saved/cached 18:03:14 it's decoded by the scanners as needed 18:03:16 But I get the point that it takes more memory. 18:03:43 <Greg_Noel> OK, maybe I'm being stubborn. "Memory is infinite and free", right? 18:03:49 If you had a monster utf-8 resource file (e.g.) it could take 2x the storage to get its text contents. I don't think that's a problem. 18:03:56 <Greg_Noel> 4x. 18:04:10 true, up to 4x depending. 18:04:21 sure, but only while scanning 18:04:24 (or is python always 4x internally?) 18:04:29 and the alternative is SCons doesn't work at all for you 18:04:33 yes, only during the scan, then it's gone. 18:04:52 Steven, I basically agree, this is needed. Just want to tease out all the implications. 18:04:55 <Greg_Noel> (Python always uses 4x on all platforms now) 18:05:00 okay 18:05:41 <Greg_Noel> I'll go with what you two decide. 18:05:59 Doesn't seem like memory usage would be a huge problem. I vote for implementing it and testing it on a couple of large builds; we have mem test infrastructure now. 18:06:11 <Greg_Noel> OK, that works, 18:07:01 2255: 1.x p2 steven then? 18:07:05 done 18:07:08 <Greg_Noel> done 18:07:19 2256 & 2257: consensus David, 1.3 p3 ? 18:07:25 yup 18:07:46 2258: invalid 18:07:57 <Greg_Noel> done 18:08:13 2259 consensus (I'd like this too) 18:08:48 <Greg_Noel> done 18:09:02 2260 consensus invalid 18:09:11 2260: I feel like it's too "interesting" to just mark it invalid somehow. 18:09:28 future? 18:09:28 future? 18:09:31 :-) 18:09:40 <Greg_Noel> What does Clean() do on a directory? We may already have a fix. 18:09:58 Good question. 18:10:03 research, then? 18:10:14 <Greg_Noel> ok, research, who? 18:10:37 I'd love to but I am overcommitted. 18:11:28 <Greg_Noel> I can check on Clean(), but I have personal stuff coming up, so my time will be limited over the next couple of months 18:12:36 <Greg_Noel> Did we lose Steven again? 18:12:49 maybe he just doesn't want it either :-~ 18:13:03 <Greg_Noel> Or he could have broken another build... 18:13:12 maybe. 18:13:45 yep, broke it again 18:13:46 <Greg_Noel> Let's make it research, me, and I'll toss it back if Clean() won't work. 18:13:53 ok. 18:14:04 and then we'll mark it future. 18:14:08 i'm pretty sure Clean() does it 18:14:09 thanks! 18:14:16 agreed, thanks for taking it 18:14:38 So, discuss 1.2 plans? 18:14:47 done with that spreadsheet; spend a little time on editlist2005q2? 18:14:48 <Greg_Noel> That concludes this spreadsheet, should we go on? Or do you need to pay attention to your build, Steven? 18:14:51 oh, 1.2 better 18:15:06 i have to wait for my second fix to build anyway... 18:16:09 btw, Greg, have you noticed some decay in the BugParty page? 18:16:18 1.2 is overdue, so my inclination is to get a candidate out there 18:16:18 <Greg_Noel> 1.2 is due out 24 Nov 18:16:30 right, sorry, candidate at least is overdue 18:16:35 i only sent out the one checkpoint so far 18:16:36 <Greg_Noel> what decay? 18:16:57 Check it out. Words with missing parts, damaged lists... 18:18:18 steven: 1.2 candidate any time is fine w/ me. I only wish I had more time to get my fixes in. 18:18:24 me too 18:18:28 <Greg_Noel> also 18:18:48 the big thing I'd like to get in is a performance improvement I've been working on for folks here 18:19:05 it changes the LIBPATH / CPPPATH search from linear (for each .h file for each .o file) 18:19:13 to O(1) by collapsing the directories into a lookup dictionary 18:19:36 That sounds good. 18:19:39 one of our libraries (from an upstream project) has literally ~80 directories in CPPPATH 18:19:49 and we use Repository() to multiply that x3 18:20:00 it cut the SCons overhead literally in half 18:20:09 amazing. 18:20:24 Were you also looking at a quoting issue? 18:20:33 yes 18:20:42 actually, string substitution in general 18:20:54 but it dovetails with the quoting for command execution 18:20:57 Ah, right. 18:21:32 <Greg_Noel> (Gary, I see it, it must be recent, I'll check into it.) 18:22:04 So is 1.2 still possible on 11/24? 18:22:17 in its more-or-less current state, yes 18:22:23 <Greg_Noel> How big is the change? Should it be kept for a checkpoint post-1.2? 18:22:31 probably post 1.2 18:22:46 it moves a bunch of scanning logic from the Node class into the Scanner proper 18:23:00 so it's potentially impactive and needs some baking time 18:23:15 actually, Gary, you could try giving it a sanity check if you want 18:23:24 its in branches/sgk_PathList 18:23:24 In that case, and given vs_revamp, the sooner we get 1.2 out the sooner both those changes can move into being testable 18:23:35 <Greg_Noel> concur 18:23:33 steven: I'll try it out this week. 18:23:40 should be able to point to bootstrap.py 18:23:45 okay, that makes sense 18:23:57 i'll go ahead and work on the candidate checkpoint after we're done 18:24:04 i should have some downtime in between breaking builds... 18:24:14 :-/ 18:24:14 <Greg_Noel> {;-} 18:24:12 and then ship 1.2 next week 18:24:22 sounds good. 18:24:22 <Greg_Noel> works for me 18:25:23 okay, then 18:25:28 <Greg_Noel> (Uh, wow, maybe it's Moin; I've got some other pages with lists that are broken...) 18:25:52 I think that page has had minor damage for quite a while, but it just got a lot worse. 18:25:46 any cycles to look at a few 2005q2 bugs, or do we need to wind down? 18:26:00 I can do a few, Steven. 18:26:07 <Greg_Noel> I've got time 18:27:05 okay, 1136: 18:27:09 consensus 1.x p3 stevenknight 18:27:19 ok 18:27:27 <Greg_Noel> done 18:27:43 1140: could Ignore() help here? 18:28:11 <Greg_Noel> Probably not; you want the dependency 18:28:29 but you can't have that dependency without making a cycle 18:28:37 it needs to be broken one way or another... 18:28:41 <Greg_Noel> I've had to create fake dependencies to deal with it in the past 18:28:56 <Greg_Noel> That works, but it's a hassle 18:29:09 You basically want the file to depend on all the other files in the dir except itself, right? 18:29:23 <Greg_Noel> yes, recursively 18:29:26 off the top of my head, that sounds right 18:29:29 eek! 18:29:57 ok, I don't know why this is useful but still sounds like you could make the file depend on the dir and then use Ignore (?) 18:30:17 But I haven't thought about it a lot so feel free to Ignore me :-) 18:30:47 <Greg_Noel> garyo-home, bad pun! I like it! 18:30:18 <Greg_Noel> The thing with using Glob() for dependencies that Ludwig is working on would solve it, but I don't know if he can do it. 18:31:24 so someone research this for a good solution? 18:31:37 <Greg_Noel> maybe Ludwig? 18:31:51 if we go with Ignore(), it should at least be documented as the recommended pattern 18:32:22 <Greg_Noel> Ignore is applied after dependencies; there's still a loop. 18:33:57 <Greg_Noel> (Silence while we contemplate.) 18:34:31 well, it sounds like a research for someone 18:34:39 to either find the right code fix or the right doc fix 18:35:29 <Greg_Noel> Let's see if Ludwig is willing. 18:36:08 okay, sounds good to me 18:36:26 1140: resesarch, Ludwig 18:36:27 <Greg_Noel> Gary, you OK with that? 18:36:37 yes 18:36:40 <Greg_Noel> done 18:36:48 1142: FIXED, ludwig 18:36:52 <Greg_Noel> done 18:37:30 1143: 2.x p4 steveknight? 18:37:44 <Greg_Noel> 1143, don't use FilterOut; I've got an enhancement with that name on it 18:37:47 sure! 18:37:58 <Greg_Noel> done 18:37:59 okay, i prefer env.Remove() myself anyway 18:38:03 me too 18:38:07 parallel with list.append => env.Append(), etc. 18:38:51 1152: gary, you filed it, so your 2.x p3 trumps 18:39:05 1152: sure, count me in. 18:39:10 <Greg_Noel> works for me 18:39:18 1152: 2.x, p3, garyo 18:39:18 done 18:39:36 1161: 2.x p2 gregnoel ? 18:40:13 <Greg_Noel> OK, although I'm going to have to digest Steven's comment... 18:40:45 nah, just spit it back up -- i'm blathering on like i usually do 18:40:44 Greg: by proxy wrappers you're thinking about -Bstatic/-Bdynamic, right? In which case I agree, this is the same. 18:41:06 i don't think my comment adds any real value 18:41:27 <Greg_Noel> yes, Bstatic() and Bdynamic() proxy wrappers 18:42:27 I like tags better than proxy wrappers but if you're implementing it, you choose. 18:42:55 <Greg_Noel> This case needs to return a list, so it needs some sort of wrapper 18:43:24 <Greg_Noel> I'll come up with a proposal, then re-triage it 18:43:27 I see your point, otherwise something else has to collect the tagged libs, and that gets hairy 18:43:49 OK, greg re-triage w/ proposal 18:44:50 done 18:45:00 <Greg_Noel> 1164, looks like the consensus is future 18:45:11 works for me 18:45:14 1164: future, p4? 18:45:18 <Greg_Noel> done 18:45:20 yes 18:45:31 1166: shall we just put it in to get it off the plate? 18:45:48 we've been kind of doing that for other tools with small user bases 18:45:56 <Greg_Noel> I don't use it, so that's fine with me 18:45:58 I think there's another bcc ticket lying around, hang on 18:46:45 yes, there are a few actually. 18:46:59 <Greg_Noel> The -e$TARGET should be first, if the command accepts that, to be consistent with other builders. 18:47:32 I did 2163 already, so why don't I do 1166 (blind) 18:47:41 gregnoel: agreed 18:47:47 <Greg_Noel> done 18:47:53 garyo: thanks: 2163: anytime garyo 18:48:02 <Greg_Noel> yes, anytime 18:48:10 er, 1166: anytime garyo 18:48:20 sure. Also I have 2164 but never got any response from the OP. 18:48:24 Maybe he's moved on. 18:48:41 seems likely 18:48:48 1170: consensus research, david 18:49:18 <Greg_Noel> done 18:49:38 yes 18:50:03 <Greg_Noel> 1175, another blind change for Gary? 18:50:12 oh joy 18:50:15 sure, why not. 18:50:22 i'm brave 18:50:31 <Greg_Noel> done 18:51:10 1176: agree w/ Greg 18:51:32 1176: agree 18:51:40 <Greg_Noel> done 18:52:00 3: greg filed it, has it been fixed? 18:52:29 <Greg_Noel> damifino, I used a workaround 18:52:06 i think you're right about gary working on it since then 18:52:40 I did clean it up a lot. I seem to remember I was skeptical about changing the existing behavior though. Anyway I'll look at it again. 18:52:57 <Greg_Noel> anytime, garyo? 18:53:15 <Greg_Noel> or is research better? 18:53:20 Would you all be in favor of changing the behavior? Would cause rebuilds... 18:53:36 * Greg_Noel has his hand up 18:53:41 call it research. Need to see if this case works or not. 18:54:10 I'd rather it be changed too. 18:54:12 <Greg_Noel> Rebuilds would be very rare... 18:54:43 <Greg_Noel> You OK with that, Steven? Or did the build break again? 18:55:00 And one more q: if you append [1, 2, 1], should it append 1,2 or 2,1? 18:55:26 <Greg_Noel> You added the option, follow the option. 18:55:44 That makes sense 18:55:51 build break 18:56:13 It's about time for me to go anyway. 18:56:34 i'm okay with changing behavior if the new is better, and we have a reasonable path 18:56:44 ok 18:56:48 so 3: research, garyo 18:56:55 <Greg_Noel> done 18:57:09 last parting shot: 1180: 1.x, p3, me 18:57:16 it's a definite problem, we leak tmp*.lnk files 18:57:24 <Greg_Noel> I should go soon as well... 18:57:32 <Greg_Noel> 1180, done 18:57:37 ok, thanks all! 18:57:38 sometimes SCons slows down because of huge numbers of leaked files in /tmp or %TMPDIR% 18:57:43 all right, good progress 18:57:46 many thanks, guys 18:57:53 <Greg_Noel> er, 1182, David? 18:58:05 1182 david, yes 18:58:11 ok 18:58:12 they're like potato chips! 18:58:16 2 weeks from now, right? 18:58:21 yes, two weeks 18:58:26 <Greg_Noel> The rest next time, yes, two weeks, after Thanksgiving. 18:58:27 have a good turkey day 18:58:39 ok, I'll see you then. Happy Thanksgiving! 18:58:40 <Greg_Noel> same to you guys 18:58:45 <Greg_Noel> cul 18:58:49 bye 18:58:50 l8r 18:58:52 * stevenknight (n=stevenkn@nat/google/x-93de785fa2957b48) has left #scons ("Leaving") 18:58:56 * Greg_Noel goes for dinner 18:59:00 * garyo-home has quit ("ChatZilla 0.9.84 [Firefox 3.0.4/2008102920]")