IrcLog2008 10 15

William Deegan edited this page Jan 14, 2016 · 2 revisions
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 

Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.