Clone wiki

SCons / BugParty / IrcLog2008-10-15

The SCons wiki has moved to

17:56:53  *      garyo-home (n=[]( has joined #scons 
17:59:18  <[GregNoel](GregNoel)>     Hey, Gary... 
17:59:25  <garyo-home>   Hi, Greg. 
18:00:00  <[GregNoel](GregNoel)>     Steven's not here yet; anyone else here for the bug party? 
17:59:48  <garyo-home>   I gave a talk on SCons last weekend.  Just need to upload it to the wiki. 
18:00:27  <[GregNoel](GregNoel)>     Yes, you mentioned it last time.  The wiki sounds like a good place. 
18:01:06  *      stevenknight (n=[stevenkn@](mailto:stevenkn@ has joined #scons 
18:01:14  <[GregNoel](GregNoel)>     Speaking of the devil... 
18:01:28  <garyo-home>   Hi, Steven. 
18:01:51  <garyo-home>   I just uploaded my SCons talk to the wiki. []( 
18:01:53  <stevenknight> hey 
18:03:01  <garyo-home>   So, how about getting going? 
18:03:11  <[GregNoel](GregNoel)>     I'll look at it afterward; yes, let's go. 
18:03:22  <[GregNoel](GregNoel)>     2220 
18:03:44  <stevenknight> sorry, hang on, still getting set up 
18:04:12  <[GregNoel](GregNoel)>     Apparently it works in 0.98.something, but not since 
18:04:06  <garyo-home>   close as invalid, make new issue w/ test case & description, then retriage? 
18:04:40  <[GregNoel](GregNoel)>     Yes, but I'd feel better if we settled the timeframe now. 
18:04:56  <stevenknight> agree w/garyo-home re: invalid and new issue 
18:05:05  <garyo-home>   IMHO it depends on how serious the *actual* issue is. 
18:05:20  <garyo-home>   If it only happens with nested builders, then 2.x p4 etc. 
18:05:43  <[GregNoel](GregNoel)>     No, my example used nothing but [VariantDir](VariantDir) 
18:06:09  <garyo-home>   Ah yes, I see that one now. 
18:06:13  <stevenknight> okay, if greg's example is pure variantdir and a 0.98 regression 
18:06:24  <stevenknight> then either 1.x 
18:06:39  <stevenknight> or 1.2 (with likelihood of falling off the plate depending on priority relative to other stuff) 
18:06:44  <stevenknight> my name on it 
18:07:09  <garyo-home>   ok, then 1.x p3?  1.2 is impossible at this point IMHO. 
18:07:11  <[GregNoel](GregNoel)>     Then I'd suggest 1.3 or 1.x 
18:07:44  <stevenknight> 1.x p3 is fine with me 
18:07:50  <[GregNoel](GregNoel)>     ok, done 
18:08:14  <garyo-home>   2225: 1.x Jim p3? 
18:08:21  <[GregNoel](GregNoel)>     2226, yes 
18:08:43  <stevenknight> i have 2225 next... 
18:08:43  <[GregNoel](GregNoel)>     oops, 2225 
18:08:44  <garyo-home>   2225 or 2226, Greg? 
18:09:32  <[GregNoel](GregNoel)>     The new spreadsheet from Google allows me to set the font larger; you bet I'm going to use that next time so I can read the thing. 
18:09:15  <garyo-home>   consensus? 
18:09:38  <[GregNoel](GregNoel)>     yes, consensus 
18:09:48  <stevenknight> 2225 yes consensus 
18:09:55  <stevenknight> glad to hear from jim... 
18:10:07  <[GregNoel](GregNoel)>     Yes, we've missed him 
18:10:21  <garyo-home>   re: jim, yes! 
18:10:00  <garyo-home>   2226: wontfix 
18:10:49  <stevenknight> 2226:  greg, agree w/WONTFIX? 
18:10:49  <[GregNoel](GregNoel)>     I can see the use case for 2226: do it once for the common case, rather than in dribs and drabs. 
18:11:10  <[GregNoel](GregNoel)>     I'd like to see a better patch, for sure 
18:11:14  <jtc>  For 2225, I agree with Jim's comment on the spreadsheet that in the long term we need to look at quoting more holistically. In particular, I think we need to look if we can defer quoting until just before spawning the command. Most make implementations will avoid spawning a subshell if there are no shell metacharacters.  It is difficult for scons to do the same if everything has been quoted (although I suppose a de-quoter could be written). 
18:11:14  <garyo-home>   But it only speeds up the initial build.  After that it's cached anyway. 
18:11:33  <garyo-home>   Hi jtc! 
18:11:45  <stevenknight> jtc: hi!  agree w/what you said re: quoting 
18:12:09  <garyo-home>   Yes, definitely.  We just need to keep all cmd lines as lists or CLVars etc. until the last minute. 
18:12:10  <jtc>  At IDE, we experienced problems with high -jN, as the subshells caused us to run against the per-user process limit twice as fast as we would have liked. 
18:12:24  <[GregNoel](GregNoel)>     Yes, I hope the subprocess module will allow us to clarify it. 
18:12:34  <garyo-home>   Good point, Greg. 
18:12:48  <stevenknight> subprocess will help 
18:13:02  <stevenknight> but you still have command pipelines and redirection that will have to be detected 
18:13:17  <garyo-home>   Sure, but if it's all in one place it's not that hard. 
18:13:18  <[GregNoel](GregNoel)>     I don't see Jim here, but we've talked aabout how to do the quoting internally; maybe we should jointly prepare a proposal. 
18:13:35  <stevenknight> that sounds good 
18:13:40  <garyo-home>   That would be great.  Discuss on ML. 
18:13:47  <[GregNoel](GregNoel)>     yes 
18:13:51  <stevenknight> on to 2226? 
18:13:58  <stevenknight> or back to it 
18:14:17  <garyo-home>   2226: we have too much to do already; this is a trivial addition even if it were fully formed. 
18:14:36  <[GregNoel](GregNoel)>     for 2225, I'm only proposing that we give it the 'toolchain' keyword so we look at it again when we're revamping the toolchain. 
18:14:49  <[GregNoel](GregNoel)>     sigh, 2226, 
18:14:49  <stevenknight> 2225:  toolchain++ 
18:14:55  <garyo-home>   ok I guess, but I don't think it has anything to do w/ that really. 
18:15:08  <stevenknight> sorry, i'm confused 
18:15:43  <[GregNoel](GregNoel)>     My eyes can't resolve 5 v. 6 so I keep typing the wrong one.  Sorry. 
18:15:56  <garyo-home>   no prob. 
18:16:03  <stevenknight> 2226:  not clear if David's trying to make it easier to configure or more efficient (one compilation vs. multiple) 
18:16:17  <garyo-home>   I thought it was just efficiency. 
18:16:19  <[GregNoel](GregNoel)>     a combination of both 
18:16:41  <stevenknight> i think you give up too much by putting everything into one compilation 
18:16:45  <[GregNoel](GregNoel)>     trying a dozen things at once is much faster if they all work; 
18:17:00  <[GregNoel](GregNoel)>     if not, you fall back to testing one at a time 
18:17:32  <stevenknight> within the call?  or do you have to write that logic in your SConscript? 
18:17:40  <garyo-home>   imho, put it on the wiki as a custom SConf test. 
18:18:06  <garyo-home>   I think David's point is that on most platforms all the funcs will be there, so you just want a quick sanity check. 
18:18:25  <[GregNoel](GregNoel)>     yes 
18:18:27  <jtc>  As the maintainer of the autotools build for ACE/TAO (which may be the largest single autotools using project), I'm not sure if that holds. 
18:18:46  <garyo-home>   jtc: I agree, just pointing out his rationale. 
18:19:27  <jtc>  For example, it has feature tests for traditional UNIX and traditional MS Windows APIs.  You typically won't find both. 
18:19:55  <garyo-home>   right, that's why I think the whole idea's a bit questionable. 
18:19:57  <[GregNoel](GregNoel)>     Uh, no, you'd combine the *IX tests or the DOS tests not both in the same flow 
18:20:49  <[GregNoel](GregNoel)>     But I'm willing to go along; we're taking too long on this. 
18:20:51  <garyo-home>   greg: true, but you're still not going to test for *every* DOS func you call, so it's not really here nor there. 
18:21:23  <garyo-home>   How about 2227? 
18:21:34  <stevenknight> yeah, let's move on -- this really seems like an unnecessary optimization 
18:21:40  <stevenknight> 2227:  
18:22:07  <garyo-home>   2227 is the first time I've ever heard anyone say "[ParseConfig](ParseConfig) works fine on windows" 
18:22:11  <garyo-home>   :-/ 
18:22:17  <stevenknight> consensus 2.x p3 ? 
18:22:29  <garyo-home>   ok w/ me 
18:22:31  <[GregNoel](GregNoel)>     ok,  
18:22:46  <[GregNoel](GregNoel)>     maybe we'll change our mind by then 
18:23:14  <[GregNoel](GregNoel)>     2228, consensus? 
18:23:27  <garyo-home>   yep 
18:23:30  <stevenknight> 2228:  done 
18:23:42  <[GregNoel](GregNoel)>     2229, consensus? 
18:23:43  <garyo-home>   2229, ditto 
18:23:59  <stevenknight> 2229:  consensus 
18:23:58  <[GregNoel](GregNoel)>     2230 
18:24:19  <garyo-home>   I'd like it, but maybe makes more sense for 2.x than 1.x. 
18:24:34  <[GregNoel](GregNoel)>     2230, I'll go with Steven 
18:24:43  <stevenknight> 2230:  okay, 2.x or anytime? 
18:25:11  <garyo-home>   I think it's worth 2.x rather than anytime 
18:25:16  <stevenknight> okay, 2.x 
18:25:33  <[GregNoel](GregNoel)>     you suggested 1.x in the spreadsheet? 
18:26:10  <stevenknight> after more thought i'm agreewing w/garyo's suggestion that 2.x is more realistic 
18:26:21  <[GregNoel](GregNoel)>     ok, I'll go with 2.x.  what priority? 
18:26:45  <garyo-home>   p3 or p4, steven's preference 
18:26:49  <stevenknight> p3 
18:26:51  <[GregNoel](GregNoel)>     done 
18:26:54  <garyo-home>   2231: more warn opts 
18:27:08  <[GregNoel](GregNoel)>     Er, not quite. 
18:27:41  <[GregNoel](GregNoel)>     The idea is that a user may not know which new deprecation flags have been added 
18:28:03  <[GregNoel](GregNoel)>     so they just use --warn=all-deprecated and they get all of them 
18:28:18  <stevenknight> that's what --warn=deprecated is supposed to do 
18:28:35  <stevenknight> the hierarchy means that it will match all of the subclassed [DeprecatedWarnings](DeprecatedWarnings) classes 
18:28:51  <[GregNoel](GregNoel)>     No, the first deprecation stage is a warning that is _off_ by default 
18:29:05  <stevenknight> ??? 
18:29:18  <[GregNoel](GregNoel)>     We didn't use it in this last round, but that's the way it's supposed to be. 
18:29:12  <stevenknight> if you specify --warn=deprecated that means "on" 
18:29:21  <stevenknight> and it will (or should) match your explicit settings 
18:29:26  <stevenknight> before it looks at the defaults 
18:29:49  <[GregNoel](GregNoel)>     So there's a state you can't specify on the command line? 
18:29:49  <stevenknight> didn't use what in this last round? 
18:29:58  <stevenknight> what state? 
18:30:34  <[GregNoel](GregNoel)>     Three states, just like it says in the issue: warning off by default, warning on by default, warning not suppressible. 
18:31:11  <[GregNoel](GregNoel)>     And three master control options: turn on options normally off, use the default, and turn off suppressible options. 
18:31:35  <stevenknight> sorry, i really don't get it -- i don't think we should ever have warnings that aren't suppressible 
18:32:10  <[GregNoel](GregNoel)>     OK, you will get screams of outrage when users are suddenly forced to upgrade. 
18:32:28  <stevenknight> ??? 
18:32:59  <[GregNoel](GregNoel)>     Yes, there will be a set of people who _always_ run with --warn=no-deprecated 
18:33:25  <[GregNoel](GregNoel)>     They will be rudely surprised when they are suddenly forced to change their scripts 
18:32:04  <stevenknight> maybe we should take this off line so you can explain it to me 
18:33:11  <garyo-home>   I think offlining this is a good idea. 
18:33:50  <[GregNoel](GregNoel)>     I'll agree to that, so retriage the issue next time? 
18:33:57  <garyo-home>   ok 
18:34:03  <stevenknight> ok 
18:34:14  <garyo-home>   (w/ additional info in the ticket) 
18:34:22  <[GregNoel](GregNoel)>     ok 
18:34:35  <[GregNoel](GregNoel)>     2232, I checked, it's fixed, I'll close it 
18:34:46  <garyo-home>   great 
18:34:50  <stevenknight> cool 
18:35:09  <garyo-home>   2233: I'll reply to OP and get details 
18:35:20  <[GregNoel](GregNoel)>     good, I'll leave it to you 
18:35:32  <stevenknight> 2233:  good, thanks 
18:35:39  <[GregNoel](GregNoel)>     retriage next time then? 
18:35:59  <garyo-home>   sure, depending on reply. 
18:36:18  <[GregNoel](GregNoel)>     done 
18:37:21  <[GregNoel](GregNoel)>     2234, consensus for anytime?  I don't like making an actual defect an open-ended issue. 
18:38:26  <garyo-home>   It seems really easy; 1.x should be OK. 
18:38:35  <stevenknight> 2234:  1.x is fine with me 
18:38:50  <[GregNoel](GregNoel)>     what priority? 
18:39:05  <stevenknight> p3 
18:39:11  <[GregNoel](GregNoel)>     done 
18:39:27  <[GregNoel](GregNoel)>     2235 
18:39:48  <garyo-home>   definitely make code agree w/ doc here 
18:40:17  <stevenknight> 2235:  agree 
18:40:36  <[GregNoel](GregNoel)>     OK, I'll run regressions and see what it catches.  As far as I know, there's only one test that does anything with them. 
18:40:48  <garyo-home>   (hmm, my kids are still awake, it's 9:40 on a school night... grr) 
18:41:02  <stevenknight> garyo-home:  i feel your pain... 
18:41:07  <garyo-home>   greg: regressions = good idea. 
18:41:22  <[GregNoel](GregNoel)>     OK, anytime is acceptable? 
18:41:24  <stevenknight> okay, done with current issues 
18:41:29  <jtc>  the curse of parenthood... 
18:41:33  <stevenknight> anytime is fine with me -- or research 
18:41:53  <garyo-home>   anytime 
18:41:54  <[GregNoel](GregNoel)>     anytime 
18:42:00  <[GregNoel](GregNoel)>     done 
18:42:01  <stevenknight> done 
18:42:22  <[GregNoel](GregNoel)>     One question before we go on... 
18:42:50  <garyo-home>   Hey, allofasudden I can edit 2005h2 and never could before (using the regular link).  Maybe it's the new google docs upgrade. 
18:42:55  <garyo-home>   yes, greg? 
18:43:17  <[GregNoel](GregNoel)>     Steven mentioned that he's normally getting off the shuttle at 18h30 or thereabouts; should we move the time earlier by a half-hour? 
18:43:45  <garyo-home>   That makes it a little harder for me. 
18:45:04  <[GregNoel](GregNoel)>     I suspected that, but it took us 45 min to clear tonight's issues; we need more than a half-hour if we're meeting at 18h00 
18:45:25  <stevenknight> i could see about shifting my schedule on the nights we have these 
18:45:33  <stevenknight> so happened that i worked from home today 
18:45:54  <[GregNoel](GregNoel)>     Always a good schedule... {;-} 
18:46:10  <garyo-home>   I could probably do it at 18h30 though, since it's only every other week. 
18:47:02  <[GregNoel](GregNoel)>     Is that better for you, Steven? 
18:47:15  <stevenknight> probably a little 
18:47:29  <stevenknight> if i take the shuttle on those nights, it gets in right about 18h30 
18:47:42  <stevenknight> but i could find a wifi cafe and join pretty shortly after 
18:47:43  <[GregNoel](GregNoel)>     OK, I'll post it that way; Steven, will you keep us informed if it has to move? 
18:47:50  <stevenknight> will do 
18:48:09  <[GregNoel](GregNoel)>     OK, onward. 
18:48:18  <garyo-home>   Wait, I meant to say half hour earlier would be ok -- but half hour later is better for me, is that what we just agreed on? 
18:48:33  <stevenknight> right, half hour later, 18h30 PDT, 21h30 EDT 
18:48:40  <garyo-home>   ok, thanks! 
18:48:51  <stevenknight> cool 
18:49:03  <stevenknight> shall we make some headway on 2005h2? 
18:49:39  <garyo-home>   1230: consensus worksforme 
18:49:40  <[GregNoel](GregNoel)>     worksforme 
18:49:45  <stevenknight> done 
18:49:47  <stevenknight> 1235: 
18:49:54  <garyo-home>   consensus fixed 
18:50:03  <stevenknight> i might have already closed it 
18:50:06  <stevenknight> 1241: 
18:50:14  <garyo-home>   invalid, I'm ok w/ that 
18:50:20  <stevenknight> 1241:  invalid 
18:50:21  <[GregNoel](GregNoel)>     done 
18:50:21  <stevenknight> done 
18:50:40  <garyo-home>   1244: let me research that.  Looks like some good stuff might be in there. 
18:50:47  <stevenknight> oh, damn -- that's right, i couldn't edit this for a while, either 
18:50:58  <stevenknight> 1244:  research, garyo, done 
18:51:10  <[GregNoel](GregNoel)>     done 
18:52:08  <[GregNoel](GregNoel)>     1249? 
18:52:23  <stevenknight> 1249:  i like your suggestion:  ludwig, research 
18:52:34  <garyo-home>   Could Mkdir just succeed if target exists, and also create intermediate dirs? 
18:52:54  <[GregNoel](GregNoel)>     It does. 
18:53:12  <[GregNoel](GregNoel)>     but it then tries to make the intermediate directory 
18:53:19  <[GregNoel](GregNoel)>     and fails 
18:53:26  <garyo-home>   ... but why doesn't that Mkdir succeed also? 
18:53:52  <[GregNoel](GregNoel)>     os.mkdir fails: directory already exists 
18:54:00  <garyo-home>   It should trap that error and ignore it. 
18:54:27  <[GregNoel](GregNoel)>     Yes, it checks, but it checks _before_ the other Mkdir creates the directory 
18:55:00  <stevenknight> needs some more research, then?  or greg, do you feel you've characterized it sufficiently to identify the right fix? 
18:55:21  <[GregNoel](GregNoel)>     Sure, but then, I think Ludwig should do it 
18:55:33  <garyo-home>   I can fix it in 10 minutes including test. 
18:55:37  <garyo-home>   Just give it to me. 
18:55:40  <[GregNoel](GregNoel)>     done 
18:55:55  <stevenknight> done 
18:56:15  <garyo-home>   (But I'm only going to fix the proximate cause, not whatever Ludwig's patch is about.) 
18:56:23  <[GregNoel](GregNoel)>     Just make sure it still fails if it's a file (or whatnot) that's preventing the creation 
18:56:26  <stevenknight> that works for me 
18:56:33  <garyo-home>   Good point, Greg. 
18:56:41  <[GregNoel](GregNoel)>     or file permissions, or anything else. 
18:56:52  <garyo-home>   Right, no problem. 
18:56:59  <[GregNoel](GregNoel)>     Ludwig's patch clears the cache when the directory is created 
18:57:24  <garyo-home>   Ah, right, so the next Mkdir gets the test right. 
18:57:37  <garyo-home>   ok let's move on 
18:57:38  <[GregNoel](GregNoel)>     you mean wrong 
18:57:43  <garyo-home>   :-) 
18:58:01  <stevenknight> 1253:   
18:58:20  <stevenknight> greg, did you reproduce with current scons?  or with 0.96.91? 
18:58:36  <[GregNoel](GregNoel)>     current, with the .sconsign he provided 
18:58:59  <stevenknight> ah 
18:59:10  <stevenknight> i'm inclined to either WORKSFORME or RESEARCH, then 
18:59:16  <stevenknight> the .sconsign file would have changed since then 
18:59:21  <stevenknight> so it's not surprising that we can't handle it 
18:59:30  <[GregNoel](GregNoel)>     but we should detect that, yes? 
18:59:51  <stevenknight> we do.  that's why we print the warning 
19:00:07  <[GregNoel](GregNoel)>     Er, I think it's a fatal error now 
19:00:08  <stevenknight> if we didn't detect it, you'd get a stack trace 
19:00:43  <[GregNoel](GregNoel)>     It's been a while, and I'm not positive, but I think it did give a stack trace 
19:01:23  <stevenknight> okay, sounds like research me 
19:01:26  <[GregNoel](GregNoel)>     done 
19:01:38  <stevenknight> note re: making sure it doesn't stack trace 
19:01:54  <[GregNoel](GregNoel)>     done 
19:02:28  <[GregNoel](GregNoel)>     1260 
19:02:37  <garyo-home>   1260: probably moot due to recent fortran work 
19:02:56  <[GregNoel](GregNoel)>     Probably, but I think David should check it out 
19:03:04  <garyo-home>   David should check, agreed. 
19:03:04  <stevenknight> what greg said 
19:03:10  <stevenknight> research, David? 
19:03:16  <[GregNoel](GregNoel)>     research? 
19:03:27  <garyo-home>   ok 
19:03:30  <[GregNoel](GregNoel)>     done 
19:03:54  <[GregNoel](GregNoel)>     1261, whatever you guys decide 
19:04:23  <garyo-home>   Interesting.  I hadn't seen that.  Do we have cygwin platform support now? 
19:04:35  <stevenknight> kinda sorta 
19:04:49  <stevenknight> never had a real cygwin expert do a thorough job with it 
19:05:11  <stevenknight> we do have places where we account for cygwin differences 
19:05:35  <stevenknight> (especially its really annoying characteristic of lying about case sensitivity) 
19:05:40  <garyo-home>   I don't think there's anything like this patch in tools now, and it looks pretty OK.  I'm inclined to take it seriously. 
19:05:46  <stevenknight> agree 
19:06:05  <[GregNoel](GregNoel)>     (Three years old, remember) 
19:06:17  <garyo-home>   It's basically a gcc-lookalike with some tweaks. 
19:06:51  <stevenknight> sounds reasonable 
19:06:55  <stevenknight> i can take it 
19:06:56  <garyo-home>   Greg: if we have this in, it'll help us remember what to do on cygwin in the toolchain stuff. 
19:07:02  <garyo-home>   Steven: great 
19:07:07  <stevenknight> what time frame? 
19:07:11  <garyo-home>   2.x? 
19:07:16  <stevenknight> that sounds right 
19:07:17  <garyo-home>   p3? 
19:07:21  <stevenknight> yes 
19:07:24  <[GregNoel](GregNoel)>     done 
19:07:27  <stevenknight> add a cygwin keyword? 
19:07:43  <[GregNoel](GregNoel)>     or 'toolchain'? 
19:07:56  <stevenknight> or both? 
19:07:59  <garyo-home>   either or both, ok w/ me 
19:08:14  <[GregNoel](GregNoel)>     Steven, your choice 
19:08:25  <stevenknight> i was thinking both might be handy in case someone tries to tackle cygwin before toolchain (or vice versa) 
19:08:36  <[GregNoel](GregNoel)>     done 
19:09:15  <[GregNoel](GregNoel)>     1263? 
19:10:38  <stevenknight> needs to be reproduced, it's been a while 
19:10:42  <stevenknight> i bet it's been fixed since then 
19:11:06  <stevenknight> better if someone else has time, but i'll take it (research) if no one else can 
19:11:43  <[GregNoel](GregNoel)>     Trivial to reproduce; it's using glob.glob() instead of Glob(), so it's in the "wrong" directory the second time through. 
19:12:35  <stevenknight> ah! 
19:12:35  <garyo-home>   That's probably right... 
19:12:44  <garyo-home>   (actually os.listdir, but same thing) 
19:12:51  <stevenknight> close it out, then, with reference to Glob() ? 
19:13:14  <[GregNoel](GregNoel)>     yup, that's what I said in the spreadsheet... 
19:13:16  <garyo-home>   I think so.  OP can reopen if desired (ok, it's 3 yrs old, they won't...) 
19:13:35  <[GregNoel](GregNoel)>     done 
19:13:46  <[GregNoel](GregNoel)>     1268 
19:14:08  <stevenknight> ah, okay, i stopped scrolling down on the spreadsheet 
19:14:09  <stevenknight> 1268: 
19:14:36  <stevenknight> agree w/greg:  research, Jim 
19:15:07  <garyo-home>   ok, but my quick look says this patch couldn't hurt. 
19:15:23  <jtc>  gotta go folks; I'll try to make the next bug party ... 
19:15:30  <[GregNoel](GregNoel)>     Let Jim decide 
19:15:32  <garyo-home>   thanks, J.T.! 
19:15:35  <stevenknight> thanks, jtc 
19:15:38  <[GregNoel](GregNoel)>     We'll look for you 
19:15:43  <[GregNoel](GregNoel)>     the more the merrier! 
19:16:12  <garyo-home>   re: let jim decide, ok. 
19:16:36  <[GregNoel](GregNoel)>     done 
19:16:56  *      jtc has quit ("Quit") 
19:17:30  <[GregNoel](GregNoel)>     1276 
19:17:49  <stevenknight> 1276:  kind of hairy and architectural 
19:17:57  <stevenknight> i'm probably the logical assignee, unless someone else wants it 
19:17:59  <garyo-home>   1276: I guess Greg's ssheet comment is right. 
19:18:00  <stevenknight> agree w/future 
19:18:03  <garyo-home>   future. 
19:18:12  <[GregNoel](GregNoel)>     what priority? 
19:18:25  <stevenknight> p2 sounds right 
19:18:32  <[GregNoel](GregNoel)>     done 
19:18:33  <stevenknight> shorter sk:  agree w/greg  :-) 
19:19:31  <[GregNoel](GregNoel)>     Huh?  Where did I say that? 
19:19:47  <stevenknight> no, i was poking fun at myself 
19:20:03  <stevenknight> the summary of my previous long-windedness was:  I agree w/greg 
19:20:19  <[GregNoel](GregNoel)>     ah 
19:20:33  <stevenknight> 1281:   
19:20:56  <stevenknight> agree we need a Java guru 
19:21:20  <[GregNoel](GregNoel)>     I had no clue with this one, and re-reading it, I still don't 
19:21:24  <stevenknight> if we had one, what priority / timeframe 
19:21:35  <stevenknight> arbitrary:  2.x p3 ? 
19:21:42  <garyo-home>   whatever 
19:21:58  <stevenknight> that lets us defer until 1) someone pops up; 2) we get to it eventually 
19:21:58  <[GregNoel](GregNoel)>     OK, I'll go with that 
19:22:31  <garyo-home>   1282: is dup of 1268 
19:22:41  <garyo-home>   sorry I mean 12385 is dup 
19:22:51  <[GregNoel](GregNoel)>     keep trying 
19:22:56  <garyo-home>   sorry, 3rd try: 1285 is dup of 1268 
19:23:01  <garyo-home>   yes, that one was right. 
19:23:04  <garyo-home>   :-) 
19:23:31  <stevenknight> okay, dup 1268 
19:23:40  <[GregNoel](GregNoel)>     done 
19:23:43  <garyo-home>   I just marked it as dup. 
19:24:50  <garyo-home>   1287: 
19:25:10  <stevenknight> yow, patch that's been hanging around way too long 
19:25:17  <garyo-home>   I think copying the attributes is the right idea. 
19:25:25  <stevenknight> yeah, sounds exactly right 
19:25:32  <stevenknight> shouldn't be too hard to cook up a test case 
19:25:43  <stevenknight> give it to me, p2, 1.2 or 1.x 
19:25:44  <stevenknight> ? 
19:25:53  <[GregNoel](GregNoel)>     your choice 
19:25:57  <garyo-home>   your choice 
19:26:17  <stevenknight> 1.2 
19:26:18  <[GregNoel](GregNoel)>     done 
19:26:48  <[GregNoel](GregNoel)>     1290 
19:26:48  <garyo-home>   1290: I think scons used to write the .sconsign incrementally 
19:26:58  <garyo-home>   maybe it does again now? 
19:27:22  <garyo-home>   Anyway we are better about signal handling so it rarely fails to update the .sconsign 
19:27:36  <stevenknight> yeah, i think we could WONTFIX it 
19:27:37  <garyo-home>   I think it's invalid due to better signal handling now 
19:27:45  <garyo-home>   WONTFIX is ok 
19:27:48  <[GregNoel](GregNoel)>     done 
19:27:52  <stevenknight> done 
19:28:00  <stevenknight> 1293: 
19:28:05  <[GregNoel](GregNoel)>     1293 
19:28:41  <stevenknight> probably research, me again... :-/ 
19:28:57  <garyo-home>   or me, at least I could try to repro it quickly 
19:29:07  <garyo-home>   I have a D drive 
19:29:23  <stevenknight> garyo, go for it 
19:29:41  <garyo-home>   ok 
19:29:44  <[GregNoel](GregNoel)>     done (Steven has too many research issues anyway) 
19:29:53  <stevenknight> agreed 
19:29:59  <[GregNoel](GregNoel)>     1211 
19:30:11  <[GregNoel](GregNoel)>     (and this is the last one in this spreadsheet) 
19:30:28  <stevenknight> (yay!) 
19:30:52  <stevenknight> old, seems to be fixed, don't spend time on it, just WORKSFORME and invite re-opening if that's hasty 
19:31:05  <garyo-home>   agree w/ both of you. 
19:31:06  <[GregNoel](GregNoel)>     worksforme! 
19:31:34  <stevenknight> excellent work tonight, gents 
19:31:39  <garyo-home>   yes 
19:31:41  <[GregNoel](GregNoel)>     OK, we've settled on 17h00 in two weeks? 
19:31:50  <stevenknight> 18h30 ? 
19:31:54  <[GregNoel](GregNoel)>     oops, 17h30? 
19:32:08  <garyo-home>   I think it was 18h30 PDT 
19:32:10  <stevenknight> 18h30 ? 
19:32:56  <[GregNoel](GregNoel)>     Uh, I'll have to scroll back, ah, ok, I was arguing for 17h30, but I guess I kept mistyping it 
19:32:58  *      jrandall (n=[]( has joined #scons 
19:33:03  <[GregNoel](GregNoel)>     Hi, Jim 
19:33:14  <garyo-home>   ok, see you then guys.  Hi, Jim! 
19:33:30  <[GregNoel](GregNoel)>     We assigned you a bunch of issues, Jim 
19:33:32  <jrandall>     hello - I seem to be somewhat late to the party 
19:33:37  <stevenknight> okay, see you later, gary 
19:33:41  <[GregNoel](GregNoel)>     Yes, just ending 
19:33:43  <garyo-home>   l8r 
19:33:48  <stevenknight> hey jim -- better late than never, though 
19:33:49  <[GregNoel](GregNoel)>     g'night 
19:34:31  <jrandall>     I'll check the log for the summary.  More quoting stuff? 
19:34:38  <stevenknight> yep 
19:35:17  *      garyo-home has quit ("[ChatZilla](ChatZilla) 0.9.83 [Firefox 3.0.3/2008092417]") 
19:35:38  <[GregNoel](GregNoel)>     And there's a comment in the spreadsheet about a possible strategy to deal with quoting 
19:35:52  <jrandall>     Nice - I'll check that out right now 
19:36:23  <jrandall>     Current issues sheet? 
19:37:14  <[GregNoel](GregNoel)>     no, 2005h2 issue 1268 
19:37:20  <jrandall>     Is the intent of scons to expose the host quoting scheme? 
19:37:39  <[GregNoel](GregNoel)>     I'd argue not 
19:38:02  <[GregNoel](GregNoel)>     in fact, I'd suggest using shlex to crack incoming strings 
19:39:12  <jrandall>     The "quoting model" was kind of the fundamental question I ran into. 
19:39:20  <jrandall>     And was unable to decide which I'd prefer.  
19:39:47  <jrandall>     The "host quoting scheme" seemed to be what I'd naturally assume, but that's tough on the project independance 
19:40:44  <[GregNoel](GregNoel)>     Yes, but there are so many incompatible schemes on DOS, so I'd prefer to pick one that's consistent and just go with it 
19:41:13  <[GregNoel](GregNoel)>     not to mention that Python has built-in support for Bourne-style shell quoting 
19:42:25  <jrandall>     So suggestion would be to use bourne-style shell quoting for all scons commands? 
19:42:47  <jrandall>     or one scheme, whatever it may be, on all host platforms? 
19:43:32  <[GregNoel](GregNoel)>     we do something similar for [ParseConfig](ParseConfig); the input is assumed to be GNU-style flags, which are placed in the right variables so they're usually "translated" to the native format 
19:44:27  <[GregNoel](GregNoel)>     not sure I understand your distinction between SCons commands and one scheme for all 
19:45:06  <jrandall>     wasn't trying to distinguish - rather tired, and not speaking well :) 
19:46:23  <[GregNoel](GregNoel)>     Yeah, I understand that---I've been getting up at 2am (PDT) the past few days, so this is well past my bedtime... 
19:46:24  <jrandall>     two approaches seem to be "crack into tokens, we control the quoting",  or  "foist quoting onto the host platform, never try to bust up strings" 
19:46:36  <jrandall>     That's a bit on the early side :) 
19:47:11  <jrandall>     The latter seems less fraught with peril, and probably more compatible with existing practice, but not as nice cross-platform 
19:47:50  <[GregNoel](GregNoel)>     It's a long story, but the short is that it's 110+ during the days right now, so we agreed that our contractors could get here at a ghastly hour to start work. 
19:48:13  <jrandall>     ouch. 
19:48:36  <jrandall>     I'm not sure exactly what 110+ translates to in celsius, but I'm pretty sure it's damn hot :) 
19:49:17  <[GregNoel](GregNoel)>     "less fraught with peril" is my motivation.  I think consistent and predictable is the win here. 
19:49:52  <[GregNoel](GregNoel)>     over 44 degrees 
19:50:29  <jrandall>     Aye.   There seems to be an endless supply of quoting issues.   As per the comment on 1268, that pretty much summarizes what needs to be able to be done if subst_list is oging to work 
19:50:56  <jrandall>     and if we can't crack into a list of tokens like that, then almost have to not rely on subst_list 
19:50:59  <[GregNoel](GregNoel)>     Yeah, I saw your comment about that, but I haven't looked at it yet 
19:51:46  <jrandall>     Part of while tempfilemunge is such a bug magnet is that it's built on subst_list, which likes to bust strings on spaces. 
19:52:46  <jrandall>     so it either has to be able to understand quoting or not be used in tempfilemunge.   Some other quoting problems in a similar vein 
19:53:21  <jrandall>     it == subst_list in previous sentence :) 
19:53:50  <[GregNoel](GregNoel)>     ambiguity, thy name is pronoun... 
19:55:57  <[GregNoel](GregNoel)>     Anyway, it looks like I have to go; can you drop me a line about this?  I'd like to see if we can come up with a spec to describe it, particularly as we make the move to subprocess, which will make all of the quoting issues go critical again. 
19:56:19  <jrandall>     Sure thing.  see you 
19:57:19  <[GregNoel](GregNoel)>     (Subprocess takes a list of strings, which are assumed to be pre-quoted, and figures out how to get them run.  If we can figure out how to create that list of strings, we win big.) 
19:57:34  <[GregNoel](GregNoel)>     Yes, the wife is calling...  cul. 
19:57:46  <jrandall>     Hrm, a good reason to stick with the list approach. 
19:57:47  <jrandall>     see you. 
19:58:39  *      jrandall (n=[]( has left #scons