-
-
Notifications
You must be signed in to change notification settings - Fork 320
IrcLog2008 10 15
William Deegan edited this page Jan 14, 2016
·
2 revisions
17:56:53 * garyo-home (n=[[email protected]](mailto:[email protected])) 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=[[email protected]](mailto:[email protected])) 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. [http://scons.org/wiki/GaryOberbrunner?action=AttachFile&do=get&target=SCons-talk-2008.pdf](http://scons.org/wiki/GaryOberbrunner?action=AttachFile&do=get&target=SCons-talk-2008.pdf)
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=[[email protected]](mailto:[email protected])) 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=[[email protected]](mailto:[email protected])) has left #scons